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