Explanation
The coder and verification¶
When a chat asks for something built, the lead hands the objective to the coder: an agent with a context of its own, the coding model of the active setup, and the workspace tools. This page explains how a build stays honest — how it continues across the model's limits, how it verifies its own work, and what "done" means.
A build is one visible thing¶
The coder works in the chat's workspace, and its steps appear in the transcript as receipts under one progress card that updates in place. A build is never moved to a background path because it is long, crosses a token boundary, or reaches a count of turns; it ends on verified completion, a real blocker, your Stop generating, watchdog-confirmed idleness, or genuine non-convergence.
Continuation across the model's limit¶
A coder session is bounded by its model's window. When it fills, the coder continues in a fresh session from a checkpoint: an authoritative snapshot of the workspace — the file tree and versions, the latest diagnostics, tests and command results — plus the retained recent rounds and every unresolved observation, in order, with the original objective first and the current work after it. The checkpoint is fitted like any request, with the same materialiser and token count, and oversized evidence is stored whole in the workspace's evidence with its path and hash rather than trimmed. Nothing the coder saw is summarised into prose it might misread as done.
Convergence¶
Progress means a changed deliverable tree or file set, or a changed authoritative syntax, diagnostic, test, command or render result. Browser clicks, screenshots, page loads and narration are not progress by themselves. A build stops for non-convergence only when the exact same remaining work is reported twice with the same authoritative progress state — never lowercased, renumbered or truncated for comparison. Elapsed time and continuation counts are never proxies.
Verification is evidence, not a claim¶
The coder verifies its own deliverable with the tools everyone else uses: it runs the project's discovered build and test commands in the sandbox, reads the diagnostics from language servers, opens a web app in the built-in browser, interacts with it and looks at the result. A test tool reports exactly which discovered command ran; a missing language server degrades to an explicit "unavailable" state, never to silence.
Verification also has a clean mode: the build and tests run against a clean checkout of the workspace's committed tree in a verification directory, so an accidental dependency on an untracked file cannot pass. The evidence gate accepts a build only when every selected suite passes cleanly, with the tree's object id and the commands' full output attached.
A deliverable is never described as complete while trusted verification is stale, failed, incomplete or still running. Semantic code review is a separate, explicit workflow, not a completion gate.
Ready, not just loaded¶
A runnable app found during coding is a candidate, not an artifact. The lifecycle is explicit — Building, Testing, Ready, with Failed or Needs attention as honest ends — and the final artifact is not shown until the authoritative tests, the browser verification and any workspace sync have succeeded. An iframe's load event means the document loaded, not that the app works.
Application previews are frozen copies. Direct edits by the lead use the same snapshot store as coder edits: after checking the behavior, the lead presents the current application manifest or its declared entrypoint. Nawa checks the copied application in the browser and confirms that its contents still match the workspace before publication and completion. An existing preview reference opens that historical copy; its presentation result reports any differences from the current workspace. It does not silently replace the old version.
Repairs¶
Repairs are atomic: one root cause, the smallest edit, a reread of the changed region, and the relevant syntax or runtime check before anything further. Speculative features are not stacked on an unresolved regression. Readable, formatted, modular source is preferred, and a one-line file is reformatted before a line-based edit is attempted on it.
Why¶
A model's report that something works is the cheapest thing it can produce, and the least reliable. Every rule above replaces a claim with an observation the harness can make — a command's exit code, a diagnostic, a rendered page — or with a comparison of authoritative states. The rules themselves are recorded in AGENTS.md (Work model, Artifact delivery lifecycle, Coder and verification reliability), and the measurements in docs/coder-checkpoint-headroom-2026-09-14.md, docs/visual-verification-guidance-2026-09-15.md and docs/repeated-observation-convergence-2026-09-20.md.