Spec Driven Development — Chapter 08 Memory: 3 - Hands on: the SDD tools

Stage: Complete
Next Step: Preview Chapter 9, “spec-kit constitution: the rules before the first move,” when the reader is ready.
Reading Span: PDF pages 64–75
Source Text: /library/Spec Driven Development/Chapter-08-Hands-on-the-SDD-tools/Chapter-08-source-text.md (read instead of PDF when needed)
Full Record: /library/Spec Driven Development/Chapter-08-Hands-on-the-SDD-tools/Chapter-08-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 cross-references to explain needed ideas 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. Split by complete path through needed layers. Reader knows the three scope checks and why complete/reopen pair; proposed UI specs first, so revisit spec scope vs. implementation order with a concrete example. Delete later as a separate spec was understood.
Open cross-book thread: maintenance and information structure in FOCUS Architecture and Context Engineering; stand-alone cross-reference promise remains under observation.

Core Question: How do SDD tools turn the same specify-plan-tasks-implement cycle into a working project process, and what makes one tool a good fit for this example?
Watch-For Themes: Unit of work and command sequence for each tool; tradeoffs in governance and ceremony; why one tool adds a step before specifying; what initialization creates versus what remains for later chapters; how a tool's unit of work relates to Chapter 7's usable-capability boundary.
Core Thesis: SDD tools package the same cycle in different work units, commands, and levels of structure; choose for project fit.
Key Concepts: spec-kit=feature; OpenSpec=change; BMAD=epic/story. Constitution sets project-wide principles. Init creates scaffolding, not usable behavior.
Notable Arguments / Evidence Limits: Author chooses spec-kit for personal use, direct cycle vocabulary, and middle structure (pp. 70–71); comparison is experiential, not controlled. Tool details checked June 2026, so current setup needs official-doc verification.
Action Item: Map one small usable feature through setup, constitution, spec, plan, tasks, implementation, and validation before running a tool.

Pending Questions: None; review complete.
Reader's Answers (paraphrase): Correctly named all three units and the author's three selection reasons; said constitution must be made after init. Did not state tool fit, constitution's purpose, or that init only creates scaffolding.
Misconceptions / Feedback Given: Filled those omissions with project-fit examples, constitution as project-wide guardrail, and the distinction between setup files and a usable feature. Reinforced Chapter 7's capability boundary.
Personal Threads: Reader may try a small task-text spec; during review, use a concrete feature to reinforce capability vs. layer and distinguish a tool's artifact structure from the feature boundary.

What evidence would show SDD overhead pays off in the reader's work?
Check whether Chapter 9 makes the constitution concrete without requiring another book.