Spec Driven Development — Chapter 07 Memory: 2c - The Scope of a Spec: How Much Fits in One Specification

Stage: Previewed — awaiting reading
Next Step: Wait for the reader to finish PDF pages 57–63; then ask 2–3 open-ended recall questions before synthesis.
Reading Span: PDF pages 57–63
Source Text: /library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-source-text.md (read instead of PDF when needed)
Full Record: /library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-chapter-notes.md (read only if needed)
Last Updated: 2026-10-01

Carried-in Context (from earlier chapters)

Ch1: Ködel's experience motivates the method but does not prove broad effectiveness; reader wants to test it.
Ch2: A specification sets a target for judging AI output; people still judge, decide, and answer. 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: The author combines specification direction with short feedback cycles and claims AI lowers code rewrite cost; no project-level measurement of total change cost. Reader said revised code must be tested against the spec.
Ch5: A useful spec records purpose, scope, behavior, criteria, and edges; technical choices belong in the plan. Reader learned that non-space versus non-whitespace changes behavior.
Ch6: Sentence precision matters: EARS gives condition and obligation; Given/When/Then gives a concrete check; Design by Contract gives pre/post/invariants; ATDD sets checks before code. The edit-task defect came from counting the task's own unchanged title as a duplicate. Reader was unsure about this even after feedback, so a concrete example was repeated before this preview.
Open cross-book thread: maintenance and information structure in FOCUS Architecture and Context Engineering; the stand-alone cross-reference promise remains under observation.

Core Question: How much work should one specification cover so it can be reviewed and its result checked as a useful piece of software?
Watch-For Themes: Unit of a spec; reviewability; complete/reopen versus create/delete; splitting by usable behavior versus layers; cases where SDD overhead may not pay off.
Core Thesis: Pending post-reading review.
Key Concepts: Pending post-reading review.
Notable Arguments / Evidence Limits: Pending post-reading review.
Action Item: Pending post-reading review.

Pending Questions: None; reading pending.
Reader's Answers (paraphrase): None for this chapter.
Misconceptions / Feedback Given: None for this chapter.
Personal Threads: Reader may try a small task-text spec; no Chapter 7 application selected.

Which boundary would make a real feature reviewable while leaving a usable result?
What evidence would show SDD overhead pays off or does not in the reader's work?
Revisit edit-task self-comparison only if it helps the reader understand a later example.