Spec Driven Development — Chapter 05 Memory: 2 - Anatomy of a specification

Stage: Complete
Next Step: None (frozen). Next: Chapter 6 preview (PDF pages 43–56); build its Carried-in Context from this file.
Reading Span: PDF pages 33–42
Source Text: /library/Spec Driven Development/Chapter-05-Anatomy-of-a-specification/Chapter-05-source-text.md (the chapter's own words; read instead of the PDF)
Full Record: /library/Spec Driven Development/Chapter-05-Anatomy-of-a-specification/Chapter-05-chapter-notes.md (read only if needed)
Last Updated: 2026-10-01

Carried-in Context (from earlier chapters)

Ch1: Ködel's professional experience motivates the method but does not prove its broad effectiveness; reader wants to test it.
Ch2: A specification sets a target for judging AI output; people still judge, decide, and answer for results. The 70/30 split is illustrative.
Ch3: SDD = what/why, FOCUS Architecture = where rules live, Context Engineering = what the agent sees and at what cost. Reader expects cross-references to explain needed ideas in place.
Ch4: Ködel combines direction from a specification with short feedback cycles; he claims AI lowers rewrite cost, but offers no project-level measurement of total change cost. The reader recalled specify → plan → tasks → implement and said revised code must be tested against the spec.
Open cross-book thread: how do these ideas connect to maintenance and information structure in FOCUS Architecture and Context Engineering?

Core Question: What information must a specification contain so someone can build and check the intended behavior without filling gaps by guesswork?
Watch-For Themes: What versus how; problem and scope; scenarios, rules, and acceptance criteria; edge cases and assumptions; ambiguity and stand-alone cross-references.
Core Thesis: A useful specification turns vague intent into clear, testable purpose, scope, behavior, and edges while leaving implementation choices for the plan.
Key Concepts: What/why versus how; in/out/non-goals; scenarios, behavioral rules, acceptance criteria; edge cases, assumptions, dependencies; clarify ambiguity before coding.
Notable Arguments / Evidence Limits: To-do app and vague-versus-measurable examples illustrate gap finding; no measured comparison of project outcomes.
Action Item: Use the reader's task-text rule as a mini-spec; check empty, whitespace-only (including tabs), and valid text against expected save behavior and validation message.

Pending Questions: None.
Reader's Answers (paraphrase): Spec holds requirements, scope, non-goals, behavior, and edges; implementation choices come later. Scenario is a user story; acceptance criterion is measurable. Suggested name change as an edge case and uniform date writing as an assumption. Follow-up: task text needs a non-whitespace character; invalid text should not save and should show a validation message.
Misconceptions / Feedback Given: Clarified that rules constrain behavior, not the document's section list; date-format assumption needs explicit resolution; name-change edge case fits an app with profiles, not this to-do scope. The reader repeated the task-text wording; clarified the criterion to reject all-whitespace input (spaces, tabs, line breaks) and let input with a non-whitespace character pass text validation. Ask and record an answer when “blank” is ambiguous.
Personal Threads: Reader plans to assess the author's ideas through use; no Chapter 5 application chosen yet.

Chapter 5 summarizes FOCUS Architecture as deciding where rules live and why dependencies point inward; the reader has not separately assessed whether that is enough for the stand-alone promise.
Test the reader's mini-spec on a real small change when an opportunity arises; compare revised behavior with the stated criterion.
The broader effectiveness and total-cost claims remain to be tested, not assumed.