speccrew 0.3.3 → 0.3.4
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.
|
@@ -172,15 +172,98 @@ After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
|
|
|
172
172
|
- `Type`: Either `Page+API` or `API-only`
|
|
173
173
|
- `Dependencies`: List of prerequisite Feature IDs (if any)
|
|
174
174
|
|
|
175
|
-
3. **Build Feature Registry**: Consolidate all features across Sub-PRDs into a unified list
|
|
175
|
+
3. **Build Feature Registry**: Consolidate all features across Sub-PRDs into a unified list.
|
|
176
|
+
|
|
177
|
+
4. **Write Feature Registry to `.checkpoints.json`**:
|
|
178
|
+
|
|
179
|
+
Write or update the checkpoint file at:
|
|
180
|
+
```
|
|
181
|
+
speccrew-workspace/iterations/{iteration}/02.feature-design/.checkpoints.json
|
|
182
|
+
```
|
|
183
|
+
|
|
184
|
+
Structure — each feature has individual status fields for full checklist tracking:
|
|
185
|
+
```json
|
|
186
|
+
{
|
|
187
|
+
"stage": "02_feature_design",
|
|
188
|
+
"checkpoints": {
|
|
189
|
+
"function_decomposition": {
|
|
190
|
+
"passed": false,
|
|
191
|
+
"confirmed_at": null,
|
|
192
|
+
"description": "Feature Registry extraction and confirmation",
|
|
193
|
+
"total_features": 42,
|
|
194
|
+
"total_modules": 13,
|
|
195
|
+
"features": [
|
|
196
|
+
{
|
|
197
|
+
"feature_id": "F-SYS-01",
|
|
198
|
+
"feature_name": "Account Login",
|
|
199
|
+
"type": "Page+API",
|
|
200
|
+
"module": "M1-System",
|
|
201
|
+
"source_prd": "crm-system-sub-system.md",
|
|
202
|
+
"dependencies": [],
|
|
203
|
+
"feature_spec_status": "pending",
|
|
204
|
+
"api_contract_status": "pending"
|
|
205
|
+
},
|
|
206
|
+
{
|
|
207
|
+
"feature_id": "F-MEMBER-01",
|
|
208
|
+
"feature_name": "Customer Info Management",
|
|
209
|
+
"type": "Page+API",
|
|
210
|
+
"module": "M2-Member",
|
|
211
|
+
"source_prd": "crm-system-sub-member.md",
|
|
212
|
+
"dependencies": ["F-SYS-01"],
|
|
213
|
+
"feature_spec_status": "pending",
|
|
214
|
+
"api_contract_status": "pending"
|
|
215
|
+
}
|
|
216
|
+
]
|
|
217
|
+
},
|
|
218
|
+
"feature_spec_review": {
|
|
219
|
+
"passed": false,
|
|
220
|
+
"confirmed_at": null
|
|
221
|
+
},
|
|
222
|
+
"api_contract_joint": {
|
|
223
|
+
"passed": false,
|
|
224
|
+
"confirmed_at": null
|
|
225
|
+
}
|
|
226
|
+
}
|
|
227
|
+
}
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
**Feature status values:**
|
|
231
|
+
- `pending`: Not started
|
|
232
|
+
- `in_progress`: Worker dispatched
|
|
233
|
+
- `completed`: Worker finished successfully
|
|
234
|
+
- `failed`: Worker failed (needs retry)
|
|
235
|
+
- `confirmed`: User confirmed the output
|
|
236
|
+
|
|
237
|
+
**After each worker completes**, update the corresponding feature's status:
|
|
238
|
+
- Feature Spec worker done → set `feature_spec_status` = `completed`
|
|
239
|
+
- API Contract worker done → set `api_contract_status` = `completed`
|
|
240
|
+
|
|
241
|
+
5. **Present Feature Registry to user for confirmation**:
|
|
242
|
+
|
|
243
|
+
Display the full feature table:
|
|
244
|
+
|
|
245
|
+
| # | Feature ID | Feature Name | Type | Module | Dependencies |
|
|
246
|
+
|---|-----------|-------------|------|--------|--------------|
|
|
247
|
+
| 1 | F-SYS-01 | Account Login | Page+API | M1-System | - |
|
|
248
|
+
| 2 | F-MEMBER-01 | Customer Info | Page+API | M2-Member | F-SYS-01 |
|
|
249
|
+
| ... | ... | ... | ... | ... | ... |
|
|
250
|
+
|
|
251
|
+
⚠️ **HARD STOP — WAIT FOR USER CONFIRMATION**
|
|
252
|
+
|
|
176
253
|
```
|
|
177
|
-
Feature Registry
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
254
|
+
DO NOT dispatch Feature Spec workers until user explicitly confirms the Feature Registry.
|
|
255
|
+
Ask user:
|
|
256
|
+
- Is the feature decomposition granularity appropriate?
|
|
257
|
+
- Are Feature IDs, Types, and dependencies correct?
|
|
258
|
+
- Any features to add, remove, or merge?
|
|
259
|
+
|
|
260
|
+
IF user requests changes → update .checkpoints.json, then re-present.
|
|
261
|
+
ONLY after user confirms → update function_decomposition.passed = true,
|
|
262
|
+
set confirmed_at via: node -e "console.log(new Date().toISOString())"
|
|
263
|
+
Then proceed to Phase 3.
|
|
181
264
|
```
|
|
182
265
|
|
|
183
|
-
|
|
266
|
+
6. **Backward Compatibility Check**:
|
|
184
267
|
- If **Feature Breakdown exists**: Proceed with Feature-granular dispatch (new behavior)
|
|
185
268
|
- If **Feature Breakdown missing**: Fall back to Sub-PRD-granular dispatch (legacy behavior)
|
|
186
269
|
- Log the dispatch mode: "📋 Dispatch mode: Feature-granular" or "📋 Dispatch mode: Module-granular (legacy)"
|