# Spec Driven Development — Chapter 09 Memory: 4 - speckit constitution: the rules before the first move
- **Stage**: Previewed — awaiting reading
- **Next Step**: Wait for the reader to finish PDF pages 76–92; then ask 2–3 open-ended recall questions before synthesis.
- **Reading Span**: PDF pages 76–92
- **Source Text**: /library/Spec Driven Development/Chapter-09-speckit-constitution-the-rules-before-the-first-move/Chapter-09-source-text.md (read instead of PDF when needed)
- **Full Record**: /library/Spec Driven Development/Chapter-09-speckit-constitution-the-rules-before-the-first-move/Chapter-09-chapter-notes.md (create at preview)
- **Last Updated**: 2026-10-02

## 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. The 70/30 split is illustrative.
- Ch3: SDD addresses what/why, FOCUS Architecture where rules live, and Context Engineering what the agent sees. Reader expects needed cross-references to be explained in place.
- Ch4: Short feedback cycles and cheap AI code rewrites are claimed without project-level change-cost data; reader said revised code must be tested against the spec.
- Ch5: A spec records purpose, scope, behavior, criteria, and edges; technical choices belong in the plan. Precise terms matter (non-space vs. non-whitespace).
- Ch6: EARS, Given/When/Then, Design by Contract, and ATDD sharpen requirements. Edit-task self-comparison defect remained a learning point.
- Ch7: One spec = one usable capability, reviewable in one sitting and spanning needed layers. Reader understood complete/reopen and delete as a later spec, but proposed UI specs first; revisit spec scope vs. implementation order with a real example.
- Ch8: Tools package the same cycle: spec-kit feature, OpenSpec change, BMAD epic/story. Author chose spec-kit for personal use, matching vocabulary, and moderate structure. Reader recalled these, but needed clarification that init creates scaffolding only and constitution governs project-wide decisions.
- Open cross-book thread: maintenance and information structure in FOCUS Architecture and Context Engineering; stand-alone cross-reference promise remains under observation.

## This Chapter
- **Core Question**: Why does spec-kit ask for project-wide rules before the first feature spec, and how should those rules be chosen and checked?
- **Watch-For Themes**: Boundary between lasting project rules, feature behavior, and technology choices; what makes a principle enforceable and justified; whether the To-Do's rules suit its small scope; how to review and amend the generated constitution; what the author expects files to preserve when chat context is cleared.
- **Core Thesis**: Pending review.
- **Key Concepts**: Pending review.
- **Notable Arguments / Evidence Limits**: Pending review.
- **Action Item**: Pending review.

## Reader State
- **Pending Questions**: None; reading pending.
- **Reader's Answers (paraphrase)**: None for this chapter.
- **Misconceptions / Feedback Given**: None for this chapter.
- **Personal Threads**: Reader may try a small task-text spec; use a concrete feature to reinforce capability vs. layer. Test whether Chapter 9's project-wide rules make sense for that small example.

## Open Threads
- What evidence would show SDD overhead pays off in the reader's work?
- Check whether the constitution guidance is concrete enough without requiring another book.