Building: the implementer and the goal

Once you approve the spec — your go, recorded in git as the move from docs/drafts/to docs/specs/, on whichever branch the work is on — an implementer agent builds the feature without you in each turn. It can do that because it arrives fully equipped: it has the codebase's standards (conventions/,technical/), the relations graph (what already exists and what's coming), and the spec itself. Almost everything it needs to decide is on the page or in the repo.

Almost. By default a build is attended: you're reachable, so when the build teaches something the contract got wrong, the builder says so in product terms, you agree or you don't, and the spec is edited in the branch. That edit is the record — no status flip, no separate PR, no re-approval ceremony. Declarebuild: unattended and you've made the opposite promise: a builder thatcan't ask has everything it needs. The brakes below belong to that promise; attended, you are the shortest brake there is.

It works toward one thing: the Goal. Intent tells it why the feature exists; the Goal is the destination it converges on. It builds, and then it has toestablish the goal is met — not by hope, but by evidence. Where a runnable check fits the Goal, it runs it and the command settles the question. Where one doesn't, it makes a grounded assessment against the code and its own tool results — evidence, not opinion. A runnable command is the strongest form of that evidence. It is not the required form.

The exit is "the goal is met, grounded in evidence" — not "a suite went green."

That distinction is the whole point of this chapter. The old framing said the build exits when tests pass. But not every goal has a suite that proves it, and a green suite proves only what the suite asserts. So the implementer's exit condition is broader and stricter at once: it builds until it can show the goal is met — running checks where they fit, assessing against the code where they don't — and a passing suite is the strongest evidence of that, never a substitute for it.

The inner loop, and its two brakes (experimental)

Everything below is the unattended build's contract — in force only once a spec declares build: unattended in a repo that has setunattended: true. Attended (the default), there's no loop to run: you're the shortest brake there is, and a contradiction is just a conversation.

The build is a loop, not a single pass. Each iteration resumes from status.md— the loop's memory: the last green checkpoint to start from, and the dead ends not to re-walk — works toward the Goal, and either advances (a check moves red to green, a new checkpoint recorded) or burns a cycle making no progress. It runs autonomously, which means it needs brakes. There are two, and the first to fire hands control back:

Same outcome, different axes, first one wins — a high-stakes feature gets a short leash. When the implementer judges the goal met, it stops and hands to review. The reviewer is deliberately absent from this inner loop: this is the implementer's own word, grounded in evidence. Whether that word holds up is the next chapter's job.