What a Run Does
A coding run is a governed loop, not a chat that happens to write code. It moves through six phases, ends in exactly one of three terminal states, and leaves behind a signed receipt for every diff it applied. The property that makes it trustworthy is simple to state and unusual in practice: the model is never asked whether its own edit worked, the loop reads the compiler and the test suite instead.
This page is the mechanism. For the developer consoles, the coding crews, the pre-commit scan, and the disconnected edge surface, see Software engineering.
The six phases
Figure D3: a coding run. Bootstrap opens one bounded egress window for dependency install (cyan); after it the network is sealed and the run is offline (amber). Verify is deterministic (green), parsed compiler and test output, never the model's opinion. The repair loop returns to Edit until both diagnostics are clean and the suite is green, and the run ends in exactly one of three terminal states.
Table equivalent
| # | Phase | What it does | The honesty property |
|---|---|---|---|
| 1 | Provision | Clone the bound repository into a fresh per-run workspace | A clone that fails, fails the run with the real error: no repair over a tree never checked out |
| 2 | Bootstrap | Install dependencies once, before the first verify, across 7 language families with a monorepo walk | Runs in one bounded egress window authorised by the egress broker; an off-allowlist registry is refused, then the network is sealed |
| 3 | Navigate | Repo map (content-hash cached), root-confined code search, compartment-scoped semantic retrieval | A language outside the supported set is omitted, never faked; retrieval cannot reach another workspace's code |
| 4 | Edit | str_replace (refuses an absent or ambiguous target) and a hunk-verified diff applier, run as an atomic changeset | A failed edit leaves the file byte-for-byte untouched; .. and absolute paths are rejected |
| 5 | Verify | 8 test frameworks parsed into a structured verdict; 7 diagnostics tools in machine-readable mode | The model is never asked whether its edit worked; a framework outside the matrix is an explicit unsupported error, never faked as passed |
| 6 | Repair | Feed the structured failures (files, lines, messages, test names) back and iterate | Clean diagnostics and a green suite are both required for success |
Verify, deterministically
The eight test frameworks, pytest, cargo, Jest, go test, Maven Surefire,
Gradle, dotnet test, and CTest, are each parsed from that framework's real
console shape into a structured verdict, and each parser is exercised on both a
passing and a failing run. The seven diagnostics tools, pyright, tsc,
cargo check, Clippy, go vet, ESLint, and Ruff, run in their machine-readable
modes, so ok is derived purely from parsed diagnostics and a broken build cannot
be mis-read as clean. A non-zero exit always yields a failure.
Three terminal states
A run ends in exactly one of these, never in a fabricated success:
| Terminal state | Meaning |
|---|---|
| Succeeded | Clean diagnostics and a green suite: both required. Clean diagnostics with a failing suite is not success |
| Failed | A clean give-up carrying the last real failures, never a made-up pass |
| Halted by the gate | The net-potential-gain governor evaluated the aggregate (value against tokens, wall-clock, fan-out, and churn) and refused the next iteration's spend, marking the run requeue-recommended |
Throughout, the run keeps a durable plan rather than holding it in the conversation. Because the plan is persisted and replicates, a run that restarts, or is picked up by a peer cell, reconstructs its plan rather than starting over. Runs can be cancelled and resumed.
The signed receipt chain: "the 16th chain"
Every applied diff produces a signed, chained receipt, one more hash-linked chain alongside the platform's other tamper-evident ledgers.
Figure D5: the signed diff receipt chain. Each receipt carries the diff's SHA-256, the who/what/why/as-of-when, a real Ed25519 detached signature over the canonical receipt bytes, and a link to the previous receipt's hash. Verification is stateless and offline, a third party needs only the receipt, the diff text, and the signer's raw public key. A changed diff or any changed metadata field is rejected, and because receipts are chained per run, removing one is detectable.
Table equivalent
| Element | What it carries | Property |
|---|---|---|
| Receipt | Diff SHA-256, actor, reason, as-of-when, previous receipt hash | Signed with a real Ed25519 detached signature over canonical bytes |
| Chain | Receipts linked per run | Removing a receipt breaks the hash link and is detectable |
| Verification | Receipt + diff text + signer's raw public key | Stateless and offline: no database, service, or account |
| Tamper | Any change to the diff or a metadata field | Rejected on verification |
Related topics
- Software engineering: the consoles, coding crews, the pre-commit scan, and the disconnected edge surface.
- Agent Runtime, the sandbox and the durable plan a run relies on.
- Delegation & authority, the seat credentials a crew's fan-out is minted from.
- Security → Cryptography, the Ed25519 primitive behind the receipts.