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

Spec Driven Development — Chapter 09: 4 - speckit constitution: the rules before the first move

• Date Created: 2026-10-02
• Status: Complete
• Reading Span: PDF pages 76–92

---

1. Pre-Reading Briefing

• 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?
• Key Points to Watch For:
  • Track the boundary between a lasting project rule, a feature's behavior, and a technology choice. Where would each belong in the workflow?
  • Notice how the author turns a broad preference into a rule that someone can apply and defend. Pay attention to the reason given for each rule.
  • Read the To-Do example critically: which rules serve a small personal app, and which might be more structure than it needs?
  • See how the generated constitution is reviewed, corrected, and changed over time. What would make you reject its first draft?
  • Examine the advice to clear chat context between steps. What information must the written artifacts preserve for the next step to work?
• Context & Thread from Prior Chapters: Chapter 8 ended with an initialized project and an empty constitution file; no feature exists yet. Chapter 7 defined a spec by the usable action it delivers. This chapter asks what rules should apply to every such feature, even when the implementation work begins in a particular layer.

---

2. Reading Review & Reflections

• Prompt Questions:
  1. Why a constitution before the first feature spec, and what separates a project rule from feature behavior or a tech choice?
  2. What makes a principle enforceable and justified; which To-Do rules fit its small scope?
  3. How do you review/amend the generated constitution, and what should files preserve when chat context is cleared?
• User Key Takeaways (verbatim):
  1. “Its what governs everything, Governance, here, is the level of the rules that sit above the day-to-day decisions and that decide what is acceptable across all of them.”
  2. “First, the principles, each with its rationale. Im not sure on this one”
  3. “you would need to change the version number and do checks for leakage coverage and form”
• Scaffolding & Feedback: Q1 matches the book's definition but omits why it comes first (otherwise each spec invents its own rules) and the constitution/spec/plan split. Q2 named only the first of four content kinds; added normative wording and rationale-as-problem-avoided; the small-scope fit is not argued by the book. Q3 correct on semver bump and the three checks (named leakage, coverage, form); missed what files preserve across /clear (files are source of truth; fix docs, not memory). Noted the book calls a clarification a “minor” bump, loosely vs. standard semver patch.

---

3. Chapter Synthesis

• Core Thesis: A project constitution is the lasting governance layer, written before the first spec so every spec, plan, and task obeys the same principles instead of inventing local rules, and it fixes structure and quality standards while leaving technology to the plan.
• Key Concepts / Mental Models:
  • Constitution / spec / plan split: Constitution = how it is built and under which standard (cross-feature, rarely changes); spec = what a feature does; plan = with which technology. Test any line: lasting rule or implementation choice?
  • Four content kinds: principles with rationale (the why makes a rule survive deadlines), engineering/quality standards (SOLID, Clean Architecture, TDD), workflow, governance (versioning and amendment).
  • Normative wording: MUST / MUST NOT / SHOULD make rules checkable; each rationale names the problem avoided, not a restatement.
  • Architecture vs. stack: layers and inward dependency direction are governance; language, framework, state library, database are plan. Proof: the same constitution serves React, Delphi, Java, C#.
  • Review checks: coverage, leakage, form (version header at 1.0.0, Sync Impact Report). Fix by re-running with a sharper request or hand edit plus version bump.
  • Living artifact: semver (major = incompatible removal/redefinition, middle = new principle, last = clarification; book calls it “minor”, loosely); committed in git; later enforced by the constitution check.
  • /clear between steps: files are the source of truth; if the next step lacks something, fix the documentation, not the chat.
• Notable Arguments & Evidence: Analogies (national constitution, condo bylaws, building code); the To-Do's six principles (Layered Architecture, Isolated Business Logic, Error as Value, TDD, Simplicity, Technology Agnosticism); portability across stacks. Limits: no empirical evidence; the book does not argue that the layering rules suit such a small app beyond “the app exists to teach the method”; the generated result may differ from the one shown.
• Updates to Prior Understanding: Extends Ch8 (init made scaffolding only; constitution fills the empty file and governs project-wide). Confirms Ch5 (technical choices belong in the plan) and Ch7 (feature scope is spec-level). Turns Ch1's TDD into a rule. Points to FOCUS Architecture for layer detail without requiring it.
• Weekly Action Item: Draft a constitution for one of your own projects: 3-4 principles, each with MUST wording and a rationale. Then run the three checks (coverage, leakage, form), and strike any line that names a technology.