# 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.

## This Chapter
- **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

## Reader State
- **Pending Questions**: None yet
- **Reader's Answers (paraphrase)**:
- **Misconceptions / Feedback Given**:
- **Personal Threads**: Reader may try a small task-text spec.

## Open Threads
- 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.