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 +23 -0
- package/agents/spec-auditor.md +42 -0
- package/agents/spec-creator.md +46 -7
- package/agents/spec-reviser.md +42 -2
- package/commands/sf/done.md +52 -1
- package/commands/sf/init.md +97 -4
- package/commands/sf/revise.md +21 -1
- package/package.json +1 -1
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
|
package/agents/spec-auditor.md
CHANGED
|
@@ -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.
|
package/agents/spec-creator.md
CHANGED
|
@@ -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. **
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
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
|
|
package/agents/spec-reviser.md
CHANGED
|
@@ -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. [
|
|
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
|
package/commands/sf/done.md
CHANGED
|
@@ -175,7 +175,58 @@ mkdir -p .specflow/archive
|
|
|
175
175
|
Update frontmatter:
|
|
176
176
|
- status → "done"
|
|
177
177
|
|
|
178
|
-
|
|
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
|
---
|
package/commands/sf/init.md
CHANGED
|
@@ -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
|
|
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
|
-
|
|
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
|
-
|
|
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
|
package/commands/sf/revise.md
CHANGED
|
@@ -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
|
-
|
|
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
|