Spec Driven Development — Chapter 12 Memory: The complete SDD cycle (book's “5”)

Stage: Previewed — awaiting reading
Next Step: Wait for reader to say “done” or /review, then ask 2–3 open questions on the Watch-For items.
Reading Span: PDF pages 99–111
Source Text: /library/Spec Driven Development/Chapter-12-The-complete-SDD-cycle/Chapter-12-source-text.md (the chapter's own words; read instead of the PDF)
Full Record: /library/Spec Driven Development/Chapter-12-The-complete-SDD-cycle/Chapter-12-chapter-notes.md (read only if needed)
Last Updated: 2026-10-05

Carried-in Context (from earlier chapters)

Ch1: Author experience motivates SDD but does not establish broad effectiveness; reader wants to test the method.
Ch2: A spec sets a target for judging AI output; people still decide and review. 70/30 split is illustrative.
Ch3: SDD = what/why; FOCUS Architecture = where rules live; Context Engineering = what the agent sees. Reader expects cross-references explained in place.
Ch4: Short feedback cycles / cheap AI rewrites claimed without change-cost data; revised code must be tested against the spec.
Ch5–6: Spec records purpose, scope, behavior, criteria, edges; tech goes in the plan. EARS, Given/When/Then, DbC, ATDD sharpen requirements.
Ch7: One spec = one usable capability, reviewable in one sitting. Reader proposed UI specs first; revisit capability vs. layer.
Ch8: spec-kit feature / OpenSpec change / BMAD epic-story package the same cycle; author uses spec-kit.
Ch9: Constitution = lasting governance written before any spec; MUST wording + rationale; coverage/leakage/form checks; semver amendments; /clear because files are source of truth.
Ch10 (+Ch11 file): Real To-Do constitution v1.0.0: six principles, tech deferred to Plan. Reader judged V Simplicity weakest (subjective), I and VI redundant; got amendment bumps reversed (new principle = MINOR, reword = PATCH, redefinition = MAJOR).
Open threads: SDD overhead evidence; small-app fit of layering rules; reader may test a small task-text spec.

Core Question: What journey does a feature travel from idea to integrated code, in what order, and why?
Watch-For Themes: (1) the cycle, not the To-Do, is the lesson; (2) main → branch → merge frame and one commit per artifact; (3) constitution sits above the loop, appears inside only as a check in the plan; (4) seven steps vs. four-step core and three checks (ambiguity / completeness / consistency); (5) artifact chain + docs as source of truth, hence /clear.
Core Thesis: Pending
Key Concepts: Pending
Notable Arguments / Evidence Limits: Pending (chapter's cost-of-rework claims are asserted, not measured; git branch convention is the author's recommendation, not required by spec-kit; diagram on PDF p.102–103 is an image, not in extracted text)
Action Item: Pending

Does the “optional” checks guidance hold for small features (see skip criteria p.109)?
Chapter points ahead to Ch. 10.5 (book numbering) for the defect-and-repair lap.