specflow-cc 1.15.0 → 1.17.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -5,6 +5,29 @@ All notable changes to SpecFlow will be documented in this file.
5
5
  The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
6
6
  and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
7
7
 
8
+ ## [1.17.0] - 2026-03-29
9
+
10
+ ### Added
11
+
12
+ - **Defer-to-TODO enforcement** — when spec-reviser defers requirements during scope reduction, TODOs are now automatically created in `.specflow/todos/TODO.md`
13
+ - New Step 5.5 in spec-reviser agent: mandatory TODO creation for every deferred item
14
+ - Revise command fallback mode also enforces TODO creation for deferred items
15
+ - Spec-auditor now reminds that removed requirements must be captured as TODOs when recommending scope reduction
16
+ - Closes a process gap where deferred work could be silently lost (discovered via SPEC-159 incident)
17
+
18
+ ## [1.16.0] - 2026-03-23
19
+
20
+ ### Added
21
+
22
+ - **Brownfield / Delta Specifications** — spec-creator now detects existing implementations and generates a `## Delta` section describing only what changes, preserving what already works
23
+ - **Delta validation in spec-auditor** — auditor validates delta sections for completeness and correctness in brownfield specs
24
+ - **Changes Applied subsection** in `/sf:done` — delta spec completion summaries now include a dedicated section listing what was actually changed
25
+
26
+ ### Fixed
27
+
28
+ - **Init re-initialization safety** — `/sf:init` now safely handles re-initialization without overwriting existing `.specflow/` state
29
+ - **Deviations subsection disambiguation** — delta completion template no longer collides subsection names when both Deviations and Delta Deviations are present
30
+
8
31
  ## [1.15.0] - 2026-03-11
9
32
 
10
33
  ### Fixed
@@ -267,6 +267,48 @@ Set NEEDS_DECOMPOSITION if ANY of:
267
267
  - Recommend `/sf:run --parallel` mode
268
268
  - Set status to NEEDS_DECOMPOSITION (if no critical issues)
269
269
 
270
+ **If recommending scope reduction (removing requirements):**
271
+ - Explicitly note in the audit that removed requirements MUST be captured as TODOs
272
+ - Add to recommendations: "Any requirements removed during revision must be tracked via `/sf:todo` to prevent scope loss"
273
+
274
+ ## Step 3.6: Delta Validation
275
+
276
+ **Detection:** Check if spec frontmatter contains `delta: true`.
277
+
278
+ **If no delta field or delta is false:** Skip this check entirely.
279
+
280
+ **If delta is true:**
281
+
282
+ a. Verify `## Delta` section exists. If missing: Critical issue "Spec marked as delta but no Delta section found."
283
+
284
+ b. Validate ADDED entries:
285
+ - For each file in ADDED: use Glob/Grep to check if file already exists in the codebase
286
+ - If file exists: Critical issue "Delta ADDED file `{path}` already exists. Should this be MODIFIED instead?"
287
+
288
+ c. Validate MODIFIED entries:
289
+ - For each file in MODIFIED: use Glob/Grep to check if file exists in the codebase
290
+ - If file does NOT exist: Critical issue "Delta MODIFIED file `{path}` not found. Should this be ADDED instead?"
291
+ - Check that each MODIFIED entry has at least one sub-bullet describing the change
292
+ - If no sub-bullets: Warning "MODIFIED entry `{path}` lacks change description"
293
+
294
+ d. Validate REMOVED entries:
295
+ - For each file in REMOVED: use Glob/Grep to check if file exists in the codebase
296
+ - If file does NOT exist: Warning "Delta REMOVED file `{path}` not found. Already removed or wrong path?"
297
+
298
+ e. Cross-reference: Check that every file mentioned in `## Requirements` is also listed in `## Delta`
299
+ - Before comparing, normalize all paths: strip any leading `./` and any trailing `/` from both sides so that `./agents/foo.md`, `agents/foo.md`, and `agents/foo.md/` all resolve to the same key.
300
+ - Files in Requirements but not in Delta (after normalization): Warning "File `{path}` in Requirements but not in Delta section"
301
+ - Files in Delta but not in Requirements (after normalization): Warning "File `{path}` in Delta but no detailed requirements specified"
302
+
303
+ **Record in audit output:**
304
+
305
+ If delta was present, add to audit summary:
306
+ ```
307
+ Delta validation: {pass_count}/{total_count} entries valid
308
+ ```
309
+
310
+ If no delta: omit this line.
311
+
270
312
  ## Step 3.7: Goal-Backward Validation
271
313
 
272
314
  **Detection:** Check if Goal Analysis section exists in the spec.
@@ -104,6 +104,22 @@ Then derive requirements that ensure ALL truths are achievable.
104
104
  - If complexity is clearly "small" (single file, simple change), Goal Analysis is optional
105
105
  - For medium/large specs, include Goal Analysis in the generated specification
106
106
 
107
+ ## Step 2.7: Brownfield Detection
108
+
109
+ Determine if the task is brownfield (modifying existing code) or greenfield (creating new functionality from scratch).
110
+
111
+ Detection heuristic:
112
+ - Task description mentions existing files, modules, or features → brownfield
113
+ - Task type is "refactor" → always brownfield
114
+ - Task type is "bugfix" → always brownfield
115
+ - Task description uses terms like "extend", "add to", "change", "update", "remove from", "refactor" → brownfield
116
+ - Task description mentions creating entirely new commands/agents/features with no existing counterpart → greenfield
117
+
118
+ **Note:** The `type` values "refactor" and "bugfix" above must match the valid frontmatter `type` values actually used in this project. Before implementing, scan existing spec files (e.g., `ls .specflow/specs/`) and note which `type` values appear. If "refactor" or "bugfix" are not present in the schema, map the heuristic to the closest equivalent types that are. For any task `type` not recognized by the heuristic, fall back to keyword-based detection on the task description rather than failing or treating the task as greenfield by default.
119
+
120
+ If brownfield: set `delta: true` in frontmatter and generate Delta section in Step 5.
121
+ If greenfield: proceed with existing Requirements format (no change).
122
+
107
123
  ## Step 3: Critical Questions (if needed)
108
124
 
109
125
  If the task has genuine ambiguity that affects approach, use AskUserQuestion.
@@ -139,17 +155,40 @@ If no specs exist in either directory, start with SPEC-001.
139
155
 
140
156
  Write to `.specflow/specs/SPEC-XXX.md` using the template structure:
141
157
 
142
- 1. **Frontmatter:** id, type, status (draft), priority, complexity, created, source (if `<todo_context>` provided — set to the TODO ID, e.g., `source: TODO-006`)
158
+ 1. **Frontmatter:** id, type, status (draft), priority, complexity, created, source (if `<todo_context>` provided — set to the TODO ID, e.g., `source: TODO-006`), and optionally `delta: true` (only for brownfield tasks detected in Step 2.7)
143
159
  2. **Title:** Clear, action-oriented
144
160
  3. **Context:** Why this is needed
145
161
  - **If `<prior_discussion>` provided:** Add "Prior Discussion" subsection linking to PRE-XXX or DISC-XXX with key decisions
146
162
  4. **Task:** What to do
147
- 5. **Requirements:** Files, interfaces, deletions
148
- 6. **Acceptance Criteria:** Specific, measurable
149
- 7. **Validation Checklist** (medium/large specs only): 3-5 concrete verification steps with expected outcomes. Each item = action + expected result. Examples: "Run `npm test` — all pass", "POST /api/users with invalid email — returns 422", "Open settings page — new toggle visible"
150
- 8. **Constraints:** What NOT to do
151
- 9. **Assumptions:** What you assumed (clearly marked)
152
- - **If `<prior_discussion>` provided:** Decisions from discussion are facts, not assumptions
163
+ 5. **Delta section (brownfield tasks only):** When `delta: true`, add a `## Delta` section immediately after Context:
164
+
165
+ ```markdown
166
+ ## Delta
167
+
168
+ ### ADDED
169
+ - `path/to/new-file.md` — Description of what this new file provides
170
+
171
+ ### MODIFIED
172
+ - `path/to/existing-file.md` — Description of what changes and why
173
+ - Section X: Add Y
174
+ - Section Z: Replace W with V
175
+
176
+ ### REMOVED
177
+ - `path/to/obsolete-file.md` — Why this file is no longer needed
178
+ ```
179
+
180
+ Rules for Delta section:
181
+ - Each subsection (ADDED/MODIFIED/REMOVED) is optional; omit if empty
182
+ - At least one subsection must be present
183
+ - MODIFIED entries include bullet points describing specific changes within the file
184
+ - The existing `## Requirements` section remains and contains the detailed specifications for each change (the Delta section is a summary/index)
185
+
186
+ 6. **Requirements:** Files, interfaces, deletions
187
+ 7. **Acceptance Criteria:** Specific, measurable
188
+ 8. **Validation Checklist** (medium/large specs only): 3-5 concrete verification steps with expected outcomes. Each item = action + expected result. Examples: "Run `npm test` — all pass", "POST /api/users with invalid email — returns 422", "Open settings page — new toggle visible"
189
+ 9. **Constraints:** What NOT to do
190
+ 10. **Assumptions:** What you assumed (clearly marked)
191
+ - **If `<prior_discussion>` provided:** Decisions from discussion are facts, not assumptions
153
192
 
154
193
  ## Step 5.5: Generate Implementation Tasks (for medium and large specs)
155
194
 
@@ -123,13 +123,44 @@ Append to Audit History:
123
123
  **Applied:** [what was applied]
124
124
 
125
125
  **Changes:**
126
- 1. [✓ if applied, ✗ if skipped] [Item description] — [what was done]
127
- 2. [✓/✗] [Item description] — [what was done]
126
+ 1. [✓ if applied, ✗ if skipped, ⏸ if deferred] [Item description] — [what was done]
127
+ 2. [✓/✗/⏸] [Item description] — [what was done]
128
128
 
129
129
  {If any skipped:}
130
130
  **Skipped:** [reason for skipping recommendations]
131
+
132
+ {If any deferred:}
133
+ **Deferred:** [items deferred to follow-up work]
131
134
  ```
132
135
 
136
+ ## Step 5.5: Create TODOs for Deferred Items
137
+
138
+ After recording the Response, check if any items were marked as deferred (⏸).
139
+
140
+ **If no deferred items:** Skip this step.
141
+
142
+ **If deferred items exist:**
143
+
144
+ For each deferred item:
145
+
146
+ 1. Read `.specflow/todos/TODO.md` to find the highest existing TODO ID
147
+ 2. Generate next TODO ID (zero-padded to 3 digits, starting from 001)
148
+ 3. Create a new TODO entry with:
149
+ - **Description:** `{item description} (deferred from {SPEC-XXX} audit v{N})`
150
+ - **Priority:** —
151
+ - **Notes:** `Origin: {SPEC-XXX} Response v{N}. {reason for deferral}`
152
+
153
+ 4. Insert the new entry into `.specflow/todos/TODO.md` after the `# To-Do List` line
154
+
155
+ 5. Append a "TODOs Created" subsection to the Response in Audit History:
156
+
157
+ ```markdown
158
+ **TODOs Created:**
159
+ - TODO-{XXX} — {item description}
160
+ ```
161
+
162
+ **Important:** This step is mandatory. Every deferred item MUST produce a TODO. If TODO creation fails, report the failure — do not silently skip.
163
+
133
164
  ## Step 6: Update Frontmatter
134
165
 
135
166
  Set status to "auditing" (ready for re-audit).
@@ -169,9 +200,16 @@ Output directly as formatted text (not wrapped in a code block):
169
200
 
170
201
  3. [✗] [Item] — [reason]
171
202
 
203
+ {If any deferred:}
204
+ ### Deferred → TODOs Created
205
+
206
+ 4. [⏸] [Item] → TODO-{XXX}
207
+
172
208
  ### Files Modified
173
209
 
174
210
  - .specflow/specs/SPEC-XXX.md
211
+ {If TODOs created:}
212
+ - .specflow/todos/TODO.md
175
213
 
176
214
  ### Next Step
177
215
 
@@ -188,6 +226,8 @@ Tip: `/clear` recommended — auditor needs fresh context
188
226
  - [ ] User's revision scope understood
189
227
  - [ ] Changes applied precisely
190
228
  - [ ] Revision Response recorded in Audit History
229
+ - [ ] Deferred items (if any) created as TODOs in `.specflow/todos/TODO.md`
230
+ - [ ] TODOs Created subsection appended to Response (if deferred items exist)
191
231
  - [ ] Frontmatter status updated
192
232
  - [ ] STATE.md updated
193
233
  - [ ] Clear summary of changes provided
@@ -175,7 +175,58 @@ mkdir -p .specflow/archive
175
175
  Update frontmatter:
176
176
  - status → "done"
177
177
 
178
- Add completion summary section to the spec:
178
+ Check if the spec frontmatter contains `delta: true`.
179
+
180
+ **If delta spec (`delta: true`):** Add the following completion summary section, which includes a "Changes Applied" subsection populated from the spec's `## Delta` section content:
181
+
182
+ ```markdown
183
+ ---
184
+
185
+ ## Completion
186
+
187
+ **Completed:** {date} {time}
188
+ **Total Commits:** {count from Execution Summary}
189
+ **Review Cycles:** {count of Review v[N] entries}
190
+
191
+ ### Outcome
192
+
193
+ {1-2 sentence summary of what was delivered}
194
+
195
+ ### Key Files
196
+
197
+ - `{path}` — {what it does/why it matters}
198
+
199
+ ### Changes Applied
200
+
201
+ **Added:**
202
+ - `path/to/new-file.md` — {brief description}
203
+
204
+ **Modified:**
205
+ - `path/to/existing-file.md` — {brief description of changes}
206
+
207
+ **Removed:**
208
+ - `path/to/obsolete-file.md` — {brief description}
209
+
210
+ {Omit any subsection (Added/Modified/Removed) if it has no entries.}
211
+
212
+ {If a /sf:review was performed before /sf:done, include this subsection noting differences between what the Delta section specified and what was actually implemented. If no deviations were found or no review was performed, omit this subsection entirely:}
213
+
214
+ ### Deviations from Delta
215
+
216
+ - `path/to/file.md` — {description of how actual implementation differed from Delta entry}
217
+
218
+ ### Patterns Established
219
+
220
+ {List any new patterns, conventions, or architectural decisions introduced.
221
+ If none: "None — followed existing patterns."}
222
+
223
+ ### Spec Deviations
224
+
225
+ {Any deviations from the original spec during implementation (unrelated to delta changes).
226
+ If none: "None — implemented as specified."}
227
+ ```
228
+
229
+ **If NOT a delta spec:** Add the standard completion summary section (no "Changes Applied" or "Deviations from Delta" subsections):
179
230
 
180
231
  ```markdown
181
232
  ---
@@ -20,19 +20,88 @@ Initialize SpecFlow in the current project. Analyzes the codebase to understand
20
20
 
21
21
  <workflow>
22
22
 
23
+ ## Step 0: Parse Arguments
24
+
25
+ Check whether the user invoked `/sf:init --force`. Look at the invocation string for the `--force` flag. Set a mental variable `FORCE_MODE` to true or false accordingly.
26
+
23
27
  ## Step 1: Check if Already Initialized
24
28
 
25
29
  ```bash
26
30
  [ -d .specflow ] && echo "EXISTS" || echo "NOT_EXISTS"
27
31
  ```
28
32
 
29
- **If EXISTS:**
33
+ **If NOT_EXISTS:** proceed to Step 2.
34
+
35
+ **If EXISTS:** scan for existing data files and directories.
36
+
37
+ ```bash
38
+ # Check each file/directory individually
39
+ [ -f .specflow/PROJECT.md ] && echo "HAS_PROJECT_MD" || true
40
+ [ -f .specflow/STATE.md ] && echo "HAS_STATE_MD" || true
41
+ [ -f .specflow/config.json ] && echo "HAS_CONFIG_JSON" || true
42
+ [ -f .specflow/todos/TODO.md ] && echo "HAS_TODO_MD" || true
43
+ [ "$(ls -A .specflow/specs 2>/dev/null)" ] && echo "HAS_SPECS" || true
44
+ [ "$(ls -A .specflow/archive 2>/dev/null)" ] && echo "HAS_ARCHIVE" || true
45
+ ```
46
+
47
+ Collect which items exist. If ANY of the above are found:
48
+
49
+ **If FORCE_MODE is false (no `--force` flag):**
50
+
51
+ Print this warning (substituting actual found items):
52
+
53
+ ```
54
+ WARNING: SpecFlow data already exists in this project.
55
+
56
+ The following files/directories would be overwritten:
57
+ [list each found item, one per line, e.g.:]
58
+ - .specflow/PROJECT.md
59
+ - .specflow/STATE.md
60
+ - .specflow/config.json
61
+ - .specflow/todos/TODO.md
62
+ - .specflow/specs/ (contains files)
63
+ - .specflow/archive/ (contains files)
64
+
65
+ Re-running init will overwrite these files. Use `/sf:init --force` to reset.
66
+
67
+ Tip: Run `/sf:status` to see current state.
68
+ ```
69
+
70
+ Exit. Do NOT proceed.
71
+
72
+ **If FORCE_MODE is true (`--force` was passed):**
73
+
74
+ Print a warning listing all files that will be overwritten, then create a timestamped backup.
75
+
76
+ ```
77
+ WARNING: --force flag detected. Existing SpecFlow data will be backed up and overwritten.
78
+
79
+ The following files/directories will be backed up:
80
+ [list each found item]
81
+ ```
82
+
83
+ Create the backup directory with a timestamp:
84
+
85
+ ```bash
86
+ BACKUP_DIR=".specflow/backup-$(date +%Y-%m-%d-%H%M%S)"
87
+ mkdir -p "$BACKUP_DIR"
88
+ echo "Backup directory: $BACKUP_DIR"
30
89
  ```
31
- SpecFlow already initialized in this project.
32
90
 
33
- Use `/sf:status` to see current state.
91
+ Copy all existing `.specflow/` content (except the backup directory itself) into the backup:
92
+
93
+ ```bash
94
+ # Copy all existing .specflow content into backup
95
+ # Use find to copy files while preserving structure, excluding backup dirs themselves
96
+ find .specflow -maxdepth 1 -not -name "backup-*" -not -name ".specflow" | while read item; do
97
+ cp -r "$item" "$BACKUP_DIR/"
98
+ done
99
+ echo "Backup complete."
34
100
  ```
35
- Exit.
101
+
102
+ Then proceed to Step 2.
103
+
104
+ **If EXISTS but no data files found** (empty directory): proceed to Step 2.
36
105
 
37
106
  ## Step 2: Detect Tech Stack
38
107
 
@@ -162,6 +231,14 @@ mkdir -p .specflow/specs .specflow/audits .specflow/archive .specflow/todos .spe
162
231
 
163
232
  ## Step 6: Generate PROJECT.md
164
233
 
234
+ **Defense-in-depth guard:** Before writing, check if `.specflow/PROJECT.md` already exists AND `--force` was NOT used. If both conditions are true, skip writing this file and note it was skipped.
235
+
236
+ ```bash
237
+ [ -f .specflow/PROJECT.md ] && echo "PROJECT_MD_EXISTS" || echo "PROJECT_MD_MISSING"
238
+ ```
239
+
240
+ If `PROJECT_MD_MISSING` OR `FORCE_MODE` is true: write the file.
241
+
165
242
  Based on detected stack and patterns, create `.specflow/PROJECT.md`:
166
243
 
167
244
  ```markdown
@@ -201,6 +278,14 @@ Based on detected stack and patterns, create `.specflow/PROJECT.md`:
201
278
 
202
279
  ## Step 7: Generate STATE.md
203
280
 
281
+ **Defense-in-depth guard:** Before writing, check if `.specflow/STATE.md` already exists AND `--force` was NOT used. If both conditions are true, skip writing this file and note it was skipped.
282
+
283
+ ```bash
284
+ [ -f .specflow/STATE.md ] && echo "STATE_MD_EXISTS" || echo "STATE_MD_MISSING"
285
+ ```
286
+
287
+ If `STATE_MD_MISSING` OR `FORCE_MODE` is true: write the file.
288
+
204
289
  Create `.specflow/STATE.md`:
205
290
 
206
291
  ```markdown
@@ -237,6 +322,14 @@ Create `.specflow/STATE.md`:
237
322
 
238
323
  ## Step 8: Generate config.json
239
324
 
325
+ **Defense-in-depth guard:** Before writing, check if `.specflow/config.json` already exists AND `--force` was NOT used. If both conditions are true, skip writing this file and note it was skipped.
326
+
327
+ ```bash
328
+ [ -f .specflow/config.json ] && echo "CONFIG_JSON_EXISTS" || echo "CONFIG_JSON_MISSING"
329
+ ```
330
+
331
+ If `CONFIG_JSON_MISSING` OR `FORCE_MODE` is true: write the file.
332
+
240
333
  Create `.specflow/config.json`:
241
334
 
242
335
  ```json
@@ -404,7 +404,13 @@ Items {N, M} require clarification before deciding.
404
404
  `/sf:audit` — re-audit with applied changes
405
405
 
406
406
  {If deferred items exist:}
407
- Note: Deferred items saved to `.specflow/todos/` for future consideration.
407
+ ### Deferred TODOs Created
408
+
409
+ | Deferred Item | TODO Created |
410
+ |---------------|-------------|
411
+ | {item description} | TODO-{XXX} |
412
+
413
+ Note: Each deferred item has been saved as a TODO for future consideration.
408
414
  ```
409
415
 
410
416
  </workflow>
@@ -464,6 +470,19 @@ NEXT_VERSION=$((RESPONSE_COUNT + 1))
464
470
  **Summary:** Applied {X}/{Y} items, Skipped {Z}, Deferred {W}
465
471
  ```
466
472
 
473
+ ### Create TODOs for Deferred Items
474
+
475
+ After recording the Response, if any items were marked "Deferred":
476
+
477
+ 1. Read `.specflow/todos/TODO.md` to find the highest existing TODO ID
478
+ 2. For each deferred item, create a new TODO entry:
479
+ - **Description:** `{item description} (deferred from {SPEC-XXX} audit v{N})`
480
+ - **Priority:** —
481
+ - **Notes:** `Origin: {SPEC-XXX} Response v{N}. {reason for deferral}`
482
+ 3. Append "**TODOs Created:**" subsection to the Response in Audit History listing created TODO IDs
483
+
484
+ **This step is mandatory.** Every "Deferred" decision MUST produce a corresponding TODO.
485
+
467
486
  ### Update Status
468
487
 
469
488
  In spec frontmatter: `status: auditing`
@@ -480,6 +499,7 @@ In STATE.md:
480
499
  - [ ] Revision scope determined (all/specific/custom)
481
500
  - [ ] Changes applied correctly
482
501
  - [ ] Response recorded in Audit History
502
+ - [ ] Deferred items (if any) created as TODOs in `.specflow/todos/TODO.md`
483
503
  - [ ] Spec frontmatter status updated
484
504
  - [ ] STATE.md updated
485
505
  - [ ] Clear summary of changes shown
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "specflow-cc",
3
- "version": "1.15.0",
3
+ "version": "1.17.0",
4
4
  "description": "Spec-driven development system for Claude Code — quality-first workflow with explicit audit cycles",
5
5
  "bin": {
6
6
  "specflow-cc": "bin/install.js"