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

Spec Driven Development — Chapter 10: Appendix: the To-Do constitution (with Chapter 11: To-Do Constitution)

• Date Created: 2026-10-05
• Status: Complete
• Reading Span: PDF pages 93–98 (Chapter 10 appendix header + Chapter 11 file text, reviewed together at the reader's request)

---

1. Pre-Reading Briefing

• Core Question: What does the real, unedited constitution that spec-kit generated for the To-Do project look like, and how does it compare with the principle-by-principle commentary in Chapter 9?
• Key Points to Watch For:
  • The Sync Impact Report comment block at the top: it is generated, and the book keeps it.
  • How each principle is worded (MUST, rationale) versus how Chapter 9 said it should be.
  • Whether anything technology-specific has leaked in, or whether the file stays at the architecture level.
  • Version and amendment metadata at the bottom.
• Context & Thread from Prior Chapters: Chapter 9 gave the checks (coverage, leakage, form) and the semver amendment rule. This appendix is the real artifact to apply them to. This chapter is one page; the file itself follows in Chapter 11.

---

2. Reading Review & Reflections

• Prompt Questions:
  1. Apply the coverage/leakage/form checks: which principle is strongest, which weakest, and why?
  2. Principles I and VI both forbid naming technology: redundant or different jobs?
  3. Workflow lists Tests after Implementation but Principle IV says “before or during”: conflict? And which version bump for a 7th principle vs. rewording one?
• User Key Takeaways:
  1. Strongest: I. Layered Architecture. Weakest: V. Simplicity, because simplicity is not necessarily the same between two people.
  2. “I think they are redundant.”
  3. “It is not a conflict. MAJOR then Minor.”
• Scaffolding & Feedback:
  1. Pick of I is sound (structure, no framework names, MUST + rationale), but the reader did not name which checks it passes. V's weakness is a form failure: unverifiable wording (“deliberately simple”, “SHOULD prioritize readability”) and a self-referential rationale. The YAGNI clause is the only testable part.
  2. Mostly right: VI is the full rule (sends tech choices to the Plan); the sentence in I restates it. Risk is drift when one is amended. Small difference: VI constrains the constitution itself, I constrains the application.
  3. “Not a conflict” is defensible (“before or during” is loose; Workflow is a coarse artifact sequence) but read literally, Tests at step 6 after Implementation at step 5 contradicts “before”; a form check would flag the wording. Amendment order looked reversed: new principle = MINOR; reword = PATCH if clarification, MAJOR only if removed/redefined. Reader asked to move on without retrying.

---

3. Chapter Synthesis

• Core Thesis: A real generated constitution is a short, MUST-worded document (six principles, standards, workflow, governance, version) that fixes architecture and process while deferring every technology choice to the Plan, and it is only as good as its wording passes the coverage, leakage and form checks.
• Key Concepts / Mental Models:
  • Principle + rationale: each rule is MUST/MUST NOT with a “why”, so a reader or agent can apply it to a case the rule never listed. Practical: write the rationale first; if it only restates the goal (as in V) the rule is weak.
  • Architecture, not stack: Layered Architecture, Isolated Business Logic, and Error as Value constrain structure; Technology Agnosticism pushes language/framework/DB to the Plan. Practical: run the leakage check by looking for any proper noun of a tool.
  • Standards vs. principles: SOLID, Clean Architecture, TDD, Error as Value, Separation of Concerns are listed as supporting standards without MUST; they back the principles rather than add rules.
  • Workflow list: Constitution → Spec → Plan → Tasks → Implementation → Tests → Review is the coarse artifact order; it must not be read as contradicting “tests before or during” in Principle IV.
  • Governance: constitution prevails over other practices; semver amendments (MAJOR remove/redefine, MINOR new principle or section, PATCH clarification) plus proposal, rationale, and version-history record; review on any permanent architecture change. Version 1.0.0, ratified 2026-06-25.
• Notable Arguments & Evidence: Faithful copy of a file generated by specify 0.11.8 for one project; no evidence it generalises. Weak spots visible in the text: I/VI overlap, unverifiable V, Workflow vs. Principle IV wording, odd “No business decision MUST exist” in II. The Sync Impact Report promised by the appendix is not in the extracted text.
• Updates to Prior Understanding: Confirms Chapter 9 (architecture vs. stack, MUST + rationale, semver). Extends it by showing the checks find real flaws in a book-endorsed example. Reader's small-app-fit question (do layering rules suit a personal To-Do?) is only answered by the author's “example of the method” rationale.
• Weekly Action Item: Take the To-Do constitution, rewrite Principle V so a stranger could verify it from a spec or diff, and merge or de-duplicate the technology ban in I and VI. Decide the version bump (PATCH vs. MAJOR) and state why.