speccrew 0.7.75 → 0.7.76

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

@@ -316,657 +316,14 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 
 # Workflow
 
+> **Detailed Phase workflow is defined in the orchestration SKILL.xml.**
+> Agent MUST load and execute SKILL.xml block-by-block per EXECUTION PROTOCOL.
+> Phase Overview: P0(Stage Gate & Resume) → P0.5(IDE Detection) → P1(Preparation) → P2(Feature List & Confirm) → P3(Feature Design) → P4(API Contract) → P4.4(Joint Confirmation)
+
 ## AgentFlow Definition
 
 <!-- @skill: speccrew-feature-designer-orchestration -->
 
----
-
-## Phase 0: Workflow Progress Management
-
-> **Path Variables** (provided by caller as absolute paths):
-> - `workspace_path`: **MANDATORY absolute path** — Worker MUST use this for ALL script calls. Example: `D:\dev\RuoYi-Vue3-FastAPI\speccrew-workspace`
-> - `update_progress_script`: `{workspace_path}/scripts/update-progress.js`
-> - `iterations_dir`: `{workspace_path}/iterations`
-
-> **Stage Gate & Resume Checkpoint System** — Ensures proper flow between pipeline stages and supports resuming from interruptions.
-
-### 0.1 Stage Gate — Verify Upstream Completion
-
-Before starting any feature design work:
-
-1. **Read `WORKFLOW-PROGRESS.json` overview**:
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{iteration-id}/WORKFLOW-PROGRESS.json --overview
-   ```
-   - If the file does not exist → Skip to Phase 1
-
-2. **Verify PRD Stage Status**:
-   - Check: `stages.01_prd.status == "confirmed"` in the output
-   - If **NOT confirmed**:
-     - **STOP** — Do not proceed
-     - Report to user: "❌ **PRD stage has not been confirmed.** Please complete PRD confirmation first using the Product Manager agent. Current status: `{status}`"
-   - If **confirmed**:
-     - Read `stages.01_prd.outputs` to get PRD file paths
-     - Proceed to Step 0.2
-
-3. **Update Stage Status**:
-   ```bash
-   node {update_progress_script} update-workflow --file {iterations_dir}/{iteration-id}/WORKFLOW-PROGRESS.json --stage 02_feature_design --status in_progress
-   ```
-
-   > **PowerShell Compatibility**: On Windows PowerShell, do not use backslash (`\`) for line continuation. Write the entire command on a single line.
-
-### 0.2 Check Resume State (Checkpoint Recovery)
-
-If resuming from an interrupted session:
-
-1. **Read checkpoints** (if file exists):
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{iteration-id}/02.feature-design/.checkpoints.json --checkpoints
-   ```
-   - If the file does not exist → Start from Phase 1 (no previous progress)
-
-2. **Evaluate Checkpoint Status**:
-
-| Checkpoint | If Passed | Resume Point |
-|------------|-----------|--------------|
-| `function_decomposition.passed == true` | Skip Checkpoint A | Start from Step 3 (Frontend Design) |
-| `feature_spec_review.passed == true` | Skip Checkpoint A & B | Start from Phase 4 (API Contract Generation) |
-| `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?" |
-
-> Evaluate checkpoints from most complete to least complete. If `api_contract_joint.passed == true`, it takes precedence over all earlier checkpoints.
-
-3. **Display Resume Summary**:
-   ```
-   📋 Resume Status:
-   ├── function_decomposition: ✅ Passed
-   ├── feature_spec_review: ✅ Passed
-   └── api_contract_joint: ⏳ Pending
-
-   Resuming from: API Contract Generation phase
-   ```
-
-4. **User Confirmation**: Show resume point and ask "Continue from this checkpoint?"
-
-### 0.3 Check Dispatch Resume (Feature-Granular Recovery)
-
-If the iteration involves multiple Features:
-
-1. **Read `DISPATCH-PROGRESS.json` summary** (if file exists):
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --summary
-   ```
-   - If the file does not exist → No dispatch in progress, proceed normally
-
-2. **List Feature Task Status**:
-   ```
-   📊 Dispatch Status:
-   ├── F-CRM-01 (Customer List): ✅ Completed
-   ├── F-CRM-02 (Customer Detail): ⏳ Pending
-   └── F-CRM-03 (Customer Search API): ❌ Failed (error message)
-
-   Total: 3 | Completed: 1 | Failed: 1 | Pending: 1
-   ```
-
-3. **Resume Strategy**:
-   - Skip tasks with `status == "completed"`
-   - Re-execute tasks with `status == "failed"`
-   - Execute tasks with `status == "pending"`
-
-4. **User Confirmation**: Ask "Resume dispatch for pending/failed Features?"
-
----
-
-## Phase 1: Preparation
-
-When user requests to start feature design:
-
-### 1.1 Identify PRD Documents
-
-User must specify one or more confirmed PRD document paths:
-- Default path pattern: `{iterations_dir}/{number}-{type}-{name}/01.prd/[feature-name]-prd.md`
-- May involve multiple PRDs: master PRD + sub PRDs (e.g., `[feature-name]-sub-[module].md`)
-
-Confirm all related PRD documents that need to be designed into feature specifications.
-
-### 1.2 Check Existing Feature Specs
-
-Check if feature specification documents already exist in the current iteration:
-- Check path: `{iterations_dir}/{number}-{type}-{name}/02.feature-design/`
-- Look for existing `[feature-name]-feature-spec.md` files
-
-### 1.3 User Confirmation
-
-- 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: Load Feature List
-
-> 🛑 **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
-
-### Step 1: Confirm PRD Path
-
-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`)
-
-Default path: `{iteration_path}/01.product-requirement`
-
-### Step 2: Read Feature List
-
-Read `.prd-feature-list.json` from the PRD directory:
-
-```bash
-Get-Content "{iteration_path}/01.product-requirement/.prd-feature-list.json" | ConvertFrom-Json
-```
-
-**If file does not exist:**
-
-```
-❌ 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
-
-🛑 HARD STOP
-Please ensure PRD phase completed successfully before starting Feature Design.
-```
-
-**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
-
-### Step 3: Extract Feature Statistics
-
-From the feature list, extract:
-
-```
-📊 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
-    └── ...
-```
-
-### Step 4: Write Checkpoint
-
-Write feature statistics to `.checkpoints.json`:
-
-```bash
-node {update_progress_script} write-checkpoint `
-  --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json `
-  --stage 02_feature_design `
-  --checkpoint function_decomposition `
-  --passed true `
-  --description "Feature decomposition confirmed: N features across M modules"
-```
-
-> **Note**: Use `--passed` and `--description` for write-checkpoint. The `--data` parameter is NOT supported by update-progress.js.
-
-**Feature status values:**
-- `pending`: Not started
-- `in_progress`: Worker dispatched
-- `completed`: Worker finished successfully
-- `failed`: Worker failed (needs retry)
-- `confirmed`: User confirmed the output
-
-**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`
-
-### Step 5: HARD STOP — User Confirmation
-
-Present the Feature List to user and wait for confirmation before proceeding:
-
-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:
-- Related module business knowledge documents
-- Business process specifications
-- Domain glossary and standards
-
-**Do not load**: 
-- Technical architecture documents (handled by speccrew-system-designer)
-- Code conventions (handled by speccrew-system-designer/speccrew-dev)
-
-## Phase 3: Feature Design (Unified Analysis + Design)
-
-> ⚠️ **WORKER ENFORCEMENT REMINDER:**
-> Multiple items detected → MUST dispatch speccrew-task-worker.
-> DO NOT invoke skills directly. See MANDATORY WORKER ENFORCEMENT section.
-
-> 🛑 **ANTI-SKIP ENFORCEMENT (Phase 3 Context Reminder)**
-> 
-> You MUST NOT skip features for any reason:
-> - ❌ "Due to context window limits, I'll only process a representative sample"
-> - ❌ "For efficiency, I'll skip to the next phase after processing one batch"
-> - ❌ "I'll demonstrate the workflow with a few examples first"
-> 
-> **MANDATORY:** Process ALL features where status = "pending". No exceptions.
-> Phase 4 CANNOT start until Phase 3 counts.pending == 0.
-
-> ⚠️ **MANDATORY RULES FOR PHASE 3:**
-> 1. **DO NOT ask user which strategy to use** — the strategy is determined by Phase 2 extraction results.
-> 2. **DO NOT invoke skills directly** when there are multiple Features. You MUST dispatch `speccrew-task-worker` agents.
-> 3. **Dispatch granularity is PER FEATURE, not per module.** Each Feature gets its own worker.
-> 4. **DO NOT generate Feature Spec documents yourself.** Your role is to DISPATCH workers.
-> 5. **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.
-
-**Purpose**: Transform PRD requirements into complete Feature Spec documents in a single pass (unified analysis + design + document generation).
-
-**Skill**: `speccrew-fd-feature-design/SKILL.md`
-
-> 🛑 **PHASE 3 MANDATORY COMPLETION RULE**
-> You MUST process ALL features with status = "pending".
-> DO NOT skip any feature regardless of total count.
-> DO NOT proceed to Phase 4 until Phase 3 counts.pending == 0.
-
-### Prepare Task List for Dispatch
-
-> ⚠️ **CRITICAL: Two Different File Formats**
->
-> The `.prd-feature-list.json` and `init --tasks-file` expect DIFFERENT formats. Do NOT use one in place of the other.
-
-#### `.prd-feature-list.json` — Feature Metadata Registry
-
-This file is generated by PM Agent and contains the complete feature metadata with nested structure:
-
-```json
-{
-  "modules": [
-    {
-      "module_id": "M1-System",
-      "module_name": "System Management",
-      "features": [
-        {
-          "feature_id": "F-SYS-01",
-          "feature_name": "Account Login",
-          "feature_type": "Page+API",
-          "dependencies": []
-        }
-      ]
-    }
-  ]
-}
-```
-
-- **Purpose**: Source of truth for feature metadata (names, types, dependencies)
-- **Structure**: Nested `modules > features` array
-- **Used by**: Agent reads this to understand feature breakdown
-- **NOT for**: Direct use with `update-progress.js init` command
-
-#### `.tasks-temp.json` — Flat Task Array for init Command
-
-The `update-progress.js init --tasks-file` expects a **flat array** of task IDs:
-
-```json
-[
-  {"id": "F-SYS-01"},
-  {"id": "F-MEMBER-01"},
-  {"id": "F-CRM-01"}
-]
-```
-
-- **Purpose**: Initialize DISPATCH-PROGRESS.json task list
-- **Structure**: Flat array with `id` field only
-- **Used by**: `update-progress.js init --tasks-file <path>`
-- **Naming**: Recommend `.tasks-temp.json` (delete after init)
-
-#### Conversion Step
-
-Before initializing DISPATCH-PROGRESS.json, extract feature IDs from `.prd-feature-list.json`:
-
-1. Read `.prd-feature-list.json`
-2. Flatten `modules[].features[].feature_id` into array
-3. Write `[{"id": "F-XXX"}, ...]` to `.tasks-temp.json`
-4. Run `update-progress.js init --tasks-file .tasks-temp.json`
-5. Delete `.tasks-temp.json`
-
----
-
-### Single Feature (Direct Invocation)
-
-If only **1 Feature** in registry:
-
-- Skill path: `speccrew-fd-feature-design/SKILL.md`
-- Parameters:
-  - `prd_path`: Path to the Sub-PRD document
-  - `feature_id`: Feature ID (e.g., `F-CRM-01`)
-  - `feature_name`: Feature name (e.g., `Customer List Management`)
-  - `feature_type`: `Page+API` or `API-only`
-  - `iteration_id`: Current iteration identifier
-  - `frontend_platforms`: List of frontend platforms from techs-manifest
-  - `output_path`: `{iterations_dir}/{iteration}/02.feature-design/{feature-id}-{feature-name}-feature-spec.md`
-- Checkpoint A & B handled inside skill (analysis confirmation + design confirmation)
-
-**Output**: One `{feature-id}-{feature-name}-feature-spec.md` per Feature
-
----
-
-### Multiple Features (Worker Dispatch)
-
-> ⚠️ **DISPATCH PROMPT FORMAT REMINDER:**
-> When dispatching Workers, the prompt MUST contain ONLY skill path + context data parameters.
-> DO NOT include "执行要求", step sequences, or output directives.
-> Worker will read the skill's SKILL.xml for its execution plan.
-> See: MANDATORY: Worker Dispatch Prompt Format section above.
-
-1. **Initialize DISPATCH-PROGRESS.json**:
-
-   > ⚠️ Use `--tasks-file` instead of `--tasks` to avoid PowerShell JSON parsing issues.
-
-   ```bash
-   # Step 1: Write tasks JSON to temp file inside iteration directory
-   # Create .tasks-temp.json with the task array content
-   # Step 2: Initialize with --tasks-file
-   node {update_progress_script} init --file {iterations_dir}/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --stage 02_feature_design_spec --tasks-file {iterations_dir}/{iteration}/02.feature-design/.tasks-temp.json
-   # Step 3: Delete .tasks-temp.json after successful init
-   ```
-
-   Example `.tasks-temp.json` content:
-   ```json
-   [{"id":"F-CRM-01"},{"id":"F-CRM-02"},{"id":"F-CRM-03"}]
-   ```
-
-2. **Dispatch Workers** (batch of 6):
-   - Each worker receives:
-     - `skill_path`: `speccrew-fd-feature-design/SKILL.md`
-     - `context`:
-       - `workspace_path`: **Absolute path to speccrew-workspace directory** (MANDATORY for update-progress.js execution)
-       - `prd_path`: Path to Sub-PRD
-       - `feature_id`: Feature ID
-       - `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
-       - `output_path`: Path for final spec
-       - `skip_analysis_checkpoint`: `true` (batch mode — skips Checkpoint A, proceeds directly to design)
-
-3. **Wait for batch completion**, update progress per worker
-
-4. **Update `.checkpoints.json`** for each completed Feature:
-   - Set `feature_spec_status` = `completed`
-
-**Output**: One `{feature-id}-{feature-name}-feature-spec.md` per Feature
-
----
-
-### 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.
-
-#### Step 1: Read Progress Summary
-
-Read DISPATCH-PROGRESS.json to get completion status and metadata for all features:
-
-```bash
-node {workspace_path}/scripts/update-progress.js read --file {dispatch_progress_path} --overview
-```
-
-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
-
-- 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
-  ```
-
----
-
-### Phase 3 Error Handling
-
-When any worker reports failure:
-
-1. **Update status**:
-   ```bash
-   node {update_progress_script} update-task --file {iterations_dir}/{iteration}/02.feature-design/DISPATCH-PROGRESS.json --task-id {feature_id} --status failed --error "{error_message}"
-   ```
-
-2. **Continue batch**: Do NOT stop entire batch for single failure. Complete remaining workers.
-
-3. **Report to user**:
-   ```
-   📊 Phase 3 (Feature Design) — Batch complete: {success}/{total} succeeded, {failed} failed
-   ├── ✅ F-SYS-01, F-SYS-02, F-SYS-03, F-SYS-04, F-MEMBER-01
-   └── ❌ F-MEMBER-02: [error description]
-   
-   Retry failed features? (yes/skip/abort)
-   ```
-
-4. **Retry strategy**:
-   - If user says "yes" → Re-dispatch failed features in next batch
-   - If user says "skip" → Mark as `skipped`, continue to Phase 3c with partial results
-   - If user says "abort" → STOP workflow, report partial results
-
-5. **Batch failure threshold**: If >50% workers in a batch fail → STOP entire workflow, report to user
-
-## Phase 4: API Contract Generation
-
-After Feature Spec documents are confirmed by user, generate API Contract documents.
-
-### 4.1 Dispatch Mode Decision
-
-Follow the same dispatch mode as Phase 3:
-
-| Condition | API Contract Strategy |
-|-----------|----------------------|
-| 2+ Feature Specs | Worker dispatch — one worker per Feature Spec |
-| 1 Feature Spec | Direct skill invocation |
-
-### 4.2 Single Feature Spec (Direct Skill Invocation)
-
-Invoke API Contract skill directly:
-- Skill path: `speccrew-fd-api-contract/SKILL.md`
-- Parameters:
-  - `feature_spec_path`: Path to the Feature Spec document
-  - `feature_id`: Feature ID (e.g., `F-CRM-01`)
-  - `feature_type`: `Page+API` or `API-only`
-  - `output_path`: `{iterations_dir}/{iteration}/03.api-contract/{feature_id}-{feature-name-slug}-api-contract.md`
-
-**Note**: Both `Page+API` and `API-only` Features require API Contract documents.
-
-### 4.3 Multiple Feature Specs (Parallel Worker Dispatch)
-
-If **2+ Feature Specs** in registry:
-
-> ⚠️ **DISPATCH PROMPT FORMAT REMINDER:**
-> When dispatching Workers, the prompt MUST contain ONLY skill path + context data parameters.
-> DO NOT include "执行要求", step sequences, or output directives.
-> Worker will read the skill's SKILL.xml for its execution plan.
-> See: MANDATORY: Worker Dispatch Prompt Format section above.
-
-### Phase 4: API Contract — Task File Management
-
-⚠️ **CRITICAL: .tasks-temp.json Regeneration**
-
-Phase 3 deletes `.tasks-temp.json` after init. Phase 4 MUST regenerate it before init:
-
-1. Read `{iteration_path}/02.feature-design/DISPATCH-PROGRESS.json` (Phase 3 results)
-2. Extract ALL task IDs from the tasks array
-3. Build flat JSON array: `[{"id":"F-M01-01"},{"id":"F-M01-02"},...]`
-4. Write to `{iteration_path}/03.api-contract/.tasks-temp.json`
-5. Run init: `node {workspace_path}/scripts/update-progress.js init --file {iteration_path}/03.api-contract/DISPATCH-PROGRESS.json --stage 02_feature_design_api_contract --tasks-file {iteration_path}/03.api-contract/.tasks-temp.json`
-6. Delete `.tasks-temp.json` after successful init
-
-**DO NOT**:
-- Run ad-hoc PowerShell/Bash commands to parse `.prd-feature-list.json`
-- Create custom scripts to build task lists
-- Skip the init step and manually edit DISPATCH-PROGRESS.json
-
-1. **Initialize DISPATCH-PROGRESS.json for API Contract stage**:
-
-   > ⚠️ Use `--tasks-file` instead of `--tasks` to avoid PowerShell JSON parsing issues.
-
-   ```bash
-   # Step 1: Read Phase 3 DISPATCH-PROGRESS.json and extract all task IDs
-   # Build flat JSON array: [{"id":"F-XXX"},...] and write to .tasks-temp.json
-   # Step 2: Initialize with --tasks-file
-   node {update_progress_script} init --file {iterations_dir}/{iteration}/03.api-contract/DISPATCH-PROGRESS.json --stage 02_feature_design_api_contract --tasks-file {iterations_dir}/{iteration}/03.api-contract/.tasks-temp.json
-   # Step 3: Delete .tasks-temp.json after successful init
-   ```
-
-   Example `.tasks-temp.json` content:
-   ```json
-   [{"id":"F-CRM-01"},{"id":"F-CRM-02"},{"id":"F-CRM-03"}]
-   ```
-
-2. **Dispatch Workers** (batch of 6):
-   - Each worker receives:
-     - `skill_path`: `speccrew-fd-api-contract/SKILL.md`
-     - `context`:
-       - `workspace_path`: **Absolute path to speccrew-workspace directory** (MANDATORY for update-progress.js execution)
-       - `feature_spec_path`: Path to one Feature Spec document
-       - `feature_id`: Feature ID (e.g., `F-CRM-01`)
-       - `feature_name`: Feature name — **MUST be the exact value from .checkpoints.json, used verbatim for output filename**
-       - `feature_type`: `Page+API` or `API-only`
-       - `output_path`: `{iterations_dir}/{iteration}/03.api-contract/{feature_id}-{feature-name-slug}-api-contract.md`
-
-3. **Wait for batch completion**, update progress per worker:
-   ```bash
-   node {update_progress_script} update-task --file {iterations_dir}/{iteration}/03.api-contract/DISPATCH-PROGRESS.json --task-id {feature_id} --status completed
-   ```
-
-4. **Update `.checkpoints.json`** for each completed Feature:
-   - Set `api_contract_status` = `completed`
-
-5. **Parallel execution**: One worker per Feature Spec document
-
-6. **Output file naming**:
-   - Format: `{feature-id}-{feature-name-slug}-api-contract.md`
-   - Example: `F-CRM-01-customer-list-api-contract.md`
-
-### 4.3.1 API Contract Error Handling
-
-When any API Contract worker reports failure:
-
-1. **Update status**:
-   ```bash
-   node {update_progress_script} update-task --file {iterations_dir}/{iteration}/03.api-contract/DISPATCH-PROGRESS.json --task-id {feature_id} --status failed --error "[Phase 4] {error_message}"
-   ```
-
-2. **Continue batch**: Do NOT stop entire batch for single failure. Complete remaining workers.
-
-3. **Report to user**:
-   ```
-   📊 Phase 4 (API Contract) — Batch complete: {success}/{total} succeeded, {failed} failed
-   ├── ✅ F-SYS-01, F-SYS-02, ...
-   └── ❌ F-MEMBER-02: [error description]
-   
-   Retry failed features? (yes/skip/abort)
-   ```
-
-4. **Retry strategy**: Same as Phase 3
-   - If user says "yes" → Re-dispatch failed features in next batch (Phase 4)
-   - If user says "skip" → Mark as `skipped`, continue to joint confirmation with partial results
-   - If user says "abort" → STOP workflow, report partial results
-
-5. **Batch failure threshold**: If >50% workers in a batch fail → STOP entire workflow
-
-### 4.4 Joint Confirmation
-
-After both Feature Spec and API Contract documents are ready, present summary to user:
-- List all Feature Spec documents with paths (grouped by Feature or Module)
-- List all API Contract documents with paths
-- Request user confirmation before proceeding to system design phase
-- After confirmation, API Contract becomes the read-only baseline for downstream stages
-- After confirmation, update `.checkpoints.json`:
-  ```bash
-  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
-  ```
-
-### 4.5 Finalize Stage (Update Workflow Progress)
-
-After user confirms Joint Confirmation:
-
-1. **Update `WORKFLOW-PROGRESS.json`**:
-   ```bash
-   node {update_progress_script} update-workflow \
-     --file {iterations_dir}/{iteration}/WORKFLOW-PROGRESS.json \
-     --stage 02_feature_design --status confirmed \
-     --output "02.feature-design/F-CRM-01-customer-list-feature-spec.md,03.api-contract/F-CRM-01-customer-list-api-contract.md,..."
-   ```
-
-2. **Confirm Transition**:
-   - Notify user: "✅ Feature Design phase completed and confirmed. Ready to start System Design phase."
-   - The next agent (speccrew-system-designer) will verify this confirmation via its Stage Gate
-
 # Deliverables
 
 | Deliverable | Path | Notes |