Review, then accept
Attended (the default), review is a conversation: you read the result and accept it, or send it back. The rest of this chapter — a separate fresh-context reviewer, thejudgeable/tasteable split — is the unattendedbuild's contract, for when there's no PO in the room to ask.
Experimental — in force only when specline.yml setsunattended: true. Off by default; nothing here is checked or listed until you turn it on.
The implementer's word that the goal is met is the start of acceptance, not the end of it. The agent that wrote the code shares its own blind spots, so a separate, fresh-context reviewer checks the work before it reaches you — and then you, the human, make the final call. This is the outer loop, and it's what turns "the implementer thinks it's done" into "this is accepted."
The reviewer judges the implementer's interpretation — not whether the code runs, but whether the build reads the spec the way the spec meant. It works against thejudgeable acceptance checks, each of which names a spec section, and against the repo's standards in conventions/ and technical/ — including the nuanced bars the Goal can't fully state, like performance and security. The named section is what makes its judgment falsifiable: it isn't reviewing on vibes, it's checking the work against a clause someone can point to.
Like the inner loop, the outer loop has a budget: review_rounds_before_human, the number of times the reviewer can bounce work back to the implementer before it stops and hands you the result. The bounce budget gates the transition to you — never the inner loop. When it's exhausted, or the reviewer is satisfied, the work arrives at your gate.
Then you accept — the second human gate, the one nothing else can settle.
The three altitudes are the handoffs (experimental refinement)
Part 1's acceptance checks are one falsifiable list, with anything only you can settle marked under a ### human sub-heading. Unattended, that one list is refined into three altitudes — not three flavors of test, but the handoffs between who certifies done, in order:
| Altitude | Who certifies | How it's settled |
|---|---|---|
| provable | The implementer | Its exit condition — the goal is met, by a runnable command where one fits or by grounded assessment against the code. |
| judgeable | The reviewer | A fresh agent judges the interpretation against a named section and the repo's standards, incl. perf and security. |
| tasteable | You | The final accept — taste, product-fit, anything no check or review can falsify. Settled once, by a person. |
Layered judgment, on purpose: the implementer asserts done and grounds it in evidence, the reviewer independently checks that interpretation, and you accept. Each altitude is a check on the one below it. That's why a stochastic builder's self-report is safe to build on — it's the first word, not the last.
Reference: the acceptance altitudes — provable, judgeable, tasteable, and the handoff each names.