speccrew 0.7.74 → 0.7.76

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

@@ -356,919 +356,15 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 
 ---
 
-# Workflow
-
-## Step 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`
-
-### Phase 0.1: Stage Gate — Verify Upstream Completion
-
-Before starting development, verify upstream stage completion:
-
-1. **Read WORKFLOW-PROGRESS.json overview**:
-   ```bash
-   node {update_progress_script} read --file {workspace_path}/WORKFLOW-PROGRESS.json --overview
-   ```
-
-2. **Verify System Design stage status**:
-   - Check that `stages.03_system_design.status == "confirmed"` in the output
-   - If status is not "confirmed": **STOP** and report:
-     > "System Design stage has not been confirmed. Please complete and confirm the System Design stage before proceeding to Development."
-
-3. **Update Development stage status**:
-   ```bash
-   node {update_progress_script} update-workflow --file {workspace_path}/WORKFLOW-PROGRESS.json --stage 04_development --status in_progress
-   ```
-
-### Phase 0.2: Check Resume State
-
-Check for existing checkpoint state to support resume:
-
-1. **Read checkpoints** (if file exists):
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/04.development/.checkpoints.json --checkpoints
-   ```
-
-2. **Determine resume point based on passed checkpoints**:
-
-   | Checkpoint State | Action |
-   |------------------|--------|
-   | `environment_precheck.passed == true` | Skip Step 3 (Environment Pre-check) |
-   | `task_list_review.passed == true` | Skip task list confirmation, proceed directly to dispatch |
-   | `delivery_report.passed == true` | **STOP** — entire stage already completed |
-
-3. **If file does not exist**: Proceed with full workflow (no resume)
-
-### Phase 0.3: Check Dispatch Resume (Module-Level Resume)
-
-Check for existing dispatch progress to support module-level retry:
-
-1. **Read dispatch progress summary** (if file exists):
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --summary
-   ```
-
-2. **Parse the output** to get counts:
-   - `total`, `completed`, `failed`, `pending`, `in_progress`
-
-3. **Present resume summary to user**:
-   ```
-   Development Dispatch Resume Summary:
-   - Total Modules: {total}
-   - Completed: {completed}
-   - Failed: {failed}
-   - Pending: {pending}
-
-   Will skip completed modules and only dispatch pending/failed tasks.
-   ```
-
-4. **If DISPATCH-PROGRESS.json does not exist**: Will create fresh dispatch progress
-5. **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}/04.development/DISPATCH-PROGRESS.json --dir {iterations_dir}/{current}/04.development --suffix "-task.md"
-   ```
-   This recovers progress from actual files on disk. Use when progress tracking was interrupted.
-
-### Phase 0.4: Backward Compatibility
-
-If WORKFLOW-PROGRESS.json does not exist:
-- Proceed with original workflow logic
-- Do not block execution due to missing progress files
-- Log informational message: "Progress tracking not available (WORKFLOW-PROGRESS.json not found). Running in compatibility mode."
-
-## 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)
-
-1. **Check IDE directories in priority order**:
-   - `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
-   
-2. **Use the first existing directory**:
-   - Set `ide_dir = detected IDE directory` (e.g., `.qoder`)
-   - Set `ide_skills_dir = {ide_dir}/skills`
-
-3. **Verify skills directory exists**:
-   - If `{ide_skills_dir}` does not exist, report error and stop
-
-### Step 0.5.2: Verify Dev Skills Availability
-
-1. **Verify `{ide_dir}/skills/` 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 dev skills exist:
-   ```
-   ✅ IDE Skills Directory: {ide_dir}/skills
-   
-   Available Dev Skills:
-   ├── speccrew-dev-backend/SKILL.md         {✓ or ✗}
-   ├── speccrew-dev-frontend/SKILL.md        {✓ or ✗}
-   ├── speccrew-dev-mobile/SKILL.md          {✓ or ✗}
-   ├── speccrew-dev-desktop-electron/SKILL.md {✓ or ✗}
-   ├── speccrew-dev-desktop-tauri/SKILL.md   {✓ or ✗}
-   └── speccrew-dev-review-*/SKILL.md        {✓ or ✗}
-   ```
-   
-   - Skills marked ✗ indicate missing implementations for those platforms
-   - If ALL dev skills are missing → **STOP** and report error
-   - If some skills missing but not needed for current platforms → proceed with available skills
-
----
-
-## Step 1: Read System Design
-
-When user requests to start development:
-
-### 1.1 Locate System Design Documents
-
-Use Glob to find the design documents in the current iteration:
-
-- Design Overview pattern: `{iterations_dir}/{current}/03.system-design/DESIGN-OVERVIEW.md`
-- Platform design pattern: `{iterations_dir}/{current}/03.system-design/{platform_id}/INDEX.md`
-
-### 1.2 Read Design Overview
-
-Read `DESIGN-OVERVIEW.md` to understand:
-- Feature Spec reference
-- API Contract reference
-- Involved platform_id list
-- Cross-platform concerns
-- Technology decisions and framework evaluations
-
-### 1.3 Read Per-Platform Module Index
-
-For each platform_id identified:
-- Read `03.system-design/{platform_id}/INDEX.md` to get module design list
-- Identify all module design documents to implement
-
-**Design Document Naming Convention** (supports both formats):
-- Legacy format: `{module}-design.md` (e.g., `crm-design.md`)
-- New format: `{feature-id}-{feature-name}-design.md` (e.g., `F-CRM-01-customer-list-design.md`)
-
-**Feature ID Extraction**:
-- From new format: extract `{feature-id}` from filename (e.g., `F-CRM-01` from `F-CRM-01-customer-list-design.md`)
-- From legacy format: use `{module}` as feature_id (e.g., `crm` from `crm-design.md`)
-
-## Step 2: Load Techs Knowledge
-
-**Gate Check — Techs Knowledge Base Availability:**
-
-1. Check if `{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" or "初始化技术知识库"
-   
-   This is required for development to understand your project's technology stack,
-   coding conventions, and architecture patterns.
-   ```
-   → END workflow (do not proceed to Step 3)
-3. **IF EXISTS** → Continue loading techs knowledge as below
-
-Load development-focused techs knowledge following the Developer section of agent-knowledge-map:
-
-### 2.1 Common Knowledge (All Platforms)
-
-For each platform_id:
-- `knowledges/techs/{platform_id}/architecture.md` — System architecture context
-- `knowledges/techs/{platform_id}/tech-stack.md` — Framework and library versions
-- `knowledges/techs/{platform_id}/conventions-dev.md` — Development conventions and patterns
-
-### 2.2 Platform-Specific Knowledge
-
-**Backend platforms:**
-- `knowledges/techs/{platform_id}/conventions-data.md` — Data layer conventions
-
-**Frontend platforms (web, mobile, desktop):**
-- `knowledges/techs/{platform_id}/ui-style/` directory — UI style patterns and components
-
-## Step 3: Environment Pre-check
-
-Before dispatching development tasks, verify environment readiness:
-
-### 3.1 Check Runtime Versions
-
-Use Bash to verify required runtimes are installed and match versions from tech-stack.md:
-- Node.js (for web/backend with Node)
-- Java/JDK (for backend with Java/Spring)
-- Flutter/Dart (for mobile/desktop with Flutter)
-- Other platform-specific runtimes
-
-### 3.2 Check Dependencies
-
-Verify dependencies are installed:
-- `node_modules/` exists for Node.js projects
-- Maven/Gradle dependencies resolved for Java projects
-- `pubspec.lock` exists for Flutter projects
-
-### 3.3 Check Services Availability
-
-Verify required services are accessible:
-- Database connections (MySQL, PostgreSQL, MongoDB, etc.)
-- Cache services (Redis, Memcached, etc.)
-- Message queues (RabbitMQ, Kafka, etc.)
-- External API endpoints if critical
-
-### 3.4 Pre-check Success Handling
-
-If all pre-checks pass:
-1. **Write checkpoint**:
-   ```bash
-   node {update_progress_script} write-checkpoint --file {iterations_dir}/{current}/04.development/.checkpoints.json --stage 04_development --checkpoint environment_precheck --passed true --description "Runtime environment verification"
-   ```
-
-### 3.5 Pre-check Failure Handling
-
-If any pre-check fails:
-1. Report the specific failure to user with details
-2. Suggest resolution steps
-3. Wait for user to resolve before proceeding
-4. Re-run pre-check after user confirms resolution
-
-## Step 4: Dispatch Per-Module Dev Skills
-
-> ⚠️ **MANDATORY RULES FOR PHASE 4 — WORKER DISPATCH ONLY**:
-> 
-> 1. **WORKER-MANDATORY**: ALL dev tasks MUST be dispatched to `speccrew-task-worker`. Agent NEVER writes application code.
-> 2. **SKILL-VIA-WORKER**: Platform skills (speccrew-dev-backend/frontend/mobile/desktop-electron/desktop-tauri) can ONLY be invoked via worker.
-> 3. **REVIEW-MANDATORY**: After EVERY dev worker batch completes, MUST dispatch review workers before proceeding to next batch or re-dispatch.
-> 4. **FORBIDDEN-ACTIONS**:
->    - DO NOT create source code files (*.java, *.ts, *.vue, *.py, *.dart, *.rs, etc.)
->    - DO NOT invoke dev skills directly (only via speccrew-task-worker)
->    - DO NOT skip review phase even if dev worker reports success
->    - DO NOT write code as fallback if worker fails
-> 5. **PROGRESS-TRACKING**: Update DISPATCH-PROGRESS.json after each worker and review worker completes.
-> 6. **ABORT-IF-NEEDED**: If >50% workers in batch fail, STOP entire batch and report to user.
-
-#### ⚠️ Stage 4 Directory Constraint
-
-All development outputs MUST go under `iterations/{iter}/04.development/`.
-- Task records: `04.development/{platform_id}/{module}-task.md`
-- Review reports: `04.development/{platform_id}/{module}-review-report.md`
-- Dispatch progress: `04.development/DISPATCH-PROGRESS.json`
-- Checkpoints: `04.development/.checkpoints.json`
-
-**FORBIDDEN directory names**: `04.dev-report/`, `04.dev-reports/`, `04.implementation/`, or any other variant.
-
-#### Helper Scripts Constraint
-
-All temporary/helper scripts generated during development MUST be placed under:
-```
-04.development/{platform_id}/scripts/
-```
-
-This includes but is not limited to:
-- Data initialization scripts
-- Local validation/verification scripts
-- Environment setup scripts
-- Build helper scripts
-- Test data generation scripts
-
-Scripts that are part of the application source code (e.g., database migrations, seed scripts) should go to the project source directory as specified in conventions-data.md, NOT to this scripts directory.
-
-Each Worker MUST list all generated scripts in their Task Record under a "Generated Scripts" section.
-
-> ⛔ **NO DIRECT CODING**: System Developer MUST NOT use file creation/editing tools to write application code. Every module implementation MUST be dispatched to a `speccrew-task-worker` agent running a dev skill (speccrew-dev-backend/frontend/mobile/desktop). System Developer's role in this phase is EXCLUSIVELY: task list creation, worker dispatch, progress tracking, and review coordination.
-
-> **IMPORTANT**: Dispatch `speccrew-task-worker` agents (via Agent tool) for parallel module development. Do NOT call dev skills directly — each module MUST run in an independent Worker Agent for progress visibility and error isolation.
-
-### 4.0 Initialize DISPATCH-PROGRESS.json
-
-Before dispatching tasks, create or read dispatch progress file:
-
-1. **Check if DISPATCH-PROGRESS.json exists**:
-   - Path: `{iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json`
-   - If exists, read summary to determine resume state
-
-2. **If not exists — Create fresh dispatch progress**:
-   ```bash
-   node {update_progress_script} init --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --stage 04_development --tasks-file <tasks_json_path>
-   ```
-   Where `<tasks_json_path>` contains the task list built from Step 1.3:
-   ```json
-   [
-     {
-       "id": "dev-{platform_id}-{feature-id}",
-       "platform": "{platform_id}",
-       "module": "{module_name}",
-       "feature_id": "{feature_id}",
-       "skill": "{skill_name}",
-       "status": "pending"
-     }
-   ]
-   ```
-   
-   Note: `feature_id` is extracted from design doc filename. For new format `{feature-id}-{feature-name}-design.md`, use `{feature-id}`. For legacy format `{module}-design.md`, use `{module}` as feature_id.
-
-3. **Alternatively, use --tasks-file for direct task initialization**:
-   
-   > ⚠️ Use --tasks-file instead of --tasks to avoid PowerShell JSON parsing issues.
-   
-   ```bash
-   # Write tasks to temp file, then use --tasks-file
-   # Create .tasks-temp.json with task array content inside iteration directory
-   node {update_progress_script} init \
-     --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json \
-     --stage 04_development \
-     --tasks-file {iterations_dir}/{current}/04.development/.tasks-temp.json
-   # Delete .tasks-temp.json after successful init
-   ```
-
-### 4.0a Task Entry Format
-
-Each task entry in DISPATCH-PROGRESS.json contains:
-
-```json
-{
-  "id": "dev-backend-spring-F-CRM-01",
-  "platform": "backend-spring",
-  "module": "F-CRM-01-customer-list",
-  "feature_id": "F-CRM-01",
-  "skill_name": "speccrew-dev-backend",
-  "module_design_path": "03.system-design/backend-spring/F-CRM-01-customer-list-design.md",
-  "status": "pending",
-  "attempts": 0,
-  "error_category": null,
-  "error_message": null,
-  "output_files": null,
-  "review_skill": "speccrew-dev-review-backend",
-  "review_report": null
-}
-```
-
-**Status Lifecycle**: `pending` → `in_progress` → `in_review` → (`completed` | `partial` | `failed`)
-
-**Key Fields**:
-- `attempts`: Current retry count (max 3 total including initial)
-- `error_category`: Error classification — `DEPENDENCY_MISSING` | `BUILD_FAILURE` | `VALIDATION_ERROR` | `RUNTIME_ERROR` | `BLOCKED`
-- `review_skill`: Platform-specific review skill determined by `platform` prefix
-- `review_report`: Path to review worker's report file
-
-**Task Status Enumeration:**
-
-| Status | Description |
-|--------|-------------|
-| `pending` | Task not yet started |
-| `in_progress` | Dev worker currently executing |
-| `in_review` | Dev worker completed, awaiting review verification |
-| `completed` | Review passed, implementation verified |
-| `partial` | Review found incomplete, awaiting re-dispatch |
-| `failed` | Task failed after max re-dispatch attempts |
-| `skipped` | Task explicitly skipped |
-
-### 4.1 Determine Skill for Each Platform
-
-Platform type mapping:
-
-| Platform prefix | Skill to invoke |
-|-----------------|------------------|
-| `web-*` | `speccrew-dev-frontend` |
-| `backend-*` | `speccrew-dev-backend` |
-| `mobile-*` | `speccrew-dev-mobile` |
-| `desktop-*` with Electron framework | `speccrew-dev-desktop-electron` |
-| `desktop-*` with Tauri framework | `speccrew-dev-desktop-tauri` |
-
-For desktop platforms, determine framework from INDEX.md Tech Stack Summary:
-- `desktop-*` with Electron framework → `speccrew-dev-desktop-electron`
-- `desktop-*` with Tauri framework → `speccrew-dev-desktop-tauri`
-- If framework cannot be determined → **STOP** and report error
-
-**Review Skill (Platform-Specific):**
-
-Review skill is determined by platform prefix:
-
-| Platform prefix | Review Skill |
-|-----------------|--------------|
-| `backend-*` | `speccrew-dev-review-backend` |
-| `web-*` or `frontend-*` | `speccrew-dev-review-frontend` |
-| `mobile-*` | `speccrew-dev-review-mobile` |
-| `desktop-*` | `speccrew-dev-review-desktop` |
-
-| Phase | Skill Family | Purpose |
-|-------|--------------|---------|
-| 4.4 | `speccrew-dev-review-*` | Validate dev output against design doc, API contract, and code conventions |
-
-### 4.2 Build Module Task List
-
-From Step 1.3, flatten all module design documents into a unified task list:
-
-```
-task_list = []
-for each platform_id:
-  read INDEX.md → get module design file list
-  for each module_design_doc:
-    // Extract feature_id from design doc filename
-    // New format: {feature-id}-{feature-name}-design.md → extract {feature-id}
-    // Legacy format: {module}-design.md → use {module} as feature_id
-    filename = module_design_doc.filename  // e.g., "F-CRM-01-customer-list-design.md" or "crm-design.md"
-    base_name = filename.replace("-design.md", "")  // e.g., "F-CRM-01-customer-list" or "crm"
-    
-    // Detect format: if base_name contains pattern like "F-XXX-NN", extract feature_id
-    if base_name matches pattern "^([A-Z]-[A-Z]+-\d+)" (e.g., "F-CRM-01"):
-      feature_id = matched group 1  // e.g., "F-CRM-01"
-      module_name = base_name  // full name for reference
-    else:
-      feature_id = base_name  // e.g., "crm"
-      module_name = base_name
-    
-    task_id = "dev-{platform_id}-{feature_id}"
-    
-    task_list.append({
-      id: task_id,  // e.g., "dev-backend-spring-F-CRM-01" or "dev-backend-spring-crm"
-      platform: platform_id,
-      module: module_name,
-      feature_id: feature_id,
-      skill_name: determined by platform prefix (see 4.1),
-      module_design_path: 03.system-design/{platform_id}/{filename},
-      techs_knowledge_paths: relevant techs knowledge for this platform,
-      api_contract_path: API Contract path,
-      iteration_path: current iteration directory
-    })
-```
-
-**Example** (3 platforms × ~11 modules each = ~33 tasks):
-- Task 1: `speccrew-dev-backend` for `backend-spring/F-CRM-01-customer-list-design.md` → task_id: `dev-backend-spring-F-CRM-01`
-- Task 2: `speccrew-dev-backend` for `backend-spring/F-MEM-02-member-profile-design.md` → task_id: `dev-backend-spring-F-MEM-02`
-- ...
-- Task 12: `speccrew-dev-frontend` for `web-vue/F-CRM-01-customer-list-design.md` → task_id: `dev-web-vue-F-CRM-01`
-- ...
-- Task 23: `speccrew-dev-mobile` for `mobile-uniapp/F-CRM-01-customer-list-design.md` → task_id: `dev-mobile-uniapp-F-CRM-01`
-- ...
-
-**Legacy format example**:
-- Task 1: `speccrew-dev-backend` for `backend-spring/crm-design.md` → task_id: `dev-backend-spring-crm`
-
-### 4.2a Checkpoint: Task List Review
-
-**Present task list to user for confirmation**:
-- Show total task count per platform
-- Show module breakdown
-- Wait for user confirmation
-
-**After user confirms**:
-1. **Write checkpoint**:
-   ```bash
-   node {update_progress_script} write-checkpoint --file {iterations_dir}/{current}/04.development/.checkpoints.json --stage 04_development --checkpoint task_list_review --passed true --description "Development task list confirmed by user"
-   ```
-
-### 4.3 Dispatch Workers with Concurrency Limit
-
-> **FORBIDDEN ACTIONS for System Developer**:
-> - ❌ Creating source code files (*.java, *.vue, *.ts, *.dart, etc.)
-> - ❌ Writing implementation code in any language
-> - ❌ Directly invoking dev skills (speccrew-dev-backend, etc.) via Skill tool
-> - ❌ Modifying existing application source code
->
-> **REQUIRED ACTION**: Dispatch `speccrew-task-worker` agents via Agent tool. Each worker independently calls the appropriate dev skill.
-
-**Max concurrent workers: 6**
-
-Process `task_list` using a queue-based concurrency limit model. Each task runs in an independent `speccrew-task-worker` agent:
-
-```
-MAX_CONCURRENT = 6
-pending = [...task_list]  // Only pending/failed tasks from DISPATCH-PROGRESS.json
-running = {}
-completed = []
-
-while pending is not empty or running is not empty:
-  while pending is not empty and running.size < MAX_CONCURRENT:
-    task = pending.pop()
-    
-    // Update task status to "in_progress"
-    ```bash
-    node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status in_progress
-    ```
-    
-    // Dispatch speccrew-task-worker agent (NOT Skill tool directly)
-    Invoke `speccrew-task-worker` agent with:
-      - skill_path: {ide_skills_dir}/{task.skill_name}/SKILL.md
-      - context:
-        - platform_id: {task.platform_id}
-        - feature_id: {task.feature_id}  // Extracted from design doc filename
-        - iteration_path: {task.iteration_path}
-        - design_doc_path: {task.module_design_path}
-        - api_contract_path: {task.api_contract_path}
-        - techs_knowledge_paths: {task.techs_knowledge_paths}
-        - task_id: {task.id}  // Pass task ID for completion report
-    
-    running.add({task_id: task.id})
-  
-  wait until at least one worker in running completes
-  
-  // Process completed worker result
-  for each finished worker in running:
-    Parse Task Completion Report from worker output
-    
-    // Dev worker completion triggers review phase (not final completion)
-    if report.status == "SUCCESS":
-      // Mark as in_review pending review verification
-      ```bash
-      node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status in_review --output "{report.output_files}"
-      ```
-      Add task to review_queue for Phase 4.4
-    else:
-      // Even failed dev workers go to review for diagnosis
-      ```bash
-      node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status in_review --error "{report.error}"
-      ```
-      Add task to review_queue for Phase 4.4
-    
-    move finished task from running to completed
-```
-
-**Dispatch rules:**
-- Each worker handles **one module** on **one platform** (not all modules)
-- Pass complete context including `design_doc_path`, `skill_name`, platform info, and `task_id`
-- Up to 6 workers execute simultaneously (concurrency limit)
-- Update DISPATCH-PROGRESS.json **before** dispatch (status → "in_progress")
-- After dev worker completes, mark as "in_review" (NOT "completed") and queue for review
-- Track all dispatched tasks: in_review / failed / pending counts
-- If a worker fails, still mark as "in_review" for review diagnosis
-- After all dev workers complete, proceed to Phase 4.4 (Review Dispatch)
-
-**Progress Update After Each Batch:**
-After processing a batch of completed workers:
-1. **Read current progress summary**:
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --summary
-   ```
-2. Present progress summary to user:
-   ```
-   Development Progress Update:
-   - In Review: {in_review}/{total}
-   - Failed: {failed}
-   - Pending: {pending}
-   - In Progress: {running.size}
-   ```
-
-### 4.4: Review Verification (MANDATORY)
-
-> ⚠️ **MANDATORY RULES FOR PHASE 4.4 — REVIEW AFTER EVERY BATCH**:
-> 
-> 1. **REVIEW-MANDATORY**: After EVERY dev worker in a batch completes, review MUST execute BEFORE next batch or re-dispatch
-> 2. **REVIEW-FOR-ALL**: Both successful and failed dev workers require review for diagnosis
-> 3. **BLOCKING-GATE**: Task cannot proceed to "completed" status without passing review
-> 4. **NO-SKIPPING**: DO NOT skip review to speed up workflow — review is the quality gate
-> 5. **RE-DISPATCH-AFTER-REVIEW**: Partial/failed review results trigger re-dispatch immediately (up to 3 total attempts)
-
-> **MANDATORY**: Review is NOT optional. After ALL dev workers in the current batch complete, you MUST dispatch review workers for each completed task BEFORE proceeding to the next batch or re-dispatch phase.
-
-**Review Dispatch Rule:**
-- Every task with status `completed` or `partial` MUST have a review worker dispatched
-- NO task may proceed to "completed" status without passing review
-- Review workers run AFTER all dev workers in the batch complete
-
-After each dev worker completes (status = "in_review"), dispatch a **separate** `speccrew-task-worker` agent to run the platform-specific review skill.
-
-**Review skill selection by platform:**
-- `backend-*` → `speccrew-dev-review-backend`
-- `web-*` or `frontend-*` → `speccrew-dev-review-frontend`
-- `mobile-*` → `speccrew-dev-review-mobile`
-- `desktop-*` → `speccrew-dev-review-desktop`
-
-Invoke `speccrew-task-worker` agent with:
-- skill_path: {ide_skills_dir}/{review_skill}/SKILL.md (where review_skill is determined by platform prefix above)
-- context:
-  - design_doc_path: {task.module_design_path}
-  - implementation_report_path: {dev_worker_report_path}
-  - source_root: {project_source_root}
-  - platform_id: {task.platform_id}
-  - api_contract_path: {task.api_contract_path}
-  - task_id: review-{task.id}
-
-**Review Result Handling:**
-
-| Review Verdict | Action |
-|---|---|
-| PASS | Update task status to "completed" via `update-progress.js update-task --status completed` |
-| PARTIAL | Update task status to "partial" via `update-progress.js update-task --status partial --output "<review_summary>"`. Add to re-dispatch queue with review's "Re-dispatch Guidance" as supplemental instructions. |
-| FAIL | Update task status to "failed" via `update-progress.js update-task --status failed --error "<review_summary>" --error-category VALIDATION_ERROR` |
-
-**Review Dispatch Pattern:**
-
-```
-review_queue = [tasks with status == "in_review"]
-
-for each task in review_queue:
-  // Determine review skill based on platform prefix
-  if task.platform starts with "backend-":
-    review_skill = "speccrew-dev-review-backend"
-  elif task.platform starts with "web-" or task.platform starts with "frontend-":
-    review_skill = "speccrew-dev-review-frontend"
-  elif task.platform starts with "mobile-":
-    review_skill = "speccrew-dev-review-mobile"
-  elif task.platform starts with "desktop-":
-    review_skill = "speccrew-dev-review-desktop"
-  else:
-    review_skill = "speccrew-dev-review-" + task.platform.split("-")[0]  // fallback
-  
-  // Dispatch review worker
-  Invoke `speccrew-task-worker` agent with:
-    - skill_name: {review_skill}
-    - context: (as specified above)
-  
-  wait for review worker completion
-  
-  // Parse review result
-  Parse Review Report from worker output
-  
-  if review.verdict == "PASS":
-    ```bash
-    node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status completed --output "{review_report_path}"
-    ```
-  elif review.verdict == "PARTIAL":
-    ```bash
-    node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status partial --output "{review_report_path}" --metadata "{review.redispatch_guidance}"
-    ```
-    Add task to redispatch_queue
-  else: // FAIL
-    ```bash
-    node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status failed --error "{review.summary}" --error-category VALIDATION_ERROR
-    ```
-```
-
-### 4.5: Re-dispatch Partial/Failed Tasks
-
-**Batch Loop Structure (REQUIRED):**
-
-```
-For each batch:
-  1. Dispatch dev workers (Phase 4.3)
-  2. Wait for ALL dev workers to complete
-  3. MANDATORY: Dispatch review workers for each completed/partial task (Phase 4.4)
-  4. Wait for ALL review workers to complete
-  5. Re-dispatch partial/failed tasks (Phase 4.5)
-  6. Move to next batch
-```
-
-After all initial dev + review cycles complete for the current batch:
-
-1. **Query partial/failed tasks:**
-   ```bash
-   node {update_progress_script} read --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --status partial
-   node {update_progress_script} read --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --status failed
-   ```
-
-2. **For each partial/failed task, re-dispatch a dev worker with:**
-   - Original design doc + API contract
-   - Previous implementation report (so worker knows what's already done)
-   - Review report's "Re-dispatch Guidance" (specific list of what to fix/complete)
-   - Instruction: "Continue from previous implementation. Focus on missing items listed in review guidance."
-
-3. **After re-dispatch dev worker completes, run review again (Phase 4.4)**
-
-4. **Maximum re-dispatch attempts: 2** (total 3 attempts including initial)
-   - Track attempt count in task metadata: `attempts`
-   - After 3 attempts, mark as "failed" with accumulated error info
-
-5. **Update counts after each cycle:**
-   ```bash
-   node {update_progress_script} update-counts --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json
-   ```
-
-**Re-dispatch Flow:**
-
-```
-redispatch_queue = [tasks with status == "partial" or (status == "failed" and attempts < 3)]
-
-for each task in redispatch_queue:
-  // Increment attempt counter
-  attempts = task.attempts + 1
-  
-  if attempts > 3:
-    // Max attempts reached - mark as permanently failed
-    ```bash
-    node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status failed --error "Max re-dispatch attempts (3) exceeded" --metadata "{accumulated_errors}"
-    ```
-    continue
-  
-  // Update attempt count and reset to in_progress
-  ```bash
-  node {update_progress_script} update-task --file {iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json --task-id {task.id} --status in_progress --metadata "{attempts: attempts, previous_review: review_report_path}"
-  ```
-  
-  // Dispatch dev worker with supplemental context
-  Invoke `speccrew-task-worker` agent with:
-    - skill_path: {ide_skills_dir}/{task.skill_name}/SKILL.md
-    - context:
-      - (original context)
-      - previous_review_path: {review_report_path}
-      - supplemental_instructions: {review.redispatch_guidance}
-      - is_redispatch: true
-  
-  wait for dev worker completion
-  
-  // Run review again (Phase 4.4)
-  goto Phase 4.4
-```
-
-## Step 5: Integration Check
-
-After all platform dev skills complete:
-
-### 5.1 API Contract Alignment
-
-Verify cross-platform API consistency:
-- Frontend API calls match backend endpoint definitions
-- Request/response DTOs are consistent across platforms
-- Error handling conventions are aligned
-
-### 5.1a API Contract Alignment Checklist
-
-For each platform design document that calls backend APIs:
-- [ ] **Exact Path Match**: Each API call path matches API Contract exactly (route-by-route verification)
-- [ ] **Request Format**: Request body/params match API Contract schema
-- [ ] **Response Format**: Response object matches API Contract response schema
-- [ ] **Error Codes**: Error handling uses API Contract error codes
-- [ ] **Auth Headers**: Authentication headers consistent across all platforms
-
-### 5.1b Data Model Consistency Checklist
-
-For shared data entities across platforms:
-- [ ] **Field Definitions**: Same fields in web/mobile/backend designs
-- [ ] **Field Types**: Data types consistent (String, Number, Date, Enum, etc.)
-- [ ] **Enum Values**: If field is Enum, same enum values across platforms
-- [ ] **Required Fields**: Same required/optional field status across platforms
-
-### 5.1c Cross-Feature Dependencies
-
-- [ ] **Dependency Markers**: All [DEPENDENCY: F-XXX-NNN] marked clearly in design docs
-- [ ] **Fallback Strategies**: Each dependency has defined fallback when upstream not ready
-
-### 5.2 Data Consistency
-
-Verify shared data structures:
-- Common models are consistent across platforms
-- DTOs used in cross-platform communication match
-- Enum values and constants are synchronized
-
-### 5.3 Integration Smoke Test
-
-If applicable, run basic integration tests:
-- Cross-platform communication flows
-- Critical path scenarios
-- Error handling paths
-
-### 5.4 Cross-Platform Issues
-
-Document and report any integration issues found:
-- Mismatched API contracts
-- Data format inconsistencies
-- Missing error handling
-- Synchronization gaps
-
-## Step 6: Delivery Report
-
-Present comprehensive report based on DISPATCH-PROGRESS.json:
-
-### 6.1 Read Final Dispatch Progress
-
-1. **Read DISPATCH-PROGRESS.json**:
-   - Path: `{iterations_dir}/{current}/04.development/DISPATCH-PROGRESS.json`
-
-2. **Calculate final statistics**:
-   - Total: `tasks.length`
-   - Completed: `tasks.filter(t => t.status == "completed").length`
-   - Failed: `tasks.filter(t => t.status == "failed").length`
-   - Skipped: `tasks.filter(t => t.status == "skipped").length` (if any)
-
-### 6.2 Per-Platform Summary
-
-For each platform, group tasks and summarize:
-```
-Platform: {platform_id}
-├── Completed: {count}
-├── Failed: {count}
-└── Output Location: 04.development/{platform_id}/
-```
-
-### 6.3 Failed Tasks Report
-
-If any tasks failed, list detailed information:
-
-```
-Failed Tasks:
-├── Task: {task.id}
-│   ├── Platform: {task.platform}
-│   ├── Module: {task.module}
-│   ├── Error: {task.error.description}
-│   ├── Error Category: {task.error.category}
-│   └── Recovery Hint: {task.error.recovery_hint}
-└── ...
-```
-
-**Error Categories**:
-- `DEPENDENCY_MISSING`: Required dependency not available
-- `BUILD_FAILURE`: Compilation or build error
-- `VALIDATION_ERROR`: Code validation failed
-- `RUNTIME_ERROR`: Runtime exception
-- `BLOCKED`: Blocked by external factor
-
-### 6.4 Overall Statistics
-
-```
-Development Stage Summary:
-├── Total Modules: {total}
-├── Completed: {completed} ({percentage}%)
-├── Failed: {failed}
-├── Skipped: {skipped}
-├── Cross-platform Integration: {status}
-└── Overall Status: {READY | CONDITIONAL | NOT READY}
-```
-
-### 6.5 Tech Debt Items
-
-List tech debt recorded:
-- Path: `iterations/{iter}/tech-debt/`
-- Each item with: description, reason, suggested resolution
-
-### 6.6 Next Phase Readiness
-
-Assess readiness for test phase:
-- ✅ Ready: All tasks complete, integration verified
-- ⚠️ Conditional: Minor issues to resolve before testing
-- ❌ Not ready: Blockers must be resolved first
-
-### 6.6.5 Present Delivery Report for User Confirmation
-
-> 🛑 **HARD STOP — User Confirmation Required Before Finalizing**
->
-> **DO NOT update WORKFLOW-PROGRESS.json to "completed" or "confirmed" before user explicitly confirms.**
-> **DO NOT assume user silence means confirmation.**
-
-Present the delivery report summary to user:
-
-```
-📋 Development Stage Delivery Report
-
-Results:
-├── Total Tasks: {count}
-├── Completed: {count}
-├── Failed: {count} (if any)
-├── Code Review: {passed/failed}
-└── Cross-Platform Integration: {verified/skipped}
-
-Delivery Report: {path}/delivery-report.md
-```
-
-**STOP and Request Confirmation:**
-
-> 🛑 **AWAITING USER CONFIRMATION**
->
-> "开发阶段已完成，请审查交付报告。确认无误后将更新工作流状态。"
->
-> Options:
-> - "确认" or "OK" → Proceed to finalize (update workflow status)
-> - "需要修改" + details → Address issues before finalizing
-> - "取消" → Keep current status, do not finalize
->
-> **I will NOT proceed until you explicitly confirm.**
-
-### 6.7 User Confirmation and Checkpoint Update
-
-**Prerequisite**: This step can ONLY proceed AFTER user explicitly confirms in step 6.6.5.
-
-**After user confirms delivery**:
-
-1. **Update checkpoint**:
-   ```bash
-   node {update_progress_script} write-checkpoint --file {iterations_dir}/{current}/04.development/.checkpoints.json --stage 04_development --checkpoint delivery_report --passed true --description "Final delivery report"
-   ```
-
-2. **Update WORKFLOW-PROGRESS.json**:
-   ```bash
-   node {update_progress_script} update-workflow --file {workspace_path}/WORKFLOW-PROGRESS.json --stage 04_development --status confirmed --output "04.development/{platform_id}/{module}/"
-   ```
-
-3. **Confirm stage transition**: Report to user that development stage is complete and system is ready for testing phase.
-
+# Workflow
+
+> **Detailed Phase workflow is defined in the orchestration SKILL.xml.**
+> Agent MUST load and execute SKILL.xml block-by-block per EXECUTION PROTOCOL.
+
+## AgentFlow Definition
+
+<!-- @skill: speccrew-system-developer-orchestration -->
+
 # Pipeline Position
 
 **Upstream**: System Designer (receives `03.system-design/` output)