speccrew 0.6.30 → 0.6.32
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.
|
@@ -195,8 +195,10 @@ If resuming from an interrupted session:
|
|
|
195
195
|
| Checkpoint | If Passed | Resume Point |
|
|
196
196
|
|------------|-----------|--------------|
|
|
197
197
|
| `function_decomposition.passed == true` | Skip Checkpoint A | Start from Step 3 (Frontend Design) |
|
|
198
|
-
| `feature_spec_review.passed == true` | Skip Checkpoint A & B | Start from Phase 4 (API Contract) |
|
|
199
|
-
| `api_contract_joint.passed == true` |
|
|
198
|
+
| `feature_spec_review.passed == true` | Skip Checkpoint A & B | Start from Phase 4 (API Contract Generation) |
|
|
199
|
+
| `api_contract_joint.passed == true` | Feature Spec + API Contract joint confirmation already passed | Ask user: "Feature Design phase already completed. Do you want to redo?" |
|
|
200
|
+
|
|
201
|
+
> Evaluate checkpoints from most complete to least complete. If `api_contract_joint.passed == true`, it takes precedence over all earlier checkpoints.
|
|
200
202
|
|
|
201
203
|
3. **Display Resume Summary**:
|
|
202
204
|
```
|
|
@@ -647,19 +649,75 @@ Invoke API Contract skill directly:
|
|
|
647
649
|
|
|
648
650
|
### 4.3 Multiple Feature Specs (Parallel Worker Dispatch)
|
|
649
651
|
|
|
650
|
-
|
|
651
|
-
|
|
652
|
-
|
|
653
|
-
|
|
654
|
-
|
|
655
|
-
- `feature_id`: Feature ID (e.g., `F-CRM-01`)
|
|
656
|
-
- `feature_type`: `Page+API` or `API-only`
|
|
657
|
-
- `output_path`: `{iterations_dir}/{iteration}/02.feature-design/{feature_id}-{feature-name-slug}-api-contract.md`
|
|
652
|
+
If **2+ Feature Specs** in registry:
|
|
653
|
+
|
|
654
|
+
1. **Initialize DISPATCH-PROGRESS.json for API Contract stage**:
|
|
655
|
+
|
|
656
|
+
> ⚠️ Use `--tasks-file` instead of `--tasks` to avoid PowerShell JSON parsing issues.
|
|
658
657
|
|
|
659
|
-
|
|
660
|
-
|
|
661
|
-
|
|
662
|
-
|
|
658
|
+
```bash
|
|
659
|
+
# Step 1: Write tasks JSON to temp file inside iteration directory
|
|
660
|
+
# Create .tasks-temp.json with the task array content
|
|
661
|
+
# Step 2: Initialize with --tasks-file
|
|
662
|
+
node {update_progress_script} init --file {iterations_dir}/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --stage 02_feature_design_api_contract --tasks-file {iterations_dir}/{iteration}/02.feature-design/.tasks-temp.json
|
|
663
|
+
# Step 3: Delete .tasks-temp.json after successful init
|
|
664
|
+
```
|
|
665
|
+
|
|
666
|
+
Example `.tasks-temp.json` content:
|
|
667
|
+
```json
|
|
668
|
+
[{"id":"F-CRM-01"},{"id":"F-CRM-02"},{"id":"F-CRM-03"}]
|
|
669
|
+
```
|
|
670
|
+
|
|
671
|
+
2. **Dispatch Workers** (batch of 6):
|
|
672
|
+
- Each worker receives:
|
|
673
|
+
- `skill_path`: `speccrew-fd-api-contract/SKILL.md`
|
|
674
|
+
- `context`:
|
|
675
|
+
- `feature_spec_path`: Path to one Feature Spec document
|
|
676
|
+
- `feature_id`: Feature ID (e.g., `F-CRM-01`)
|
|
677
|
+
- `feature_name`: Feature name — **MUST be the exact value from .checkpoints.json, used verbatim for output filename**
|
|
678
|
+
- `feature_type`: `Page+API` or `API-only`
|
|
679
|
+
- `output_path`: `{iterations_dir}/{iteration}/02.feature-design/{feature_id}-{feature-name-slug}-api-contract.md`
|
|
680
|
+
|
|
681
|
+
3. **Wait for batch completion**, update progress per worker:
|
|
682
|
+
```bash
|
|
683
|
+
node {update_progress_script} update-task --file {iterations_dir}/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --task-id {feature_id} --status completed
|
|
684
|
+
```
|
|
685
|
+
|
|
686
|
+
4. **Update `.checkpoints.json`** for each completed Feature:
|
|
687
|
+
- Set `api_contract_status` = `completed`
|
|
688
|
+
|
|
689
|
+
5. **Parallel execution**: One worker per Feature Spec document
|
|
690
|
+
|
|
691
|
+
6. **Output file naming**:
|
|
692
|
+
- Format: `{feature-id}-{feature-name-slug}-api-contract.md`
|
|
693
|
+
- Example: `F-CRM-01-customer-list-api-contract.md`
|
|
694
|
+
|
|
695
|
+
### 4.3.1 API Contract Error Handling
|
|
696
|
+
|
|
697
|
+
When any API Contract worker reports failure:
|
|
698
|
+
|
|
699
|
+
1. **Update status**:
|
|
700
|
+
```bash
|
|
701
|
+
node {update_progress_script} update-task --file {iterations_dir}/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --task-id {feature_id} --status failed --error "[Phase 4] {error_message}"
|
|
702
|
+
```
|
|
703
|
+
|
|
704
|
+
2. **Continue batch**: Do NOT stop entire batch for single failure. Complete remaining workers.
|
|
705
|
+
|
|
706
|
+
3. **Report to user**:
|
|
707
|
+
```
|
|
708
|
+
📊 Phase 4 (API Contract) — Batch complete: {success}/{total} succeeded, {failed} failed
|
|
709
|
+
├── ✅ F-SYS-01, F-SYS-02, ...
|
|
710
|
+
└── ❌ F-MEMBER-02: [error description]
|
|
711
|
+
|
|
712
|
+
Retry failed features? (yes/skip/abort)
|
|
713
|
+
```
|
|
714
|
+
|
|
715
|
+
4. **Retry strategy**: Same as Phase 3
|
|
716
|
+
- If user says "yes" → Re-dispatch failed features in next batch (Phase 4)
|
|
717
|
+
- If user says "skip" → Mark as `skipped`, continue to joint confirmation with partial results
|
|
718
|
+
- If user says "abort" → STOP workflow, report partial results
|
|
719
|
+
|
|
720
|
+
5. **Batch failure threshold**: If >50% workers in a batch fail → STOP entire workflow
|
|
663
721
|
|
|
664
722
|
### 4.4 Joint Confirmation
|
|
665
723
|
|
|
@@ -668,6 +726,10 @@ After both Feature Spec and API Contract documents are ready, present summary to
|
|
|
668
726
|
- List all API Contract documents with paths
|
|
669
727
|
- Request user confirmation before proceeding to system design phase
|
|
670
728
|
- After confirmation, API Contract becomes the read-only baseline for downstream stages
|
|
729
|
+
- After confirmation, update `.checkpoints.json`:
|
|
730
|
+
```bash
|
|
731
|
+
node {update_progress_script} write-checkpoint --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json --stage 02_feature_design --checkpoint api_contract_joint --passed true
|
|
732
|
+
```
|
|
671
733
|
|
|
672
734
|
### 4.5 Finalize Stage (Update Workflow Progress)
|
|
673
735
|
|
|
@@ -94,6 +94,19 @@ Stage 4: System Summary
|
|
|
94
94
|
<field name="completed_dir" required="true" type="string" desc="Marker file output directory for Worker results (absolute path required)"/>
|
|
95
95
|
</block>
|
|
96
96
|
|
|
97
|
+
<!-- ============================================================
|
|
98
|
+
Global Continuous Execution Rules
|
|
99
|
+
============================================================ -->
|
|
100
|
+
<block type="rule" id="GLOBAL-R1" level="forbidden" desc="Continuous execution constraints — NEVER violate">
|
|
101
|
+
<field name="text">DO NOT ask user "Should I continue?" or "How would you like to proceed?" between stages</field>
|
|
102
|
+
<field name="text">DO NOT offer options like "Full execution / Sample execution / Pause" — always execute ALL stages to completion</field>
|
|
103
|
+
<field name="text">DO NOT suggest "Let me split this into batches" or "Let's do this in parts" — process ALL features sequentially</field>
|
|
104
|
+
<field name="text">DO NOT pause to list what you plan to do next — just do it</field>
|
|
105
|
+
<field name="text">DO NOT ask for confirmation before generating output files</field>
|
|
106
|
+
<field name="text">DO NOT warn about "large number of files" or "this may take a while" — proceed with generation</field>
|
|
107
|
+
<field name="text">ONLY pause at explicit <event action="confirm"> blocks defined in the workflow</field>
|
|
108
|
+
</block>
|
|
109
|
+
|
|
97
110
|
<!-- ============================================================
|
|
98
111
|
Stage 0: Platform Detection
|
|
99
112
|
============================================================ -->
|
|
@@ -140,13 +153,12 @@ Discovered frontend platform: ${frontend.name} → Tech stack: Vue/React/UniApp
|
|
|
140
153
|
</block>
|
|
141
154
|
</block>
|
|
142
155
|
|
|
143
|
-
<!-- Step 4:
|
|
144
|
-
<block type="task" id="S0-B4" action="run-script" status="pending" desc="
|
|
145
|
-
<field name="command">node "
|
|
146
|
-
<field name="
|
|
147
|
-
<field name="arg">${
|
|
148
|
-
<field name="arg"
|
|
149
|
-
<field name="arg">${sync_state_bizs_dir}/platforms.json</field>
|
|
156
|
+
<!-- Step 4: Generate platform list JSON -->
|
|
157
|
+
<block type="task" id="S0-B4" action="run-script" status="pending" desc="Generate platforms.json from discovered modules and frontends">
|
|
158
|
+
<field name="command">node -e "const fs=require('fs'); const data=JSON.parse(process.argv[1]); fs.mkdirSync(process.argv[2], {recursive:true}); fs.writeFileSync(process.argv[2]+'/platforms.json', JSON.stringify(data,null,2)); console.log('platforms.json written')"</field>
|
|
159
|
+
<field name="note">The LLM constructs the platforms array from S0-L1 and S0-L2 discovery results, then writes it via this inline script. No external platform-detector.js is needed.</field>
|
|
160
|
+
<field name="arg">${platforms_json_string}</field>
|
|
161
|
+
<field name="arg">${sync_state_bizs_dir}</field>
|
|
150
162
|
<field name="output" var="platforms" from="${sync_state_bizs_dir}/platforms.json"/>
|
|
151
163
|
</block>
|
|
152
164
|
|
|
@@ -984,3 +996,33 @@ After all 5 stages complete, return a summary object to the caller:
|
|
|
984
996
|
}
|
|
985
997
|
}
|
|
986
998
|
```
|
|
999
|
+
|
|
1000
|
+
---
|
|
1001
|
+
|
|
1002
|
+
## CONTINUOUS EXECUTION RULES
|
|
1003
|
+
|
|
1004
|
+
This skill MUST execute all stages continuously without unnecessary interruptions.
|
|
1005
|
+
|
|
1006
|
+
### FORBIDDEN Interruptions
|
|
1007
|
+
|
|
1008
|
+
1. DO NOT ask user "Should I continue?" after completing a stage
|
|
1009
|
+
2. DO NOT suggest "Let me split this into batches" or "Let's do this in parts"
|
|
1010
|
+
3. DO NOT pause to list what you plan to do next — just do it
|
|
1011
|
+
4. DO NOT ask for confirmation before generating output files
|
|
1012
|
+
5. DO NOT warn about "large number of files" — proceed with generation
|
|
1013
|
+
6. DO NOT offer "Should I proceed with the remaining items?"
|
|
1014
|
+
7. DO NOT present options like "Full execution / Sample execution / Pause"
|
|
1015
|
+
|
|
1016
|
+
### When to Pause (ONLY these cases)
|
|
1017
|
+
|
|
1018
|
+
1. Explicit `<event action="confirm">` blocks in the workflow (e.g., Stage 0 platform confirmation)
|
|
1019
|
+
2. Ambiguous requirements that genuinely need clarification
|
|
1020
|
+
3. Unrecoverable errors that prevent further progress (failure rate > 50%)
|
|
1021
|
+
4. Security-sensitive operations (e.g., deleting existing files)
|
|
1022
|
+
|
|
1023
|
+
### Batch Execution Behavior
|
|
1024
|
+
|
|
1025
|
+
- When multiple features need processing, process ALL of them sequentially without asking
|
|
1026
|
+
- Use marker files (.done.json) to track progress, enabling resumption if interrupted by context limits
|
|
1027
|
+
- If context window is approaching limit, save progress to checkpoint and inform user how to resume
|
|
1028
|
+
- NEVER voluntarily stop mid-batch to ask if user wants to continue
|