# Spec Driven Development — Chapter 07 Memory: 2c - The Scope of a Spec: How Much Fits in One Specification
- **Stage**: Complete
- **Next Step**: Preview Chapter 8, "Hands on: the SDD tools," when the reader is ready.
- **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-02

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

## This Chapter
- **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**: One spec covers one usable capability that can be reviewed in one sitting before implementation.
- **Key Concepts**: One-lap scope; complete user path across needed layers; reciprocal actions may form one capability; split diagnostics: demonstrability, mutual dependency, duplicated rule.
- **Notable Arguments / Evidence Limits**: To-Do sequence: create/list, complete/reopen, filter, delete, edit (pp. 58–60). Skip or defer for throwaways, exploration, known one-off fixes, expiring prototypes (pp. 61–62). Ten-minute review and cost claims are heuristics, not measured here.
- **Action Item**: Choose a small task-app change; state its usable result, apply the three scope checks, and keep needed UI, behavior, and storage in one spec.

## Reader State
- **Pending Questions**: None; review complete.
- **Reader's Answers (paraphrase)**: Named all three scope checks; explained complete/reopen correctly; would revisit a one-off script if retained or shared. Proposed UI specs first, then a separate delete spec.
- **Misconceptions / Feedback Given**: Clarified no-"and" as a heuristic and distinguished implementation order from spec scope. A UI-only spec lacks a complete user action; first To-Do spec is create/list across needed layers. Deletion later is correct. The layer-vs-capability distinction may need a concrete future example.
- **Personal Threads**: Reader may try a small task-text spec; raised continued or shared use of a script as a reason to reconsider one-off status.

## Open Threads
- Check the layer-vs-capability distinction with a concrete reader-owned feature in a later chapter.
- 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.