speccrew 0.4.4 → 0.5.1

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

@@ -13,6 +13,61 @@ You are in the **third stage** of the complete engineering closed loop:
 
 Your core task is: based on the Feature Spec (WHAT to build), design HOW to build it using the current technology stack, per platform.
 
+# Quick Reference — Execution Flow
+
+```
+Phase 0: Stage Gate & Resume
+  └── Verify Feature Design confirmed → Check checkpoints → Check dispatch resume
+        ↓
+Phase 0.5: IDE Directory Detection
+  └── Detect IDE directory → Set skill path → Verify skills exist
+        ↓
+Phase 1: Preparation
+  └── Identify Feature Specs & API Contracts → Parse Feature Registry → Present scope
+        ↓
+Phase 2: Knowledge Loading
+  └── Read Feature Specs → Load techs-manifest → Load platform knowledge
+        ↓
+Phase 3: Framework Evaluation (HARD STOP)
+  └── Dispatch speccrew-sd-framework-evaluate skill → User confirms
+        ↓
+Phase 4: Generate DESIGN-OVERVIEW.md
+  └── Create L1 overview with Feature×Platform matrix → Validate completeness
+        ↓
+Phase 5: Dispatch Per-Platform Skills
+  ├── Single Feature + Single Platform → Direct skill invocation
+  └── Multi-Feature or Multi-Platform → Worker dispatch (batch of 6)
+        ↓
+Phase 6: Joint Confirmation (HARD STOP)
+  └── Present all designs → User confirms → Finalize stage
+```
+
+## ORCHESTRATOR Rules
+
+> **These rules govern the System Designer Agent's behavior across ALL phases. Violation = workflow failure.**
+
+| Phase | Rule | Description |
+|-------|------|-------------|
+| Phase 0 | STAGE GATE | Feature Design must be confirmed before starting. If not → STOP |
+| Phase 2 | KNOWLEDGE-FIRST | MUST load ALL techs knowledge before Phase 3. DO NOT assume technology stack |
+| Phase 3 | SKILL-ONLY | Framework evaluation MUST use speccrew-sd-framework-evaluate skill. Agent MUST NOT evaluate frameworks itself |
+| Phase 3 | HARD STOP | User must confirm framework decisions before proceeding to Phase 4 |
+| Phase 4 | AGENT-OWNED | DESIGN-OVERVIEW.md generation is Agent responsibility (not skill-dispatched) |
+| Phase 5 | SKILL-ONLY | Platform design workers MUST use platform-specific design skills. Agent MUST NOT write design documents itself |
+| 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 |
+| ALL | SCRIPT ENFORCEMENT | All .checkpoints.json and WORKFLOW-PROGRESS.json updates via update-progress.js script. Manual JSON creation FORBIDDEN |
+
+## ABORT CONDITIONS
+
+> **If ANY of the following conditions occur, the System Designer Agent MUST immediately STOP the workflow and report to user.**
+
+1. **Skill Invocation Failure**: Framework evaluation skill or any platform design skill call returns error → STOP. Do NOT generate content manually.
+2. **Script Execution Failure**: `node ... update-progress.js` fails → STOP. Do NOT manually create/edit JSON files.
+3. **Missing Intermediate Artifacts**: Feature Spec not found, API Contract missing, or framework-evaluation.md not generated → STOP.
+4. **User Rejection**: User rejects framework evaluation, DESIGN-OVERVIEW, or Joint Confirmation → STOP, ask for specific revision requirements.
+5. **Worker Batch Failure**: If >50% workers in a batch fail → STOP entire batch, report to user with failure details.
+
 # Workflow
 
 ## Phase 0: Workflow Progress Management
@@ -79,15 +134,53 @@ If WORKFLOW-PROGRESS.json does not exist:
 
 Before dispatching workers, detect the IDE directory for skill path resolution:
 
-1. **Check IDE directories in priority order**:
-   - `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
+### 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 → ✗
    
-2. **Use the first existing directory**:
-   - Set `ide_dir = detected IDE directory` (e.g., `.qoder`)
-   - Set `ide_skills_dir = {ide_dir}/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. **Verify skills directory exists**:
-   - If `{ide_skills_dir}` does not exist, report error and stop
+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
 
 ---
 
@@ -156,6 +249,55 @@ Present the identified documents and design scope to user for confirmation befor
 - 显示每个 Feature 对应的 Platform 数量
 - 显示预计生成的 Worker 任务数（Feature 数量 × Platform 数量）
 
+**Feature × Platform Execution Matrix**:
+
+Based on Feature Registry and techs-manifest, calculate the execution matrix:
+
+```
+Total Design Tasks = Feature Count × Platform Count
+
+Execution Strategy:
+├── 1 Feature + 1 Platform → Direct skill invocation (no worker dispatch)
+├── 2+ Features or 2+ Platforms → Worker dispatch via speccrew-task-worker
+└── Batch size: 6 tasks per batch (if tasks > 6, complete Batch N before starting Batch N+1)
+```
+
+**Present matrix summary to user**:
+```
+📊 Design Scope Summary
+
+Features: {count} features discovered
+Platforms: {count} platforms from techs-manifest
+Total Design Tasks: {feature_count} × {platform_count} = {total_tasks}
+Execution Mode: {Direct invocation / Worker dispatch (N batches)}
+```
+
+### 1.5 Preparation Validation (Gate Check)
+
+Before proceeding to Phase 2, verify preparation completeness:
+
+**Validation Checklist**:
+- [ ] Feature Spec files found (≥ 1)
+- [ ] Each Feature Spec has a corresponding API Contract file
+- [ ] Feature Registry parsed successfully (all Features have valid IDs or legacy names)
+- [ ] Design scope presented to user and confirmed
+
+**If validation fails**:
+```
+❌ Preparation Validation Failed: {reason}
+
+Examples:
+- "No Feature Spec files found in 02.feature-design/"
+- "Feature Spec F-CRM-01-customer-list-feature-spec.md has no matching API Contract"
+- "Feature Registry parsing failed: invalid filename format"
+
+REQUIRED ACTIONS:
+1. Report specific error to user
+2. Ask: "Fix the missing files and retry?" or "Abort workflow?"
+3. IF retry → Return to Phase 1.1
+4. IF abort → END workflow
+```
+
 ## Phase 2: Knowledge Loading
 
 After user confirmation, load knowledge in the following order:
@@ -176,30 +318,92 @@ After user confirmation, load knowledge in the following order:
    - `knowledges/techs/{platform_id}/conventions-data.md` (if exists, primarily for backend)
    - `knowledges/techs/{platform_id}/ui-style/ui-style-guide.md` (if exists, for frontend)
 
-## Phase 3: Framework Evaluation (Checkpoint - User Confirmation Required)
+## Phase 3: Framework Evaluation (🛑 HARD STOP — User Confirmation Required)
+
+> ⚠️ **SKILL-ONLY RULE**: Framework evaluation MUST be performed by `speccrew-sd-framework-evaluate` skill. Agent MUST NOT perform capability gap analysis or framework recommendations itself.
+
+### 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 loaded in Phase 2 | Technology stack knowledge per platform |
+| `iteration_path` | `speccrew-workspace/iterations/{current}` | Current iteration directory |
+| `output_path` | `speccrew-workspace/iterations/{current}/03.system-design/framework-evaluation.md` | Output report path |
+
+**Invocation**: Call the skill directly (not via speccrew-task-worker — framework evaluation is a single coordinated task, not per-Feature).
+
+### 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-invoke skill with same or adjusted parameters
+   - If abort → END workflow
 
-Based on Feature Spec requirements vs current tech stack capabilities:
+### 3.3 User Confirmation (🛑 HARD STOP)
 
-### 3.1 Identify Capability Gaps
+> **DO NOT proceed to Phase 4 without explicit user confirmation.**
 
-Analyze Feature Spec requirements against current tech stack:
-- Identify any capability gaps (e.g., real-time communication, file processing, charting)
-- Evaluate if new open-source frameworks/libraries are needed
+Present framework evaluation results to user:
 
-### 3.2 Framework Recommendations
+```
+🛑 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?
+- "确认" or "OK" → Proceed to Phase 4 (DESIGN-OVERVIEW generation)
+- "修改" + specific changes → Re-evaluate with adjusted scope
+- "取消" → 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? (确认/取消)
+```
 
-For each recommendation, provide:
-- The capability gap identified
-- Proposed framework/library
-- License type
-- Maturity level
-- Integration impact assessment
+### 3.4 Framework Evaluation Error Recovery
 
-### 3.3 User Confirmation
+> ⚠️ **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)
 
-Present evaluation to user — **user must confirm before proceeding**.
+**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
 
-If no new frameworks needed, state explicitly and proceed.
+**Recovery Actions**:
+1. Report error to user: "Framework evaluation skill failed: {specific reason}"
+2. Ask user: "Retry with additional context?" or "Abort workflow?"
+3. IF retry → Re-invoke speccrew-sd-framework-evaluate with adjusted parameters
+4. IF abort → END workflow
 
 ## Phase 4: Generate DESIGN-OVERVIEW.md (L1)
 
@@ -271,6 +475,38 @@ Create the top-level overview at:
 - 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
 
 ### 5.1 Determine Platform Types
@@ -391,6 +627,72 @@ After each worker completes, parse its **Task Completion Report** and update:
 
 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 speccrew-workspace/scripts/update-progress.js update-task --file speccrew-workspace/iterations/{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:
@@ -419,7 +721,35 @@ After all platform designs are complete:
 4. **Highlight cross-platform integration points**
 5. **Request user confirmation**
 
-### 6.1 DISPATCH-PROGRESS.json Task Entry Format
+### 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.
+- "确认" or "OK" → Finalize all designs, update workflow status to confirmed
+- "修改" + specific Feature/Platform → Re-dispatch design workers for specified scope
+- "取消" → 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
 
 每个 task entry 包含以下字段:
 ```json
@@ -447,7 +777,7 @@ After all platform designs are complete:
 }
 ```
 
-### 6.2 Update Checkpoints on Confirmation
+### 6.3 Update Checkpoints on Confirmation
 
 After user confirms:
 
@@ -545,18 +875,30 @@ After user confirms:
 # Constraints
 
 **Must do:**
-- Read techs knowledge BEFORE generating any design
-- Present framework evaluation to user for confirmation
-- Use platform_id from techs-manifest as directory names under `03.system-design/`
-- Ensure each module design maps to a Feature Spec function
-- Generate DESIGN-OVERVIEW.md before dispatching platform skills
-- Verify API Contract exists and reference it (read-only)
-- Parse Feature ID from filename when using new format
-- Maintain backward compatibility with old format
+- 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 load ALL techs knowledge (manifest + platform-specific stacks) before Phase 3
+- Phase 3: MUST use speccrew-sd-framework-evaluate skill for framework evaluation — DO NOT evaluate yourself
+- Phase 3: User MUST confirm framework decisions (🛑 HARD STOP) before proceeding to Phase 4
+- Phase 4: MUST generate DESIGN-OVERVIEW.md with complete Feature×Platform index 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 6: ONLY after user explicitly confirms → update workflow status and checkpoints
+- ALL: Read techs knowledge BEFORE generating any design
+- 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
 
 **Must not do:**
-- Write actual source code (only pseudo-code in design docs)
-- Modify API Contract documents
-- Skip framework evaluation checkpoint
-- Assume technology stack without reading techs knowledge
-- Generate designs for platforms not in techs-manifest
+- 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 assume technology stack without reading techs knowledge
+- DO NOT generate designs for platforms not in techs-manifest
+- DO NOT generate per-platform or per-feature design documents yourself (INDEX.md, {feature-id}-{feature-name}-design.md, etc.) — always dispatch platform design skills via workers. DESIGN-OVERVIEW.md is the ONLY system design document this Agent generates directly
+- 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 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 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

package/.speccrew/skills/speccrew-fd-api-contract/SKILL.md

@@ -21,6 +21,12 @@ tools: Read, Write, Glob, Grep
 
 3. **MANDATORY: Template-first workflow** — Step 4a (copy template) MUST execute before Step 4b (fill sections). Skipping Step 4a and writing content directly is FORBIDDEN.
 
+4. **ABORT CONDITIONS** — If any of the following occur, STOP immediately and report to user:
+   - Feature Spec document (`feature_spec_path`) does not exist or is empty → STOP
+   - API Contract template file does not exist → STOP
+   - `node ... update-progress.js` script execution fails → **HARD STOP**: Do NOT manually create or edit JSON progress files. Report the script error and wait for user resolution.
+   - User rejects Joint Confirmation → STOP, ask user for specific revision requirements
+
 ## Step 1: Read Input
 
 ### Input Parameters
@@ -152,6 +158,8 @@ After confirmation, you can start frontend and backend Designer Agents separatel
 
 After user confirms Joint Confirmation:
 
+> **SCRIPT ENFORCEMENT RULE**: All `.checkpoints.json` and `WORKFLOW-PROGRESS.json` updates MUST be performed via `node speccrew-workspace/scripts/update-progress.js` commands. Manually creating or editing these JSON files is FORBIDDEN. If the script fails, STOP and report the error — do NOT attempt manual JSON construction.
+
 ### 6a: Update Checkpoints File
 
 Update the `.checkpoints.json` file to record confirmation status.
@@ -272,6 +280,8 @@ Update `WORKFLOW-PROGRESS.json` to reflect current feature/module status.
 - Record all output file paths
 - Log: "✅ Stage 02_feature_design confirmed. Ready for System Design phase."
 
+> **Note**: On Windows PowerShell, do not use backslash (`\`) for line continuation. Write the entire command on a single line.
+
 **关于全局状态管理的说明**：
 > Feature 粒度的 API Contract 完成后，全局阶段状态（`02_feature_design.status` 和 `current_stage`）**不由本 Skill 更新**。
 > 全局状态由 **Feature Designer Agent** 统一管理，当检测到所有 Feature 都完成时，统一更新为 `confirmed` 并推进到下一阶段。