@boyingliu01/xp-gate 0.18.5 → 0.19.0

package/plugins/dsh/skills/sprint-flow/references/components/skill-invocations.md

@@ -0,0 +1,105 @@
+# skill-invocations.md — Phase→Skill 调用链与参数路由（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 中各 Phase 调用 Skills (L88-103, L155-167) 的 AHE 对齐展开。**
+> 用于 ablation 实验：验证 phase→skill 映射完整性对 Sprint 成功率的影响。
+
+## 组件职责
+
+提供完整的 Phase→Skill 映射表，包括技能来源、参数路由规则、条件分支逻辑。确保每次 Skill 调用具有足够的上下文信息。
+
+---
+
+## 完整 Phase→Skill 映射矩阵
+
+### Phase 0: THINK
+
+| Skill | 来源 | 触发条件 | 输出 |
+|-------|------|---------|------|
+| `grill-with-docs` | Matt Pocock (内置) | CONTEXT.md 不存在时（首个 Skill） | 访谈记录 + CONTEXT.md + ADR |
+| `delphi-review --mode requirements` | xp-gate | R1 三专家独立评审，验证 distinct model IDs 后聚合 ≥90% | requirements-reviewed.json |
+| 原生设计文档生成 | sprint-flow 编排层 | R1 APPROVED 后 | docs/plans/YYYY-MM-DD-<topic>-design.md |
+| **硬闸门** | — | 设计未批准 → 停止 | 禁止进入 Plan |
+
+### Phase 1: PLAN
+
+| Skill | 来源 | 触发条件 | 条件分支 |
+|-------|------|---------|---------|
+| `batch-grill-me` | Matt Pocock (内置) | 标准路径（change_type != "修改已存在代码"） | 批量前置决策 |
+| `delphi-review` | xp-gate | R2 三专家独立评审，最多 5 轮 | 必须产生 `.sprint-state/delphi-reviewed.json` 且 verdict=APPROVED |
+| `to-issues` | xp-gate | delphi-review APPROVED 后 | 拆解为垂直切片 → slices-manifest.json |
+
+### Phase 2: BUILD
+
+| 步骤 | Skill | 来源 | 参数注入 |
+|------|-------|------|---------|
+| -1 | `hooks-install` | githooks | 无 |
+| 0 | BUILD-ENTRY-CONTRACT | xp-gate CLI | slices-manifest.json schema + slice↔REQ 校验 |
+| 1 | `test-driven-development` | xp-gate (内置) | `--lang` 注入对应 TDD skill |
+| 2 | ralph-loop / parallel dispatch | sprint-flow 编排层 | 隔离 session，review checkpoint |
+| 3 | blind-review (read-only subagent) | sprint-flow 编排层 | tools: [Read, Grep, Glob] |
+| 4 | verification-before-completion | sprint-flow 编排层 | 运行测试 + lint |
+| 5 | 成本监控 | sprint-flow 编排层 | token 阈值 |
+| 6 | learnings.md 写入 | sprint-flow 编排层 | 原生文件写入 |
+
+### Phase 3: REVIEW
+
+| Skill | 模式 | 触发条件 |
+|-------|------|---------|
+| `delphi-review` | `--mode code-walkthrough` | 强制调用 |
+| `test-specification-alignment` | 默认 | 强制调用（#367 程序化 HARD-GATE） |
+| `xp-gate check --all` | 全量门禁 | 强制调用 |
+| 浏览器验证 | Layer 4 可选链 | gstack browse > browser-use MCP > SKIP |
+| `k6`/`locust`/`gatling` | 性能测试 | `--with-performance` 或 `--type backend-*` |
+
+### Phase 4: USER ACCEPTANCE
+
+| Skill | 说明 |
+|-------|------|
+| **无 Skill** | 必须人工验收 |
+
+### Phase 5: FEEDBACK
+
+| Skill | 来源 | 说明 |
+|-------|------|------|
+| learnings.md 写入 | 原生 | 模式记录（替代原 gstack learn） |
+| `xp-gate retro` | 原生 CLI | 工程回顾（含 #369 返工率区块） |
+| systematic-debugging | Layer 4 可选 | 根因调试（如已安装；否则"无根因不修复"文本纪律） |
+
+### Phase 6: SHIP
+
+| Skill | 说明 |
+|-------|------|
+| 分支完成决策（原生 4 选项） | merge / PR / keep / discard |
+| native ship 步骤 | test → VERSION-GATE → commit → push → gh pr create |
+| native land 步骤 | merge 确认 → wait CI → canary → fail git revert |
+
+---
+
+## 参数路由规则
+
+### `--lang` 路由
+
+| 值 | Phase 2 注入 | Phase 3 注入 |
+|---|-------------|-------------|
+| `springboot` | `springboot-tdd` | springboot-verification |
+| `django` | `django-tdd` | django-verification |
+| `golang` | `golang-testing` | golang-verification |
+
+### `--type` 路由
+
+| 值 | 检测依据 | 额外 Skill |
+|---|---------|-----------|
+| `web-nextjs` | `next.config.js` / `app/` | `design-shotgun` |
+| `backend-go` | `go.mod` | `k6` |
+| `backend-springboot` | `pom.xml` | `gatling` |
+| `backend-django` | `manage.py` | `locust` |
+
+---
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | Skill Invocation Chain |
+| 修改频率预期 | 中（新 skill 注册时更新） |
+| 消融实验假设 | 调用链中断 → Sprint 执行失败率 ↑ |

package/plugins/dsh/skills/sprint-flow/references/components/system-prompt.md

@@ -0,0 +1,27 @@
+# system-prompt.md — Sprint Flow 行为定义（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 核心原则部分 (L34-43) 的 AHE 对齐展开。**
+> 用于 ablation 实验：单独修改本文件可观察核心原则对 Sprint pass rate 的影响。
+
+## 核心职责
+
+定义 Sprint Flow 的行为边界和全局约束。相当于 AHE 的 System Prompt 组件（虽 AHE 论文显示单独修改 System Prompt 不改善性能，但作为行为基准仍然必要）。
+
+## 核心原则 (AHE 对齐)
+
+| # | AHE 概念 | 原则 | 说明 | 硬闸门 |
+|---|---------|------|------|--------|
+| 1 | 单一入口 | `/sprint-flow` | 用户只需一个命令，自动串联全流程 | Phase 0 HARD-GATE |
+| 2 | 自动流水线 | Think → Ship | 类似 autoplan，自动执行多个阶段 | 无需用户手动调用中间技能 |
+| 3 | 关键节点暂停 | APPROVED / Gate 1 / Phase 4 / Ship | 明确暂停点，不是随时停 | Phase 0 设计未 APPROVED → 禁止编码 |
+| 4 | 承认 Emergent Requirements | 用户验收环节必须人工 | 78% 失败不可见，无法自动化 | Phase 4 MUST NOT 自动化 |
+| 5 | 复用现有 Skills | 不重新发明 | 整合 brainstorming + autoplan + delphi-review + TDD 等 | 不创建新 skill，复用现有体系 |
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | System Prompt |
+| 修改频率预期 | 低（行为基线稳定后极少改变） |
+| 消融实验假设 | 修改核心原则 → Sprint pass rate 不变或下降（AHE 发现单独修改系统提示下降 2.3%） |
+| 关键约束 | 不得删除 Phase 4 人工验收硬闸 |

package/plugins/dsh/skills/sprint-flow/references/components/tool-descriptions.md

@@ -0,0 +1,95 @@
+# tool-descriptions.md — Sprint Flow 各 Phase 调用的 Skill 完整描述（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 中 Phase 2-6 Skill 调用 (L120-298) 的 AHE 对齐展开。**
+> 用于 ablation 实验：AHE 论文显示 Tool 组件贡献占 48%，单独修改可显著影响性能。
+
+## 组件职责
+
+完整描述 sprint-flow 在每个 Phase 中调用的 Skill，包括参数路由、`--lang`/`--type` 注入、条件分支逻辑。是 ablation 实验中**最可能产生显著增益**的组件。
+
+---
+
+## Phase 2: BUILD 工具链（核心贡献区 — 48%）
+
+### 默认模式: ralph-loop
+
+| 步骤 | Skill | 来源 | 说明 |
+|------|-------|------|------|
+| -1 | `hooks-install` | githooks | `githooks/verify.sh` → 缺失则 `githooks/install.sh` |
+| 0 | BUILD-ENTRY-CONTRACT | xp-gate CLI | slices-manifest.json schema + slice↔REQ 校验 |
+| 1 | `test-driven-development` | xp-gate (内置) | RED → GREEN → REFACTOR |
+| 2 | ralph-loop / parallel dispatch | sprint-flow 编排层 | 隔离 session，review checkpoint |
+| 3 | blind-review (read-only subagent) | sprint-flow 编排层 | tools: [Read, Grep, Glob]，只读盲评 |
+| 4 | verification-before-completion | sprint-flow 编排层 | 测试 + lint |
+| 5 | 成本监控 | sprint-flow 编排层 | 超阈值 BLOCK |
+| 6 | learnings.md 写入 | sprint-flow 编排层 | 原生模式记录 |
+
+### GITHOOKS-GATE (Phase 1→2 闸门)
+
+- 执行时机: Phase 1 完全通过、准备进入 Phase 2 BUILD 前
+- `githooks/verify.sh` 全部存在 → 进入 BUILD 入口（仍必须先执行 DELPHI-GATE）
+- 缺失 → `githooks/install.sh` 安装（hooks + adapter 基础设施）
+- **核心原则**: 没有质量门禁的代码不可进入 BUILD。**失败 → 不可编码。**
+
+### 语言特定 TDD
+
+通过 `--lang` 参数注入:
+- `springboot-tdd` → springboot-verification
+- `django-tdd` → django-verification
+- `golang-testing` → golang-verification
+
+---
+
+## Phase 3: REVIEW + TEST 工具链
+
+| Skill | 模式 | 说明 |
+|-------|------|------|
+| `delphi-review` | `--mode code-walkthrough` | 多专家匿名代码走查 |
+| `test-specification-alignment` | 默认 | 测试与 Spec 对齐验证（#367 程序化 HARD-GATE） |
+| `xp-gate check --all` | 全量门禁 | Gate 0–9 含安全审计 |
+| 浏览器验证 | Layer 4 可选链 | gstack browse > browser-use MCP > SKIP |
+| `k6` / `locust` / `gatling` | 可选 | 后端负载测试 |
+
+---
+
+## Phase 5: FEEDBACK 工具链
+
+| Skill | 说明 |
+|-------|------|
+| learnings.md 写入 | 原生模式记录（替代原 gstack learn） |
+| `xp-gate retro` | 原生工程回顾（含 #369 返工率区块） |
+| systematic-debugging | Layer 4 可选，根因调试（如已安装） |
+
+---
+
+## Phase 6: SHIP 工具链
+
+| Skill | 说明 |
+|-------|------|
+| 分支完成决策（原生 4 选项） | merge / PR / keep / discard |
+| native ship 步骤 | test → VERSION-GATE → commit → push → gh pr create |
+| native land 步骤 | merge 确认 → wait CI → canary → fail git revert |
+
+---
+
+## 项目类型 → Skill 注入映射
+
+| Phase | Backend (default) | Web Frontend | Mobile |
+|-------|------------------|-------------|--------|
+| Phase 0 (THINK) | `grill-with-docs` + R1 `delphi-review --mode requirements` | (同) | (同) |
+| Phase 1 (PLAN) | `batch-grill-me` + R2 `delphi-review` | + OPTIONAL `design-shotgun` | (同 web) |
+| Phase 2 (BUILD) | TDD + blind-review (read-only subagent) | (同 backend) | + `vercel-react-native-skills` / `flutter-review` |
+| Phase 3 (REVIEW) | `delphi-review --mode code-walkthrough` + `xp-gate check --all` | + `xp-gate ui-review` + OPTIONAL qa/design-review/benchmark | `flutter-test` / `detox E2E` |
+| Phase 5 (FEEDBACK) | learnings.md + `xp-gate retro` | (同) | (同) |
+| Phase 6 (SHIP) | 原生 4 选项 + native ship + native land | (同) | + platform deploy |
+
+---
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | Tool Description |
+| 修改频率预期 | 高（Phase 2 BUILD 工具链频繁调整） |
+| 消融实验假设 | 增删 phase→skill 映射 → Sprint pass rate 变化 ±20%+ |
+| 参考证据 | AHE 论文: Tool 组件单独修改带来 +3.3% 总增益 |

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

@@ -0,0 +1,204 @@
+# Sprint Flow 执行级别定义
+
+**执行时机**: Phase 2/6 DESIGN 之前，PREP AUTO-ESTIMATE 完成后。
+
+**目的**: 根据需求规模调整上下文深度与迭代预算，平衡质量保障与效率。Force level 永远不改变专家数量或批准语义。
+
+**核心原则**:
+- 所有级别**必须经过 Delphi 评审**，不可跳过
+- 所有级别都采用 architecture、technical、feasibility 三专家 Delphi；Round 1 独立执行并验证三份成功结果
+- 模型 ID、provider、vendor、gateway 和国籍不受限制；`requested_model` trimmed 后必须 distinct
+- 评审达到 ≥90% 共识，最多 5 轮；失败或无法验证时阻断
+- 自动升级机制：当出现风险信号时强制升级级别
+
+---
+
+## 级别定义
+
+| 级别 | 适用场景 | 专家数 | 最多轮数 | 通过条件 | 预计耗时 |
+|------|---------|--------|---------|----------|---------|
+| **轻量** | 小改动、局部修改、删除代码 | 3 | 1-5 | ≥90% 聚合共识 | 10-20 分钟 |
+| **标准** | 常规功能开发、模块重构 | 3 | 1-5 | ≥90% 聚合共识 | 30-60 分钟 |
+| **复杂** | 核心模块、跨模块变更、新增架构 | 3 | 1-5 | ≥90% 聚合共识 | 1-2 小时 |
+
+---
+
+## Token 成本预算
+
+| 级别 | delphi-review 调用 | 预计 Token 消耗 | 成本说明 |
+|------|-------------------|--------------|---------|
+| **轻量** | 1 次（3 专家、最多 5 轮） | ~8,000 | 简化上下文，仍需完整执行 |
+| **标准** | 1-2 次（3 专家、最多 5 轮） | ~15,000-25,000 | 可能需要反馈轮次 |
+| **复杂** | 1-3 次（3 专家、最多 5 轮） | ~30,000-60,000 | 多轮深度评审 |
+
+> **成本计算依据**: 基于实际 Sprint 历史数据，假设每次 delphi-review 调用平均消耗 8,000-10,000 Token（含 3 位专家的输入输出）。
+
+---
+
+## 测试与验证要求
+
+| 级别 | 单元测试 | 测试覆盖率 | 验证方式 |
+|------|---------|-----------|---------|
+| **轻量** | 修改处必须有测试 | ≥75% | 自动运行 + 人工抽查 |
+| **标准** | 新增功能必须有测试 | ≥80% | 自动运行 + 人工复核 |
+| **复杂** | 全链路测试 + 边界用例 | ≥85% | 自动运行 + Delphi 验证 |
+
+**强制规则**:
+- 轻量级修改**不可跳过测试**，至少添加回归测试
+- 所有级别必须通过 `test-specification-alignment` 验证
+- 未添加测试 → 自动升级至标准级别
+
+---
+
+## 自动升级机制
+
+当出现以下任一情况时，**强制升级**至更高级别：
+
+| 触发条件 | 原级别 | 升级至 | 说明 |
+|---------|--------|--------|------|
+| Delphi 评审出现 REQUEST_CHANGES | 轻量 | 标准 | 需要第二轮评审 |
+| 专家意见分歧 | 轻量/标准 | 复杂 | 增加上下文深度与后续轮次预算，不增加或替换专家 |
+| 涉及公共 API 变更 | 轻量 | 标准 | 影响外部调用方 |
+| 修改文件数 > 5 或 LOC > 200 | 轻量 | 标准 | 改动规模超出轻量范围 |
+| 存在循环依赖 | 轻量/标准 | 复杂 | 架构风险高 |
+| 测试覆盖率 < 75% | 轻量 | 标准 | 质量不达标 |
+| 修改核心模块（core/handlers） | 轻量/标准 | 复杂 | 关键路径 |
+
+**升级流程**:
+1. 自动检测触发条件
+2. 输出升级警告：`[LEVEL_UPGRADE] 从 {原级别} 升级至 {新级别}，原因：{触发条件}`
+3. 保存升级记录到 `.sprint-state/level-upgrade-log.json`
+4. 重新执行对应级别的评审流程
+
+---
+
+## 与 AUTO-ESTIMATE 的关系
+
+AUTO-ESTIMATE 提供**初始级别建议**（Phase 1/6 PREP），Force Levels 定义**具体执行规则**：
+
+```
+AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发）
+```
+
+| AUTO-ESTIMATE 指标 | 建议级别 | Force Levels 执行 |
+|-------------------|---------|------------------|
+| 引用计数 ≤ 3 + 跨模块 ≤ 1 | 轻量 | 3 专家、最多 5 轮 Delphi |
+| 引用计数 4-10 或 跨模块 2 | 标准 | 3 专家、最多 5 轮 Delphi |
+| 引用计数 > 10 或 跨模块 ≥ 3 | 复杂 | 3 专家、最多 5 轮 Delphi |
+| 存在循环依赖 | 强制复杂 | 3 专家、最多 5 轮 + 架构评审 |
+
+**关键区别**:
+- AUTO-ESTIMATE: **客观指标分析**（代码结构、引用计数）
+- Force Levels: **执行规则定义**（评审流程、升级机制）
+
+---
+
+## 与 DELPHI-GATE 的关系
+
+**DELPHI-GATE** 是 Phase 3/6 BUILD 的**强制门禁**，检查 `.sprint-state/delphi-reviewed.json` 的 `verdict=APPROVED`。Force Levels 定义**产生该门禁文件的评审强度**：
+
+| 场景 | DELPHI-GATE | Force Levels |
+|------|------------|-------------|
+| Phase 2/6 DESIGN 设计评审 | 3 专家、≥90% 共识、生成 specification.yaml | 不适用（设计阶段） |
+| Phase 3/6 BUILD 入口 | **必须检查** `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED` | 轻量/标准/复杂：通过对应强度的 delphi-review 生成该门禁文件 |
+| 轻量级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 5 轮、≥90% 聚合共识） | 3 专家、最多 5 轮、写入门禁文件 |
+| 标准级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 5 轮、≥90% 聚合共识） | 3 专家、最多 5 轮、写入门禁文件 |
+| 复杂级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 5 轮、≥90% 聚合共识） | 3 专家、最多 5 轮、写入门禁文件 |
+| Phase 4/6 VERIFY 代码走查 | 再次检查 `delphi-reviewed.json` 或重新评审 | 复用 Force Levels 规则 |
+
+**关键规则**:
+- **DELPHI-GATE 永不跳过**：Phase 3/6 BUILD 入口必须检查 `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED`
+- **Force Levels 定义上下文强度**：所有级别都用三专家、distinct model IDs 和最多 5 轮来**产生**门禁文件
+- **轻量级不是跳过评审**：只缩短上下文，不减少专家或共识验证
+- **LIGHTWEIGHT ≠ ONE-EXPERT**: 1 专家违反 Delphi 核心原则，禁止
+
+---
+
+## 轻量级详细规则
+
+**适用场景**:
+- 删除已存在代码（如移除废弃模块）
+- 小规模修改（≤ 5 个文件、≤ 200 行改动）
+- 不涉及公共 API
+- 无循环依赖
+
+**执行流程**:
+1. 三位专家独立评审并验证 distinct requested_model
+2. 最多 5 轮迭代，直到达到 ≥90% 聚合共识
+3. 三份成功结果且 APPROVED 才通过
+4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
+
+**输出文件** (`.sprint-state/delphi-reviewed.json`):
+```json
+{
+  "sprint_id": "sprint-2026-06-05-01",
+  "level": "轻量",
+  "delphi_review": {
+    "experts": ["architecture-model", "technical-model", "feasibility-model"],
+    "rounds": 1,
+    "votes": {
+      "expert_a": "APPROVED",
+      "expert_b": "APPROVED",
+      "expert_c": "APPROVED"
+    },
+    "consensus": ">=90% APPROVED",
+    "timestamp": "2026-06-05T10:30:00Z"
+  },
+  "status": "passed"
+}
+```
+
+**强制升级条件**（轻量级触发）:
+- 任一专家 REQUEST_CHANGES → 升级至标准级
+- 涉及公共 API → 升级至标准级
+- 修改文件 > 5 或 LOC > 200 → 升级至标准级
+
+---
+
+## 标准级详细规则
+
+**适用场景**:
+- 常规功能开发
+- 模块重构（不涉及架构变更）
+- 中等规模改动（5-15 个文件、200-500 行改动）
+
+**执行流程**:
+1. 三位专家独立评审（Round 1）
+2. 如有 REQUEST_CHANGES，继续后续轮次（最多 5 轮）
+3. 三份成功结果聚合达到 ≥90% 才通过
+4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
+
+**升级至复杂级条件**:
+- Round 5 仍未达到共识 → BLOCK，不能以仲裁或多数票绕过
+- 涉及核心模块（core/handlers）→ 升级至复杂级
+- 存在循环依赖 → 升级至复杂级
+
+---
+
+## 复杂级详细规则
+
+**适用场景**:
+- 核心模块开发
+- 跨模块变更（≥ 3 个目录）
+- 架构调整
+- 公共 API 重大变更
+
+**执行流程**:
+1. architecture、technical、feasibility 三位专家使用用户配置的任意可执行模型独立评审
+2. 最多 5 轮评审
+3. 三份成功结果聚合达到 ≥90% 且全部 APPROVED 才通过
+4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
+
+**分歧处理**:
+- 每轮都保持同一组 architecture、technical、feasibility 三个角色，不新增仲裁者，也不减少执行
+- Round 5 仍未达到批准共识时 BLOCK 进入 Phase 3/6 BUILD
+
+---
+
+## 参见
+
+- [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/plugins/dsh/skills/sprint-flow/references/orchestration-rules.md

@@ -0,0 +1,236 @@
+## 编排层规则（Orchestration Rules）
+
+### Agent Dispatch Rules
+
+| Agent Type | 适用场景 | 不适用场景 | 超时处理 |
+|-----------|---------|-----------|---------|
+| `explore` (bare) | **窄搜索**：单个关键词/pattern，已知文件位置 | 多角度宽泛搜索，读取大文件，3+ search angles | >5min → cancel + 用 `deep` 重试 |
+| `librarian` (bare) | **外部参考**：API 文档、OSS 示例 | 内部代码库宽泛探索 | >5min → cancel + 用 `deep` 重试 |
+| `task(category="deep")` | **复杂研究**：多模块分析，架构决策 | 单文件 trivial fix | 无限制 |
+| `task(category="unspecified-high")` | **高 effort 实现**：新模块、重构 | 单行修改 | 无限制 |
+
+**关键规则**：
+
+1. Bare `explore` agent 本质是 contextual grep，**不是研究 agent**。如果任务涉及：
+   - 3+ 个独立搜索角度
+   - 读取多个大文件（>200 行）
+   - 需要跨层分析（如"查 ralph-loop + .sprint-state/ + token 阈值 + phase transition"）
+    
+   → **必须用 `task(category="deep", load_skills=[...])` 替代**
+
+2. 如果 `explore` agent >5 分钟未返回 → cancel 并立即用 `task(category="deep")` 重试。不要等待。
+
+3. **并行 explore 仍然是正确模式**。2-4 个窄搜索 explore agent 并行执行是高效且推荐的。问题在于给单一 explore agent 分配宽泛任务。
+
+**issue #83 根因**：`bg_1abf2ed9` 被分配了 4 个独立搜索角度的宽泛任务（ralph-loop context + .sprint-state/ + token threshold + phase transition），bare explore agent 超时丢失 session。同批的 `bg_5ecf590d`（窄搜索 OpenCode compaction API）3m35s 正常完成。
+
+### Phase Subagent Dispatch Matrix
+
+| Phase | 名称 | Subagent? | Category | load_skills | 执行者 |
+|-------|------|:---------:|----------|-------------|--------|
+| 1/6 | PREP | ❌ | Bash（直接执行） | 无 | orchestrator |
+| 2/6 | DESIGN | ❌ | orchestrator（直接执行） | `["grill-with-docs", "batch-grill-me", "delphi-review", "to-issues"]` | orchestrator |
+| 3/6 | BUILD | ✅ | ralph-loop | `["test-driven-development"]` | subagent |
+| 4/6 | VERIFY | ❌ | orchestrator（直接执行） | `["delphi-review", "test-specification-alignment"]` | orchestrator |
+| 5/6 | SHIP | ❌ | orchestrator（直接执行） | 无（原生步骤） | orchestrator |
+| 6/6 | CLOSE | ❌ | **强制人工 (UAT)** + Bash (CLEANUP) | 无 | 用户 + orchestrator |
+
+**⚠️ 交互式 skill 必须由 orchestrator 直接执行（不可 dispatch 到 subagent）**：
+
+| Phase | Skill | 为什么不能在 subagent 中执行 |
+|-------|-------|---------------------------|
+| 2/6 | `grill-with-docs` | 需要与用户对话确认需求、提出澄清问题。Subagent 是 fire-and-forget 模式，无法暂停等待用户输入（Issue #217） |
+| 2/6 | `batch-grill-me` | 批量决策节点暂停等待用户确认。必须由 orchestrator 直接执行 |
+| 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 | 分支完成决策 | 4 选项菜单 (merge/PR/keep/discard) 需要用户选择；Option 4 (discard) 要求 typed confirmation |
+| 5/6 | native ship | PR 创建前需要用户确认 |
+| 5/6 | native land | Merge 确认、rollback 决策 — 均为用户交互点 |
+
+**Phase 2/6 DESIGN 执行模式（全部 orchestrator 直接执行）**：
+1. **Orchestrator 直接执行 grill-with-docs**：`skill(name="grill-with-docs")` → 访谈 + CONTEXT.md/ADR
+2. **Orchestrator 调用 R1 Agent skill**：`/delphi-review --mode requirements`，分别执行 architecture、technical、feasibility 三个 per-expert runner → requirements-reviewed.json
+3. **Orchestrator 生成设计文档** → 等待用户 APPROVED
+4. **Orchestrator 直接执行 batch-grill-me**：`skill(name="batch-grill-me")` → 批量决策确认
+5. **Orchestrator 直接执行 R2 delphi-review**：`skill(name="delphi-review")` → 等待 APPROVED
+6. **Orchestrator 直接执行 to-issues**：`skill(name="to-issues")` → 等待用户确认 Issue 拆分
+
+**上下文隔离原则**：
+- 每个 Subagent 在**独立 session** 中启动，不继承 orchestrator 的对话历史
+- orchestrator session 仅接收 subagent 的最终结果摘要（~13,000 tokens/sprint）
+- 现代模型百万 token 上下文 + 缓存命中 → 单 sprint 不会触发 overflow
+
+### CONTEXT INHERITANCE
+
+每个 Phase subagent 启动时，上下文仅通过以下路径继承：
+
+| Phase | 加载来源 | 内容 |
+|-------|---------|------|
+| 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-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
+
+每个 Phase subagent 完成后，必须按顺序执行以下步骤：
+
+1. **写入 Phase 摘要**：创建 `.sprint-state/phase-outputs/phase-{N}-summary.md`
+   - 格式：YAML frontmatter + Markdown body（body ≤ 50 行）
+   - 大小限制：≤ 40,000 字符（≈ 10,000 tokens）
+
+2. **调用 phase-transition CLI**（替代手动更新 sprint-state.json + 手动渲染看板）：
+   ```
+   npx xp-gate phase-transition <phase> <status> --render [--outputs '<json>']
+   ```
+   - Phase 开始时：`npx xp-gate phase-transition <N> in_progress --render`
+   - Phase 完成时：`npx xp-gate phase-transition <N> completed --render --outputs '{"key":"value"}'`
+   - Phase 跳过时：`npx xp-gate phase-transition <N> skipped --render`
+   - CLI 自动完成：更新 `sprint-state.json`（phase, phase_history, outputs）+ 渲染 ASCII 看板
+   - 看板规则：已完成 ✅ + 耗时，当前 🔄，待做 ⬜，跳过 ⏭️，失败 ❌
+   - 进度条：`[████▓░░░░░░] {pct}%`
+   - **禁止**手动写入 `sprint-state.json` 或手动调用 `render-sprint-progress.cjs`（已废弃）
+
+3. **等待用户确认 checkpoint**（如适用）
+
+4. **Phase 6 CLOSE 完成后运行 sprint-audit**（自动提醒，Layer 1.5 触发）：
+   ```
+   npx xp-gate sprint-audit
+   ```
+   - 检查 phase 覆盖度、时间记录、输出物记录、状态一致性
+   - 输出人类可读报告或 JSON（`--json`）
+   - 报告写入 `.sprint-state/audit-report.json`（最新覆盖）
+   - Verdict: PASS / PASS_WITH_WARNINGS / FAIL / SKIP
+   - `phase-transition` CLI 在 Phase 6 completed 时自动输出提醒，无需额外指令
+
+### Background Task Resume Protocol (MANDATORY — Issue #248)
+
+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_...")`
+3. **When ALL tasks complete**: immediately resume by:
+   a. Synthesizing results into the current phase assessment
+   b. Executing the phase transition gate
+   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" (Issue #235, #248).
+
+### Phase Summary 格式（YAML Frontmatter Schema）
+
+每个 `phase-N-summary.md` 必须包含以下 YAML frontmatter：
+
+```markdown
+---
+phase: 1
+phase_name: PREP
+status: completed
+outputs:
+  - path: ".worktrees/sprint/sprint-YYYY-MM-DD-NN"
+    type: directory
+decisions:
+  - title: "Worktree isolation enabled"
+    rationale: "Prevent main branch pollution"
+unresolved_issues: []
+next_phase_context: "Worktree created at {path}. All subsequent edits MUST use this workdir."
+---
+```
+
+**必填字段**: `phase`, `phase_name`, `status`, `outputs`, `decisions`, `next_phase_context`
+
+### Phase Transition Gate
+
+Orchestrator dispatch 下一 Phase 前必须执行验证（与旧模型相同，但 phase number 使用 1-6）：
+
+```bash
+SUMMARY=".sprint-state/phase-outputs/phase-${N}-summary.md"
+[ -f "$SUMMARY" ] || { echo "[BLOCK] phase-${N}-summary 不存在"; exit 1; }
+# ... (完整校验见原规则，phase 编号范围为 1-6)
+```
+
+### RESUME GATE / --resume-from 断点校验（Issue #148）
+
+当使用 `--resume-from <phase>` 时，在执行 Phase Transition Gate 之前，
+orchestrator MUST 先执行断点校验。与新 6-phase 模型一致，phase 编号使用 1-6。
+
+### WORKTREE ENFORCEMENT（Issue #84）
+
+Phase 1/6 PREP 执行完毕后，**所有后续操作（Phase 2/6 到 Phase 6/6）的文件编辑、命令执行 MUST 在 worktree 目录下执行**：
+- **工作目录**：所有 Bash 命令必须通过 `workdir` 参数在 worktree 路径下执行
+- **文件写入**：所有 `write`、`edit` 工具的 `filePath` 必须位于 `isolation.worktree_path` 下
+- **例外**：`.gitignore` 校验和 `git worktree remove`（Phase 6/6 CLOSE 清理）在仓库根目录执行
+
+Sprint state is persisted as JSON in `.sprint-state/sprint-state.json`:
+```json
+{
+  "id": "sprint-2026-07-08-01",
+  "task_description": "开发访谈机器人，支持多轮对话",
+  "phase": 1,
+  "status": "running|paused|completed",
+  "started_at": "2026-07-08T10:00:00Z",
+  "isolation": {
+    "worktree_path": ".worktrees/sprint/sprint-2026-07-08-01",
+    "branch": "sprint/2026-07-08-01",
+    "created_from": "main",
+    "created_from_commit": "abc123def..."
+  },
+  "auto_estimate": {
+    "change_type": "删除已存在代码|修改已存在代码|新增功能|Bug修复",
+    "metrics": {
+      "ref_count": 12,
+      "cross_module_count": 3,
+      "modules": ["auth", "user", "admin"],
+      "circular_dep": true,
+      "public_api_count": 5,
+      "test_file_count": 4
+    },
+    "estimated_level": "轻量|标准|复杂",
+    "recommended_flow": "轻量流程|标准流程|完整 Sprint Flow (6 phases)",
+    "risk_warnings": ["循环依赖: user ↔ plane"],
+    "user_decision": "accepted|overridden|cancelled",
+    "override_reason": null
+  },
+  "phase_history": [
+    {
+      "phase": 1,
+      "phase_name": "PREP",
+      "status": "completed",
+      "started_at": "2026-07-08T10:00:00Z",
+      "completed_at": "2026-07-08T10:05:00Z",
+      "duration_seconds": 300
+    }
+  ],
+  "outputs": {
+    "pain_document": "docs/pain-document.md",
+    "specification": "specification.yaml",
+    "mvp": "mvp-v1/",
+    "review_report": "review-report.md"
+  },
+  "metrics": {
+    "tests_passed": 15,
+    "tests_failed": 0,
+    "coverage_pct": 85
+  }
+}
+```
+
+**新增字段说明**:
+- `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`.