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

## This Chapter
- **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.

## Reader State
- **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.

## Open Threads
- 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.