Specline canon 2.8.0 Reference Docs For agents ↗
07 · Building

Building: the implementer and the goal

Once you ratify the spec — approve it by merging to main — 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. It doesn't need you in the room, because everything it needs to decide is on the page or in the repo.

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 to establish 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

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:

BrakeAxisWhat it catches
loop_budgetProgress — cycles with no advanceThrashing. It's the PO's autonomy grant, set at ratification: how long the build may run unattended before calling you.
stale_afterTime — wall-clock since the build openedAbandonment. A build left open too long, regardless of progress.

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.

Reference: frontmatter fields (loop_budget, stale_after) and the acceptance altitudes — where provable is defined.