speccrew 0.5.2 → 0.5.4

package/.speccrew/agents/speccrew-feature-designer.md

@@ -59,6 +59,7 @@ Phase 4: API Contract Generation
 | Phase 4 | HARD STOP | Joint Confirmation must be confirmed by user before finalizing |
 | ALL | ABORT ON FAILURE | If any skill invocation fails → STOP and report. Do NOT attempt to generate content manually as fallback |
 | ALL | SCRIPT ENFORCEMENT | All .checkpoints.json and WORKFLOW-PROGRESS.json updates via update-progress.js script. Manual JSON creation FORBIDDEN |
+| ALL | NAME LOCK | After Phase 2 Feature Registry is confirmed, feature_name is immutable. All Skills MUST use the exact parameter value for output filenames. Name translation or substitution is FORBIDDEN |
 
 ## ABORT CONDITIONS
 
@@ -284,6 +285,15 @@ After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
    - Feature Spec worker done → set `feature_spec_status` = `completed`
    - API Contract worker done → set `api_contract_status` = `completed`
 
+### 2.5a Feature Name Normalization
+
+Before presenting the Feature Registry to user:
+
+1. **Extract exact names** from PRD Section 3.4 table — use the name column value verbatim
+2. **Store as-is** in `.checkpoints.json` `feature_name` field — no translation, no slug conversion
+3. **Validate uniqueness**: Ensure no two Features share the same `feature_name`
+4. **Language rule**: `feature_name` MUST preserve the PRD's original language (Chinese names stay Chinese)
+
 5. **Present Feature Registry to user for confirmation**:
 
    Display the full feature table:
@@ -328,6 +338,7 @@ When involving related business domains, read `speccrew-workspace/knowledges/biz
 > 4. **DO NOT generate Feature Spec documents yourself.** Your role is to DISPATCH workers.
 > 5. **Phase 3a → 3b → 3c is STRICTLY SERIAL.** Each phase must complete before the next begins.
 > 6. **Intermediate artifacts are MANDATORY.** .feature-analysis.md must exist before Phase 3b.
+> 7. **Feature name is LOCKED after Phase 2 confirmation.** All Worker dispatch parameters MUST use the exact `feature_name` from `.checkpoints.json`. DO NOT derive, translate, or modify feature names at any point after the Feature Registry is confirmed.
 
 ---
 
@@ -355,9 +366,9 @@ If only **1 Feature** in registry:
 
 If **2+ Features** in registry:
 
-1. **Initialize/Update DISPATCH-PROGRESS.json**:
+1. **Initialize DISPATCH-PROGRESS.json**:
    ```bash
-   node speccrew-workspace/scripts/update-progress.js init-dispatch --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --stage 02_feature_design_analyze --tasks "F-CRM-01,F-CRM-02,F-CRM-03"
+   node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --stage 02_feature_design_analyze --tasks "[{\"id\":\"F-CRM-01\"},{\"id\":\"F-CRM-02\"},{\"id\":\"F-CRM-03\"}]"
    ```
 
 2. **Dispatch Workers** (batch of 6):
@@ -366,7 +377,7 @@ If **2+ Features** in registry:
      - `context`:
        - `prd_path`: Path to Sub-PRD
        - `feature_id`: Feature ID
-       - `feature_name`: Feature name
+       - `feature_name`: Feature name — **MUST be the exact value from .checkpoints.json, used verbatim for output filename**
        - `feature_type`: `Page+API` or `API-only`
        - `iteration_id`: Current iteration
        - `frontend_platforms`: Platform list
@@ -408,9 +419,9 @@ If only **1 Feature** in registry:
 
 #### Multiple Features (Worker Dispatch)
 
-1. **Update DISPATCH-PROGRESS.json**:
+1. **Initialize DISPATCH-PROGRESS.json for Design & Generate stage**:
    ```bash
-   node speccrew-workspace/scripts/update-progress.js update-stage --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --stage 02_feature_design_spec
+   node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --stage 02_feature_design_spec --tasks "[{\"id\":\"F-CRM-01\"},{\"id\":\"F-CRM-02\"},{\"id\":\"F-CRM-03\"}]"
    ```
 
 2. **Dispatch Workers** (batch of 6):
@@ -420,7 +431,7 @@ If only **1 Feature** in registry:
        - `feature_analysis_path`: Path to `.feature-analysis.md`
        - `prd_path`: Path to Sub-PRD
        - `feature_id`: Feature ID
-       - `feature_name`: Feature name
+       - `feature_name`: Feature name — **MUST be the exact value from .checkpoints.json, used verbatim for output filename**
        - `feature_type`: `Page+API` or `API-only`
        - `frontend_platforms`: Platform list
        - `output_path`: Path for final spec
@@ -470,7 +481,7 @@ If only **1 Feature** in registry:
    - If user requests modification for specific Feature → Re-dispatch design worker for that Feature only
    - If user confirms → Update `.checkpoints.json`:
      ```bash
-     node speccrew-workspace/scripts/update-progress.js write-checkpoint --file speccrew-workspace/iterations/{iteration}/02.feature-design/.checkpoints.json --checkpoint feature_spec_review --passed true
+     node speccrew-workspace/scripts/update-progress.js write-checkpoint --file speccrew-workspace/iterations/{iteration}/02.feature-design/.checkpoints.json --stage 02_feature_design --checkpoint feature_spec_review --passed true
      ```
 
 ---
@@ -483,7 +494,7 @@ When any worker (analyze/design) reports failure:
 
 2. **Update status**: Set the failed feature's status in `.checkpoints.json`:
    ```bash
-   node speccrew-workspace/scripts/update-progress.js update-task --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --task {feature_id} --status failed --error "[{phase}] {error_message}"
+   node speccrew-workspace/scripts/update-progress.js update-task --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --task-id {feature_id} --status failed --error "[{phase}] {error_message}"
    ```
 
 3. **Continue batch**: Do NOT stop entire batch for single failure. Complete remaining workers.

package/.speccrew/skills/speccrew-fd-feature-analyze/SKILL.md

@@ -31,6 +31,7 @@ This skill applies ISA-95 Stages 1-3 as an internal thinking framework for analy
 1. **FORBIDDEN: Script execution failure** — If `update-progress.js` fails, HARD STOP and report error
 2. **FORBIDDEN: Hand-written `.checkpoints.json`** — ALWAYS use `update-progress.js` script
 3. **FORBIDDEN: Skip Checkpoint A** — User confirmation required before proceeding to design phase (unless `skip_checkpoint=true`)
+4. **FORBIDDEN: Rename features** — Output filename MUST use the exact `feature_name` parameter value. DO NOT translate, abbreviate, paraphrase, or substitute with alternative names found in PRD content. The `feature_name` parameter is the SINGLE SOURCE OF TRUTH for file naming.
 
 ## Step 1: Read PRD Input
 
@@ -144,6 +145,7 @@ After user confirms (or if skipped):
 ```bash
 node speccrew-workspace/scripts/update-progress.js write-checkpoint \
   --file speccrew-workspace/iterations/{iteration_id}/02.feature-design/.checkpoints.json \
+  --stage 02_feature_design \
   --checkpoint function_decomposition \
   --passed true
 ```
@@ -161,6 +163,11 @@ Write analysis results to `.feature-analysis.md`:
 | With feature_id | `{prd_parent}/02.feature-design/{feature-id}-{feature-name}.feature-analysis.md` |
 | Legacy mode | `{prd_parent}/02.feature-design/.feature-analysis.md` |
 
+**CRITICAL — Filename Lock Rule:**
+- `{feature-name}` in the output path MUST be the exact value of the `feature_name` parameter
+- If PRD uses a different name for the same feature → use `feature_name` parameter for filename, note the discrepancy in the document header
+- Example: parameter `feature_name = "店铺信息管理"` → filename MUST contain "店铺信息管理", NOT "shop-management" or "多店切换"
+
 ### Output Structure
 
 ```markdown
@@ -191,6 +198,12 @@ Write analysis results to `.feature-analysis.md`:
 - **Data Changes**: {description}
 - **System Relationship**: [EXISTING]/[MODIFIED]/[NEW] — {explanation}
 
+## Name Discrepancy Notice (if applicable)
+- Parameter feature_name: {feature_name}
+- PRD actual feature name: {prd_name}
+- Discrepancy: {description}
+- File naming follows: parameter value (as per Filename Lock Rule)
+
 ## Decomposition Status
 - Checkpoint A: {passed/pending}
 - Confirmed at: {timestamp or null}

package/.speccrew/skills/speccrew-fd-feature-design/SKILL.md

@@ -39,6 +39,8 @@ ISA-95 Stages 4-6 as internal thinking framework:
 
 **NOTE:** Design process is internal — no intermediate design-data files are produced.
 
+**FORBIDDEN: Rename features** — Output filename MUST use the exact `feature_name` parameter value. DO NOT translate, abbreviate, paraphrase, or substitute with names derived from analysis content. The `feature_name` parameter is the SINGLE SOURCE OF TRUTH for file naming.
+
 ## Step 0: Precondition Check
 
 ### Step 0 Input Parameters
@@ -66,6 +68,15 @@ ISA-95 Stages 4-6 as internal thinking framework:
    - `functions[]`: Function breakdown list
    - `platforms[]`: Frontend platforms list
 
+### 0.3 Verify Feature Name Consistency
+
+1. Read the `Feature Name` field from `.feature-analysis.md` header
+2. Compare with `feature_name` parameter
+3. If different:
+   - Log: "⚠️ Name discrepancy: parameter='{feature_name}', analysis='{analysis_name}'"
+   - Continue with `feature_name` parameter value for all file naming
+   - Use the analysis file's actual content (not its filename) for design work
+
 ## Step 1: Frontend Design
 
 ### 1.0 Conditional Execution
@@ -325,6 +336,7 @@ After user confirms (or if skipped):
 ```bash
 node speccrew-workspace/scripts/update-progress.js write-checkpoint \
   --file speccrew-workspace/iterations/{iteration_id}/02.feature-design/.checkpoints.json \
+  --stage 02_feature_design \
   --checkpoint feature_design_review \
   --passed true
 ```
@@ -349,6 +361,11 @@ Log: "✅ Checkpoint B (feature_design_review) passed and recorded"
 - Master Spec: `{iteration_path}/02.feature-design/[master-name]-feature-spec.md`
 - Sub Specs: `{iteration_path}/02.feature-design/[sub-name]-feature-spec.md` (one per sub-feature)
 
+**CRITICAL — Filename Lock Rule:**
+- `{feature_name}` in the output path MUST be the exact value of the `feature_name` parameter
+- If analysis file uses a different name → use `feature_name` parameter for filename
+- Example: parameter `feature_name = "店铺信息管理"` → filename MUST contain "店铺信息管理", NOT "shop-management" or "多店切换"
+
 ### 5.2 Copy Template
 
 1. Read template: `templates/FEATURE-SPEC-TEMPLATE.md` (relative path from skill directory)
@@ -414,6 +431,7 @@ Set final checkpoint status:
 ```bash
 node speccrew-workspace/scripts/update-progress.js write-checkpoint \
   --file speccrew-workspace/iterations/{iteration_id}/02.feature-design/.checkpoints.json \
+  --stage 02_feature_design \
   --checkpoint feature_spec_review \
   --passed true
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "speccrew",
-  "version": "0.5.2",
+  "version": "0.5.4",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {