speccrew 0.5.3 → 0.5.5

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
 
@@ -70,6 +71,14 @@ Phase 4: API Contract Generation
 4. **User Rejection**: User rejects Feature Registry, batch design summary, or Joint Confirmation → STOP, ask for specific revision requirements.
 5. **Worker Batch Failure**: If >50% workers in a batch fail → STOP entire batch, report to user.
 
+## TIMESTAMP INTEGRITY
+
+> **All timestamps in progress files (.checkpoints.json, DISPATCH-PROGRESS.json, WORKFLOW-PROGRESS.json) are generated exclusively by `update-progress.js` script.**
+
+1. **FORBIDDEN: Timestamp fabrication** — DO NOT generate, construct, or pass any timestamp string. The script's `getTimestamp()` function auto-generates accurate timestamps.
+2. **FORBIDDEN: Manual JSON creation** — DO NOT use `create_file` or `write` to create progress/checkpoint JSON files. ALWAYS use the appropriate `update-progress.js` command.
+3. **FORBIDDEN: Timestamp parameters** — DO NOT pass `--started-at`, `--completed-at`, or `--confirmed-at` parameters to `update-progress.js` commands. These parameters are deprecated.
+
 # Workflow
 
 ## Phase 0: Workflow Progress Management
@@ -284,6 +293,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:
@@ -304,8 +322,7 @@ After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
    - Any features to add, remove, or merge?
 
    IF user requests changes → update .checkpoints.json, then re-present.
-   ONLY after user confirms → update function_decomposition.passed = true,
-   set confirmed_at via: node -e "console.log(new Date().toISOString())"
+   ONLY after user confirms → update function_decomposition.passed = true.
    Then proceed to Phase 3.
    ```
 
@@ -328,6 +345,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.
 
 ---
 
@@ -366,7 +384,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
@@ -420,7 +438,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

package/.speccrew/agents/speccrew-product-manager.md

@@ -859,8 +859,7 @@ node speccrew-workspace/scripts/update-progress.js write-checkpoint \
 ```bash
 node speccrew-workspace/scripts/update-progress.js update-workflow \
   --file speccrew-workspace/iterations/{iteration}/WORKFLOW-PROGRESS.json \
-  --stage 01_prd --status completed \
-  --completed-at $(node -e "console.log(new Date().toISOString())")
+  --stage 01_prd --status completed
 ```
 
 **5.3.3 Update PRD Status**
@@ -944,6 +943,7 @@ Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 (if complex) → Phase 5
 - For complex requirements (3+ modules), dispatch Sub-PRD generation to parallel workers using `speccrew-pm-sub-prd-generate/SKILL.md`
 
 ### Must not do
+- **FORBIDDEN: Timestamp fabrication** — DO NOT generate or pass timestamp strings. All timestamps are auto-generated by `update-progress.js` script.
 - Do not make technical solution decisions (that's speccrew-planner's responsibility)
 - Do not skip manual confirmation to directly start the next stage
 - Do not assume business rules on your own; clarify unclear requirements with the user

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
 
@@ -162,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
@@ -192,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
@@ -350,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)

package/package.json

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

package/workspace-template/scripts/update-progress.js

@@ -34,8 +34,6 @@
  *      --output <text>         任务输出（completed 时使用）
  *      --error <text>          错误信息（failed 时使用）
  *      --error-category <cat>  错误类别（failed 时使用）
- *      --started-at <iso>      覆盖 started_at 时间戳
- *      --completed-at <iso>    覆盖 completed_at 时间戳
  *
  * 4. update-counts - 强制重算计数
  *    node update-progress.js update-counts --file <path>
@@ -56,9 +54,6 @@
  *      --stage <name>          阶段名称（必需）
  *      --status <status>       状态：pending/in_progress/completed/confirmed（必需）
  *      --output <text>         输出信息（可选）
- *      --started-at <iso>      覆盖 started_at 时间戳
- *      --completed-at <iso>    覆盖 completed_at 时间戳
- *      --confirmed-at <iso>    覆盖 confirmed_at 时间戳
  *
  * 输出格式：
  *   成功：{"success": true, "message": "...", "data": {...}}
@@ -555,24 +550,24 @@ function cmdUpdateTask(args) {
         task.status = args.status;
         task.updated_at = now;
 
-        // 根据状态自动设置时间戳
+        // 根据状态自动设置时间戳（始终使用脚本生成的真实时间，不接受外部参数）
         if (args.status === 'in_progress') {
-            task.started_at = args.startedAt || now;
+            task.started_at = now;
         } else if (args.status === 'partial') {
             // partial 状态：部分完成，可能已有 started_at，可选设置 completed_at
             if (!task.started_at) {
-                task.started_at = args.startedAt || now;
+                task.started_at = now;
             }
             if (args.output) {
                 task.output = args.output;
             }
         } else if (args.status === 'completed') {
-            task.completed_at = args.completedAt || now;
+            task.completed_at = now;
             if (args.output) {
                 task.output = args.output;
             }
         } else if (args.status === 'failed') {
-            task.completed_at = args.completedAt || now;
+            task.completed_at = now;
             if (args.error) {
                 task.error = args.error;
             }
@@ -750,16 +745,16 @@ function cmdUpdateWorkflow(args) {
         // 更新状态
         stage.status = args.status;
 
-        // 根据状态自动设置时间戳
+        // 根据状态自动设置时间戳（始终使用脚本生成的真实时间，不接受外部参数）
         if (args.status === 'in_progress') {
             // 如 started_at 已有值则不覆盖
             if (!stage.started_at) {
-                stage.started_at = args.startedAt || now;
+                stage.started_at = now;
             }
         } else if (args.status === 'completed') {
-            stage.completed_at = args.completedAt || now;
+            stage.completed_at = now;
         } else if (args.status === 'confirmed') {
-            stage.confirmed_at = args.confirmedAt || now;
+            stage.confirmed_at = now;
         }
 
         // 更新输出