Book-Reader-Assist/library/Spec Driven Development/Chapter-09-speckit-constitution-the-rules-before-the-first-move/Chapter-09-memory.md

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.