Book-Reader-Assist/library/Spec Driven Development/Chapter-10-Appendix-the-To-Do-constitution/Chapter-10-memory.md

Spec Driven Development — Chapter 10 Memory: Appendix: the To-Do constitution

• Stage: Complete
• Next Step: Preview Chapter 12 (The complete SDD cycle). Chapter 11 (To-Do Constitution, PDF 94–98) was folded into this chapter; do not create a separate Ch11 memory.
• Reading Span: PDF pages 93–98 (Ch10 appendix header + Ch11 file text)
• Source Text: /library/Spec Driven Development/Chapter-10-Appendix-the-To-Do-constitution/Chapter-10-source-text.md
• Full Record: /library/Spec Driven Development/Chapter-10-Appendix-the-To-Do-constitution/Chapter-10-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: Spec records purpose, scope, behavior, criteria, edges; technical choices belong in the plan.
• Ch6: EARS, Given/When/Then, Design by Contract, ATDD sharpen requirements.
• Ch7: One spec = one usable capability, reviewable in one sitting, spanning needed layers. 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. init = scaffolding only; constitution = project-wide.
• Ch9: Constitution = lasting governance written before any spec; fixes structure/quality, leaves tech to the plan. Four content kinds, MUST wording with rationale, coverage/leakage/form checks, semver amendments, /clear because files are source of truth. Reader gaps: why-before-spec, 4 content kinds, what files preserve after /clear.
• Open threads: SDD overhead evidence; whether constitution guidance is concrete enough; small-app fit of layering rules.

This Chapter

• Core Question: What does a real generated constitution look like, and does it match Chapter 9's commentary?
• Watch-For Themes: Sync Impact Report header (generated, kept as is); the six principles; MUST wording + rationale; version/amendment metadata; architecture vs. stack separation.
• Core Thesis: Real generated constitution = short MUST-worded rules fixing architecture/process, all tech deferred to the Plan; quality depends on passing coverage/leakage/form.
• Key Concepts: Ch11 file: 6 principles (Layered Architecture, Isolated Business Logic, Error as Value, TDD, Simplicity, Technology Agnosticism), Engineering Standards (SOLID, Clean Arch, TDD, Error as Value, SoC), Workflow (Constitution→Spec→Plan→Tasks→Impl→Tests→Review), Governance (supersedes; semver: MAJOR remove/redefine, MINOR new principle, PATCH clarification), v1.0.0 ratified 2026-06-25.
• Observations (shared with reader): Sync Impact Report block promised in appendix is absent from extracted text (check PDF p.93-94 only if reader asks); I and VI overlap in “no technology” wording; Principles I/III/II are architecture-style rules, yet “Error as Value” arguably borders on a design pattern; Workflow lists Tests after Implementation vs Principle IV “before or during”; Standards (SOLID etc.) named as ‘general principles’ without MUST; V rationale is self-referential; II has odd “No business decision MUST exist”.
• Notable Arguments / Evidence Limits: Faithful copy from specify 0.11.8; single example project.
• Action Item: Rewrite Principle V so it is verifiable, de-duplicate the tech ban in I and VI, and state the version bump with why.

Reader State

• Pending Questions: None
• Reader's Answers (paraphrase): (1) I strongest; V Simplicity weakest because simplicity is subjective. (2) I and VI redundant. (3) Not a conflict; “MAJOR then Minor”.
• Misconceptions / Feedback Given: Did not name which checks I passes. Amendment bumps reversed: new principle = MINOR, reword = PATCH (clarification) or MAJOR (redefinition); reader did not retry. “Not a conflict” defensible but literal Workflow order vs. Principle IV is loose wording.
• Personal Threads: Reader may try a small task-text spec; test whether project-wide rules fit.

Open Threads

• Does the real file satisfy Ch9's coverage/leakage/form checks?