speccrew 0.6.25 → 0.6.27

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

@@ -22,9 +22,9 @@ Phase 0: Stage Gate
 Phase 1: Preparation
   └── Identify PRD documents → Check existing specs
         ↓
-Phase 2: Knowledge Loading
-  └── Read PRDs → Discover platforms → Extract Features
-  └── Write .checkpoints.json → HARD STOP (user confirms Feature Registry)
+Phase 2: Load Feature List
+  └── Read .prd-feature-list.json → Verify structure
+  └── Write .checkpoints.json → HARD STOP (user confirms Feature List)
         ↓
 Phase 3: Feature Design — Two-Stage Pipeline
   └── 3a: Analyze (fd-feature-analyze)
@@ -51,7 +51,8 @@ Phase 4: API Contract Generation
 | Phase | Rule | Description |
 |-------|------|-------------|
 | Phase 0 | STAGE GATE | PRD must be confirmed before starting. If not → STOP |
-| Phase 2 | HARD STOP | Feature Registry must be confirmed by user before Phase 3 |
+| Phase 2 | HARD STOP | Feature List must be confirmed by user before Phase 3 |
+| Phase 2 | FILE REQUIRED | `.prd-feature-list.json` must exist. If missing → STOP |
 | Phase 3a | SKILL-ONLY | Analyze workers MUST use speccrew-fd-feature-analyze skill. Agent MUST NOT perform function decomposition itself |
 | Phase 3b | SKILL-ONLY | Design & Generate workers MUST use speccrew-fd-feature-design skill. Agent MUST NOT design features or write Feature Spec documents itself |
 | Phase 3c | HARD STOP (multi) | For 2+ Features: Agent MUST present batch summary and wait for user confirmation after Feature Specs are generated |
@@ -59,7 +60,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 |
+| ALL | NAME LOCK | After Phase 2 Feature List is confirmed, feature_name is immutable. All Skills MUST use the exact parameter value for output filenames. Name translation or substitution is FORBIDDEN |
 
 ## MANDATORY WORKER ENFORCEMENT
 
@@ -131,7 +132,7 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 1. **Skill Invocation Failure**: Any skill call returns error → STOP. Do NOT generate content manually.
 2. **Script Execution Failure**: `node ... update-progress.js` fails → STOP. Do NOT manually create/edit JSON files.
 3. **Missing Intermediate Artifacts**: `.feature-analysis.md` missing before Phase 3b → STOP.
-4. **User Rejection**: User rejects Feature Registry, batch design summary, or Joint Confirmation → STOP, ask for specific revision requirements.
+4. **User Rejection**: User rejects Feature List, 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
@@ -261,138 +262,121 @@ Check if feature specification documents already exist in the current iteration:
 - If feature specification documents already exist → Ask user whether to overwrite or create a new version
 - If no feature specification documents exist → Proceed directly to design phase
 
-## Phase 2: Knowledge Loading
+## Phase 2: Load Feature List
 
-After user confirmation, load knowledge in the following order:
+> 🛑 **ORCHESTRATOR RULES — Phase 2**
+> - ❌ DO NOT read PRD files directly
+> - ❌ DO NOT parse Feature Breakdown tables yourself
+> - ✅ ONLY read `.prd-feature-list.json` generated by PM Agent
+> - ✅ Verify file structure and content completeness
+> - ✅ ONLY present summary and collect user confirmation
 
-### Must Read
-Read all confirmed PRD documents specified by the user. PRD documents contain:
-- Feature background and goals
-- User stories and scenarios
-- Functional requirements description
-- Business process flows
-- Acceptance criteria
+### Step 1: Confirm PRD Path
 
-### Discover Frontend Platforms
+Confirm the PRD directory path with user. The PRD directory should contain:
+- Master PRD (`*-master-prd.md`)
+- Sub-PRD files (`*-sub-*.md`)
+- Feature list (`.prd-feature-list.json`)
 
-Read `{workspace_path}/knowledges/techs/techs-manifest.json` to identify all frontend platforms:
-- Look for platform entries with type starting with `web-` or `mobile-`
-- If multiple frontend platforms exist (e.g., web-vue + mobile-uniapp), frontend design MUST cover each platform separately
-- If only one frontend platform exists, design for that single platform
-- Store discovered platform list for use in Phase 3 worker dispatch
+Default path: `{iteration_path}/01.product-requirement`
 
-### Extract Feature Breakdown (Section 3.4)
+### Step 2: Read Feature List
 
-After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
+Read `.prd-feature-list.json` from the PRD directory:
 
-1. **Locate Section 3.4**: In each Sub-PRD, find the "Feature Breakdown" table under Section 3.4
+```bash
+Get-Content "{iteration_path}/01.product-requirement/.prd-feature-list.json" | ConvertFrom-Json
+```
 
-2. **Parse Feature Table**: Extract the following columns for each Feature:
-   - `Feature ID`: Unique identifier (e.g., `F-CRM-01`, `F-CRM-02`)
-   - `Feature Name`: Descriptive name (e.g., `Customer List Management`)
-   - `Type`: Either `Page+API` or `API-only`
-   - `Module`: Module identifier the feature belongs to (e.g., `M1-System`, `M2-Member`). Derive from the Sub-PRD's module classification.
-   - `Source PRD`: The Sub-PRD filename this feature was extracted from (e.g., `crm-system-sub-member.md`)
-   - `Dependencies`: List of prerequisite Feature IDs (if any)
+**If file does not exist:**
 
-3. **Build Feature Registry**: Consolidate all features across Sub-PRDs into a unified list.
+```
+❌ ERROR: Feature list file not found
+├── Expected path: {iteration_path}/01.product-requirement/.prd-feature-list.json
+└── This file should be generated by PM Agent during Sub-PRD dispatch
 
-4. **Write Feature Registry to `.checkpoints.json`**:
+🛑 HARD STOP
+Please ensure PRD phase completed successfully before starting Feature Design.
+```
 
-   Write or update the checkpoint file at:
-   ```
-   {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json
-   ```
+**Verify file structure:**
+- File exists and is valid JSON
+- Contains `modules` array
+- Each module has:
+  - `module_id`: Unique identifier
+  - `module_name`: Display name
+  - `features`: Array of feature objects
+- Each feature has:
+  - `feature_id`: Feature identifier (e.g., `F-CRM-01`)
+  - `feature_name`: Feature name
+  - `feature_type`: `Page+API` or `API-only`
+  - `dependencies`: Array of prerequisite Feature IDs
 
-   Structure — each feature has individual status fields for full checklist tracking:
-   ```json
-   {
-     "stage": "02_feature_design",
-     "checkpoints": {
-       "function_decomposition": {
-         "passed": false,
-         "confirmed_at": null,
-         "description": "Feature Registry extraction and confirmation",
-         "total_features": 42,
-         "total_modules": 13,
-         "features": [
-           {
-             "feature_id": "F-SYS-01",
-             "feature_name": "Account Login",
-             "type": "Page+API",
-             "module": "M1-System",
-             "source_prd": "crm-system-sub-system.md",
-             "dependencies": [],
-             "feature_spec_status": "pending",
-             "api_contract_status": "pending"
-           },
-           {
-             "feature_id": "F-MEMBER-01",
-             "feature_name": "Customer Info Management",
-             "type": "Page+API",
-             "module": "M2-Member",
-             "source_prd": "crm-system-sub-member.md",
-             "dependencies": ["F-SYS-01"],
-             "feature_spec_status": "pending",
-             "api_contract_status": "pending"
-           }
-         ]
-       },
-       "feature_spec_review": {
-         "passed": false,
-         "confirmed_at": null
-       },
-       "api_contract_joint": {
-         "passed": false,
-         "confirmed_at": null
-       }
-     }
-   }
-   ```
+### Step 3: Extract Feature Statistics
 
-   **Feature status values:**
-   - `pending`: Not started
-   - `in_progress`: Worker dispatched
-   - `completed`: Worker finished successfully
-   - `failed`: Worker failed (needs retry)
-   - `confirmed`: User confirmed the output
+From the feature list, extract:
 
-   **After each worker completes**, update the corresponding feature's status:
-   - Feature Spec worker done → set `feature_spec_status` = `completed`
-   - API Contract worker done → set `api_contract_status` = `completed`
+```
+📊 Feature List Summary
+├── Total Modules: {module_count}
+├── Total Features: {total_feature_count}
+├── Features by Type:
+│   ├── Page+API: {page_api_count}
+│   └── API-only: {api_only_count}
+└── Features by Module:
+    ├── {module_1}: {count} features
+    ├── {module_2}: {count} features
+    └── ...
+```
 
-### 2.5a Feature Name Normalization
+### Step 4: Write Checkpoint
 
-Before presenting the Feature Registry to user:
+Write feature statistics to `.checkpoints.json`:
 
-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)
+```bash
+node {update_progress_script} write-checkpoint `
+  --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json `
+  --stage 02_feature_design `
+  --checkpoint function_decomposition `
+  --data '{"features": [...], "total_features": N, "total_modules": M}'
+```
 
-5. **Present Feature Registry to user for confirmation**:
+**Feature status values:**
+- `pending`: Not started
+- `in_progress`: Worker dispatched
+- `completed`: Worker finished successfully
+- `failed`: Worker failed (needs retry)
+- `confirmed`: User confirmed the output
 
-   Display the full feature table:
+**After each worker completes**, update the corresponding feature's status:
+- Feature Spec worker done → set `feature_spec_status` = `completed`
+- API Contract worker done → set `api_contract_status` = `completed`
 
-   | # | Feature ID | Feature Name | Type | Module | Dependencies |
-   |---|-----------|-------------|------|--------|--------------|
-   | 1 | F-SYS-01 | Account Login | Page+API | M1-System | - |
-   | 2 | F-MEMBER-01 | Customer Info | Page+API | M2-Member | F-SYS-01 |
-   | ... | ... | ... | ... | ... | ... |
+### Step 5: HARD STOP — User Confirmation
 
-   ⚠️ **HARD STOP — WAIT FOR USER CONFIRMATION**
+Present the Feature List to user and wait for confirmation before proceeding:
 
-   ```
-   DO NOT dispatch Feature Spec workers until user explicitly confirms the Feature Registry.
-   Ask user:
-   - Is the feature decomposition granularity appropriate?
-   - Are Feature IDs, Types, and dependencies correct?
-   - 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.
-   Then proceed to Phase 3.
-   ```
+Display the full feature table:
+
+| # | Feature ID | Feature Name | Type | Module | Dependencies |
+|---|-----------|-------------|------|--------|--------------|
+| 1 | F-SYS-01 | Account Login | Page+API | M1-System | - |
+| 2 | F-MEMBER-01 | Customer Info | Page+API | M2-Member | F-SYS-01 |
+| ... | ... | ... | ... | ... | ... |
+
+⚠️ **HARD STOP — WAIT FOR USER CONFIRMATION**
+
+```
+DO NOT dispatch Feature Spec workers until user explicitly confirms the Feature List.
+Ask user:
+- Is the feature decomposition granularity appropriate?
+- Are Feature IDs, Types, and dependencies correct?
+- Any features to add, remove, or merge?
+
+IF user requests changes → report error: Feature List is read-only (generated by PM Agent)
+ONLY after user confirms → update function_decomposition.passed = true.
+Then proceed to Phase 3.
+```
 
 ### Read on Demand
 When involving related business domains, read `{workspace_path}/knowledges/bizs/system-overview.md` first, then follow the links within it to navigate to:
@@ -417,7 +401,7 @@ When involving related business domains, read `{workspace_path}/knowledges/bizs/
 > 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.
+> 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 List is confirmed.
 
 ---
 
@@ -551,41 +535,59 @@ If only **1 Feature** in registry:
 
 ### Phase 3c: Confirm — Batch Spec Review (Multi-Feature Only)
 
+> 🛑 **ORCHESTRATOR RULES — Phase 3c**
+> - ❌ DO NOT read feature-spec.md files for summary aggregation
+> - ❌ DO NOT count functions/components/APIs by parsing Spec documents
+> - ✅ ONLY read DISPATCH-PROGRESS.json for summary data
+> - ✅ Summary metadata is written by each Worker via update-progress.js
+
 **Condition**: Execute ONLY when 2+ Features exist
 
 **Purpose**: Present batch Feature Spec summary and obtain user confirmation before proceeding to API Contract generation.
 
-1. **Read all `feature-spec.md` files** generated in Phase 3b
+#### Step 1: Read Progress Summary
 
-2. **Build Batch Spec Summary**:
+Read DISPATCH-PROGRESS.json to get completion status and metadata for all features:
 
-   | Feature ID | Feature Name | Functions | Frontend Components | APIs | Data Entities |
-   |------------|--------------|-----------|---------------------|------|---------------|
-   | F-CRM-01 | Customer List | 5 | 3 | 4 | 2 new, 1 mod |
-   | F-CRM-02 | Customer Detail | 4 | 2 | 3 | 1 new |
-   | ... | ... | ... | ... | ... | ... |
+```bash
+node {workspace_path}/scripts/update-progress.js read --file {dispatch_progress_path} --overview
+```
 
-3. **Present to User**:
-   ```
-   📋 Batch Feature Spec Summary
-   
-   Total Features: {N}
-   ├── Functions Designed: {total}
-   ├── Frontend Components: {total}
-   ├── Backend APIs: {total}
-   └── Data Entities: {new} new, {modified} modified
-   
-   [Summary table above]
-   
-   ⚠️ HARD STOP — Please review all Feature Specs before proceeding to API Contract generation.
-   ```
+The progress file contains each task's status and metadata (function_count, component_count, api_count, entity_count) updated by Workers upon completion.
+
+#### Step 2: Build Summary from Progress Data
+
+From the progress data, build the batch summary table:
+
+| Feature ID | Feature Name | Functions | Frontend Components | APIs | Data Entities | Status |
+|---|---|---|---|---|---|---|
+
+> 🛑 **DO NOT read individual feature-spec.md files to build this summary.**
+> All summary data comes from DISPATCH-PROGRESS.json metadata fields.
+
+#### Step 3: Present Summary to User
+
+```
+📋 Batch Feature Spec Summary
+
+Total Features: {N}
+├── Functions Designed: {total}
+├── Frontend Components: {total}
+├── Backend APIs: {total}
+└── Data Entities: {new} new, {modified} modified
+
+[Summary table above]
+
+⚠️ HARD STOP — Please review all Feature Specs before proceeding to API Contract generation.
+```
+
+#### Step 4: HARD STOP — Wait for User Confirmation
 
-4. **HARD STOP**: Wait for user confirmation
-   - If user requests modification for specific Feature → Re-dispatch design worker for that Feature only
-   - If user confirms → Update `.checkpoints.json`:
-     ```bash
-     node {update_progress_script} write-checkpoint --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json --stage 02_feature_design --checkpoint feature_spec_review --passed true
-     ```
+- If user requests modification for specific Feature → Re-dispatch design worker for that Feature only
+- If user confirms → Update `.checkpoints.json`:
+  ```bash
+  node {update_progress_script} write-checkpoint --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json --stage 02_feature_design --checkpoint feature_spec_review --passed true
+  ```
 
 ---
 

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

@@ -546,6 +546,62 @@ No knowledge base exists. A lightweight feature inventory scan is triggered to d
 > The scope was already determined by the matcher in Step 1.
 > Asking "do you want to continue?" mid-way is FORBIDDEN.
 >
+> **Path B Step 3.5: Generate Graph Data**
+>
+> After ALL feature analysis Workers in Step 3 complete, dispatch Graph Workers for each completed analysis task:
+>
+> **For each completed API analysis task** (analyzer_skill = speccrew-knowledge-bizs-api-analyze):
+> - Dispatch Worker with skill: `speccrew-knowledge-bizs-api-graph`
+> - Input: the generated analysis document from Step 3
+> - Output: `.graph.json` file with nodes (api, service, table, dto) and edges (operates, invokes, references, depends-on, maps-to)
+>
+> **Agent Tool Invocation for API Graph Worker**:
+> ```
+> Use the Agent tool to invoke speccrew-task-worker:
+> - agent: speccrew-task-worker
+> - task: Execute speccrew-knowledge-bizs-api-graph for feature "{task.fileName}"
+> - context:
+>     skill: speccrew-knowledge-bizs-api-graph
+>     api_analysis_path: {workspace_path}/{task.documentPath}
+>     platform_id: {task.platform_id}
+>     output_dir: {sync_state_bizs_dir}/completed
+>     module: {task.module}
+>     fileName: {task.fileName}
+>     sourcePath: {task.sourcePath}
+>     sourceFile: features-{task.platform_id}.json
+>     language: {language}
+>     subpath: {task.subpath}
+> ```
+>
+> **For each completed UI analysis task** (analyzer_skill = speccrew-knowledge-bizs-ui-analyze):
+> - Dispatch Worker with skill: `speccrew-knowledge-bizs-ui-graph`
+> - Input: the generated UI analysis document from Step 3
+> - Output: `.graph.json` file with UI component nodes and relationships
+>
+> **Agent Tool Invocation for UI Graph Worker**:
+> ```
+> Use the Agent tool to invoke speccrew-task-worker:
+> - agent: speccrew-task-worker
+> - task: Execute speccrew-knowledge-bizs-ui-graph for feature "{task.fileName}"
+> - context:
+>     skill: speccrew-knowledge-bizs-ui-graph
+>     fileName: {task.fileName}
+>     sourcePath: {source_path}/{task.sourcePath}
+>     documentPath: {workspace_path}/{task.documentPath}
+>     module: {task.module}
+>     platform_type: {task.platform_type}
+>     platform_subtype: {task.platform_subtype}
+>     completed_dir: {sync_state_bizs_dir}/completed
+>     sourceFile: features-{task.platform_id}.json
+>     status: success
+>     analysisNotes: "Graph data generation from UI analysis"
+>     language: {language}
+> ```
+>
+> **Dispatch Strategy**: Same batch parallel strategy as Step 3 (max 5 Workers per batch).
+>
+> ⚠️ Step 3.5 MUST complete before Step 4 (Module Summaries). Graph data enriches module summaries.
+>
 > **Path B Step 4: Generate Module Summaries**
 > For each matched module, dispatch Worker with `speccrew-knowledge-module-summarize` skill:
 > ```
@@ -1187,10 +1243,13 @@ From the Skill's Step 12c output, collect:
 - `module_design_file`: Path to `.module-design.md`
 - `output_dir`: Directory for Sub-PRD files (same as Master PRD directory)
 - Module list with context for each module:
+  - `module_id`: Unique identifier for the module (used for feature list indexing)
   - `module_name`, `module_key`, `module_scope`, `module_entities`
-  - `module_user_stories`, `module_requirements`, `module_features`
+  - `module_user_stories`, `module_requirements`
   - `module_dependencies`
 
+> **Note**: The dispatch plan now contains only scheduling fields (module metadata, dependencies). Feature data (`module_features`) is stored separately in `.prd-feature-list.json`, which will be used by FD Agent for Feature Registry initialization.
+
 **Store these values as workflow context variables for use in Worker dispatches.**
 
 ---
@@ -1327,6 +1386,7 @@ Use the Agent tool to invoke speccrew-task-worker:
 - task: Generate Sub-PRD for module "{module_name}"
 - context:
     skill: speccrew-pm-sub-prd-generate
+    module_id: {module_id}
     module_name: {module_name}
     module_key: {module_key}
     module_scope: {module_scope}
@@ -1349,13 +1409,14 @@ Use the Agent tool to invoke speccrew-task-worker:
 | Parameter | Source | Description |
 |-----------|--------|-------------|
 | `skill` | Fixed | `speccrew-pm-sub-prd-generate` |
+| `module_id` | Dispatch Plan | Unique identifier for the module (used for feature list indexing) |
 | `module_name` | Dispatch Plan | Display name (e.g., "Customer Management") |
 | `module_key` | Dispatch Plan | Identifier for file naming (e.g., "customer") |
 | `module_scope` | Dispatch Plan | What this module covers |
 | `module_entities` | Dispatch Plan | Core business entities |
 | `module_user_stories` | Dispatch Plan | Module-specific user stories |
 | `module_requirements` | Dispatch Plan | Module-specific functional requirements (P0/P1/P2) |
-| `module_features` | Dispatch Plan | Feature Breakdown entries for this module |
+| `module_features` | Dispatch Plan | Feature Breakdown entries for this module (used by Sub-PRD Skill to generate content and write to feature list) |
 | `module_dependencies` | Dispatch Plan | Dependencies on other modules |
 | `master_prd_path` | Dispatch Plan | Path to the Master PRD |
 | `clarification_file` | Step 5.1 | Path to `.clarification-summary.md` |
@@ -1516,6 +1577,41 @@ node "{update_progress_script}" write-checkpoint `
   --status passed
 ```
 
+**Step 5.5.5: Verify Feature List Completeness**
+
+After all Sub-PRDs are generated, verify that `.prd-feature-list.json` contains complete feature data:
+
+1. **Read feature list file**:
+   ```bash
+   Get-Content "{iterations_dir}/{iteration}/01.product-requirement/.prd-feature-list.json" | ConvertFrom-Json
+   ```
+
+2. **Verify structure**:
+   - File exists and is valid JSON
+   - Contains `modules` array
+   - Each module has `module_id` and `features` array
+
+3. **Verify completeness**:
+   - Module count in feature list should equal `totalModules` from dispatch plan
+   - If any module is missing, display WARNING:
+   ```
+   ⚠️ WARNING: Feature list incomplete
+   ├── Expected modules: {expected_count}
+   ├── Found modules: {actual_count}
+   └── Missing modules: {missing_module_ids}
+
+   Feature list will be used by FD Agent for Feature Registry initialization.
+   Missing modules may cause errors in Feature Design phase.
+   ```
+
+4. **If verification passes**:
+   ```
+   ✅ Feature list verification passed
+   ├── Modules: {count}
+   ├── Total features: {total_features}
+   └── Ready for Feature Design phase
+   ```
+
 **Before proceeding to Phase 6, verify:**
 - [ ] All workers were dispatched via speccrew-task-worker (one Worker per module)
 - [ ] No Sub-PRD was generated by PM Agent directly
@@ -1761,12 +1857,13 @@ After PRD verification passes and user has confirmed, delete intermediate proces
 - `{iteration_path}/01.product-requirement/.checkpoints.json` (execution checkpoint tracking)
 - `{iteration_path}/01.product-requirement/.prd-generation-report.md` (intermediate generation report)
 - `{iteration_path}/01.product-requirement/.prd-completion-report.md` (completion report)
-- `{iteration_path}/01.product-requirement/.sub-prd-dispatch-plan.json` (Sub-PRD dispatch plan)
+- `{iteration_path}/01.product-requirement/.sub-prd-dispatch-plan.json` (dispatch plan — no longer needed after dispatch complete)
 
 **Files to KEEP (referenced by downstream phases):**
 - Master PRD and all Sub-PRD documents (`*-prd.md`, `*-sub-*.md`)
 - `.clarification-summary.md`
 - `.module-design.md`
+- `.prd-feature-list.json` (Feature list for Feature Design phase — used by FD Agent to load Feature Registry)
 - `.clarification-questions-round-*.md` (optional, for reference)
 
 ⚠️ **Only execute cleanup AFTER:**

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

@@ -510,6 +510,26 @@ node speccrew-workspace/scripts/update-progress.js write-checkpoint \
 
 Log: "✅ Feature Spec generation completed. Checkpoint feature_spec_review passed."
 
+## Step 9: Update Progress with Metadata
+
+After generating the Feature Spec document, update the task in DISPATCH-PROGRESS.json with summary metadata:
+
+```bash
+node {workspace_path}/scripts/update-progress.js update-task \
+  --file {dispatch_progress_path} \
+  --task-id {feature_task_id} \
+  --status completed \
+  --metadata '{"function_count": X, "component_count": Y, "api_count": Z, "entity_count": W}'
+```
+
+Where:
+- `function_count`: Number of functions defined in the Feature Spec
+- `component_count`: Number of frontend components identified
+- `api_count`: Number of API endpoints defined
+- `entity_count`: Number of data entities defined
+
+⚠️ This step is MANDATORY — the FD Agent relies on this metadata for batch summary in Phase 3c.
+
 ---
 
 # Key Rules
@@ -555,6 +575,7 @@ Log: "✅ Feature Spec generation completed. Checkpoint feature_spec_review pass
 - [ ] **[CRITICAL]** Processing Logic uses Mermaid flowchart TD (NOT ASCII)
 - [ ] All Mermaid diagrams follow mermaid-rule.md compliance rules
 - [ ] `.checkpoints.json` updated via script
+- [ ] **CRITICAL**: DISPATCH-PROGRESS.json updated with metadata (function_count, component_count, api_count, entity_count)
 - [ ] No technology decisions included
 - [ ] No intermediate design-data artifact created
 - [ ] **CRITICAL — Business Content Only**: Verify ALL sections use business-level descriptions. Zero tolerance for: file paths, code snippets, SQL, framework names, component names, technical types

package/.speccrew/skills/speccrew-pm-sub-prd-generate/SKILL.md

@@ -30,6 +30,7 @@ tools: Read, Write, Glob, Grep
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
+| module_id | Yes | Module ID for feature registry (e.g., "M1", "M2") |
 | module_name | Yes | Human-readable module name (e.g., "Customer Management") |
 | module_key | Yes | Module identifier for file naming (e.g., "customer") |
 | module_scope | Yes | What this module covers |
@@ -188,3 +189,90 @@ IF verification fails:
   → Output: "❌ Sub-PRD verification failed: {reason}"
   → Attempt to fix the specific issue
 ```
+
+## Step 5: Write Module Features to Feature List
+
+> **Purpose:** Separate feature data from dispatch plan into dedicated `.prd-feature-list.json` file.
+> Each Sub-PRD Worker writes its module's features upon completion.
+
+### 5.1 Determine Feature List File Path
+
+```
+feature_list_path = dirname(output_path) + '/.prd-feature-list.json'
+```
+
+This is the same directory containing `.sub-prd-dispatch-plan.json`.
+
+### 5.2 Read or Initialize Feature List File
+
+```javascript
+IF file exists at feature_list_path:
+  feature_list = read_json(feature_list_path)
+ELSE:
+  feature_list = {
+    "created_at": "{timestamp from update-progress.js}",
+    "updated_at": "{timestamp from update-progress.js}",
+    "modules": []
+  }
+```
+
+> ⚠️ **Timestamp constraint:** Use `node scripts/update-progress.js write-checkpoint` or similar script to get accurate timestamps. DO NOT fabricate timestamps.
+
+### 5.3 Build Current Module Feature Entry
+
+Construct the module entry from input parameters:
+
+```json
+{
+  "module_id": "{module_id}",
+  "module_name": "{module_name}",
+  "module_key": "{module_key}",
+  "source_prd": "{feature_name}-sub-{module_key}.md",
+  "feature_count": {module_features.length},
+  "features": [
+    // Map each item in module_features to:
+    {
+      "feature_id": "{item.feature_id}",
+      "feature_name": "{item.feature_name}",
+      "type": "{item.type}",
+      "priority": "{item.priority}",
+      "sub_features": "{item.sub_features}",
+      "description": "{item.description}"
+    }
+  ]
+}
+```
+
+### 5.4 Merge into Feature List
+
+```javascript
+existing_index = find_index(feature_list.modules, m => m.module_key === module_key)
+
+IF existing_index >= 0:
+  // Retry scenario: replace existing entry
+  feature_list.modules[existing_index] = module_entry
+ELSE:
+  // New module: append
+  feature_list.modules.push(module_entry)
+
+// Update timestamp
+feature_list.updated_at = "{current timestamp}"
+```
+
+### 5.5 Write Feature List File
+
+Write the updated `feature_list` to `{feature_list_path}` using `create_file`.
+
+### 5.6 Report Result
+
+```
+IF write succeeds:
+  → Output: "✅ Feature list updated: {feature_count} features for module {module_id}"
+IF write fails:
+  → Output: "⚠️ Feature list write failed: {error}"
+  → Continue without blocking Sub-PRD completion
+```
+
+---
+
+> **Note:** Step 5 is a pure incremental operation. Failure here should NOT affect the Sub-PRD file generation result. The primary deliverable is the Sub-PRD document itself.

package/package.json

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