@boyingliu01/xp-gate 0.18.5 → 0.19.1

package/plugins/dsh/skills/sprint-flow/references/phase-1-prep.md

@@ -0,0 +1,294 @@
+# Phase 1/6: PREP（准备工作 — worktree 隔离 + 规模评估）
+
+**执行时机**: `/sprint-flow` 启动后、Phase 2/6 DESIGN 之前。**自动执行**。
+
+**目的**: 默认在 git worktree 中隔离 sprint 工作，防止在保护分支上直接运行造成代码污染。随后自动评估需求规模，匹配适度流程，避免小需求走重量级流程造成资源浪费。
+
+**对应旧模型**: Phase -1 ISOLATE + Phase -0.5 AUTO-ESTIMATE
+
+**核心原则**:
+- **隔离优先**: 默认 worktree 隔离，防止保护分支污染
+- **客观指标 > 主观判断**: 依赖代码结构分析，不依赖人/AI 的主观直觉
+- **显式告知**: 用户看到客观指标，不是 AI 主观结论
+- **可纠偏**: 用户可接受/修改/取消
+- **学习闭环**: 记录用户 override，优化阈值
+
+---
+
+## Part A: ISOLATE（git worktree 隔离）
+
+**AI agent 直接执行 bash 命令**（不需要调用外部 skill），步骤如下：
+
+| 步骤 | 动作 | 说明 |
+|------|------|------|
+| 0 | **检测当前环境** | 运行 `git rev-parse --git-dir` 和 `git rev-parse --git-common-dir`。如果 `GIT_DIR != GIT_COMMON`：已在 worktree 中 → 输出 "Already in isolated worktree" → 进入 Part B |
+| 0.5 | **Sprint Lock 检测（Issue #144）** | 检查 `.sprint-state/sprint.lock` 是否存在: `[ -f .sprint-state/sprint.lock ]`。如果存在: 读取锁内容，检查是否 stale（超过 24 小时或 worktree 目录不存在）→ stale → 输出 `[WARN] 发现过期 sprint lock，将覆盖` → 更新锁。非 stale → 输出 `[BLOCK] 已有活跃 sprint (ID: {sprint_id}, started: {started_at})。请先完成当前 sprint 或手动删除 .sprint-state/sprint.lock` → 退出。锁不存在 → 创建锁: `echo '{"sprint_id":"sprint-YYYY-MM-DD-NN","started_at":"<ISO8601>"}' > .sprint-state/sprint.lock` |
+| 1 | **检查保护分支** | 获取当前分支名 `git branch --show-current`。保护分支列表: `main, master, develop, trunk, mainline`。保护分支 → 强制创建 worktree。非保护分支 → 依然创建 worktree（推荐，不阻断） |
+| 2 | **创建 worktree** | 创建目录: `mkdir -p .worktrees/sprint`。检测已有 NN 编号: `ls .worktrees/sprint/ 2>/dev/null \| grep -oE '[0-9]{2}$' \| sort -n \| tail -1`（取最后两位数字，数值排序，取最大），NN = 结果 + 1（无结果则从 01 开始）。运行 `git worktree add .worktrees/sprint/sprint-YYYY-MM-DD-NN -b sprint/YYYY-MM-DD-NN`。**注意**: `cd` 在 AI agent 单次工具调用中不保持状态，步骤 3-6 必须通过 `workdir` 参数或 `&&` 链式命令在新 worktree 目录下执行 |
+| 3 | **项目 setup** | 在 worktree 目录下: 检测项目类型: `package.json` → `npm install`, `go.mod` → `go mod download`, `pyproject.toml` → `pip/poetry install` |
+| 4 | **.gitignore 校验** | 在**仓库根目录**（非 worktree）执行: `git check-ignore -q .worktrees`。如果未忽略 → 将 `.worktrees/` 添加到 `.gitignore` → `git add .gitignore` → `git commit -m 'chore: ignore .worktrees directory'` |
+| 5 | **Sprint State 记录** | `mkdir -p .sprint-state` 在 worktree 目录下。写入 `.sprint-state/sprint-state.json`（如已存在则合并，保留原有字段），新增/更新 `isolation` 对象，设置 `phase: 1`，`status: "running"` |
+| 6 | **基线验证** | 在 worktree 目录下: 检测测试方式（package.json 有 "test" script → `npm test`, go.mod → `go test ./...`, pyproject.toml → `pytest`）。测试失败 → 输出失败信息 → 询问用户是否继续 |
+
+### 参数处理
+
+- `--no-isolate`: 跳过自动创建，输出 ⚠️ 警告 `'[WARN] 未创建 worktree 隔离，在 {branch} 分支上直接运行 sprint 有污染风险'` → 进入 Part B
+- `--branch-name <name>`: 使用自定义分支名（默认自动生成 `sprint/YYYY-MM-DD-NN`），分支名中的 `/` 在 worktree 路径中自动替换为 `-`（如 `feat/user-login` → 分支名 `feat/user-login`，路径 `.worktrees/sprint/feat-user-login`）
+- `--force`: 强制在当前分支继续（即使已是保护分支），**要求用户显式确认**: 输出 ⚠️ 警告 `'[WARN] 使用 --force 在 {branch} 分支上直接运行 sprint。此操作绕过隔离保护，请确认风险。'` → 等待用户确认（"继续" / "取消"） → 确认后进入 Part B
+
+### 参数交互规则
+
+| 参数组合 | 行为 |
+|---------|------|
+| `--no-isolate` 单独 | 跳过隔离，输出警告 → Part B |
+| `--force` 单独 | 跳过隔离，要求确认 → Part B |
+| `--no-isolate` + `--branch-name` | `--branch-name` 忽略，仅 `--no-isolate` 生效 |
+| `--force` + `--branch-name` | `--branch-name` 忽略，仅 `--force` 生效 |
+| `--no-isolate` + `--force` | 等效，输出 `--no-isolate` 警告 → Part B |
+| `--resume-from build` + `--no-isolate` | `--resume-from` 优先，直接跳过 PREP |
+
+### 错误处理和回退
+
+| 错误场景 | 回退行为 |
+|---------|---------|
+| `git worktree add` 失败（沙箱/权限问题） | 输出 `[ERROR] git worktree add 失败: {error}` → `[WARN] 无法创建 worktree 隔离，将在当前目录继续。请手动设置隔离分支。` → 在当前目录继续 |
+| `.gitignore` 自动添加失败 | 输出 `[WARN] 无法自动添加 .gitignore，请手动将 .worktrees/ 添加到 .gitignore` → 继续 |
+| 基线测试失败 | 输出 `[FAIL] 基线测试未通过:` + 失败详情 → 询问用户 `'基线测试失败，是否继续 sprint？(y/N)'` |
+
+### sprint-state.json isolation 对象格式
+
+```json
+{
+  "isolation": {
+    "worktree_path": ".worktrees/sprint/sprint-2026-05-24-01",
+    "branch": "sprint/2026-05-24-01",
+    "created_from": "main",
+    "created_from_commit": "abc123def..."
+  }
+}
+```
+
+---
+
+## Part B: AUTO-ESTIMATE（自动化规模评估与流程路由）
+
+### 步骤 1: 识别需求类型
+
+分析用户输入的需求描述，判定变更类型：
+
+| 关键词模式 | 变更类型 | AUTO-ESTIMATE 时机 |
+|-----------|---------|-------------------|
+| 删除、移除、去掉、砍掉、清理 + 已有模块名 | 删除已存在代码 | 立即执行 |
+| 修改、改、调整、重构、优化 + 已有模块名 | 修改已存在代码 | 立即执行 |
+| 新增、添加、开发、实现、创建 + 新模块名 | 新增功能 | brainstorming 后执行 |
+| 修复、fix、bug | Bug 修复 | 立即执行 |
+| 无法判断 | 询问用户 | — |
+
+**IF 新增功能**: 跳过当前 AUTO-ESTIMATE，先执行 Phase 2/6 DESIGN brainstorming，brainstorming 完成后以设计文档为输入重新执行 AUTO-ESTIMATE。
+
+**IF 删除/修改/Bug 修复**: 继续执行以下步骤。
+
+### 步骤 2: 收集指标
+
+#### 2.1 引用计数
+
+```bash
+grep -rn "{target_pattern}" --include="*.{ext}" . | grep -v node_modules | grep -v .git | wc -l
+```
+
+**阈值**: ≤3: 轻量 | 4-10: 标准 | >10: 复杂
+
+#### 2.2 跨模块依赖
+
+```bash
+grep -rn "{target_pattern}" --include="*.{ext}" . | grep -v node_modules | grep -v .git | \
+  awk -F: '{print $1}' | sed 's|/[^/]*$||' | sort -u
+```
+
+**阈值**: 1 个目录: 轻量 | 2 个目录: 标准 | 3+ 个目录: 复杂
+
+#### 2.3 循环依赖检测
+
+简单检查：如果 A 引用 B 且 B 引用 A，则存在循环依赖。
+
+```bash
+grep -rn "import.*{target}" --include="*.ts" --include="*.tsx" .
+grep -rn "import.*{caller}" --include="*.ts" --include="*.tsx" {target_dir}/
+```
+
+**阈值**: 无: 正常 | 存在: 高风险 → 无论如何输出风险警告
+
+#### 2.4 Public API 暴露
+
+```bash
+grep -rn "^export " {target_dir}/ --include="*.ts" | wc -l
+```
+
+**阈值**: ≤2: 低影响 | 3-5: 中影响 | >5: 高影响 → 输出风险警告
+
+#### 2.5 相关测试文件
+
+```bash
+find . -name "*{target}*.test.*" -o -name "*{target}*.spec.*" | grep -v node_modules | wc -l
+```
+
+**阈值**: 0: 无测试覆盖（风险提示） | 1-2: 正常 | >3: 重构工作量大 → 提示
+
+### 步骤 3: 汇总评估
+
+```
+总分计算：
+- 引用计数：轻量=1, 标准=2, 复杂=3
+- 跨模块：轻量=1, 标准=2, 复杂=3
+- 循环依赖：无=0, 存在=5（强制复杂）
+- Public API：低=0, 中=1, 高=2
+- 测试文件：正常=0, 多=1
+
+总分：1-3 = 轻量 | 4-6 = 标准 | 7+ 或 循环依赖存在 = 复杂
+```
+
+### 步骤 4: 输出评估结果
+
+使用 `templates/auto-estimate-output-template.md` 的标准格式向用户展示评估结果。
+
+**MUST** 遵循模板格式，包含：
+- 需求描述 + 变更类型
+- 影响级别标识
+- 各项指标的具体数值
+- 建议流程
+- 风险警告（如有）
+- 用户操作选项
+
+### 步骤 5: 处理用户选择
+
+#### 用户选择「接受建议」
+按推荐流程执行。保存评估结果到 sprint-state.json。
+
+```json
+{
+  "auto_estimate": {
+    "change_type": "删除已存在代码",
+    "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"
+  }
+}
+```
+
+#### 用户选择「修改流程」
+展示修改流程子菜单（3 个选项：轻量/标准/完整）。要求用户输入修改原因（必填）。
+
+记录到学习日志：
+```json
+{
+  "sprint_id": "{sprint_id}",
+  "task_description": "{需求描述}",
+  "estimated_level": "标准",
+  "user_override_level": "轻量",
+  "override_reason": "{用户输入原因}",
+  "timestamp": "{当前时间}"
+}
+```
+
+数据写入 `.sprint-state/auto-estimate-learning.json`（追加模式）。
+
+#### 用户选择「取消」
+停止本次 sprint。输出：`[CANCELLED] 用户取消 Sprint，AUTO-ESTIMATE 评估结果为 {estimated_level}`。
+
+### 步骤 6: 路由执行
+
+根据最终确定的流程级别，进入对应 Phase：
+
+| 流程级别 | 路由 |
+|---------|------|
+| **轻量** | → Phase 2/6 DESIGN（reduced-intensity 流程，见 references/force-levels.md） |
+| **标准** | → Phase 2/6 DESIGN（正常流程） |
+| **复杂** | → Phase 2/6 DESIGN（完整流程 + 风险警告提示） |
+
+**DELPHI-GATE invariant**: 所有流程级别（轻量/标准/复杂）的 Phase 3/6 BUILD 启动前，**必须**检查 `.sprint-state/delphi-reviewed.json` 的 verdict 为 `APPROVED`。未通过 delphi-review 直接路由到 BUILD 属于严重违规。
+
+**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**3 专家、最多 5 轮、≥90% 聚合共识、较短上下文**），**不是**跳过 delphi-review，**不是**减少专家或模型执行。见 references/force-levels.md 的轻量级流程定义。
+
+**自动 escalation 规则**（检测到以下情况时，自动提升流程级别）:
+
+| 触发条件 | 原级别 | 提升级别 | 理由 |
+|---------|--------|---------|------|
+| 风险警告（循环依赖、Public API > 5） | 轻量 | 标准 | 技术风险需要标准流程 |
+| 多位专家 disagreement 或 REQUEST_CHANGES | 轻量/标准 | 复杂 | 意见分歧需要更全面评审 |
+| 涉及文件数 > 10 或 LOC > 500 | 轻量 | 标准 | 超出轻量级预算 |
+| 修改公共 API（export 接口） | 轻量/标准 | 复杂 | API 变更影响范围广 |
+| 检测到循环依赖 | 任何级别 | 复杂 | 架构风险强制复杂流程 |
+| 相关测试文件缺失或覆盖率 < 80% | 轻量/标准 | 标准 | 需要补充测试 |
+
+**跨参考**: 详见 references/force-levels.md 的各级别流程定义和强制规则。
+
+---
+
+## 特殊场景处理
+
+### 场景 1: 小改动（总计 < 20 行新增/删除代码）
+
+```bash
+git diff --stat HEAD 2>/dev/null
+```
+
+**处理**: 如果预估改动 < 20 行且涉及 ≤ 2 个文件，自动判定为「轻量」并告知用户，不强制展示完整 AUTO-ESTIMATE 面板。
+
+**注意**: 轻量级仍需要完整的 Sprint Flow 流程（包括 delphi-review），只是 reduced-intensity。**不会**绕过 DELPHI-GATE 直接路由到 BUILD。
+
+### 场景 2: 无法提取目标关键词
+
+**处理**: 询问用户「无法自动识别目标模块，请指定要分析的关键词（函数名/类名/模块名）：」
+
+### 场景 3: 用户输入包含多个独立需求
+
+**处理**: 提示用户「检测到多个独立需求，建议分别执行 sprint。是否拆分？」→ 等待确认
+
+---
+
+## 编排注意事项
+
+PREP 经常使用并行 background explore agents 评估代码影响范围。Agent dispatch 后必须遵循 **Background Task Resume Protocol**（参见 `orchestration-rules.md`），在所有 background task 返回后自动恢复继续，不得等待人工消息（Issue #248）。
+
+---
+
+## 与学习循环的集成
+
+### 数据收集
+
+每次 sprint 完成（Phase 6/6 CLOSE）后，将以下数据记录到 `.sprint-state/auto-estimate-learning.json`：
+
+```json
+{
+  "entries": [
+    {
+      "sprint_id": "sprint-YYYY-MM-DD-NN",
+      "estimated_level": "标准",
+      "user_decision": "accepted",
+      "actual_effort_phase_count": 5,
+      "actual_duration_minutes": 45,
+      "was_accurate": true
+    }
+  ]
+}
+```
+
+### 阈值优化
+
+当积累 ≥ 20 条记录后，提示用户可以运行阈值分析：
+
+> 已积累 {n} 条 AUTO-ESTIMATE 记录。是否运行阈值优化分析？
+> 分析会检查：过度估计（建议标准但实际轻量）、低估（建议轻量但实际复杂），并推荐阈值调整。
+
+---
+
+> **清理提示**: Sprint 完成后，Phase 6/6 CLOSE 执行 `git worktree remove <worktree_path>` 清理 worktree 目录，同时保留 `.sprint-state/` 中的历史记录。

package/plugins/dsh/skills/sprint-flow/references/phase-2-design.md

@@ -0,0 +1,273 @@
+# Phase 2/6: DESIGN（设计 — 需求探索 + 双点评审）
+
+**执行时机**: Phase 1/6 PREP 完成后、Phase 3/6 BUILD 之前。
+**对应旧模型**: Phase 0 THINK + Phase 1 PLAN
+
+## 目标
+
+使用 grill-with-docs 进行结构化需求探索（含 CONTEXT.md/ADR 沉淀），经 R1 需求评审验证需求完整性，输出经用户批准的设计文档。然后通过 batch-grill-me 批量前置决策 + R2 delphi-review 达成 ≥90% 共识，生成 specification.yaml。
+
+**新链（v0.18.0+，零外部依赖，双点评审）**:
+```
+grill-with-docs → R1 需求评审(轻量) → 原生设计文档+APPROVAL门 → batch-grill-me → R2 delphi-review(设计维度) → to-issues
+     ↓                ↓ #368                 ↓ HARD-GATE              ↓              ↓ HARD-GATE
+ CONTEXT.md+ADR   需求完整性/AC覆盖     用户审批设计文档      批量前置决策     ≥90% 共识
+```
+
+---
+
+## Part A: THINK（需求探索 + 需求评审）
+
+### Step 0: CONTEXT.md 预检（v0.14.9+ — Issue #322）
+
+在进入 grill 访谈前，检查 `CONTEXT.md` 是否已存在：
+
+```
+IF CONTEXT.md 存在于项目根目录:
+  → 读取已有设计上下文
+  → SKIP grill-with-docs 访谈（设计上下文已存在，避免重复探索）
+  → ⚠️ R1 需求评审仍执行（Round 1 修订：CONTEXT.md 可能陈旧，快速路径同样需要需求评审）
+  → 评审对象为 CONTEXT.md + 本次需求陈述
+  → 输出: "[sprint-flow] CONTEXT.md 已存在，跳过需求访谈，进入 R1 需求评审"
+ELSE:
+  → 继续执行 Step 1（结构化需求探索）
+```
+
+**CONTEXT.md 预检路由表**:
+
+| CONTEXT.md 状态 | grill-with-docs | R1 需求评审 | 输入到 Part B | 说明 |
+|----------------|-----------------|-------------|---------------|------|
+| 不存在 | ✅ 执行 | ✅ 执行 | grill 输出 + R1 结论 | 标准路径 |
+| 存在 | ❌ SKIP | ✅ 执行 | 已有 CONTEXT.md + R1 结论 | 快速路径 (Issue #322) |
+
+### Step 1: 调用 grill-with-docs（需求访谈）
+
+**仅当 CONTEXT.md 不存在时执行。**
+
+```
+skill(name="grill-with-docs", user_message="[需求描述]")
+```
+
+grill-with-docs 执行：
+1. **逐个追问决策树** — 每题附推荐答案；事实自行探查，决策留给用户
+2. **同步维护 CONTEXT.md** — 项目上下文沉淀（`domain-modeling` 内置）
+3. **同步维护 ADR** — `docs/adr/ADR-NNNN-*.md` 架构决策记录
+4. **达成共享理解** — 需求边界、用户场景、验收标准清晰化
+
+### Step 2: R1 需求评审（#368 恢复的第一点评审）
+
+grill 访谈达成共享理解后（或 CONTEXT.md 快速路径下读取已有上下文后）、设计文档生成前，调用需求评审：
+
+```
+/delphi-review --mode requirements
+```
+
+这是 Agent skill 调用，不是 `xp-gate` npm CLI 子命令。Skill orchestrator 必须分别调用 per-expert runner 三次，每次保留 `--expert <architecture|technical|feasibility> --mode requirements`，再聚合三份结果；禁止用一个 runner 进程执行全部模型。
+
+**评审配置**：
+- 复用现有 3 专家（architecture/feasibility/technical），`--mode requirements` 切换评审焦点提示词
+- 所有路径固定使用 3 专家，Round 1 独立执行并验证 distinct model IDs，最多 5 轮
+- force level 只调整上下文深度与迭代预算；所有路径都执行 R1，不减少专家数
+
+**评审焦点**：
+- 用户场景遗漏
+- 验收标准覆盖度与可测试性
+- 用户画像清晰度
+- 需求边界
+
+**阻塞语义（程序化）**：
+
+输出 `.sprint-state/phase-outputs/requirements-reviewed.json`：
+
+```json
+{
+  "verdict": "APPROVED | GAPS_FOUND",
+  "timestamp": "<ISO 8601>",
+  "requirements_statement": "<被评审的原始需求陈述>",
+  "context_file_used": "CONTEXT.md | null",
+  "requirements_hash": "<SHA-256 of requirements_statement + context file exact UTF-8 content if used + timestamp YYYY-MM-DD>",
+  "head_commit": "<git rev-parse HEAD>",
+  "consensus_ratio": 1.0,
+  "expert_verdicts": [
+    { "role": "architecture", "verdict": "APPROVED", "result_type": "delphi_expert_result", "requested_model": "provider/model-a" },
+    { "role": "technical", "verdict": "APPROVED", "result_type": "delphi_expert_result", "requested_model": "provider/model-b" },
+    { "role": "feasibility", "verdict": "APPROVED", "result_type": "delphi_expert_result", "requested_model": "provider/model-c" }
+  ],
+  "rounds": 1,
+  "gaps": []
+}
+```
+
+**GAPS_FOUND 处理**：
+- 回到 Step 1 补充访谈（或补充 CONTEXT.md 内容）
+- 最多 5 轮循环后升级给用户决策
+
+**程序化校验**：
+- `phase-transition 2 completed` 校验 schema-v2 必填字段、`verdict=APPROVED`、三份专家证据、`consensus_ratio`、当前 HEAD，并从需求陈述、可选 context 文件和 timestamp 日期重新计算 `requirements_hash`
+- 不匹配 → BLOCK（防陈旧绑定）
+
+### Step 3: 原生设计文档生成
+
+orchestrator 基于访谈记录 + CONTEXT.md + R1 评审结论生成设计文档：
+
+**路径**: `docs/plans/YYYY-MM-DD-<topic>-design.md`
+
+**内容结构**:
+1. 需求摘要（来自 grill 访谈 + R1 评审结论）
+2. 2–3 候选方案与 trade-offs
+3. 推荐方案
+4. 成功标准
+
+### Step 4: HARD-GATE — 用户审批设计文档
+
+```
+⚠️ HARD-GATE: 设计未 APPROVED → 不可进入 Part B
+
+等待用户审批设计文档。
+用户 APPROVE 前，禁止进入 Part B (PLAN) 或任何实现。
+```
+
+**sprint-flow 编排层行为**:
+- 收到用户 APPROVED 后，自动进入 Part B
+- 如果用户未 APPROVED，BLOCK 并等待
+
+### 暂停点
+
+| 暂停点 | 触发条件 | 用户操作 | 自动恢复条件 |
+|--------|---------|---------|-------------|
+| R1 GAPS_FOUND | 需求评审发现缺口 | 补充访谈/上下文 | 重新 R1 评审（最多 5 轮） |
+| **HARD-GATE** | 设计文档未 APPROVED | 用户审批设计文档 | 设计 APPROVED 后自动进入 Part B |
+
+### 输出
+
+- CONTEXT.md（项目上下文沉淀）
+- ADR 文件（`docs/adr/ADR-NNNN-*.md`）
+- requirements-reviewed.json（`.sprint-state/phase-outputs/`）
+- Design Document（`docs/plans/YYYY-MM-DD-<topic>-design.md`）
+- 进入 Part B 自动执行（使用设计文档作为输入）
+
+---
+
+## Part B: PLAN（共识评审）
+
+### Step 5: 路由分叉（v0.14.0+ — Issue #306, #322）
+
+根据 Phase 1/6 PREP (AUTO-ESTIMATE) 的 `change_type` 决定路径：
+
+```
+读取 .sprint-state/sprint-state.json → auto_estimate.change_type
+
+IF change_type == "修改已存在代码":
+  → 增量优化路径: SKIP batch-grill-me
+   → 直接进入 Step 7: R2 delphi-review（3 专家，最多 5 轮）
+ELSE (change_type == "新增功能" 或 未定义):
+  → 标准路径: 继续 Step 6 (batch-grill-me) → Step 7
+```
+
+**路由决策表**:
+
+| change_type | batch-grill-me | R2 delphi-review |
+|------------|----------------|------------------|
+| `修改已存在代码` | ❌ SKIP | 3 专家，最多 5 轮 |
+| `新增功能` | ✅ 执行 | 标准 (3 专家) |
+| `undefined` / 缺失 | ✅ 执行 | 标准 (3 专家) |
+
+**HARD-GATE 不变**: 两条路径最终都必须产出 APPROVED 的 delphi-reviewed.json。
+
+### Step 6: 调用 batch-grill-me（仅标准路径）
+
+**仅当 change_type != "修改已存在代码" 时执行。**
+
+```
+skill(name="batch-grill-me", user_message="[设计文档 + 待确认决策列表]")
+```
+
+batch-grill-me 替代 autoplan 的 taste_decisions 功能：
+- 前置已确定决策整批提出
+- 用户一轮确认
+- 输出批量决策结果
+
+### Step 7: R2 设计评审（delphi-review，原生 HARD-GATE）
+
+```
+# 标准路径（3 专家）
+skill(name="delphi-review", user_message="[设计文档 + batch-grill-me 决策结果]")
+
+# 增量优化路径（3 专家，最多 5 轮）
+skill(name="delphi-review", user_message="[设计文档]", experts=3, max_rounds=5)
+```
+
+- **标准路径**: Round 1: 3 专家匿名独立评审 → Round 2+: 交换意见直到共识
+- **增量优化路径**: 3 专家，最多 5 轮
+- ≥90% 共识 + APPROVED 才通过
+- 输出: APPROVED / REQUEST_CHANGES
+
+**如果 REQUEST_CHANGES**: 暂停等待用户处理 → 修复后重新评审 → 直到 APPROVED
+
+### Step 8: 调用 to-issues（原生保留）
+
+```
+skill(name="to-issues")
+```
+
+垂直切片 Issue 拆分 → `slices-manifest.json`（格式不变，ralph-loop 零改动）
+
+to-issues 原生能力：blocked_by/dependency_graph/DAG 循环检测/拓扑排序 → Phase 3/6 BUILD 按 execution_order 执行
+
+### Step 9: 生成 specification.yaml
+
+从 APPROVED 设计文档提取：
+
+```yaml
+specification:
+  requirements:
+    - id: REQ-001
+      description: [需求描述]
+      priority: [critical/high/medium/low]
+  acceptance_criteria:
+    - id: AC-001
+      requirement: REQ-001
+      criteria: [验收标准]    # #368: 每个 REQ 必须含清晰验收标准
+      test_type: [unit/integration/e2e]
+  design_decisions:
+    - id: DD-001
+      decision: [设计决策]
+      rationale: [理由]
+      alternatives_considered: [备选方案]
+```
+
+### Step 10: 保存产出物
+
+保存到 `<project-root>/.sprint-state/phase-outputs/`:
+- `specification.yaml`
+- `slices-manifest.json`（to-issues 输出）
+
+### Web 前端项目额外注入
+
+**IF project_type is web-nextjs / web-react / web-vue / mobile-flutter / mobile-react-native:**
+
+OPTIONAL: 若检测到 `design-shotgun` skill 已安装，可生成多版 UI 设计变体辅助设计评审。未安装则 SKIP。
+
+### 暂停点
+
+| 暂停点 | 触发条件 | 用户操作 |
+|--------|---------|---------|
+| batch-grill-me 决策确认 | 批量决策需要用户确认 | 用户一轮确认所有决策 |
+| R2 delphi-review APPROVED | Round 结果 REQUEST_CHANGES | 用户修复并重新评审 |
+
+### 输出
+
+- specification.yaml（每 REQ 含验收标准 — #368）
+- slices-manifest.json
+- 进入 Phase 3/6 BUILD（除非 `--stop-at design`）
+
+---
+
+## 证据文件汇总
+
+| 证据文件 | 路径 | 校验时机 | 防陈旧绑定 |
+|----------|------|----------|-----------|
+| requirements-reviewed.json | `.sprint-state/phase-outputs/` | `phase-transition 2 completed` | `requirements_hash`（SHA-256） |
+| delphi-reviewed.json | `.sprint-state/` | DELPHI-GATE (Phase 2→3) | verdict + timestamp |
+| specification.yaml | `.sprint-state/phase-outputs/` | `phase-transition 3 in_progress` | slice↔REQ 一致性 |
+| slices-manifest.json | `.sprint-state/phase-outputs/` | `phase-transition 3 in_progress` | schema + REQ 引用校验 |