diff --git a/MEMORY.md b/MEMORY.md index 209f34f..46be767 100644 --- a/MEMORY.md +++ b/MEMORY.md @@ -3,8 +3,8 @@ Status board only. Details live in each chapter's `memory.md`; read the one list ## Spec Driven Development — J.C. Ködel - **Status**: In Progress -- **Current Position**: Chapter 6 of 26 complete — Chapter 7 preview next -- **Current Chapter Memory**: /library/Spec Driven Development/Chapter-06-Requirement-Language-Writing-What-the-AI-Executes-Without/Chapter-06-memory.md +- **Current Position**: Chapter 7 of 26 previewed — awaiting reading +- **Current Chapter Memory**: /library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-memory.md - **Folder**: /library/Spec Driven Development/ - **Source File**: /library/Spec Driven Development/source-file.pdf - **Structure**: /library/Spec Driven Development/book-structure.md (26 top-level sections; the unnumbered author intro is Chapter 1 here, the book's section 0 is Chapter 2) diff --git a/library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-chapter-notes.md b/library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-chapter-notes.md new file mode 100644 index 0000000..6702236 --- /dev/null +++ b/library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-chapter-notes.md @@ -0,0 +1,26 @@ +# Spec Driven Development — Chapter 07: 2c - The Scope of a Spec: How Much Fits in One Specification +- **Date Created**: 2026-10-01 +- **Status**: In Progress — preview prepared; awaiting reading +- **Reading Span**: PDF pages 57–63 + +--- + +## 1. Pre-Reading Briefing +- **Core Question**: How much work should one specification cover so it can be reviewed and its result checked as a useful piece of software? +- **Key Points to Watch For**: + - Notice what Ködel treats as the unit of a spec, and how he tests whether the boundary is small enough to review but large enough to deliver value. + - Compare his reasons for grouping “complete and reopen” while separating “create and delete.” + - Watch how he proposes splitting a large feature and what becomes visible to a user after each slice. + - Look for warning signs that a split follows technical layers rather than user-visible behavior. + - Identify the situations where he says the method's up-front work may not pay off, and ask what assumptions those exceptions rely on. +- **Context & Thread from Prior Chapters**: Chapter 5 identified the parts of a spec; Chapter 6 examined the precision of each requirement sentence. This chapter moves to the size and boundary of the spec as a whole. Keep the earlier edit-task example in mind: a reviewable boundary should help expose decisions like whether a task counts its own unchanged title as a duplicate. + +--- + +## 2. Reading Review & Reflections +Pending reading. + +--- + +## 3. Chapter Synthesis +Pending post-reading review. diff --git a/library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-memory.md b/library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-memory.md new file mode 100644 index 0000000..5eccc7e --- /dev/null +++ b/library/Spec Driven Development/Chapter-07-The-Scope-of-a-Spec-How-Much-Fits-in-One-Specification/Chapter-07-memory.md @@ -0,0 +1,35 @@ +# 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. + +## 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**: Pending post-reading review. +- **Key Concepts**: Pending post-reading review. +- **Notable Arguments / Evidence Limits**: Pending post-reading review. +- **Action Item**: Pending post-reading review. + +## Reader State +- **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. + +## Open Threads +- 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.