The spec.md body
The build contract's sections, in order. Each carries one kind of thing, and the order runs from the human's why (Intent) down to the loop's mechanical exit (Acceptance checks). Write intent and rules richly; once code exists, it owns the mechanics (B6) — so prescribed mechanics tend to anchor a frontier builder and go stale. It's advice, not a rule: a weaker target or a pre-build spec may carry worked mechanics where they're load-bearing.
Knowing what each section holds — and what belongs in another — is what keeps the contract reviewable in one sitting:
1. Intent
The product outcome in plain language, and the appetite — the one-sitting scope this spec deliberately fits. This is the why, for the human.
2. Goal
A single falsifiable sentence: the observable outcome that means done. The target the autonomous loop converges toward. If you can't state it falsifiably in one line, the feature isn't shaped yet.
3. Non-goals
Explicit. The most valuable section for strong models — it is where over-building is fenced off.
4. Behavior
Observable behaviors, numbered, each verifiable from outside.
5. Business rules
The rules, sorted Must / Should / May.
6. Assumptions
Assumptions and external dependencies: what this spec takes as given about systems it does not control, and what to do at a contradiction. Contradictions live at the seams; naming them tells the agent where to escalate fast instead of hacking around a system it cannot change.
7. Critical files
Pointers into existing code, not restatements of it. The builder reads code; this just aims it.
8. Acceptance checks
Falsifiable and partitioned by altitude: agent-loopable (provable — leads with a runnable command, is the loop's mechanical exit; since v2.8 an item may carry its command inline: <claim> — run: `cmd`), judgeable (settled by a fresh-context agent against a named section), and human-gate (tasteable — verified once by a person).
9. Out of scope / deferred
What's deliberately excluded or pushed out, with IDs if already allocated.
Acceptance partitions are the build loop. The agent-loopable set is the inner loop's exit condition, run in the implementation PR. The judgeable set is the outer loop, owned by a fresh-context verifier against a named section. The human-gate set is settled once by a person. Judgment is layered, not banished.
Up: handbook — shaping. The law: the canon, "spec.md body".