# Solana adaptive work-block architecture Status: design proposal; implementation is intentionally frozen Baseline: `c10d9f6bb8ac79efc94a9bd212e7be5d69531065` Purpose: define the complete target architecture before changing Solana runtime code ## 1. The outcome Solana accepts one goal and keeps moving toward it without routine human checkpoints. It converts the goal into small independently verifiable work blocks, sends every block through only the capabilities it needs, preserves useful accepted work, adapts when evidence disproves the current plan, and retires changes through one authoritative integration boundary. The target is not an agent chat room. Sol and Luna are replaceable reasoning and implementation providers inside a deterministic system. They may propose plans or produce candidates; they never own project truth, locks, retries, acceptance, or Git authority. The architecture must serve both extremes: - A tiny correction becomes one work block and immediately enters the pipeline. - A huge product becomes a durable goal tree whose near-term epics are recursively expanded into work blocks over many planning horizons. There is one execution model. A direct task is a graph containing one leaf, not a second runtime. ## 2. Binding design decisions 1. **The runnable primitive is a WorkBlock.** Frontend, backend, bug fixing, design, and release are capability needs, not separate orchestration systems. 2. **The complete goal and the current strategy are different objects.** The goal contract preserves intent; the strategy, epics, chunks, routes, and implementation choices may change. 3. **All runnable work uses one five-stage safety pipeline:** fetch, decode, execute, verify, retire. 4. **Only one Workspace Authority may mutate one authoritative repository.** Many planners, workers, verifiers, or remote Solana nodes may produce immutable proposals and candidates around it. 5. **Accepted history is never rewritten.** Before retirement, bad work may be discarded. After retirement, correction is a forward-fix with new artifact versions. 6. **Planning is rolling and recursive.** Solana keeps the complete outcome visible but fully details only the next one or two milestones and a bounded ready buffer. 7. **Adaptation is evidence-driven and versioned.** Failed tests, performance measurements, stale contracts, and resource pressure may trigger a local graph rewrite; model preference alone may not. 8. **Three Luna implementation lanes are the initial ceiling on this computer.** The actual number is reduced when work conflicts or machine pressure requires it. 9. **The target throughput benchmark is 20,000–40,000 accepted implementation-and-test lines per 12 hours for a suitably parallel greenfield build.** It is an observed capacity metric only, never an optimization objective, worker quota, completion gate, or reason to discard useful work. 10. **The first implementation remains one process and SQLite.** No microservices, graph database, workflow DSL, message bus, or distributed consensus is needed to prove this design. ## 3. Mental model ```text operator goal | v Goal Contract + Requirement Ledger <-------------------------------+ | | v | coarse goal tree: product -> epics -> milestones | | | v | expand only the next useful horizon | | | v | small WorkBlocks + dependency/artifact graph | | | v | Fetch -> Decode -> Execute -> Verify -> Retire | | | | | | context Luna tests/Sol one Git authority | | | | | | +----------+----------+----------+ | evidence | | | v | Observe -> diagnose -> adapt strategy -------------+ ``` The CPU comparison is useful and exact enough to guide implementation: | CPU concept | Solana concept | |---|---| | Instruction | WorkBlock | | Program/dependency graph | Goal tree plus WorkGraph | | Decode | Context packet and capability-path construction | | Execution unit | Luna, Sol reviewer, test host, browser, or deploy adapter | | Scoreboard | ResourceBroker and versioned claims | | Register renaming | Isolated Git worktrees and immutable candidates | | Reorder buffer | IntegrationQueue | | Retirement | Authoritative integration after accepted evidence | | Branch recovery | Selective graph revision and descendant invalidation | Several blocks may occupy different stages simultaneously. Only retirement changes authoritative source. ## 4. The five architectural planes ### 4.1 Authority kernel Deterministic code owns all durable truth: - goal and requirement revisions; - epic and WorkBlock state; - artifact versions and dependency edges; - priorities, leases, budgets, and attempt identity; - candidate and evidence identity; - graph revisions and invalidation; - integration ordering and authoritative Git movement; - crash recovery and read-model projection. The authority kernel does not decide product taste or write application code. ### 4.2 Planning plane Sol/high operates read-only and proposes: - the Goal Contract; - requirement classification and proof obligations; - the coarse epic map; - architecture and interface artifacts; - the next expansion bundle; - a WorkBlock's capability needs and acceptance contract; - local strategy revisions when evidence invalidates the current plan; - independent semantic, architecture, security, or visual judgments. Every proposal passes deterministic admission. Sol cannot create lifecycle states, omit required outcomes, spend ungranted resources, or accept its own work. ### 4.3 Execution plane Luna/xhigh receives one admitted WorkBlock packet and writes only inside an isolated attempt worktree. Host code seals the exact allowed change into an immutable candidate. Luna has no commit, merge, scheduler, retry, or acceptance authority. ### 4.4 Evidence plane The evidence plane runs deterministic commands, browser/device flows, performance checks, security checks, and fresh Sol review when policy requires it. Evidence always names the candidate, input versions, tool version, environment, and consumer. ### 4.5 Query and control plane A read model exposes the truthful goal tree, active graph, pipeline stages, requirements, resources, failures, evidence, and releases. The future Hermes agent talks to this API and submits goals or revisions through the same policy boundary; it never bypasses the authority kernel. ## 5. Core durable objects | Object | Purpose | Mutable rule | |---|---|---| | `GoalContract` | User intent, required outcomes, non-goals, quality thresholds, authority, release boundary | New version only | | `Requirement` | One traceable must/should/could outcome and its proof obligation | Status changes; meaning changes by revision | | `Epic` | A non-runnable outcome container that may be expanded | Children may be revised until accepted | | `WorkBlock` | One runnable, independently verifiable outcome | Contract sealed at admission; replacement creates a new block | | `ArtifactVersion` | Versioned contract, design, schema, candidate, package, or other consumed output | Immutable | | `Attempt` | One bounded execution try for one WorkBlock | Append-only lifecycle | | `Candidate` | Host-sealed Git commit or non-code artifact set | Immutable | | `EvidenceSet` | Reproducible proof tied to one candidate and environment | Immutable | | `Lease` | Temporary authority to use a logical or physical resource | Deterministic state transitions | | `IntegrationJob` | A retirement request for one accepted candidate | Exactly one terminal receipt | | `GraphRevision` | Atomic record of added, superseded, or rerouted future work | Immutable | | `GoalRevision` | Evidence-backed change in strategy or allowed scope | Immutable and fully diffed | SQLite stores these objects initially. Git stores product source and durable human-readable checkpoints. Large captures and packages may move to a content-addressed artifact directory later, but SQLite retains their hashes and lineage. ## 6. Goal contract and requirement ledger The Goal Contract separates hard intent from adjustable execution choices. ```yaml goal: intent: "the durable user-visible outcome" must: [] should: [] could: [] nonGoals: [] qualityThresholds: [] releaseBoundary: "local | preview | production | packaged artifact" authority: {} runPolicy: "until_goal | bounded" optimizationOrder: - correctness - safety_and_security - required_user_value - named_performance_thresholds - maintainability - optional_scope - visual_polish ``` The exact optimization order may be product-specific, but hard safety and explicit must requirements cannot be silently traded away. Every requirement receives a stable identity and contains: - priority: `must`, `should`, or `could`; - observable acceptance statement; - one or more terminal proof types; - owning epic IDs; - covering WorkBlock IDs; - accepted evidence IDs; - current state: uncovered, planned, active, proven, superseded, or bounded exception. The coverage invariant is binding: ```text coverage(parent epic) = union(coverage(children)) ``` An expansion that loses a requirement is rejected. A project cannot complete while a must requirement lacks accepted terminal evidence. ## 7. Adaptive goals without dishonest goal drift Solana may freely change **how** it reaches the goal. It may not secretly redefine success because the current approach is difficult. There are three revision classes: ### 7.1 Strategy revision No user-visible requirement changes. Solana may: - split or merge future chunks; - reorder work; - select a different library, algorithm, data structure, architecture, or design implementation; - add a diagnostic, research, benchmark, compatibility, or migration block; - reroute a block through different capabilities; - replace an unaccepted candidate; - alter concurrency or resource use. These revisions are automatic when deterministic admission proves requirement coverage is unchanged. ### 7.2 Scope-equivalent goal revision The user-visible result remains equivalent, but wording, architecture boundaries, or proof strategy changes. Sol proposes a requirement-to-requirement mapping. The controller admits it only when every old must requirement maps to an equal or stronger new requirement and terminal proof. Example: replacing a custom tab persistence format with SQLite is scope-equivalent if restart recovery, migration, and performance requirements remain satisfied. ### 7.3 Degrading revision A requirement is dropped or weakened only to preserve a harder product requirement, remain within an explicit authority or resource boundary, or satisfy a product performance threshold named in the Goal Contract. This is legal only for `should` or `could` requirements, or through a fallback already allowed by the Goal Contract. The revision records exactly what was removed and why. Engineering-throughput measurements such as accepted lines per hour never authorize this revision. A must requirement may never disappear while the project reports `complete`. If it is genuinely impossible under standing authority, Solana delivers every unaffected result and reports `complete_with_bounded_exceptions` or `blocked_external` with evidence. This gives Solana permission to replace optional product behavior only when the actual product contract requires the tradeoff. It does not permit scope removal merely to make Solana's build-rate measurements look better. ## 8. Recursive goal compilation The compiler operates in seven steps. ### Step 1: normalize the request Sol inspects the repository and converts the operator request into a proposed Goal Contract and Requirement Ledger. Deterministic admission verifies identity, authority, budgets, non-empty proofs, and no contradictory must requirements. ### Step 2: create a coarse outcome tree Sol proposes approximately three to twelve epics for a large product. Epics describe outcomes and interface boundaries, not file-level tasks. A tiny goal may skip this step and propose one leaf directly. ### Step 3: establish high-fan-out contracts first Schemas, public APIs, navigation grammar, design foundations, security boundaries, and other consistency spines become versioned artifacts before wide implementation fan-out. ### Step 4: select a rolling horizon The controller selects the next one or two milestones from dependency order, critical-path unlock value, risk, and user priority. Solana does not fully detail months of uncertain work. ### Step 5: expand recursively Sol returns an `ExpansionBundle` containing two to eight children, coverage mappings, dependencies, ownership domains, acceptance obligations, estimates, and capability needs. Each child is either another epic or a WorkBlock. If a proposed leaf fails the fit gate, deterministic admission returns exact reasons and Sol splits it again. Every accepted split must reduce at least one measured dimension: outcome count, write-domain count, unresolved decisions, source surface, dependency uncertainty, verification surface, or expected duration. ### Step 6: admit a ready buffer Keep roughly six to twelve admitted leaves ready or near-ready for three Luna lanes, with a hard initial ceiling of twenty-four detailed active leaves. This prevents worker starvation without building a stale thousand-node plan. ### Step 7: roll the horizon After retirement and milestone proof, Solana updates requirement coverage, compacts accepted detail into a checkpoint, expands the next epics, and continues until terminal proof covers the Goal Contract. Planning one expansion bundle may define several blocks. Sol is not called once for every trivial packet field; deterministic code fills pinned versions, repeated policy, command restrictions, and resource metadata. ## 9. WorkBlock contract and fit gate A WorkBlock contains only the context needed for one outcome. ```yaml identity: projectId: blockId: parentEpicId: graphRevision: outcome: statement: requirementIds: [] userOrSystemValue: inputs: integrationHead: contractVersions: [] artifactVersions: [] ownership: primaryWriteDomain: allowedPaths: [] readClaims: [] writeClaims: [] exclusiveResources: [] route: capabilities: [] riskFlags: [] acceptance: assertions: [] workerCommands: [] trustedChecks: [] requiredEvidence: [] budget: targetMinutes: hardMinutes: maxImplementationAttempts: exclusions: [] ``` Hard fit rules: 1. one observable outcome; 2. one primary write domain; 3. exact accepted input versions; 4. no unresolved architecture, interface, product, or visual-foundation decision; 5. independent acceptance; 6. explicit exclusions; 7. one known retirement destination; 8. two to six concrete assertions; 9. a bounded attempt, normally ten to thirty minutes and never planned above sixty; 10. a context packet small enough that Luna can locate the first relevant edit without broad repository exploration. Planning heuristics, not hard success gates: - usually one to five files; - usually fifty to three hundred changed lines; - handwritten files should average two hundred to four hundred logical lines within a module; - a handwritten file above five hundred lines triggers review, not automatic rejection; - mechanical migrations may be larger when deterministic transformation and proof are exact. Do not create one block per CSS property, one block per trivial function, or several blocks that are useless until all are combined. Small means cohesive and independently useful, not microscopic. ## 10. Capability paths instead of frontend/backend modules The initial capability catalog is intentionally small: | Capability | Typical executor | Product writes? | |---|---|---:| | `inspect.repository` | deterministic index plus Sol | no | | `research.external` | Sol with allowed network tools | no | | `diagnose.failure` | deterministic evidence plus Sol | no | | `spec.interface` | Sol proposal, controller-persisted artifact | no | | `spec.visual` | Sol proposal, controller-persisted artifact | no | | `implement.code` | Luna | yes, isolated | | `verify.commands` | worker then trusted host | no product writes | | `verify.browser` | trusted browser harness | no product writes | | `review.semantic` | fresh Sol | no | | `review.security` | deterministic checks plus fresh Sol | no | | `package.artifact` | deterministic adapter | frozen output only | | `deploy.target` | deterministic authorized adapter | external side effect | A compile-time registry maps each capability to a typed module contract. This is not a general workflow language. Adding a capability requires a real consumer, independent fixture, isolated failure need, and measured value. Sol proposes the minimum path. Deterministic policy may add mandatory capabilities but may never remove a required safety gate. | Observed block property | Mandatory path additions | |---|---| | Existing bug | reproduce failing behavior before implementation; regression proof after | | Visible UI write | accepted visual foundation, browser behavior, responsive matrix, visual review at the required risk boundary | | Public API change | versioned interface artifact and consumer compatibility proof | | Authentication, authorization, secrets | threat assumptions, security checks, fresh security review | | Data/schema migration | forward test, rollback proof, compatibility window, data-integrity checks | | Named performance target | reproducible baseline, benchmark threshold, regression evidence | | External deployment | frozen commit, standing authority, deployment lease, smoke proof, rollback proof | | Copy/config-only change | focused implementation and affected check; no unnecessary architecture or visual-foundation ceremony | Examples: ```text small UI correction inspect -> implement -> focused build -> browser/responsive proof -> retire API defect reproduce -> diagnose -> implement -> regression/API proof -> retire password reset feature interface contract -> backend implementation -> API/security proof -----+ -> UI implementation -> browser/a11y proof ----------+-> integration proof -> retire release frozen milestone -> package -> platform/security checks -> deploy -> smoke/rollback proof ``` ## 11. The five-stage pipeline ### Fetch The scheduler selects the highest-value ready WorkBlock whose dependencies, input versions, write claims, physical resources, provider slots, and machine capacity are compatible. ### Decode The context builder resolves exact files, symbols, contracts, tests, prior failure evidence, design artifacts, and the capability path. It seals a bounded implementation packet. If inputs changed, the block returns to planning before a worker starts. ### Execute The selected executor runs in isolation. Code-writing blocks use Luna in a fresh worktree. Host code validates the reported diff, rejects out-of-scope paths, and seals a deterministic candidate commit. ### Verify Only relevant checks run for the leaf, followed by policy-required browser, security, performance, or fresh Sol review. Verifier transport errors retry against the same sealed candidate; they never trigger a code rebuild. ### Retire The sole IntegrationQueue rechecks lineage, contracts, claims, and combined behavior. It integrates one candidate or a compatible same-base batch, advances the authoritative head exactly once, records the receipt, and updates requirement coverage. Each stage is durable and independently testable. A controller crash resumes the incomplete stage by idempotency key rather than restarting the entire block. ## 12. Dependencies and hazards - **Read after write:** a consumer waits for the exact accepted producer artifact version. - **Write after write:** two cooperative writers to the same consistency domain cannot execute concurrently. - **Write after read:** a block may read immutable version `vN` while a writer prepares `vN+1`, but retirement rechecks the pinned version and may require re-decode or re-verification. - **Structural hazard:** browser, device, build, GPU, port, deployment, and provider slots use physical leases. - **Plan hazard:** an invalidated contract supersedes only descendants that consumed its version. - **Retirement hazard:** only one authority mutation runs per workspace; disjoint same-base candidates may form one deterministic batch. Isolated worktrees permit speculative implementation without granting repository authority. Version checks make speculation safe. ## 13. Scheduling, fast fixes, and worker count The initial local limits are: | Resource | Initial limit | |---|---:| | Luna implementation workers per active workspace | 3 | | Sol planning transaction per project | 1 | | Browser automation session | 1 | | Integration/retirement mutation per workspace | 1 | | Deployment mutation per target | 1 | Three is a ceiling, not a promise. The scheduler runs fewer workers when fewer disjoint blocks are ready, memory pressure is high, the provider is constrained, or verification/integration backlog is growing. Priority classes are: 1. `interrupt`: a new urgent correction against an active long build; 2. `foreground`: the operator's current requested outcome; 3. `background`: long-horizon continuation; 4. `maintenance`: cleanup, indexing, cache, and optional debt. Within a class, deterministic scoring uses critical-path unlock value, number of descendants unlocked, age, deadline, scarce-resource wait, and estimated duration. Weighted fairness and age prevent background starvation. When at least two Luna slots exist, one slot is reservable for interrupt or foreground work. If no such work is waiting, background work may borrow it. A same-workspace quick fix does not kill a healthy Luna process mid-edit. Solana: 1. stops dispatching new overlapping background blocks; 2. lets active blocks reach the next safe seal boundary; 3. runs the quick fix from the current authoritative head; 4. retires it first; 5. rechecks waiting candidates; 6. keeps disjoint candidates, re-decodes compatible stale ones, and creates bounded repair/rebase blocks for overlaps; 7. resumes the long build. ## 14. Adaptive chunk and strategy controller The controller continuously compares expected and observed evidence: - attempt duration and progress heartbeat; - first-pass acceptance rate; - repeated failure category; - context size and files inspected before the first edit; - test and integration wait; - benchmark or product threshold misses; - resource conflicts and machine pressure; - requirement coverage and critical-path movement. When evidence says the current plan is wrong, the adaptation ladder uses the cheapest valid change first: 1. retry a failed transport against unchanged inputs; 2. repair the sealed candidate using precise rejection evidence; 3. split the failing block; 4. reroute it through a diagnostic, contract, design, security, or performance capability; 5. replace the dependency, library, algorithm, or local implementation strategy; 6. revise the affected epic architecture or interface version; 7. remove or simplify optional scope under the Goal Contract's optimization policy. Two materially identical failures may not trigger a third identical implementation attempt. The next revision must reduce scope, add evidence, or change strategy. Adaptive graph rewriting is atomic. A proposal must include: - triggering evidence; - blocks and artifacts affected; - requirement coverage before and after; - blocks preserved, superseded, split, or added; - version changes; - resource and budget effect; - new terminal proof path. Admission rejects cycles, lost must requirements, edits to accepted history, unsafe cancellation of a live lease, duplicate ownership, or a revision that does not reduce the observed failure. ## 15. Preserving and discarding previous work Previous work is classified instead of treated as all-or-nothing: | State of prior work | Adaptation behavior | |---|---| | Accepted artifact still version-compatible | Reuse directly | | Accepted artifact interface-compatible but environment changed | Reverify only | | Sealed candidate contains useful compatible work | Base bounded repair or salvage on the candidate | | Candidate is out-of-scope, unsafe, or based on invalid lineage | Discard and restart from accepted head | | Planned or ready descendant consumed a superseded artifact | Supersede and regenerate only that dependency closure | | Running descendant is now stale | Let it seal safely, then salvage or reject by exact version check | | Already-retired implementation is no longer wanted | Add a forward removal/migration block; never reset history | | Independent sibling is unaffected | Continue normally | Discarded candidates remain content-addressed for audit and possible salvage but never count as product completion. Sunk work has no authority over the best forward strategy. A throughput shortfall alone is never evidence that useful work should be discarded. ## 16. Continuous verification without killing throughput Continuous testing means evidence moves alongside implementation, not that the entire repository suite runs after every ten-line change. | Level | When | Typical proof | |---|---|---| | Leaf | Every candidate | syntax, typecheck subset, focused unit/behavior test | | Integration batch | Every retirement batch | union of affected tests and contract checks | | Milestone | Accepted vertical product slice | broader system, browser, security, performance, fresh Sol review | | Release | Frozen release candidate | full required platform matrix, packaging, deploy smoke, rollback | Tests are selected by explicit acceptance contracts plus a deterministic import/symbol/test-impact map. Any uncertainty expands the check set. Content-addressed results may be reused only when source, dependencies, toolchain, environment, and command match exactly. Visual products receive deterministic viewport and interaction evidence. A small representative screenshot set is paired with a deterministic responsive matrix covering every required viewport, overflow, visibility, and state assertion. ## 17. Throughput design and the 20k–40k target The throughput target is plausible only when the workload is large, greenfield or modular, and contains enough independent accepted write domains. It is not realistic for every security audit, legacy migration, or one-file bug. It is telemetry for evaluating Solana's capacity, not an input to goal adaptation or scheduling priority. One useful capacity model is: ```text 3 Luna lanes x 2 to 3 accepted blocks per lane per hour x 250 to 400 implementation-and-test lines per block = roughly 1,500 to 3,600 accepted lines per hour = roughly 18,000 to 43,000 accepted lines per 12 hours ``` Solana aims for the upper range by: - keeping a ready buffer two to four times the Luna slot count; - expanding several related blocks in one Sol planning bundle; - resolving high-fan-out contracts before implementation fan-out; - assembling repeated packet fields deterministically instead of spending a Sol call per field; - preparing context and warming dependency/build caches while other blocks execute; - using focused leaf checks and broader milestone checks; - batching compatible same-base retirement candidates; - retrying reviewer transport against the same candidate; - using bounded repairs rather than rebuilding a rejected feature from zero; - measuring the actual critical-path bottleneck before increasing concurrency; - scaling execution to remote satellites only after the local three-lane pipeline stays full and correct. The scheduler adapts block size and concurrency with deterministic thresholds: - high idle time with low rejection: expand earlier and permit slightly larger cohesive blocks; - high first-pass rejection: reduce block surface and strengthen decode/contract evidence; - growing verification backlog: slow implementation admission or add verification capacity; - growing integration backlog: stop adding writers and drain retirement; - high resource pressure: reduce weighted slots with hysteresis; - repeated hot-path benchmark failure: force strategy revision rather than polishing the same design. The benchmark reports: - unique accepted handwritten implementation and test lines per hour; - accepted WorkBlocks and proven requirements per hour; - first-pass acceptance and repair rates; - Luna utilization; - planning, queue, verify, and integration wait; - cache hit rate; - discarded and superseded work; - milestone correctness and later regression rate. Generated, vendored, copied, reformatted-only, and duplicated lines are excluded. Deletions are reported separately. Workers never receive a line quota, because that would reward bloat. Missing the benchmark changes which orchestration bottleneck is investigated; it never weakens acceptance, drops product scope, cancels useful work, or changes the definition of complete. ## 18. Huge-project behavior For “build a browser application,” Solana does not give Luna that sentence. A coarse tree might contain: ```text browser product architecture and engine boundary executable shell and navigation tabs and window lifecycle session persistence and crash recovery history, bookmarks, and downloads permissions, privacy, and security accessibility and platform integration packaging, updates, and rollback ``` Only the first useful runnable milestone is expanded. “Session persistence” might eventually produce blocks such as: - define the versioned session record and recovery invariants; - persist the ordered pinned-tab set; - restore it after forced process termination; - expose corrupted-session recovery without startup failure; - prove restart latency stays under the named threshold. Each accepted milestone leaves a runnable product and a compact checkpoint. Later architecture can change without replaying every prior model conversation. A new browser engine or operating system is a portfolio of programs, not one oversized graph. The same architecture scales by adding program-level outcome trees and versioned contracts; it does not make the real engineering or security work disappear. Solana's promise is durable autonomous progress and high useful throughput, not magical completion independent of problem complexity. ## 19. Multiple Solanas working together Scaling occurs in three steps. ### Step 1: one local authority, several local executors The first system uses one process, one SQLite database, one Workspace Authority per active repository, up to three Luna lanes, one browser session, and one retirement queue. ### Step 2: one authority, remote satellite executors A satellite receives a signed, immutable WorkBlock packet containing: - block and attempt identity; - exact repository/base bundle hash; - input artifact versions; - ownership and resource claims; - capability route and policy version; - acceptance and budget; - return endpoint and expiry. It returns an immutable candidate bundle and evidence manifest. It cannot change the graph or authoritative repository. Duplicate delivery is idempotent by attempt ID. A lost satellite lease permits redispatch after the authority proves no accepted candidate exists. ### Step 3: program authority over several workspace authorities For a product spanning repositories or major subsystems: ```text Program Authority shared Goal Contract requirement coverage cross-workspace contract registry release graph | +-- Workspace Authority A -> local/remote block executors +-- Workspace Authority B -> local/remote block executors +-- Workspace Authority C -> local/remote block executors ``` Each workspace retains one retirement authority and may integrate concurrently with other workspaces. Cross-workspace edges consume immutable contract and release artifact versions. A contract revision invalidates only named consumers. Several Sol planners may later propose expansions for disjoint epics against the same graph snapshot. The Program or Workspace Authority admits those proposals one transaction at a time. There is no peer-to-peer shared Git mutation and no need for Raft or a distributed graph database initially. The invariant is simple: many systems may think and execute; one named authority retires each resource. ## 20. Unattended operation Runtime operation contains no routine design or architecture checkpoint. - Ordinary ambiguity triggers repository inspection, bounded research, or a reversible default. - Visual direction is selected by a fresh Sol review against the product-specific visual contract. - Missing implementation detail returns to planning, not to the operator. - Provider limits or daily resource caps create a durable checkpoint and automatic resume, not false failure. - Missing external credentials or irreversible authority finishes every unaffected branch and returns the safest useful artifact. - User feedback after delivery or during a long build becomes a versioned interrupt GoalRevision. - Only explicit cancel, an impossible hard contradiction, unavailable external authority with no safe fallback, or exhausted standing run policy stops useful autonomous progress. Per-block budgets remain strict so one bad task cannot spin forever. Project lifetime is governed separately. An `until_goal` project renews rolling horizons and resumes after temporary capacity limits until terminal evidence satisfies the Goal Contract. ## 21. Control-plane site and future Hermes The site should visualize tested truth from the read model: - goal tree and requirement coverage; - current detailed WorkGraph and artifact edges; - pipeline lanes with blocks in fetch, decode, execute, verify, and retire; - Luna/browser/integration resource occupancy; - priority and quick-fix interruption state; - graph revisions and preserved/superseded work; - candidate evidence and accepted commits; - throughput, first-pass rate, backlog, and bottlenecks; - local and remote Solana nodes when federation exists. The graph must be real SVG or canvas data bound to the runtime, responsive at phone, tablet, laptop, and wide desktop sizes. It must not fake activity. The visual standard forbids full-cap labels, uses neutral sans-serif typography, and follows the already accepted Wobbleby-derived shape and spacing principles with Solana-specific colors. Hermes is later a conversational client over versioned query and command APIs. It may submit a goal, revision, priority change, pause, resume, or cancel request within standing policy. Solana still performs all planning, implementation, verification, and retirement. ## 22. What survives, changes, and leaves the current system ### Preserve - durable SQLite state and transactional compare-and-set behavior; - versioned WorkGraph and artifact dependency checks; - ResourceBroker leases and recovery; - isolated worktrees and trusted candidate sealing; - process-family cleanup and restart evidence; - independent acceptance and visual proof; - IntegrationQueue and exact Git lineage; - Sol/high planning and review with Luna/xhigh product writes; - frozen release evidence and rollback proof. ### Change - replace the capped one-shot GoalPlan with Goal Contract, Requirement Ledger, coarse epics, and recursive ExpansionBundles; - split the fused execute/inspect/verify/integrate runner into durable pipeline stages; - replace hard-coded recipe wiring with a small typed capability registry and deterministic path policy; - replace FIFO project scheduling and fixed priority `10` with goal-aware priority, aging, fast-lane reservation, and machine-capacity admission; - replace whole-workspace execution serialization with granular claims while retaining one retirement authority; - make public project status derive from the actual graph/pipeline state; - fund repair from observed runtime and rejection evidence rather than the original estimate alone. ### Retire after parity - the separate direct runtime; a one-block graph is the fast path; - `long_build` as a special execution recipe; long duration is repeated horizon expansion over normal WorkBlocks; - frontend/backend recipe identity as orchestration structure; those become resource and capability facts; - static module metadata that production never discovers or validates; - duplicated state projections and completion definitions; - any requirement that one initial Sol call fully decomposes a huge project. Nothing is deleted from the accepted baseline until its replacement passes matched canaries. ## 23. Implementation sequence after design approval ### Phase A: planning kernel only Implement Goal Contract, Requirement Ledger, Epic, WorkBlock, ExpansionBundle, fit-gate, coverage, and graph-revision contracts as pure code. Use fixtures and fake Sol outputs only. Gate: tiny UI, cross-stack feature, and browser-scale synthetic goals preserve every requirement, form acyclic graphs, and produce fitted leaves without touching product repositories. ### Phase B: independent path and scheduler simulators Implement the capability registry, mandatory route policy, priority queue, resource compatibility, and machine-capacity policy as pure components. Gate: table tests prove route selection, fast-fix ordering, starvation prevention, write hazard exclusion, and pressure-based worker reduction. ### Phase C: staged single-block engine Introduce durable fetch/decode/execute/verify/retire boundaries behind fake executors and a real Git fixture. Gate: crash after every stage resumes without duplicate execution or duplicate retirement. ### Phase D: one live Sol and Luna canary Run one bounded non-visual block through the new pipeline in an isolated fixture repository. Gate: one Sol expansion, one Luna candidate, focused proof, exact retirement, clean process tree, and truthful terminal state. ### Phase E: adaptive multi-block pipeline Run three disjoint blocks, one dependency chain, one rejection requiring a split, and one foreground quick fix during background work. Gate: three Luna lanes overlap where safe; only affected descendants change; accepted siblings remain; quick fix retires first without killing healthy execution. ### Phase F: real UI and cross-capability canaries Run a visual block and a frontend/API feature using the dynamic capability policy. Gate: responsive behavior, visual proof, contract compatibility, and milestone review pass without hard-coded UI/backend recipe controllers. ### Phase G: throughput and endurance Run a twelve-hour representative greenfield benchmark plus forced restarts, verifier failures, stale candidates, and capacity pressure. Gate: no orphan process, no lost requirement, no duplicate retirement, bounded rework, high Luna utilization, and a measured accepted-throughput report. The 20k–40k range is evaluated honestly, not forced by weakening proof. ### Phase H: satellite seam and program layer Move one executor out of process using immutable packet and candidate bundles, then coordinate two fixture workspaces under one program goal. Gate: loss and duplicate delivery are idempotent; each workspace has one authority; cross-workspace contract invalidation is selective. ### Phase I: migration and product work Shadow the new pipeline against the accepted baseline. Only after parity and measurable improvement may Solana resume FocusUp/Helios work or replace the old authority path. ## 24. Required proof suite The design is not accepted merely because classes and tables exist. It must prove: 1. one tiny request becomes exactly one WorkBlock; 2. a cross-stack feature takes different capability paths for its blocks and reunites through integration proof; 3. a huge goal expands recursively without losing requirements or detailing the entire future; 4. a failed oversized block is split and resumed automatically; 5. a performance miss changes strategy and preserves unaffected work; 6. an optional feature can be removed without weakening a must requirement; 7. a must requirement cannot be silently dropped; 8. a quick fix jumps ahead at a safe boundary; 9. conflicting writers never execute cooperatively at the same time; 10. disjoint work executes in parallel and retires deterministically; 11. verifier failure does not rebuild unchanged code; 12. rejection produces bounded repair or salvage rather than global restart; 13. crash recovery repeats no accepted stage; 14. accepted history is corrected only forward; 15. a remote duplicate result cannot retire twice; 16. project status, site state, events, graph, and integration receipts agree; 17. a twelve-hour run continuously expands, executes, tests, retires, checkpoints, and resumes without human input. ## 25. Anti-overengineering boundary The first accepted version contains: - one control-plane process; - one SQLite database; - one scheduler and ResourceBroker; - one WorkGraph representation; - one integration queue per workspace authority; - one compile-time capability registry; - one Sol planner route and one Luna implementation route; - one Playwright-backed browser contract; - at most three local Luna lanes; - a bounded set of pipeline states. Do not add microservices, Kafka, Temporal, a graph database, dynamic workflow code, peer-to-peer agents, distributed locks, leader election, a vector database, self-modifying policy, or multiple browser stacks during the initial proof. A new mechanism must name the measured failure it fixes, its existing consumer, its independent test, the mechanism it replaces or avoids, and its removal trigger. ## 26. Design acceptance This design is ready for implementation only after agreement on these five points: 1. a one-block goal and a million-line goal share the same WorkBlock pipeline; 2. the Goal Contract remains honest while strategy and optional scope may adapt automatically; 3. one Workspace Authority owns retirement even when many Solanas work together; 4. three Luna lanes, one browser lane, and one retirement lane are the initial local limits; 5. 20k–40k accepted lines per 12 hours is reported as a serious capacity metric only; it never influences product scope, acceptance, completion, or whether useful work is preserved. Until then, Solana remains stopped and no product or runtime source is changed.