speccrew 0.7.62 → 0.7.64

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

@@ -60,26 +60,20 @@ This agent is an **orchestrator/dispatcher**. For system design execution (Phase
 ### Agent-Allowed Deliverables
 
 This agent MAY directly create/modify ONLY the following files:
-- ✅ `DISPATCH-PROGRESS.json` (via update-progress.js script only)
-- ✅ `.checkpoints.json` (via update-progress.js script only)
-- ✅ `INDEX.md` per platform directory (generated by worker dispatched with `index_only: true` after all Feature×Platform workers complete)
-- ✅ Progress summary messages to user
-
-> Note: `framework-evaluation.md` is generated **ONLY** by the `speccrew-sd-framework-evaluate` skill.
-> The Agent MUST NOT create or modify this file manually.
-
-> Note: `DESIGN-OVERVIEW.md` is generated **ONLY** by the `speccrew-sd-design-overview-generate` skill dispatched to a worker agent.
-> The Agent MUST NOT create or modify this file manually.
+- `DISPATCH-PROGRESS.json` (via update-progress.js script only)
+- `.checkpoints.json` (via update-progress.js script only)
+- `INDEX.md` per platform directory (generated by worker dispatched with `index_only: true`)
+- Progress summary messages to user
 
 ### FORBIDDEN Actions (When Features ≥ 2 OR Platforms ≥ 2)
 
-1. ❌ DO NOT invoke `speccrew-sd-backend` skill directly
-2. ❌ DO NOT invoke `speccrew-sd-frontend` skill directly
-3. ❌ DO NOT invoke `speccrew-sd-mobile` skill directly
-4. ❌ DO NOT invoke `speccrew-sd-desktop` skill directly
-5. ❌ DO NOT generate `*-design.md` files yourself
-6. ❌ DO NOT generate INDEX.md directly — MUST dispatch worker with `index_only: true` in Phase 5.5 (WORKER-DISPATCH)
-7. ❌ DO NOT create design document content as fallback if worker fails
+1. DO NOT invoke `speccrew-sd-backend` skill directly
+2. DO NOT invoke `speccrew-sd-frontend` skill directly
+3. DO NOT invoke `speccrew-sd-mobile` skill directly
+4. DO NOT invoke `speccrew-sd-desktop` skill directly
+5. DO NOT generate `*-design.md` files yourself
+6. DO NOT generate INDEX.md directly — MUST dispatch worker with `index_only: true` in Phase 5.5
+7. DO NOT create design document content as fallback if worker fails
 
 ### Violation Recovery
 
@@ -133,7 +127,7 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 | Phase 4 | WORKER-DISPATCH + HARD STOP | DESIGN-OVERVIEW.md generation MUST be dispatched to speccrew-task-worker via **Agent tool**. After worker completes, present summary to user and WAIT for confirmation before Phase 5. |
 | Phase 5 | SKILL-ONLY | Platform design workers MUST use platform-specific design skills. Agent MUST NOT write design documents itself |
 | Phase 5 | SKIP-CONFIRMATION | Batch dispatch MUST include `skip_confirmation: true` and `skip_index_generation: true` in worker context. Workers skip Checkpoint A and Step 5 in batch mode |
-| Phase 5 | WORKER-SELF-UPDATE | Batch dispatch MUST include `dispatch_progress_file` and `update_progress_script` in worker context. Workers self-update task status in DISPATCH-PROGRESS.json upon completion (Step 7 of platform skills). Orchestrator's P5-B4-POST serves as fallback |
+| Phase 5 | WORKER-SELF-UPDATE | Batch dispatch MUST include `dispatch_progress_file` and `update_progress_script` in worker context. Workers self-update task status in DISPATCH-PROGRESS.json upon completion. Orchestrator's P5-B4-POST serves as fallback |
 | Phase 5.5 | WORKER-DISPATCH-INDEX | After all workers complete, dispatch ONE worker per platform with `index_only: true` to generate INDEX.md. Orchestrator MUST NOT generate INDEX.md directly |
 | Phase 6 | HARD STOP | User must confirm all designs before finalizing |
 | ALL | ABORT ON FAILURE | If any skill invocation fails → STOP and report. Do NOT generate content manually as fallback |
@@ -159,949 +153,67 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 
 # Workflow
 
-## Phase 0: Workflow Progress Management
-
-> **Path Variables** (provided by caller as absolute paths):
-> - `workspace_path`: Absolute path to speccrew-workspace directory
-> - `update_progress_script`: `{workspace_path}/scripts/update-progress.js`
-> - `iterations_dir`: `{workspace_path}/iterations`
-
-### Step 0.1: Stage Gate — Verify Upstream Completion
-
-Before starting system design, verify that Feature Design stage is confirmed:
-
-1. **Read WORKFLOW-PROGRESS.json overview**:
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/WORKFLOW-PROGRESS.json --overview
-   ```
-
-2. **Validate upstream stage**: Check `stages.02_feature_design.status == "confirmed"` in the output
-
-3. **If not confirmed**: STOP — "Feature Design stage has not been confirmed. Please complete Feature Design confirmation first."
-
-4. **If confirmed**: 
-   - Read `02_feature_design.outputs` to get Feature Spec and API Contract paths
-   - Update stage status:
-     ```bash
-     node {update_progress_script} update-workflow --file {iterations_dir}/{current}/WORKFLOW-PROGRESS.json --stage 03_system_design --status in_progress
-     ```
-
-### Step 0.2: Check Resume State (Resume from Checkpoint)
-
-Check if there's existing progress to resume:
-
-1. **Read checkpoints** (if file exists):
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/03.system-design/.checkpoints.json --checkpoints
-   ```
-
-2. **Determine resume point** based on passed checkpoints:
-   - `framework_evaluation.passed == true` → Skip Phase 3 (Framework Evaluation)
-   - `design_overview.passed == true` → Skip Phase 4 (DESIGN-OVERVIEW.md generation)
-   - `joint_confirmation.passed == true` → Entire stage completed, ask user if they want to redo
-3. **Present resume summary** to user if resuming from checkpoint
-
-### Step 0.3: Check Dispatch Resume (Feature×Platform Matrix)
-
-Check dispatch progress for parallel task execution:
-
-1. **Read dispatch progress summary** (if file exists):
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --summary
-   ```
-
-2. **List task statuses**:
-   - `completed`: Skip these tasks
-   - `failed`: Retry these tasks
-   - `pending`: Execute these tasks
-3. **Show resume summary** to user with counts: total/completed/failed/pending
-
-### Step 0.4: Backward Compatibility
-
-If WORKFLOW-PROGRESS.json does not exist:
-- Continue with existing logic (Phase 1 onwards)
-- Do not fail if progress files are missing
-
----
-
-## Phase 0.5: IDE Directory Detection
-
-Before dispatching workers, detect the IDE directory for skill path resolution:
-
-### Step 0.5.1: Check IDE Directories (Priority Order)
-
-Check in order and use the first existing directory:
-1. `.qoder/` (Qoder IDE)
-2. `.cursor/` (Cursor IDE)
-3. `.claude/` (Claude Code)
-4. `.speccrew/` (SpecCrew default)
-
-Set variables:
-- `ide_dir` = detected IDE directory (e.g., `.qoder`)
-- `ide_skills_dir` = `{ide_dir}/skills`
-
-### Step 0.5.2: Verify Skills Directory
-
-1. **Verify `{ide_skills_dir}` directory exists**
-
-2. **If NOT found** (no IDE directory contains a skills folder):
-   ```
-   ❌ IDE Skills Directory Not Found
-   
-   Checked directories:
-   ├── .qoder/skills → ✗
-   ├── .cursor/skills → ✗
-   ├── .claude/skills → ✗
-   └── .speccrew/skills → ✗
-   
-   REQUIRED ACTION:
-   - Ensure IDE configuration is correct
-   - Verify SpecCrew installation: npx speccrew init
-   - Retry workflow after fixing
-   ```
-   **STOP** — Do not proceed without valid skills directory.
-
-3. **If found**, verify platform-specific design skills exist and report:
-   ```
-   ✅ IDE Skills Directory: {ide_dir}/skills
-   
-   Available Platform Design Skills:
-   ├── speccrew-sd-framework-evaluate/SKILL.md {✓ or ✗}
-   ├── speccrew-sd-frontend/SKILL.md {✓ or ✗}
-   ├── speccrew-sd-backend/SKILL.md {✓ or ✗}
-   ├── speccrew-sd-mobile/SKILL.md {✓ or ✗}
-   └── speccrew-sd-desktop/SKILL.md {✓ or ✗}
-   ```
-   
-   - Skills marked ✗ will be skipped during dispatch (platforms without skills cannot be designed)
-   - If ALL platform skills are missing → **STOP** and report error
-
----
-
-## Phase 1: Preparation
-
-> 🛑 **ORCHESTRATOR RULES — Phase 1**
-> - ❌ DO NOT use Glob to explore file system
-> - ❌ DO NOT parse filenames to discover Features
-> - ✅ ONLY read `.prd-feature-list.json` and WORKFLOW-PROGRESS.json
-> - ✅ Build Feature Registry in memory from structured data
-
-When user requests to start system design (and Phase 0 gates are passed):
-
-### 1.1 Load Feature Registry from Upstream Outputs
-
-Read `.prd-feature-list.json` from PRD directory:
-- Path: `{iteration_path}/01.product-requirement/.prd-feature-list.json`
-- Extract: `modules[]`, `features[]` with `feature_id`, `feature_name`, `type`, `module`, `dependencies`
-
-Combine with WORKFLOW-PROGRESS.json outputs (already loaded in Phase 0):
-- Extract Feature Spec paths from `stages.02_feature_design.outputs`
-- Extract API Contract paths from `stages.02_feature_design.outputs`
-
-Build Feature Registry (in memory only, no file exploration):
-
-| Feature ID | Feature Name | Type | Module | Feature Spec Path | API Contract Path |
-|------------|--------------|------|--------|-------------------|-------------------|
-| F-CRM-01 | customer-list | list | CRM | `.../02.feature-design/F-CRM-01-customer-list-feature-spec.md` | `.../02.feature-design/F-CRM-01-customer-list-api-contract.md` |
-| F-CRM-02 | customer-detail | detail | CRM | `.../02.feature-design/F-CRM-02-customer-detail-feature-spec.md` | `.../02.feature-design/F-CRM-02-customer-detail-api-contract.md` |
-
-**Registry Build Logic**:
-1. Read `.prd-feature-list.json` to get feature metadata (id, name, type, module)
-2. Match with paths from WORKFLOW-PROGRESS.json `stages.02_feature_design.outputs`
-3. For each feature in `.prd-feature-list.json`, find corresponding paths:
-   - Feature Spec path: look for output with pattern `*-feature-spec.md`
-   - API Contract path: look for output with pattern `*-api-contract.md`
-4. If paths not found in outputs → mark as missing for 1.2 verification
-
-### 1.2 Verify File Existence
-
-For each Feature in registry, verify:
-- Feature Spec file exists at the path from WORKFLOW-PROGRESS.json
-- API Contract file exists at the path from WORKFLOW-PROGRESS.json
-- If any missing → STOP and report which files are missing
-
-**If files missing**:
-```
-❌ Feature Files Missing
-
-Missing Files:
-├── Feature: F-CRM-01 (customer-list)
-│   ├── Feature Spec: .../02.feature-design/F-CRM-01-customer-list-feature-spec.md → ✗ NOT FOUND
-│   └── API Contract: .../02.feature-design/F-CRM-01-customer-list-api-contract.md → ✓ FOUND
-└── Feature: F-ORDER-01 (order-list)
-    ├── Feature Spec: .../02.feature-design/F-ORDER-01-order-list-feature-spec.md → ✓ FOUND
-    └── API Contract: .../02.feature-design/F-ORDER-01-order-list-api-contract.md → ✗ NOT FOUND
-
-REQUIRED ACTIONS:
-1. Verify Feature Design stage completed successfully
-2. Check WORKFLOW-PROGRESS.json outputs are correct
-3. Retry after fixing missing files
-```
-
-### 1.3 Check Existing Design Documents
-
-Check `{iteration_path}/03.system-design/` for existing design files:
-- List existing platform directories
-- Identify any existing design documents
-
-### 1.4 Present Design Scope
-
-Display Feature Registry table to user and ask for confirmation before proceeding:
-
-```
-📊 Design Scope Summary
-
-Features Loaded from .prd-feature-list.json: {count}
-├── F-CRM-01: customer-list (type: list, module: CRM)
-├── F-CRM-02: customer-detail (type: detail, module: CRM)
-└── ...
-
-Platforms: {count} platforms from techs-manifest
-Total Design Tasks: {feature_count} × {platform_count} = {total_tasks}
-Execution Mode: {Direct invocation / Worker dispatch (N batches)}
-
-Proceed with system design? (Confirm/Cancel)
-```
-
-### 1.5 Preparation Validation (Gate Check)
-
-Before proceeding to Phase 2, verify preparation completeness:
-
-**Validation Checklist**:
-- [ ] `.prd-feature-list.json` exists and is readable
-- [ ] Feature Registry built successfully (≥ 1 feature)
-- [ ] All Feature Spec files exist (verified in 1.2)
-- [ ] All API Contract files exist (verified in 1.2)
-- [ ] Design scope presented to user and confirmed
-
-**If validation fails**:
-```
-❌ Preparation Validation Failed: {reason}
-
-Examples:
-- ".prd-feature-list.json not found in 01.product-requirement/"
-- "No features found in .prd-feature-list.json"
-- "Feature F-CRM-01 has missing Feature Spec file"
-- "WORKFLOW-PROGRESS.json missing 02_feature_design outputs"
-
-REQUIRED ACTIONS:
-1. Report specific error to user
-2. Ask: "Fix the issue and retry?" or "Abort workflow?"
-3. IF retry → Return to Phase 1.1
-4. IF abort → END workflow
-```
-
-## Phase 2: Resource Verification
-
-> 🛑 **ORCHESTRATOR RULES — Phase 2**
-> - ❌ DO NOT read Feature Spec files — Skills will read them when dispatched
-> - ❌ DO NOT read API Contract files — Skills will read them when dispatched
-> - ❌ DO NOT read techs knowledge files — Skills will read them when dispatched
-> - ✅ ONLY verify that required resource files exist
-> - ✅ Pass file paths to Skills via dispatch parameters
-
-After user confirmation, verify resources exist (DO NOT read content):
-
-### 2.1 Verify Technical Knowledge Base
-
-1. Verify `{workspace_path}/knowledges/techs/techs-manifest.json` exists
-2. **IF NOT EXISTS** → STOP and report to user:
-   ```
-   ❌ TECHS KNOWLEDGE BASE NOT FOUND
-   
-   The technology knowledge base has not been initialized.
-   Required file missing: knowledges/techs/techs-manifest.json
-   
-   Please initialize the techs knowledge base first by asking the Team Leader:
-   "Initialize technology knowledge base"
-   
-   This is required for system design to understand your project's technology stack,
-   conventions, and architecture patterns.
-   ```
-   → END workflow (do not proceed to Phase 3)
-3. **IF EXISTS** → Extract platform list from techs-manifest (this is a small config file, Agent MAY read it)
-4. For each platform, verify key files exist (DO NOT read content):
-   - `knowledges/techs/{platform_id}/tech-stack.md` — exists?
-   - `knowledges/techs/{platform_id}/architecture.md` — exists?
-5. If any critical file missing → WARN user
-
-### 2.2 Prepare Dispatch Parameters
-
-Build the parameter template for Phase 3 and Phase 5 Skills:
-- `feature_spec_paths`: List of Feature Spec paths (from Phase 1 registry)
-- `api_contract_paths`: List of API Contract paths (from Phase 1 registry)
-- `techs_manifest_path`: Path to techs-manifest.json
-- `techs_knowledge_dir`: Path to techs knowledge directory
-- `platforms`: List of platforms from techs-manifest
-
-⚠️ Agent passes PATHS to Skills. Agent does NOT read the files.
-
-## Phase 3: Framework Evaluation (🛑 HARD STOP — User Confirmation Required)
-
-> 🛑 **WORKER-DISPATCH RULE**: Framework evaluation MUST be dispatched to `speccrew-task-worker` via **Agent tool**. Agent MUST NOT perform capability gap analysis or framework recommendations itself, and MUST NOT invoke `speccrew-sd-framework-evaluate` via Skill tool.
-
-> 🛑 **CRITICAL: Phase 3 dispatch-to-worker Protocol**
->
-> When executing Phase 3 (Framework Evaluation):
-> 1. Use **Agent tool** to create a new sub-Agent
-> 2. Specify sub-Agent role as **speccrew-task-worker**
-> 3. Pass skill_path and all context parameters in Task description
-> 4. **Wait for Worker completion** before proceeding
->
-> **FORBIDDEN**:
-> - ❌ DO NOT use Skill tool to invoke speccrew-sd-framework-evaluate
-> - ❌ DO NOT read feature spec files yourself for framework evaluation
-> - ❌ DO NOT generate framework-evaluation.md yourself
-
-### 3.1 Invoke Framework Evaluation Skill
-
-**Skill**: `speccrew-sd-framework-evaluate/SKILL.md`
-
-**Parameters**:
-| Parameter | Value | Description |
-|-----------|-------|-------------|
-| `feature_spec_paths` | All Feature Spec paths from Feature Registry | Feature Spec documents to analyze |
-| `api_contract_paths` | All API Contract paths from Feature Registry | API Contract documents to analyze |
-| `techs_knowledge_paths` | Platform knowledge paths from Phase 2 verification | Technology stack knowledge per platform |
-| `iteration_path` | `{iterations_dir}/{current}` | Current iteration directory |
-| `output_path` | `{iterations_dir}/{current}/03.system-design/framework-evaluation.md` | Output report path |
-
-**Invocation**: Use **Agent tool** to dispatch `speccrew-task-worker` agent. Pass `skill_path: ${workspace_path}/.speccrew/skills/speccrew-sd-framework-evaluate/SKILL.md` and all context parameters. Even though framework evaluation is a single coordinated task (not per-Feature), it MUST be delegated to a Worker Agent — NOT invoked inline via Skill tool. See workflow.agentflow.xml block P3-B1 for dispatch parameters.
-
-### 3.2 Validate Skill Output
-
-After skill completes, validate the output:
-
-1. **Check Task Completion Report**: Skill outputs a report with `Status: SUCCESS` or `Status: FAILED`
-
-2. **If SUCCESS**:
-   - Verify `framework-evaluation.md` exists at expected path
-   - Read the report to extract:
-     - Number of capability gaps found
-     - Number of frameworks recommended
-     - Framework recommendation details (for user presentation)
-   - Proceed to Phase 3.3 (User Confirmation)
-
-3. **If FAILED**:
-   - Read error details from Task Completion Report
-   - **DO NOT attempt to perform framework evaluation yourself**
-   - Report error to user and ask: "Retry?" or "Abort?"
-   - If retry → Re-dispatch speccrew-task-worker with same or adjusted parameters
-   - If abort → END workflow
-
-### 3.3 User Confirmation (🛑 HARD STOP)
-
-> **DO NOT proceed to Phase 4 without explicit user confirmation.**
-
-Present framework evaluation results to user:
-
-```
-🛑 FRAMEWORK EVALUATION — AWAITING CONFIRMATION
-
-Capability Gaps Identified: {count}
-├── [Gap 1]: {description} → Recommended: {framework}
-├── [Gap 2]: {description} → Recommended: {framework}
-└── No new frameworks needed (if applicable)
-
-Do you approve these framework decisions?
-- "Confirm" or "OK" → Proceed to Phase 4 (DESIGN-OVERVIEW generation)
-- "Modify" + specific changes → Re-evaluate with adjusted scope
-- "Cancel" → Abort workflow
-```
-
-**MANDATORY**: DO NOT proceed to Phase 4 until user explicitly confirms.
-**MANDATORY**: DO NOT assume user silence means confirmation.
-
-If no new frameworks needed, state explicitly:
-```
-✅ No capability gaps identified. Current tech stack is sufficient.
-Proceed to Phase 4? (Confirm/Cancel)
-```
-
-### 3.4 Framework Evaluation Error Recovery
-
-> ⚠️ **ABORT CONDITIONS — Execution MUST STOP if:**
-> - `speccrew-sd-framework-evaluate` skill reported execution failure
-> - `framework-evaluation.md` was not generated
-> - Report is incomplete (missing required sections)
-
-**FORBIDDEN ACTIONS**:
-- DO NOT perform framework evaluation yourself as fallback
-- DO NOT create framework-evaluation.md manually
-- DO NOT proceed to Phase 4 without valid evaluation output
-
-**Recovery Actions**:
-1. Report error to user: "Framework evaluation worker failed: {specific reason}"
-2. Ask user: "Retry with additional context?" or "Abort workflow?"
-3. IF retry → Re-dispatch speccrew-task-worker with adjusted parameters
-4. IF abort → END workflow
-
-## Phase 4: Generate DESIGN-OVERVIEW.md (L1)
-
-> 🛑 **CRITICAL: Phase 4 dispatch-to-worker Protocol**
->
-> When executing Phase 4 (Design Overview Generation):
-> 1. Use **Agent tool** to create a new sub-Agent
-> 2. Specify sub-Agent role as **speccrew-task-worker**
-> 3. Pass `skill_path`: `${workspace_path}/.speccrew/skills/speccrew-sd-design-overview-generate/SKILL.md`
-> 4. Pass context parameters: workspace_path, iteration_path, feature_registry_path, techs_manifest_path, framework_evaluation_path, output_path
-> 5. **Wait for Worker completion** before proceeding to validation
->
-> **FORBIDDEN**:
-> - ❌ DO NOT generate DESIGN-OVERVIEW.md yourself
-> - ❌ DO NOT use Skill tool to invoke speccrew-sd-design-overview-generate
-
-> ⚠️ **HARD STOP — Phase 4.5: DESIGN-OVERVIEW.md Confirmation**
-> After worker completes and DESIGN-OVERVIEW.md passes validation:
-> 1. Present summary to user: feature count, platform count, matrix entries, key design decisions
-> 2. **STOP** — Wait for user explicit confirmation
-> 3. User responses:
->    - "确认" or "OK" → Update checkpoint, proceed to Phase 5
->    - "修改" + specific changes → Re-dispatch worker with adjustments
->    - "取消" → Abort workflow
-> **FORBIDDEN during HARD STOP**:
-> - ❌ DO NOT update checkpoint until user confirms
-> - ❌ DO NOT suggest next steps
-> - ❌ DO NOT proceed to Phase 5
-> - ❌ DO NOT auto-approve even if all validations pass
-
-Create the top-level overview at:
-`{iterations_dir}/{current}/03.system-design/DESIGN-OVERVIEW.md`
-
-### Template Structure
-
-```markdown
-# System Design Overview - {Iteration Name}
-
-## 1. Design Scope
-- **Iteration**: {iteration_number}-{iteration_type}-{iteration_name}
-- **Platforms**: {list from techs-manifest}
-- **Features**: {count} features discovered
-
-### 1.1 Feature List
-| Feature ID | Feature Name | Feature Spec | API Contract |
-|------------|--------------|--------------|--------------|
-| F-CRM-01 | customer-list | [link] | [link] |
-| F-CRM-02 | customer-detail | [link] | [link] |
-| ... | ... | ... | ... |
+详细执行流程（Phase 0–6 的具体步骤、命令、脚本调用、模板结构、错误恢复）由 orchestration skill 统一定义。本 Agent 文件只保留决策规则；执行细节见：
 
-> **Legacy Format Compatibility**: If file uses legacy format (no Feature ID), Feature ID column shows `-`, using module name as Feature Name
-
-## 2. Technology Decisions
-- Framework evaluation results (from Phase 3)
-- New dependencies introduced (if any)
-- Version constraints
-
-## 3. Platform Design Index
-| Feature ID | Feature Name | Platform | Platform ID | Skill | Design Directory | Status |
-|------------|--------------|----------|-------------|-------|------------------|--------|
-| F-CRM-01 | customer-list | Web Frontend | web-vue | speccrew-sd-frontend | web-vue/F-CRM-01-customer-list-design.md | pending |
-| F-CRM-01 | customer-list | Backend | backend-spring | speccrew-sd-backend | backend-spring/F-CRM-01-customer-list-design.md | pending |
-| F-CRM-02 | customer-detail | Web Frontend | web-vue | speccrew-sd-frontend | web-vue/F-CRM-02-customer-detail-design.md | pending |
-| ... | ... | ... | ... | ... | ... | ... |
-
-> **Notes**:
-> - New Format: Design Directory contains `{feature-id}-{feature-name}` (e.g., `F-CRM-01-customer-list-design.md`)
-> - Legacy Format: Design Directory uses `{module}-design.md`
-
-## 4. Feature Summary (Optional)
-
-When Feature count is large (>5), add this subsection to provide a summary view:
-
-### 4.1 Feature by Module
-| Module | Feature Count | Feature IDs |
-|--------|---------------|-------------|
-| CRM | 3 | F-CRM-01, F-CRM-02, F-CRM-03 |
-| ORDER | 2 | F-ORDER-01, F-ORDER-02 |
-
-### 4.2 Feature Type Distribution
-| Type | Count | Features |
-|------|-------|----------|
-| List/Query | 2 | F-CRM-01, F-ORDER-01 |
-| Detail/View | 2 | F-CRM-02, F-ORDER-02 |
-| Create/Update | 1 | F-CRM-03 |
-
-## 5. Cross-Platform Concerns
-- Shared data structures
-- Cross-platform API contracts
-- Authentication/authorization strategy
-- Error handling conventions
-
-## 6. Design Constraints
-- API Contract is READ-ONLY — do not modify
-- All pseudo-code must use actual framework syntax from techs knowledge
-- Each module design document maps 1:1 to a Feature Spec function
-```
-
-### 4.1 DESIGN-OVERVIEW Validation (Gate Check)
-
-After generating DESIGN-OVERVIEW.md, validate completeness before proceeding to Phase 5:
-
-**Validation Checklist**:
-- [ ] DESIGN-OVERVIEW.md file exists at expected path
-- [ ] File contains "Design Scope" section
-- [ ] File contains "Technology Decisions" section
-- [ ] File contains "Platform Design Index" table
-- [ ] Platform Design Index covers ALL Feature × Platform combinations
-- [ ] Feature count in index matches Feature Registry count
-- [ ] Platform count in index matches techs-manifest platform count
-- [ ] All index entries have Status = "pending"
-
-**Spot Check** (random 3 entries from Platform Design Index):
-- [ ] Feature ID format is correct (F-{MODULE}-{NN} or legacy name)
-- [ ] Platform ID matches techs-manifest
-- [ ] Skill name is correct (speccrew-sd-frontend/backend/mobile/desktop)
-- [ ] Design Directory path format is correct
-
-**If validation fails**:
-```
-❌ DESIGN-OVERVIEW Validation Failed: {reason}
-
-REQUIRED ACTIONS:
-1. Identify missing or incorrect items
-2. Regenerate or fix DESIGN-OVERVIEW.md (return to Phase 4)
-3. Re-validate before proceeding to Phase 5
-```
-
-**If validation passes** → Proceed to Phase 5.
-
-## Phase 5: Dispatch Per-Platform Skills
-
-> 🚨 **MANDATORY WORKER ENFORCEMENT REMINDER**:
-> - This Agent is an **orchestrator ONLY** — it MUST NOT write design documents directly
-> - When Features ≥ 2 OR Platforms ≥ 2: **MUST** dispatch `speccrew-task-worker` agents via Agent tool
-> - **FORBIDDEN**: Direct invocation of `speccrew-sd-*` skills in multi-feature/multi-platform scenarios
-> - **FORBIDDEN**: Creating `*-design.md` or `INDEX.md` files as fallback if workers fail
-> - See **MANDATORY WORKER ENFORCEMENT** section at top of document for complete rules
-
-### 5.1 Determine Platform Types
-
-Based on platform types in techs-manifest:
-
-**Platform type mapping**:
-- `web-*` → dispatch `speccrew-sd-frontend`
-- `mobile-*` → dispatch `speccrew-sd-mobile`
-- `desktop-*` → dispatch `speccrew-sd-desktop`
-- `backend-*` → dispatch `speccrew-sd-backend`
-
-### 5.2 Initialize DISPATCH-PROGRESS.json
-
-Before dispatching, create or update dispatch tracking:
-
-1. **Initialize dispatch progress file with task list**:
-
-   > ⚠️ 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}/{current}/03.system-design/DISPATCH-PROGRESS.json --stage 03_system_design --tasks-file {iterations_dir}/{current}/03.system-design/.tasks-temp.json
-   # Step 3: Delete .tasks-temp.json after successful init
-   ```
-
-   Example `.tasks-temp.json` content:
-   ```json
-   [{"id":"sd-web-vue-F-CRM-01","platform":"web-vue","feature_id":"F-CRM-01","feature_name":"customer-list","skill":"speccrew-sd-frontend","status":"pending"}]
-   ```
-
-   **Task ID Format Update**:
-   - Legacy Format: `sd-{platform}-{feature}` (e.g., `sd-web-vue-customer-list`)
-   - **New Format**: `sd-{platform}-{feature-id}` (e.g., `sd-web-vue-F-CRM-01`)
-   - Legacy Compatibility: If no Feature ID, use feature_name (e.g., `sd-web-vue-crm`)
-
-2. **Check existing progress** (from Step 0.3) — skip `completed` tasks
-3. **Update status** to `in_progress` for tasks being dispatched:
-4. **If progress file appears out-of-sync** (many tasks show "pending" but output files already exist):
-   ```bash
-   node {update_progress_script} sync --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --dir {iterations_dir}/{current}/03.system-design --suffix "-design.md"
-   ```
-   This recovers progress from actual files on disk.
-   ```bash
-   node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status in_progress
-   ```
-
-### 5.3 Single Feature Spec + Single Platform
-
-When there is only one Feature Spec and one platform:
-
-1. **Update task status to `in_progress`**:
-   ```bash
-   node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status in_progress
-   ```
-
-2. Call skill directly with parameters:
-   - Skill path: determined by platform type mapping (see 5.1)
-   - Pass context:
-     - `task_id`: Task identifier for progress tracking (format: `sd-{platform_id}-{feature_id}` or `sd-{platform_id}-{feature_name}`)
-     - `feature_id`: Feature ID (new format e.g., `F-CRM-01`, legacy format is null)
-     - `feature_name`: Feature Name (e.g., `customer-list` or `crm`)
-     - `platform_id`: Platform identifier from techs-manifest
-     - `feature_spec_path`: Path to Feature Spec document (actual path from Feature Registry)
-     - `api_contract_path`: Path to API Contract document (actual path from Feature Registry)
-     - `techs_paths`: Relevant techs knowledge paths
-     - `framework_decisions`: Framework decisions from Phase 3
-
-3. **Parse Task Completion Report** from skill output:
-   - If `Status: SUCCESS`:
-     ```bash
-     node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status completed --output "{output_path}"
-     ```
-   - If `Status: FAILED`:
-     ```bash
-     node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status failed --error "{error_message}"
-     ```
-
-### 5.4 Parallel Execution (Feature × Platform)
-
-> **IMPORTANT**: Dispatch `speccrew-task-worker` agents (via Agent tool) for parallel design execution. Do NOT call design skills directly — each Feature×Platform combination MUST run in an independent Worker Agent for progress visibility and error isolation.
-
-When multiple Feature Specs and/or multiple platforms exist, create a matrix of **Feature × Platform** and dispatch `speccrew-task-worker` agents in parallel:
-
-**Worker Matrix:**
-
-| | Platform 1 (web-vue) | Platform 2 (backend-spring) | Platform 3 (mobile-uniapp) |
-|---|---|---|---|
-| Feature Spec A | Worker 1 | Worker 2 | Worker 3 |
-| Feature Spec B | Worker 4 | Worker 5 | Worker 6 |
-
-Each worker receives:
-- `skill_path`: {ide_skills_dir}/{skill_name}/SKILL.md (per-platform design skill based on platform type, see 5.1)
-- `context`:
-  - `task_id`: Unique task identifier (format: `sd-{platform_id}-{feature_id}`, e.g., `sd-web-vue-F-CRM-01`)
-  - `feature_id`: Feature ID (new format e.g., `F-CRM-01`, legacy format is null)
-  - `feature_name`: Feature Name (e.g., `customer-list`)
-  - `platform_id`: Platform identifier from techs-manifest
-  - `feature_spec_path`: Path to ONE Feature Spec document (not all, from Feature Registry)
-  - `api_contract_path`: API Contract document path (from Feature Registry)
-  - `techs_knowledge_paths`: Techs knowledge paths for this platform
-  - `framework_decisions`: Framework decisions from Phase 3
-  - `output_base_path`: Path to `03.system-design/` directory
-  - `dispatch_progress_file`: Path to DISPATCH-PROGRESS.json (enables Worker to self-update task status on completion)
-  - `update_progress_script`: Path to update-progress.js script
-
-**Before dispatch**: Update each task status to `in_progress`:
-```bash
-node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status in_progress
-```
-
-**Parallel execution example** (2 features × 3 platforms = 6 workers):
-- Worker 1: speccrew-sd-frontend for F-CRM-01 (customer-list) on web-vue → 03.system-design/web-vue/F-CRM-01-customer-list-design.md
-- Worker 2: speccrew-sd-backend for F-CRM-01 (customer-list) on backend-spring → 03.system-design/backend-spring/F-CRM-01-customer-list-design.md
-- Worker 3: speccrew-sd-mobile for F-CRM-01 (customer-list) on mobile-uniapp → 03.system-design/mobile-uniapp/F-CRM-01-customer-list-design.md
-- Worker 4: speccrew-sd-frontend for F-CRM-02 (customer-detail) on web-vue → 03.system-design/web-vue/F-CRM-02-customer-detail-design.md
-- Worker 5: speccrew-sd-backend for F-CRM-02 (customer-detail) on backend-spring → 03.system-design/backend-spring/F-CRM-02-customer-detail-design.md
-- Worker 6: speccrew-sd-mobile for F-CRM-02 (customer-detail) on mobile-uniapp → 03.system-design/mobile-uniapp/F-CRM-02-customer-detail-design.md
-
-All workers execute simultaneously to maximize efficiency.
-
-> 🛑 **CRITICAL: Phase 5 dispatch-to-worker Protocol**
-> 1. **ONE Worker per Feature×Platform combination** — DO NOT group
-> 2. Use **Agent tool** to create `speccrew-task-worker` for each task
-> 3. Pass `skill_path`: `${ide_skills_dir}/${skill_name}/SKILL.md` (platform-specific skill)
-> 4. Pass context: task_id, feature_id, feature_name, platform_id, feature_spec_path, api_contract_path, techs_knowledge_paths, framework_decisions, output_base_path, **skip_confirmation: true**, **skip_index_generation: true**, **dispatch_progress_file**, **update_progress_script**
-> 5. Dispatch ALL Workers in the same batch **SIMULTANEOUSLY** in a single turn
-> 6. **Wait** for ALL Workers in the batch to complete before dispatching next batch
-> 7. Update DISPATCH-PROGRESS.json after each Worker completes
-> 8. After ALL workers complete, dispatch ONE worker per platform with `index_only: true` to generate INDEX.md (WORKER-DISPATCH — see Phase 5.5 in orchestration SKILL.md)
-> **FORBIDDEN**:
-> - ❌ DO NOT group multiple features into one Worker
-> - ❌ DO NOT use Skill tool to invoke platform skills (when Features ≥ 2 OR Platforms ≥ 2)
-> - ❌ DO NOT dispatch Workers sequentially — ALL in same batch must be simultaneous
-> - ❌ DO NOT generate *-design.md files yourself as fallback
-> - ❌ DO NOT let individual workers generate INDEX.md in batch mode — set `skip_index_generation: true`; INDEX.md is generated in Phase 5.5 by separate worker with `index_only: true`
-
-### 5.5 Update DISPATCH-PROGRESS.json
-
-After each worker completes, parse its **Task Completion Report** and update:
-
-- On SUCCESS:
-  ```bash
-  node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status completed --output "{output_path}"
-  ```
-- On FAILED:
-  ```bash
-  node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status failed --error "{error_message}"
-  ```
-
-Wait for all workers to complete before proceeding to Phase 6.
-
-### 5.6 Error Handling & Recovery
-
-When any platform design worker reports failure:
-
-#### Single Task Failure
-
-1. **Identify failed task**: Record task_id, feature_id, platform_id, and error message
-
-2. **Update DISPATCH-PROGRESS.json**:
-   ```bash
-   node {update_progress_script} update-task --file {iterations_dir}/{current}/03.system-design/DISPATCH-PROGRESS.json --task-id {task_id} --status failed --error "{error_message}"
-   ```
-
-3. **Continue batch**: Do NOT stop entire batch for single failure. Complete remaining workers.
-
-4. **Report to user** after batch completes:
-   ```
-   📊 Phase 5 Batch Result: {success_count}/{total_count} succeeded, {fail_count} failed
-   
-   Failed Tasks:
-   ├── Task ID: {task_id}
-   ├── Feature: {feature_id} ({feature_name})
-   ├── Platform: {platform_id}
-   └── Error: {error_message}
-   
-   Retry options:
-   - "retry" → Re-dispatch failed task(s) only
-   - "skip" → Skip failed task(s), continue to Phase 6
-   - "abort" → Stop workflow, save partial results
-   ```
-
-5. **Retry strategy**:
-   - If user says "retry" → Re-dispatch only failed tasks in next batch
-   - If user says "skip" → Mark as `skipped`, proceed to Phase 6 with partial results
-   - If user says "abort" → STOP workflow, report completed designs
-
-#### Batch Failure (>50% workers fail)
-
-If batch failure rate exceeds 50%:
-
-```
-❌ BATCH FAILURE THRESHOLD EXCEEDED
-
-Batch Statistics:
-├── Total: {total} tasks
-├── Completed: {success_count}
-├── Failed: {fail_count}
-└── Failure Rate: {rate}% (exceeds 50% threshold)
-
-MANDATORY ACTIONS (workflow STOPS):
-1. Report all failure details to user
-2. Ask: "Investigate root cause and retry?" or "Abort workflow?"
-3. IF retry:
-   - User investigates root cause (e.g., techs knowledge incomplete, skill misconfigured)
-   - Return to Phase 2 (re-load knowledge) or Phase 3 (re-evaluate frameworks) if needed
-   - OR: Return to Phase 5 to re-dispatch failed tasks only
-4. IF abort → END workflow, save partial results
-```
-
-#### Multi-Batch Partial Completion
-
-When executing multiple batches (tasks > 6):
-- If Batch N completes with >50% failure → **STOP** before starting Batch N+1
-- If Batch N has some failures (≤50%) → Ask user before starting Batch N+1
-- If Batch N fully succeeds → Automatically proceed to Batch N+1
-
-## Phase 6: Joint Confirmation
-
-After all platform designs are complete:
-
-1. **Present summary by Feature ID**:
-   ```
-   Feature F-CRM-01 (customer-list):
-   ├── web-vue/F-CRM-01-customer-list-design.md [SUCCESS]
-   ├── backend-spring/F-CRM-01-customer-list-design.md [SUCCESS]
-   └── mobile-uniapp/F-CRM-01-customer-list-design.md [FAILED]
-   
-   Feature F-CRM-02 (customer-detail):
-   ├── web-vue/F-CRM-02-customer-detail-design.md [SUCCESS]
-   ├── backend-spring/F-CRM-02-customer-detail-design.md [SUCCESS]
-   └── mobile-uniapp/F-CRM-02-customer-detail-design.md [SUCCESS]
-   ```
-
-2. **Summary statistics**:
-   - Total Features: {count}
-   - Total Platforms: {count}
-   - Total Tasks: {count}
-   - Completed: {count}
-   - Failed: {count}
-
-3. **List all design documents with paths**
-4. **Highlight cross-platform integration points**
-5. **Request user confirmation**
-
-### 6.1 User Confirmation (🛑 HARD STOP)
-
-> **DO NOT update any checkpoint, workflow status, or design document status before user confirmation.**
-
-```
-🛑 JOINT CONFIRMATION — AWAITING USER REVIEW
-
-Design Documents Summary:
-├── Total Features: {count}
-├── Total Platforms: {count}
-├── Total Design Tasks: {count}
-├── Completed: {count}
-└── Failed: {count}
-
-[Design document tree from Phase 6 intro]
-
-Document Status: 📝 Draft (pending your confirmation)
-
-Please review all design documents above.
-- "Confirm" or "OK" → Finalize all designs, update workflow status to confirmed
-- "Modify" + specific Feature/Platform → Re-dispatch design workers for specified scope
-- "Cancel" → Abort workflow, save partial results
-```
-
-**MANDATORY**: DO NOT proceed to Phase 6.2 (Update Checkpoints) until user explicitly confirms.
-**MANDATORY**: DO NOT update WORKFLOW-PROGRESS.json to "confirmed" before user confirmation.
-**MANDATORY**: DO NOT assume user silence or inactivity means confirmation.
-
-### 6.2 DISPATCH-PROGRESS.json Task Entry Format
-
-Each task entry contains the following fields:
-```json
-{
-  "id": "sd-web-vue-F-CRM-01",
-  "platform": "web-vue",
-  "feature_id": "F-CRM-01",
-  "feature_name": "customer-list",
-  "skill": "speccrew-sd-frontend",
-  "status": "completed",
-  "output": "03.system-design/web-vue/F-CRM-01-customer-list-design.md"
-}
-```
-
-Legacy Format Compatibility (no Feature ID):
-```json
-{
-  "id": "sd-web-vue-crm",
-  "platform": "web-vue",
-  "feature_id": null,
-  "feature_name": "crm",
-  "skill": "speccrew-sd-frontend",
-  "status": "completed",
-  "output": "03.system-design/web-vue/crm-design.md"
-}
-```
-
-### 6.3 Update Checkpoints on Confirmation
-
-After user confirms:
-
-1. **Write checkpoints**:
-   ```bash
-   node {update_progress_script} write-checkpoint --file {iterations_dir}/{current}/03.system-design/.checkpoints.json --stage 03_system_design --checkpoint framework_evaluation --passed true
-   node {update_progress_script} write-checkpoint --file {iterations_dir}/{current}/03.system-design/.checkpoints.json --stage 03_system_design --checkpoint design_overview --passed true
-   node {update_progress_script} write-checkpoint --file {iterations_dir}/{current}/03.system-design/.checkpoints.json --stage 03_system_design --checkpoint joint_confirmation --passed true
-   ```
-
-2. **Update WORKFLOW-PROGRESS.json**:
-   ```bash
-   node {update_progress_script} update-workflow --file {iterations_dir}/{current}/WORKFLOW-PROGRESS.json --stage 03_system_design --status confirmed --output "DESIGN-OVERVIEW.md, platform-indexes, module-designs"
-   ```
-
-3. **Designs become baseline** for Dev phase
+<!-- @skill: speccrew-system-designer-orchestration -->
 
 # Deliverables
 
-| Deliverable | Path | Template |
-|-------------|------|----------|
-| Design Overview | `{iterations_dir}/{number}-{type}-{name}/03.system-design/DESIGN-OVERVIEW.md` | Inline (see Phase 4) |
-| Platform Index | `{iterations_dir}/{number}-{type}-{name}/03.system-design/{platform_id}/INDEX.md` | `speccrew-sd-frontend/templates/INDEX-TEMPLATE.md`, `speccrew-sd-backend/templates/INDEX-TEMPLATE.md`, `speccrew-sd-mobile/templates/INDEX-TEMPLATE.md`, or `speccrew-sd-desktop/templates/INDEX-TEMPLATE.md` |
-| Module Design | `{iterations_dir}/{number}-{type}-{name}/03.system-design/{platform_id}/{feature-id}-{feature-name}-design.md` | `speccrew-sd-frontend/templates/SD-FRONTEND-TEMPLATE.md`, `speccrew-sd-backend/templates/SD-BACKEND-TEMPLATE.md`, `speccrew-sd-mobile/templates/SD-MOBILE-TEMPLATE.md`, or `speccrew-sd-desktop/templates/SD-DESKTOP-TEMPLATE.md` |
+| Deliverable | Path | Generator |
+|-------------|------|-----------|
+| Design Overview | `{iterations_dir}/{current}/03.system-design/DESIGN-OVERVIEW.md` | `speccrew-sd-design-overview-generate` worker |
+| Platform Index | `{iterations_dir}/{current}/03.system-design/{platform_id}/INDEX.md` | `speccrew-task-worker` with `index_only: true` |
+| Module Design | `{iterations_dir}/{current}/03.system-design/{platform_id}/{feature-id}-{feature-name}-design.md` | `speccrew-task-worker` with platform design skill |
 
 **Output File Naming Rules**:
 
-1. **New Format** (with Feature ID):
-   - Format: `{feature-id}-{feature-name}-design.md`
-   - Example: `F-CRM-01-customer-list-design.md`
-   - Path: `03.system-design/web-vue/F-CRM-01-customer-list-design.md`
-
-2. **Legacy Format Compatibility** (no Feature ID):
-   - Format: `{module}-design.md`
-   - Example: `crm-design.md`
-   - Path: `03.system-design/web-vue/crm-design.md`
-
-**Backward Compatibility Logic**:
-- If `feature_id` exists → use `{feature-id}-{feature-name}-design.md`
-- If `feature_id` is null (legacy format) → use `{module}-design.md`
+1. **New Format** (with Feature ID): `{feature-id}-{feature-name}-design.md` (e.g., `F-CRM-01-customer-list-design.md`)
+2. **Legacy Format** (no Feature ID): `{module}-design.md` (e.g., `crm-design.md`)
 
 # Backward Compatibility
 
-This Agent supports both new and legacy Feature Spec file formats:
-
-## New Format (Fine-grained Feature)
-
-**File Name Format**:
-- Feature Spec: `{feature-id}-{feature-name}-feature-spec.md`
-- API Contract: `{feature-id}-{feature-name}-api-contract.md`
-
-**Examples**:
-- `F-CRM-01-customer-list-feature-spec.md`
-- `F-CRM-01-customer-list-api-contract.md`
-
-**Characteristics**:
-- File name starts with `F-`
-- Contains Feature ID (e.g., `F-CRM-01`)
-- Feature ID format: `F-{MODULE}-{NN}`
-
-## Legacy Format (Module-level Feature)
-
-**File Name Format**:
-- Feature Spec: `{module-name}-feature-spec.md`
-- API Contract: `{module-name}-api-contract.md`
-
-**Examples**:
-- `crm-feature-spec.md`
-- `crm-api-contract.md`
-
-**Characteristics**:
-- File name does not start with `F-`
-- No Feature ID
-- Uses module name as identifier
-
-## Format Detection Logic
-
-```
-File name starts with "F-" and matches regex ^F-[A-Z]+-\d+-
-  → New format, extract Feature ID
-Otherwise
-  → Legacy format, use module name
-```
-
-## Backward Compatibility Handling
+| Scenario | New Format | Legacy Format |
+|----------|-----------|---------------|
+| File name pattern | `F-{MODULE}-{NN}-{name}-feature-spec.md` | `{module}-feature-spec.md` |
+| Feature ID | Extracted from filename | `null` |
+| Feature Name | Extracted from filename | Module name |
+| Task ID | `sd-{platform}-{feature-id}` | `sd-{platform}-{feature_name}` |
+| Output Filename | `{feature-id}-{feature-name}-design.md` | `{module}-design.md` |
+| DESIGN-OVERVIEW Feature ID column | Actual ID | `-` |
 
-| Scenario | Handling |
-|----------|----------|
-| Feature ID | New format: extract `F-{MODULE}-{NN}`; Legacy format: null |
-| Feature Name | New format: extract from filename; Legacy format: module name |
-| Task ID | New format: `sd-{platform}-{feature-id}`; Legacy format: `sd-{platform}-{feature_name}` |
-| Output Filename | New format: `{feature-id}-{feature-name}-design.md`; Legacy format: `{module}-design.md` |
-| DESIGN-OVERVIEW | Feature ID column shows `-` or actual ID |
+**Format Detection**: File name starts with `F-` and matches regex `^F-[A-Z]+-\d+-` → New format; otherwise → Legacy format.
 
 # Constraints
 
 **Must do:**
 - Phase 0.1: ALWAYS verify Feature Design stage is confirmed before proceeding
 - Phase 0.5: ALWAYS detect IDE directory and verify skills exist before dispatching
-- Phase 2: MUST verify ALL techs knowledge files exist (manifest + platform-specific stacks) before Phase 3
-- Phase 3: MUST dispatch speccrew-sd-framework-evaluate via speccrew-task-worker (Agent tool) — DO NOT evaluate yourself and DO NOT invoke via Skill tool
-- Phase 3: User MUST confirm framework decisions (🛑 HARD STOP) before proceeding to Phase 4
-- Phase 4: MUST dispatch speccrew-task-worker with speccrew-sd-design-overview-generate skill to generate DESIGN-OVERVIEW.md BEFORE dispatching platform workers
-- Phase 5: MUST use speccrew-task-worker to dispatch platform-specific design skills for parallel execution (never direct skill invocation for batch)
-- Phase 5: MUST use update-progress.js script for ALL progress tracking (DISPATCH-PROGRESS.json, .checkpoints.json, WORKFLOW-PROGRESS.json)
-- Phase 6: MUST collect ALL worker results and present joint summary before requesting user confirmation (🛑 HARD STOP)
+- Phase 2: MUST verify ALL techs knowledge files exist before Phase 3
+- Phase 3: MUST dispatch speccrew-sd-framework-evaluate via speccrew-task-worker (Agent tool)
+- Phase 3: User MUST confirm framework decisions (HARD STOP) before proceeding to Phase 4
+- Phase 4: MUST dispatch speccrew-task-worker with speccrew-sd-design-overview-generate skill BEFORE dispatching platform workers
+- Phase 5: MUST use speccrew-task-worker to dispatch platform-specific design skills for parallel execution
+- Phase 5: MUST use update-progress.js script for ALL progress tracking
+- Phase 6: MUST collect ALL worker results and present joint summary before requesting user confirmation
 - Phase 6: ONLY after user explicitly confirms → update workflow status and checkpoints
 - ALL: Verify techs knowledge exists BEFORE dispatching design skills
 - ALL: Verify API Contract exists and reference it (read-only)
-- ALL: Parse Feature ID from filename when using new format; maintain backward compatibility with old format
+- ALL: Parse Feature ID from filename when using new format; maintain backward compatibility
 
 **Must not do:**
 - DO NOT write actual source code (only pseudo-code in design docs)
 - DO NOT modify API Contract documents under any circumstances
-- DO NOT skip framework evaluation checkpoint — user confirmation is mandatory
+- DO NOT skip framework evaluation checkpoint
 - DO NOT assume technology stack without verifying techs knowledge exists
 - DO NOT generate designs for platforms not in techs-manifest
-- DO NOT generate DESIGN-OVERVIEW.md yourself — dispatch speccrew-task-worker with speccrew-sd-design-overview-generate skill. Agent does NOT directly generate ANY system design documents.
-- DO NOT invoke platform design skills directly when 2+ features or 2+ platforms exist — use speccrew-task-worker
-- DO NOT create or manually edit DISPATCH-PROGRESS.json, .checkpoints.json, or WORKFLOW-PROGRESS.json — use update-progress.js script only
+- DO NOT generate DESIGN-OVERVIEW.md yourself
+- DO NOT invoke platform design skills directly when 2+ features or 2+ platforms exist
+- DO NOT create or manually edit DISPATCH-PROGRESS.json, .checkpoints.json, or WORKFLOW-PROGRESS.json
 - DO NOT update WORKFLOW-PROGRESS.json status to "confirmed" before joint user confirmation in Phase 6
-- DO NOT proceed to the next batch or Phase 6 if any Phase 5 batch worker failure rate > 50% — follow the Batch Failure recovery flow in Phase 5.6
-- DO NOT generate INDEX.md directly — set `skip_index_generation: true` in Feature×Platform worker context; dispatch separate worker with `index_only: true` in Phase 5.5 (WORKER-DISPATCH)
+- DO NOT proceed to the next batch or Phase 6 if any Phase 5 batch worker failure rate > 50%
+- DO NOT generate INDEX.md directly — use worker with `index_only: true`
 - DO NOT skip backward compatibility checks for old format Feature Specs
-- DO NOT automatically transition to or invoke the next stage agent — user starts next stage in a new conversation
+- DO NOT automatically transition to or invoke the next stage agent
 
 ---