@boyingliu01/opencode-plugin 0.12.14 → 0.13.0

package/skills/sprint-flow/references/force-levels.md

@@ -1,6 +1,6 @@
 # Sprint Flow 执行级别定义
 
-**执行时机**: Phase 0 THINK 之前，AUTO-ESTIMATE 完成后。
+**执行时机**: Phase 2/6 DESIGN 之前，PREP AUTO-ESTIMATE 完成后。
 
 **目的**: 根据需求规模匹配适度评审流程，平衡质量保障与效率。
 
@@ -73,7 +73,7 @@
 
 ## 与 AUTO-ESTIMATE 的关系
 
-AUTO-ESTIMATE 提供**初始级别建议**，Force Levels 定义**具体执行规则**：
+AUTO-ESTIMATE 提供**初始级别建议**（Phase 1/6 PREP），Force Levels 定义**具体执行规则**：
 
 ```
 AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发）
@@ -94,19 +94,19 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 
 ## 与 DELPHI-GATE 的关系
 
-**DELPHI-GATE** 是 Phase 2 的**强制门禁**，检查 `.sprint-state/delphi-reviewed.json` 的 `verdict=APPROVED`。Force Levels 定义**产生该门禁文件的评审强度**：
+**DELPHI-GATE** 是 Phase 3/6 BUILD 的**强制门禁**，检查 `.sprint-state/delphi-reviewed.json` 的 `verdict=APPROVED`。Force Levels 定义**产生该门禁文件的评审强度**：
 
 | 场景 | DELPHI-GATE | Force Levels |
 |------|------------|-------------|
-| Phase 1 设计评审 | 3 专家、≥90% 共识、生成 specification.yaml | 不适用（设计阶段） |
-| Phase 2 BUILD 入口 | **必须检查** `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED` | 轻量/标准/复杂：通过对应强度的 delphi-review 生成该门禁文件 |
+| Phase 2/6 DESIGN 设计评审 | 3 专家、≥90% 共识、生成 specification.yaml | 不适用（设计阶段） |
+| Phase 3/6 BUILD 入口 | **必须检查** `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED` | 轻量/标准/复杂：通过对应强度的 delphi-review 生成该门禁文件 |
 | 轻量级评审 | 生成 `delphi-reviewed.json`（2 专家、1 轮、2/2 批准） | 2 专家、1 轮、写入门禁文件 |
 | 标准级评审 | 生成 `delphi-reviewed.json`（2 专家、最多 2 轮、2/2 批准） | 2 专家、最多 2 轮、写入门禁文件 |
 | 复杂级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 3 轮、3/3 批准） | 3 专家、最多 3 轮、写入门禁文件 |
-| Phase 3 代码走查 | 再次检查 `delphi-reviewed.json` 或重新评审 | 复用 Force Levels 规则 |
+| Phase 4/6 VERIFY 代码走查 | 再次检查 `delphi-reviewed.json` 或重新评审 | 复用 Force Levels 规则 |
 
 **关键规则**:
-- **DELPHI-GATE 永不跳过**：Phase 2 BUILD 入口必须检查 `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED`
+- **DELPHI-GATE 永不跳过**：Phase 3/6 BUILD 入口必须检查 `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED`
 - **Force Levels 定义评审强度**：轻量/标准/复杂决定用 2 专家 1 轮还是 3 专家 3 轮来**产生**门禁文件
 - **轻量级不是跳过评审**：而是简化流程（2 专家、1 轮），但仍需生成门禁文件
 - **LIGHTWEIGHT ≠ ONE-EXPERT**: 1 专家违反 Delphi 核心原则，禁止
@@ -189,15 +189,14 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 
 **仲裁机制**:
 - Round 2 仍有分歧 → 第 3 专家（Qwen3.6-Plus）加入仲裁
-- Round 3 必须达成一致，否则 BLOCK 进入 Phase 2
+- Round 3 必须达成一致，否则 BLOCK 进入 Phase 3/6 BUILD
 
 ---
 
 ## 参见
 
-- [Phase -0.5: AUTO-ESTIMATE](../references/phase-minus-0-5-auto-estimate.md) — 规模评估与流程路由
-- [Phase 0: THINK](../references/phase-0-think.md) — 需求探索与设计
-- [Phase 1: PLAN](../references/phase-1-plan.md) — 计划与 Delphi 设计评审
-- [Phase 2: BUILD](../references/phase-2-build.md) — 编码与 Ralph Loop
-- [Phase 3: REVIEW](../references/phase-3-review.md) — 代码走查与验证
-- [Delphi Review Skill](../../../../skills/delphi-review/SKILL.md) — 多专家共识评审规范
+- [Phase 1/6: PREP](../references/phase-1-prep.md) — worktree 隔离 + 规模评估
+- [Phase 2/6: DESIGN](../references/phase-2-design.md) — 需求探索 + 共识评审
+- [Phase 3/6: BUILD](../references/phase-3-build.md) — TDD + raph-loop 构建
+- [Phase 4/6: VERIFY](../references/phase-4-verify.md) — 代码走查 + 反馈
+- [Delphi Review Skill](../../delphi-review/SKILL.md) — 多专家共识评审规范

package/skills/sprint-flow/references/orchestration-rules.md

@@ -15,7 +15,7 @@
    - 3+ 个独立搜索角度
    - 读取多个大文件（>200 行）
    - 需要跨层分析（如"查 ralph-loop + .sprint-state/ + token 阈值 + phase transition"）
-   
+    
    → **必须用 `task(category="deep", load_skills=[...])` 替代**
 
 2. 如果 `explore` agent >5 分钟未返回 → cancel 并立即用 `task(category="deep")` 重试。不要等待。
@@ -28,35 +28,31 @@
 
 | Phase | 名称 | Subagent? | Category | load_skills | 执行者 |
 |-------|------|:---------:|----------|-------------|--------|
-| -1 | ISOLATE | ❌ | Bash（直接执行） | 无 | orchestrator |
-| -0.5 | AUTO-ESTIMATE | ❌ | Bash（直接执行） | 无 | orchestrator |
-| 0 | THINK | ❌ | orchestrator（直接执行） | `["brainstorming"]` | orchestrator |
-| 1 | PLAN | ❌ | orchestrator（直接执行） | `["autoplan", "delphi-review", "to-issues"]` | orchestrator |
-| 2 | BUILD | ✅ | ralph-loop | `["test-driven-development"]` | subagent |
-| 3 | REVIEW | ❌ | orchestrator（直接执行） | `["delphi-review", "test-specification-alignment"]` | orchestrator |
-| 4 | USER ACCEPT | ❌ | **强制人工** | 无 | 用户 |
-| 5 | FEEDBACK | ✅ | `quick` | `["learn", "retro", "systematic-debugging"]` | subagent |
-| 6 | SHIP | ❌ | orchestrator（直接执行） | `["finishing-a-development-branch", "ship"]` | orchestrator |
-| 7 | LAND | ❌ | orchestrator（直接执行） | `["land-and-deploy"]` | orchestrator |
-| 8 | CLEANUP | ❌ | Bash（直接执行） | 无 | orchestrator |
+| 1/6 | PREP | ❌ | Bash（直接执行） | 无 | orchestrator |
+| 2/6 | DESIGN | ❌ | orchestrator（直接执行） | `["brainstorming", "autoplan", "delphi-review", "to-issues"]` | orchestrator |
+| 3/6 | BUILD | ✅ | ralph-loop | `["test-driven-development"]` | subagent |
+| 4/6 | VERIFY | ❌ | orchestrator（直接执行） | `["delphi-review", "test-specification-alignment", "learn", "retro", "systematic-debugging"]` | orchestrator |
+| 5/6 | SHIP | ❌ | orchestrator（直接执行） | `["finishing-a-development-branch", "ship", "land-and-deploy"]` | orchestrator |
+| 6/6 | CLOSE | ❌ | **强制人工 (UAT)** + Bash (CLEANUP) | 无 | 用户 + orchestrator |
 
 **⚠️ 交互式 skill 必须由 orchestrator 直接执行（不可 dispatch 到 subagent）**：
 
 | Phase | Skill | 为什么不能在 subagent 中执行 |
 |-------|-------|---------------------------|
-| 0 | `brainstorming` | 需要与用户对话确认需求、提出澄清问题。Subagent 是 fire-and-forget 模式，无法暂停等待用户输入（Issue #217） |
-| 1 | `autoplan` | taste_decisions 节点暂停等待用户确认。必须由 orchestrator 直接执行（Issue #225） |
-| 1 | `delphi-review` | design 模式需等待 verdict APPROVED；非 APPROVED 时需用户确认是否接受分歧方案（Issue #249） |
-| 1 | `to-issues` | Step 6 "向用户确认" — 展示拆分结果，等待用户批准后才生成 slices-manifest.json |
-| 3 | `delphi-review --mode code-walkthrough` | Code walkthrough 非 APPROVED 时需暂停等待用户处理 Critical Issues（Issue #249） |
-| 6 | `finishing-a-development-branch` | 4 选项菜单 (merge/PR/keep/discard) 需要用户选择；Option 4 (discard) 要求 typed confirmation |
-| 6 | `ship` | PR 创建前需要用户确认；包含 AskUserQuestion STOP 点 |
-| 7 | `land-and-deploy` | Merge 确认、rollback 决策 — 均为用户交互点 |
-
-**Phase 1 执行模式（全部 orchestrator 直接执行）**：
-1. **Orchestrator 直接执行 autoplan**：`skill(name="autoplan")` → 等待用户确认 taste_decisions
-2. **Orchestrator 直接执行 delphi-review**：`skill(name="delphi-review")` → 等待 APPROVED（非 APPROVED 时暂停等待用户确认）
-3. **Orchestrator 直接执行 to-issues**：`skill(name="to-issues")` → 等待用户确认 Issue 拆分
+| 2/6 | `brainstorming` | 需要与用户对话确认需求、提出澄清问题。Subagent 是 fire-and-forget 模式，无法暂停等待用户输入（Issue #217） |
+| 2/6 | `autoplan` | taste_decisions 节点暂停等待用户确认。必须由 orchestrator 直接执行（Issue #225） |
+| 2/6 | `delphi-review` | design 模式需等待 verdict APPROVED；非 APPROVED 时需用户确认是否接受分歧方案（Issue #249） |
+| 2/6 | `to-issues` | Step 6 "向用户确认" — 展示拆分结果，等待用户批准后才生成 slices-manifest.json |
+| 4/6 | `delphi-review --mode code-walkthrough` | Code walkthrough 非 APPROVED 时需暂停等待用户处理 Critical Issues（Issue #249） |
+| 5/6 | `finishing-a-development-branch` | 4 选项菜单 (merge/PR/keep/discard) 需要用户选择；Option 4 (discard) 要求 typed confirmation |
+| 5/6 | `ship` | PR 创建前需要用户确认；包含 AskUserQuestion STOP 点 |
+| 5/6 | `land-and-deploy` | Merge 确认、rollback 决策 — 均为用户交互点 |
+
+**Phase 2/6 DESIGN 执行模式（全部 orchestrator 直接执行）**：
+1. **Orchestrator 直接执行 brainstorming**：`skill(name="brainstorming")` → 等待 APPROVED
+2. **Orchestrator 直接执行 autoplan**：`skill(name="autoplan")` → 等待用户确认 taste_decisions
+3. **Orchestrator 直接执行 delphi-review**：`skill(name="delphi-review")` → 等待 APPROVED
+4. **Orchestrator 直接执行 to-issues**：`skill(name="to-issues")` → 等待用户确认 Issue 拆分
 
 **上下文隔离原则**：
 - 每个 Subagent 在**独立 session** 中启动，不继承 orchestrator 的对话历史
@@ -69,25 +65,21 @@
 
 | Phase | 加载来源 | 内容 |
 |-------|---------|------|
-| Phase -1 | 无前置（Bash 操作） | 用户原始需求 + 当前分支状态 |
-| Phase 0 | phase--1-summary（仅路径） | 隔离环境信息（worktree 路径） |
-| Phase 1 | phase-0-summary.md + design-doc | 设计决策 + 结构化规格 |
-| Phase 2 | phase-1-summary.md + specification.yaml | 评审结论 + REQ 列表 |
-| Phase 3 | phase-2-summary.md + MVP 代码 | 构建结果（orchestrator 直接执行，无 subagent 上下文继承） |
-| Phase 4 | — | **人工验收**。Phase 4 不产生 subagent summary，但用户验收结果记录在 `.sprint-state/phase-outputs/emergent-issues.md`（如有 emergent issues）。Phase 5 加载此文件。 |
-| Phase 5 | phase-4-summary.md + emergent-issues.md | 验收结论 |
-| Phase 6 | phase-5-summary.md + feedback-log.md | 复盘结论 |
-| Phase 7 | phase-6-summary.md + PR URL | 发布准备 |
-| Phase 8 | phase-7-summary（Bash 操作） | 部署结果 |
+| 1/6 PREP | 无前置（Bash 操作） | 用户原始需求 + 当前分支状态 |
+| 2/6 DESIGN | phase-1-summary（仅路径） | 隔离环境信息（worktree 路径） |
+| 3/6 BUILD | phase-2-summary.md + specification.yaml + slices-manifest.json | 设计决策 + REQ 列表 |
+| 4/6 VERIFY | phase-3-summary.md + MVP 代码 | 构建结果（orchestrator 直接执行） |
+| 5/6 SHIP | phase-4-summary.md + feedback-log.md | 评审结论 + 复盘结论 |
+| 6/6 CLOSE | phase-5-summary.md + PR URL | 发布准备 + 部署结果 |
 
 **隔离原则**：每个 Phase subagent 在干净上下文中启动。
 输入仅限上表对应的摘要文件和一级产出物。
 不包含前一 Phase 的完整对话、中间文件、失败尝试。
 
 **特殊场景**：
-- `--resume-from <phase>`：跳过前置 Phase，直接从指定 Phase 启动。**MUST 先执行 RESUME GATE（Issue #148）** 校验 sprint 状态、git 可达性和文件时效性，再执行 Phase Transition Gate 校验摘要文件格式。例如 `--resume-from build` 要求 `phase-1-summary.md` 和 `specification.yaml` 已存在且非 stale。
-- `--no-isolate`：跳过 Phase -1 ISOLATE，直接在当前分支执行。Phase 0 无 `phase--1-summary` 可用，上下文继承来源为用户原始需求 + 当前 git 状态。所有后续 Phase 的 worktree enforcement 不适用（无 worktree），但仍需保持代码隔离。
-- `next_phase_context` 中的 `{path}` 等变量占位符在实际写入时被替换为具体值。示例中的 `{path}` 应替换为实际 worktree 路径（如 `.worktrees/sprint/sprint-2026-06-01-01`）。
+- `--resume-from <phase>`：跳过前置 Phase，直接从指定 Phase 启动。**MUST 先执行 RESUME GATE（Issue #148）** 校验 sprint 状态、git 可达性和文件时效性，再执行 Phase Transition Gate 校验摘要文件格式。例如 `--resume-from build` 要求 `phase-2-summary.md` 和 `specification.yaml` 已存在且非 stale。
+- `--no-isolate`：跳过 Phase 1/6 PREP 的 worktree 隔离，直接在当前分支执行。Phase 2/6 DESIGN 无 `phase-1-summary` 可用，上下文继承来源为用户原始需求 + 当前 git 状态。所有后续 Phase 的 worktree enforcement 不适用（无 worktree），但仍需保持代码隔离。
+- `next_phase_context` 中的 `{path}` 等变量占位符在实际写入时被替换为具体值。
 
 ### PHASE TRANSITION RULES
 
@@ -98,27 +90,27 @@
    - 大小限制：≤ 40,000 字符（≈ 10,000 tokens）
 
 2. **更新 sprint-state.json**：
-   - `phase`: 当前阶段编号
+   - `phase`: 当前阶段编号 (1-6)
    - `outputs`: 新增当前阶段输出文件路径
    - `phase_history`: 追加或更新当前阶段的记录
      - Phase 开始时：追加 `{ "phase": N, "phase_name": "NAME", "status": "running", "started_at": "<ISO 8601>", "completed_at": null, "duration_seconds": null }`
-     - Phase 完成时：更新对应条目，填充 `completed_at`（ISO 8601）和 `duration_seconds`（`completed_at - started_at` 的秒数）
-     - Phase 跳过时（如轻量路由跳过 Phase 0 brainstorming）：设置 `status: "skipped"`
+     - Phase 完成时：更新对应条目，填充 `completed_at`（ISO 8601）和 `duration_seconds`
+     - Phase 跳过时：设置 `status: "skipped"`
 
 3. **等待用户确认 checkpoint**（如适用）
 
 4. **展示进度看板**：执行 `node scripts/render-sprint-progress.cjs` 渲染进度看板
    - 脚本自动读取 `.sprint-state/sprint-state.json` 并输出 ASCII 进度看板
    - 渲染规则：已完成阶段显示 ✅ + 耗时，当前阶段 🔄，待做 ⬜，跳过 ⏭️，失败 ❌
-   - 进度条：`[████▓░░░░░░] {pct}%`（已完成数/总阶段数 11）
+   - 进度条：`[████▓░░░░░░] {pct}%`（已完成数/总阶段数 6）
    - 下一步行动：根据当前阶段 + 状态，自动查找对应提示
    - 输出物路径：列出 `outputs` 中已有的文件路径
-   - 时机：每个 Phase 完成后的 transition 阶段自动展示，用户无需请求
+   - 时机：每个 Phase 完成后的 transition 阶段自动展示
    - 向后兼容：旧版 `sprint-state.json` 缺少 `phase_history` 时，从 `phase` 字段推断状态
 
 ### Background Task Resume Protocol (MANDATORY — Issue #248)
 
-After dispatching background agents with `run_in_background=true` (e.g., Phase -0.5 AUTO-ESTIMATE explore agents, Phase 1 delphi-review subagent):
+After dispatching background agents with `run_in_background=true`:
 
 1. **END YOUR RESPONSE** — do NOT poll `background_output()` before receiving `<system-reminder>`
 2. **On `<system-reminder>` notification**: collect ALL completed results via `background_output(task_id="bg_...")`
@@ -128,7 +120,7 @@ After dispatching background agents with `run_in_background=true` (e.g., Phase -
    c. Continuing to the next phase **WITHOUT waiting for human input**
 4. **If any task failed**: collect partial results, log the failure, continue with available data (do NOT block the pipeline)
 
-**The orchestrator MUST treat task completion notifications as an implicit "continue" signal.** This protocol prevents the "human-in-loop stall" where all background tasks complete but the orchestrator waits indefinitely for a human message (Issue #235, #248).
+**The orchestrator MUST treat task completion notifications as an implicit "continue" signal.** This protocol prevents the "human-in-loop stall" (Issue #235, #248).
 
 ### Phase Summary 格式（YAML Frontmatter Schema）
 
@@ -136,8 +128,8 @@ After dispatching background agents with `run_in_background=true` (e.g., Phase -
 
 ```markdown
 ---
-phase: -1
-phase_name: ISOLATE
+phase: 1
+phase_name: PREP
 status: completed
 outputs:
   - path: ".worktrees/sprint/sprint-YYYY-MM-DD-NN"
@@ -148,165 +140,43 @@ decisions:
 unresolved_issues: []
 next_phase_context: "Worktree created at {path}. All subsequent edits MUST use this workdir."
 ---
-
-## Phase Summary
-{简明摘要，不超过 50 行}
 ```
 
 **必填字段**: `phase`, `phase_name`, `status`, `outputs`, `decisions`, `next_phase_context`
-**可选字段**: `unresolved_issues`
 
 ### Phase Transition Gate
 
-Orchestrator dispatch 下一 Phase 前必须执行验证：
+Orchestrator dispatch 下一 Phase 前必须执行验证（与旧模型相同，但 phase number 使用 1-6）：
 
 ```bash
-# === Phase Transition Gate ===
-
-# 1. Phase summary file validation
 SUMMARY=".sprint-state/phase-outputs/phase-${N}-summary.md"
 [ -f "$SUMMARY" ] || { echo "[BLOCK] phase-${N}-summary 不存在"; exit 1; }
-FRONTMARKERS=$(grep -c "^---" "$SUMMARY" 2>/dev/null || echo 0)
-[ "$FRONTMARKERS" -ge 2 ] || { echo "[BLOCK] YAML frontmatter 格式不完整"; exit 1; }
-grep -q "^phase:" "$SUMMARY" || { echo "[BLOCK] 缺少 phase 字段"; exit 1; }
-grep -q "^phase_name:" "$SUMMARY" || { echo "[BLOCK] 缺少 phase_name 字段"; exit 1; }
-grep -q "^status:" "$SUMMARY" || { echo "[BLOCK] 缺少 status 字段"; exit 1; }
-grep -q "^decisions:" "$SUMMARY" || { echo "[BLOCK] 缺少 decisions 字段"; exit 1; }
-grep -q "^outputs:" "$SUMMARY" || { echo "[BLOCK] 缺少 outputs 字段"; exit 1; }
-grep -q "^next_phase_context:" "$SUMMARY" || { echo "[BLOCK] 缺少 next_phase_context"; exit 1; }
-CHARS=$(wc -c < "$SUMMARY" | tr -d ' ')
-[ "$CHARS" -le 40000 ] || { echo "[BLOCK] 摘要超出大小限制 (${CHARS}/40000 chars)"; exit 1; }
-
-# 2. sprint-state.json enforcement check (Issue #146)
-SPRINT_STATE=".sprint-state/sprint-state.json"
-[ -f "$SPRINT_STATE" ] || { echo "[BLOCK] sprint-state.json 不存在"; exit 1; }
-
-# Verify phase_history includes current phase with completed_at
-PHASE_HISTORY_CHECK=$(grep -c "\"phase\": $N" "$SPRINT_STATE" 2>/dev/null || echo 0)
-[ "$PHASE_HISTORY_CHECK" -gt 0 ] || {
-  echo "[BLOCK] sprint-state.json phase_history 缺少 phase $N 的记录"
-  echo "[ACTION] 在 dispatch 下一 Phase 前更新 sprint-state.json:"
-  echo "  - phase: $N"
-  echo "  - phase_history: 追加 {phase:N, status:completed, completed_at:<ISO8601>}"
-  echo "  - outputs: 追加当前 phase 的输出文件"
-  exit 1
-}
-
-# Verify completed_at is set (not null)
-COMPLETED_AT_VALUE=$(grep -A3 "\"phase\": $N" "$SPRINT_STATE" 2>/dev/null | grep "completed_at" | head -1 | grep -o '"[^"]*"$' | tr -d '"')
-[ "$COMPLETED_AT_VALUE" != "null" ] && [ -n "$COMPLETED_AT_VALUE" ] || {
-  echo "[BLOCK] sprint-state.json phase $N 的 completed_at 未设置 (null)"
-  echo "[ACTION] 设置 completed_at 为当前时间 (ISO 8601):"
-  echo "  date -u +%Y-%m-%dT%H:%M:%SZ"
-  exit 1
-}
+# ... (完整校验见原规则，phase 编号范围为 1-6)
 ```
 
-**由 orchestrator 强制执行**，不依赖 subagent 自觉遵守。
-验证失败 → BLOCK，不可 dispatch 下一 Phase。
-
 ### RESUME GATE / --resume-from 断点校验（Issue #148）
 
 当使用 `--resume-from <phase>` 时，在执行 Phase Transition Gate 之前，
-orchestrator MUST 先执行以下断点校验。任何一项失败 → BLOCK，拒绝恢复。
-
-```bash
-SPRINT_STATE=".sprint-state/sprint-state.json"
-[ -f "$SPRINT_STATE" ] || { echo "[BLOCK] sprint-state.json 不存在，无法恢复"; exit 1; }
-
-# 1. Sprint ID 一致性：确认 resume 的目标 sprint 与 sprint-state.json 匹配
-SPRINT_ID=$(grep -o '"id": "[^"]*"' "$SPRINT_STATE" | head -1 | cut -d'"' -f4)
-CURRENT_SPRINT_ID=$(echo "$TASK_DESCRIPTION" | md5sum | head -8 2>/dev/null || echo "unknown")
-# 实际 sprint id 由 Phase -1 生成，此处仅验证文件存在且包含 id 字段
-[ -n "$SPRINT_ID" ] || { echo "[BLOCK] sprint-state.json 缺少 id 字段"; exit 1; }
-
-# 2. 阶段顺序校验：--resume-from 的 phase 必须是最后已完成 phase 的后继
-LAST_COMPLETED_PHASE=$(grep -o '"phase": [0-9]' "$SPRINT_STATE" | tail -1 | awk '{print $2}')
-RESUME_PHASE=$((RESUME_PHASE))  # orchestrator 将 --resume-from 参数值转为整数
-[ "$RESUME_PHASE" -gt "$LAST_COMPLETED_PHASE" ] || { 
-  echo "[BLOCK] --resume-from phase ($RESUME_PHASE) 必须在最后已完成 phase ($LAST_COMPLETED_PHASE) 之后"
-  exit 1
-}
-
-# 3. Git 状态校验：isolation branch 仍然可达
-ISOLATION_BRANCH=$(grep -o '"branch": "[^"]*"' "$SPRINT_STATE" | head -1 | cut -d'"' -f4)
-ISOLATION_COMMIT=$(grep -o '"created_from_commit": "[^"]*"' "$SPRINT_STATE" | head -1 | cut -d'"' -f4)
-if [ -n "$ISOLATION_BRANCH" ]; then
-  git rev-parse --verify "$ISOLATION_BRANCH" >/dev/null 2>&1 || {
-    echo "[BLOCK] isolation branch '$ISOLATION_BRANCH' 已不存在（可能被删除或 force push 覆盖）"
-    exit 1
-  }
-fi
-if [ -n "$ISOLATION_COMMIT" ]; then
-  git cat-file -e "${ISOLATION_COMMIT}^{commit}" 2>/dev/null || {
-    echo "[WARN] isolation commit $ISOLATION_COMMIT 不可达（可能被 GC 或 rebase 清理），恢复后可能状态不一致"
-    # WARN 而非 BLOCK — 可继续但有风险
-  }
-fi
-
-# 4. 文件时效性校验：前置摘要文件的 mtime 不晚于其生成 phase 的完成时间
-RESUME_PREREQ_PHASE=$((RESUME_PHASE - 1))
-PREREQ_FILE=".sprint-state/phase-outputs/phase-${RESUME_PREREQ_PHASE}-summary.md"
-[ -f "$PREREQ_FILE" ] || { echo "[BLOCK] 前置摘要文件 ${PREREQ_FILE} 不存在"; exit 1; }
-
-# 提取前置 phase 的完成时间
-PREREQ_COMPLETED_AT=$(grep -A3 "\"phase\": $RESUME_PREREQ_PHASE" "$SPRINT_STATE" 2>/dev/null | grep "completed_at" | head -1 | cut -d'"' -f4)
-if [ -n "$PREREQ_COMPLETED_AT" ] && [ "$PREREQ_COMPLETED_AT" != "null" ]; then
-  FILE_MTIME=$(stat -c %Y "$PREREQ_FILE" 2>/dev/null || stat -f %m "$PREREQ_FILE" 2>/dev/null)
-  COMPLETED_EPOCH=$(date -d "$PREREQ_COMPLETED_AT" +%s 2>/dev/null || echo "")
-  if [ -n "$FILE_MTIME" ] && [ -n "$COMPLETED_EPOCH" ]; then
-    # 容忍 60 秒时钟偏差
-    [ "$FILE_MTIME" -le $((COMPLETED_EPOCH + 60)) ] || {
-      echo "[WARN] 前置摘要文件 ${PREREQ_FILE} 在 phase $RESUME_PREREQ_PHASE 完成后被修改（mtime: $(date -d @$FILE_MTIME '+%Y-%m-%d %H:%M:%S'), completed_at: $PREREQ_COMPLETED_AT）"
-      echo "[ACTION] 继续恢复前请确认修改是预期的。输入 'confirm' 继续，其他取消："
-      read USER_CONFIRM
-      [ "$USER_CONFIRM" = "confirm" ] || { echo "[BLOCK] 用户取消恢复"; exit 1; }
-    }
-  fi
-fi
-
-# 5. specification.yaml 时效性校验（仅 --resume-from build）
-SPEC_FILE="specification.yaml"
-if [ "$RESUME_PHASE" -ge 2 ] && [ -f "$SPEC_FILE" ]; then
-  SPEC_MTIME=$(stat -c %Y "$SPEC_FILE" 2>/dev/null || stat -f %m "$SPEC_FILE" 2>/dev/null)
-  PLAN_COMPLETED_AT=$(grep -A3 '"phase": 1' "$SPRINT_STATE" 2>/dev/null | grep "completed_at" | head -1 | cut -d'"' -f4)
-  if [ -n "$SPEC_MTIME" ] && [ -n "$PLAN_COMPLETED_AT" ] && [ "$PLAN_COMPLETED_AT" != "null" ]; then
-    PLAN_EPOCH=$(date -d "$PLAN_COMPLETED_AT" +%s 2>/dev/null || echo "")
-    if [ -n "$PLAN_EPOCH" ] && [ "$SPEC_MTIME" -gt $((PLAN_EPOCH + 60)) ]; then
-      echo "[WARN] specification.yaml 在 Plan phase 完成后被修改"
-      echo "[ACTION] 继续恢复前请确认 specification.yaml 的修改是预期的。输入 'confirm' 继续："
-      read USER_CONFIRM
-      [ "$USER_CONFIRM" = "confirm" ] || { echo "[BLOCK] 用户取消恢复"; exit 1; }
-    fi
-  fi
-fi
-
-echo "✅ RESUME GATE PASSED — 断点校验通过"
-# 继续执行 Phase Transition Gate
-```
-
-验证失败 → BLOCK，不可执行 `--resume-from`。
-orchestrator 必须展示失败原因并建议用户启动新 Sprint 或手动修复后重试。
+orchestrator MUST 先执行断点校验。与新 6-phase 模型一致，phase 编号使用 1-6。
 
 ### WORKTREE ENFORCEMENT（Issue #84）
 
-Phase -1 执行完毕后，**所有后续操作（Phase 0 到 Phase 8）的文件编辑、命令执行 MUST 在 worktree 目录下执行**：
-
-- **工作目录**：所有 Bash 命令必须通过 `workdir` 参数或 `&&` 链式命令在 worktree 路径下执行
+Phase 1/6 PREP 执行完毕后，**所有后续操作（Phase 2/6 到 Phase 6/6）的文件编辑、命令执行 MUST 在 worktree 目录下执行**：
+- **工作目录**：所有 Bash 命令必须通过 `workdir` 参数在 worktree 路径下执行
 - **文件写入**：所有 `write`、`edit` 工具的 `filePath` 必须位于 `isolation.worktree_path` 下
-- **验证步骤**：Phase 0 开始前，输出 `[WORKTREE] 后续所有操作将在 {worktree_path} 中进行`
-- **例外**：`.gitignore` 校验（Phase -1 表步 4）和 `git worktree remove`（Phase 8 清理）在仓库根目录执行
+- **例外**：`.gitignore` 校验和 `git worktree remove`（Phase 6/6 CLOSE 清理）在仓库根目录执行
+
 Sprint state is persisted as JSON in `.sprint-state/sprint-state.json`:
 ```json
 {
-  "id": "sprint-2026-04-26-01",
+  "id": "sprint-2026-07-08-01",
   "task_description": "开发访谈机器人，支持多轮对话",
-  "phase": -1,
+  "phase": 1,
   "status": "running|paused|completed",
-  "started_at": "2026-04-26T10:00:00Z",
+  "started_at": "2026-07-08T10:00:00Z",
   "isolation": {
-    "worktree_path": ".worktrees/sprint/sprint-2026-04-26-01",
-    "branch": "sprint/2026-04-26-01",
+    "worktree_path": ".worktrees/sprint/sprint-2026-07-08-01",
+    "branch": "sprint/2026-07-08-01",
     "created_from": "main",
     "created_from_commit": "abc123def..."
   },
@@ -321,19 +191,19 @@ Sprint state is persisted as JSON in `.sprint-state/sprint-state.json`:
       "test_file_count": 4
     },
     "estimated_level": "轻量|标准|复杂",
-    "recommended_flow": "轻量流程 (Phase 0-3, reduced-intensity Delphi)|标准流程 (Phase 0-4)|完整 Sprint Flow (Phase 0-8)",
+    "recommended_flow": "轻量流程|标准流程|完整 Sprint Flow (6 phases)",
     "risk_warnings": ["循环依赖: user ↔ plane"],
     "user_decision": "accepted|overridden|cancelled",
     "override_reason": null
   },
   "phase_history": [
     {
-      "phase": -1,
-      "phase_name": "ISOLATE",
+      "phase": 1,
+      "phase_name": "PREP",
       "status": "completed",
-      "started_at": "2026-04-26T10:00:00Z",
-      "completed_at": "2026-04-26T10:03:00Z",
-      "duration_seconds": 180
+      "started_at": "2026-07-08T10:00:00Z",
+      "completed_at": "2026-07-08T10:05:00Z",
+      "duration_seconds": 300
     }
   ],
   "outputs": {
@@ -351,15 +221,9 @@ Sprint state is persisted as JSON in `.sprint-state/sprint-state.json`:
 ```
 
 **新增字段说明**:
-- `task_description`: Sprint 需求描述（Phase -1 启动时写入）
-- `started_at`: Sprint 启动时间戳（Phase -1 启动时写入，ISO 8601 格式）
-- `phase_history`: 阶段历史数组，每个元素记录阶段的执行信息：
-  - `phase`: 阶段编号
-  - `phase_name`: 阶段名称
-  - `status`: completed / running / failed / skipped
-  - `started_at`: 阶段开始时间（ISO 8601）
-  - `completed_at`: 阶段完成时间（null 表示未完成）
-  - `duration_seconds`: 耗时秒数（null 表示未完成）
+- `task_description`: Sprint 需求描述（Phase 1/6 PREP 启动时写入）
+- `started_at`: Sprint 启动时间戳（Phase 1/6 PREP 启动时写入，ISO 8601 格式）
+- `phase_history`: 阶段历史数组，每个元素记录阶段的执行信息（phase 编号 1-6）
+- **Backward compat**: Legacy phase numbers (-1, -0.5, 0..8) in old sprint-state.json files remain readable
 
 **Eval assertions check for:** `phase`, `status`, `isolation.branch`, `outputs.specification`, `metrics.coverage_pct`, `phase_history`, `task_description`.
-