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: Complete
• Next Step: Preview Chapter 10 (next section: the feature cycle map before the first specify; builds on the constitution check).
• 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: Constitution = lasting governance written before any spec so all specs/plans/tasks obey shared principles; fixes structure and quality, leaves technology to the plan.
• Key Concepts: Constitution/spec/plan split (how+standard / what / which tech); four content kinds; MUST wording with rationale; architecture vs. stack (portability proof); checks coverage/leakage/form; semver amendments; /clear because files are source of truth.
• Notable Arguments / Evidence Limits: Analogies and the To-Do's six principles; no empirical evidence; small-app fit of layering rules only justified as teaching; book's “minor” for clarification is loose semver.
• Action Item: Draft 3-4 MUST principles with rationales for one of your projects; run coverage/leakage/form checks.

Reader State

• Pending Questions: None (answered 2026-10-05); optional retry of Q1 gap and Q2.
• Reader's Answers (paraphrase): (1) Constitution = governance, the rules above day-to-day decisions. (2) Principles with rationale; unsure beyond that. (3) Bump version; check leakage, coverage, form.
• Misconceptions / Feedback Given: Q1 missing why-before-spec and spec/plan split; Q2 only 1 of 4 content kinds, no normative wording, no To-Do scope view; Q3 missed what files preserve after /clear. Book's “minor” for clarification is loose semver.
• 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.