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 saved for that chat, 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.

Watching a result change¶

The coder can test a component directly, then verify the requested behavior from its normal starting state. For a background export, the end-to-end check can watch for a download link after the user starts the export. For a self-playing game, it can watch the floor counter from a fresh launch without pressing any keys.

One browser watch can observe a visible label, a URL, or a value the page exposes. When it samples a value over time, the result includes timestamped changes. The coder can specify a finish condition, a time limit, and an interval after which an unchanged value counts as stalled. A timeout or stall reports the last observation. A watch that simply reaches the end of its observation window establishes only what happened during that window.

In one Torchlight playtest, a single watch recorded ten status changes and returned when the hero reached Floor 2 after 34 seconds. A separate fresh browser observed the same transition on the visible HUD with no input. The first build had stayed on Floor 1 for six minutes, so the game needed a repair before it passed. The complete build and repair took more model calls than the earlier verified build.

Handoff and completion¶

Main passes the full request, constraints and test expectations to the coder. The coder owns workspace inspection and implementation planning, so Main need not design the whole implementation before handing it over. Tool calls can carry public progress messages; whether those messages appear still depends on the model's response.

When an agent makes the same tool call several times in a row and receives the same observation, Nawa tells it how many times that happened. This feedback also reaches Main and other specialists. The agent can use the observation to take another step or explain what is blocking progress. It can still poll a pending operation or repeat an action whose effect is needed more than once.

The coder must call finish_coding with its completion result. A plain-text claim of completion is not a substitute. Nawa gives corrective feedback when that call is missing and stops repeated missing-tool responses with an explicit result. If a model prints a tool request as JSON in its answer, recovery asks for a supported native tool call; it does not execute arbitrary answer text as a command. Server support for tool calling still matters.

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¶

During development the coder can test individual parts with controlled inputs. For the final check it exercises the requested outcome through the normal entry point from the intended starting state. A test that jumps directly to a later state can verify that state in isolation. A workflow that promises to reach it automatically needs an end-to-end observation of that transition. The coder reuses checks that still apply and can watch a meaningful progress value in one bounded browser wait.

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.