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 (Intent over description) — so prescribed mechanics tend to anchor a frontier builder and go stale. It's advice, not a rule: 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
One list, each item falsifiable — settleable the same way twice. Anything only a person can settle sits under an optional ### human sub-heading. (Unattended builds — experimental — refine this into three altitudes: provable, judgeable, tasteable.)
9. Out of scope / deferred
What's deliberately excluded or pushed out, with IDs if already allocated.
Acceptance, refined (experimental). Unattended, the provable 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 tasteable set (### human) is settled once by a person. Judgment is layered, not banished.
Up: handbook — shaping. The law: the canon, "spec.md body".