@boyingliu01/xp-gate 0.19.1 → 0.19.3

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

@@ -29,30 +29,32 @@
 | Phase | 名称 | Subagent? | Category | load_skills | 执行者 |
 |-------|------|:---------:|----------|-------------|--------|
 | 1/6 | PREP | ❌ | Bash（直接执行） | 无 | orchestrator |
-| 2/6 | DESIGN | ❌ | orchestrator（直接执行） | `["brainstorming", "autoplan", "delphi-review", "to-issues"]` | 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", "learn", "retro", "systematic-debugging"]` | orchestrator |
-| 5/6 | SHIP | ❌ | orchestrator（直接执行） | `["finishing-a-development-branch", "ship", "land-and-deploy"]` | orchestrator |
+| 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 | `brainstorming` | 需要与用户对话确认需求、提出澄清问题。Subagent 是 fire-and-forget 模式，无法暂停等待用户输入（Issue #217） |
-| 2/6 | `autoplan` | taste_decisions 节点暂停等待用户确认。必须由 orchestrator 直接执行（Issue #225） |
+| 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 | `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 决策 — 均为用户交互点 |
+| 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 直接执行 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 拆分
+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 的对话历史
@@ -89,24 +91,29 @@
    - 格式：YAML frontmatter + Markdown body（body ≤ 50 行）
    - 大小限制：≤ 40,000 字符（≈ 10,000 tokens）
 
-2. **更新 sprint-state.json**：
-   - `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`
-     - Phase 跳过时：设置 `status: "skipped"`
+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. **展示进度看板**：执行 `node scripts/render-sprint-progress.cjs` 渲染进度看板
-   - 脚本自动读取 `.sprint-state/sprint-state.json` 并输出 ASCII 进度看板
-   - 渲染规则：已完成阶段显示 ✅ + 耗时，当前阶段 🔄，待做 ⬜，跳过 ⏭️，失败 ❌
-   - 进度条：`[████▓░░░░░░] {pct}%`（已完成数/总阶段数 6）
-   - 下一步行动：根据当前阶段 + 状态，自动查找对应提示
-   - 输出物路径：列出 `outputs` 中已有的文件路径
-   - 时机：每个 Phase 完成后的 transition 阶段自动展示
-   - 向后兼容：旧版 `sprint-state.json` 缺少 `phase_history` 时，从 `phase` 字段推断状态
+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)
 

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

@@ -216,7 +216,7 @@ find . -name "*{target}*.test.*" -o -name "*{target}*.spec.*" | grep -v node_mod
 
 **DELPHI-GATE invariant**: 所有流程级别（轻量/标准/复杂）的 Phase 3/6 BUILD 启动前，**必须**检查 `.sprint-state/delphi-reviewed.json` 的 verdict 为 `APPROVED`。未通过 delphi-review 直接路由到 BUILD 属于严重违规。
 
-**轻量级的正确理解**: 轻量级意味着较短上下文与较低迭代预算，仍由 architecture、technical、feasibility 三个 Custom Agent 独立执行并聚合 ≥90% 共识。它不跳过 delphi-review，也不减少专家数。见 references/force-levels.md。
+**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**3 专家、最多 5 轮、≥90% 聚合共识、较短上下文**），**不是**跳过 delphi-review，**不是**减少专家或模型执行。见 references/force-levels.md 的轻量级流程定义。
 
 **自动 escalation 规则**（检测到以下情况时，自动提升流程级别）:
 

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

@@ -1,197 +1,222 @@
-# Phase 2/6: DESIGN（设计 — 需求探索 + 共识评审）
+# Phase 2/6: DESIGN（设计 — 需求探索 + 双点评审）
 
 **执行时机**: Phase 1/6 PREP 完成后、Phase 3/6 BUILD 之前。
 **对应旧模型**: Phase 0 THINK + Phase 1 PLAN
 
 ## 目标
 
-使用 brainstorming skill 进行结构化需求探索，在设计审批前通过 Qoder 三个 Custom Agent 执行 R1 requirements review，输出经用户批准的设计文档。然后通过 autoplan + R2 delphi-review 达成 ≥90% 共识，生成 specification.yaml。
+使用 grill-with-docs 进行结构化需求探索（含 CONTEXT.md/ADR 沉淀），经 R1 需求评审验证需求完整性，输出经用户批准的设计文档。然后通过 batch-grill-me 批量前置决策 + R2 delphi-review 达成 ≥90% 共识，生成 specification.yaml。
 
+**新链（v0.18.0+，零外部依赖，双点评审）**:
 ```
-brainstorming → R1 requirements (3 Custom Agents) → 用户审批 → autoplan → R2 delphi-review → to-issues
-                    ↓ HARD-GATE                                      ↓ HARD-GATE
-          requirements-reviewed.json                         ≥90% design consensus
+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（需求探索与设计）
+## Part A: THINK（需求探索 + 需求评审）
 
-### 调用 Skills
+### Step 0: CONTEXT.md 预检（v0.14.9+ — Issue #322）
 
-- `brainstorming` (superpowers) — **HARD-GATE**: 设计未批准 → 不可进入实现
-- 可选补充：`office-hours` (gstack) — 当用户需求非常模糊、需要先验证产品方向时
-
-**关键变更（ISSUE30）**: 从 `office-hours` 切换到 `brainstorming`，原因:
-- brainstorming 有 **HARD-GATE**（设计未批准 → 不可进入实现），防止 "觉得已经理解了就直接开始写代码"
-- brainstorming 输出结构化设计文档，可直接作为 Phase 2/6 Part B PLAN 的输入
-- office-hours 的 YC 六问适合新产品方向验证，brainstorming 更适合"具体功能实现前设计"的场景
-
-### HARD-GATE 机制
+在进入 grill 访谈前，检查 `CONTEXT.md` 是否已存在：
 
 ```
-DO NOT enter Part B (PLAN) or do any implementation
-until the brainstorming design has been APPROVED by the user.
+IF CONTEXT.md 存在于项目根目录:
+  → 读取已有设计上下文
+  → SKIP grill-with-docs 访谈（设计上下文已存在，避免重复探索）
+  → ⚠️ R1 需求评审仍执行（Round 1 修订：CONTEXT.md 可能陈旧，快速路径同样需要需求评审）
+  → 评审对象为 CONTEXT.md + 本次需求陈述
+  → 输出: "[sprint-flow] CONTEXT.md 已存在，跳过需求访谈，进入 R1 需求评审"
+ELSE:
+  → 继续执行 Step 1（结构化需求探索）
 ```
 
-brainstorming skill 内部会执行：
-
-1. **Explore project context** — 检查文件、文档、最近 commits
-2. **Ask clarifying questions** — 一次一个，理解目的/约束/成功标准
-3. **Propose approaches** — 2-3 个方案，含 trade-offs 和建议
-4. **Present design** — 分节展示，每节获得用户批准
-5. **Write design doc** — 保存到 `docs/plans/YYYY-MM-DD-<topic>-design.md`
-6. **Transition to R1** — brainstorming 完成后先执行 requirements mode，不直接进入实现
+**CONTEXT.md 预检路由表**:
 
-**sprint-flow 编排层行为**:
-- 收到 brainstorming 设计文档后，先执行 R1；R1 与用户审批都通过后自动进入 Part B
-- 如果 brainstorming 未完成（用户未 APPROVED），BLOCK 并等待
+| CONTEXT.md 状态 | grill-with-docs | R1 需求评审 | 输入到 Part B | 说明 |
+|----------------|-----------------|-------------|---------------|------|
+| 不存在 | ✅ 执行 | ✅ 执行 | grill 输出 + R1 结论 | 标准路径 |
+| 存在 | ❌ SKIP | ✅ 执行 | 已有 CONTEXT.md + R1 结论 | 快速路径 (Issue #322) |
 
-### 执行步骤
+### Step 1: 调用 grill-with-docs（需求访谈）
 
-#### Step 1: 调用 brainstorming skill
+**仅当 CONTEXT.md 不存在时执行。**
 
 ```
-skill(name="brainstorming", user_message="[需求描述]")
+skill(name="grill-with-docs", user_message="[需求描述]")
 ```
 
-#### Step 2: 等待 HARD-GATE APPROVED
+grill-with-docs 执行：
+1. **逐个追问决策树** — 每题附推荐答案；事实自行探查，决策留给用户
+2. **同步维护 CONTEXT.md** — 项目上下文沉淀（`domain-modeling` 内置）
+3. **同步维护 ADR** — `docs/adr/ADR-NNNN-*.md` 架构决策记录
+4. **达成共享理解** — 需求边界、用户场景、验收标准清晰化
 
-```
-⚠️ HARD-GATE: 设计未 APPROVED → 不可进入 Part B
+### Step 2: R1 需求评审（#368 恢复的第一点评审）
 
-等待用户审批 brainstorming 输出的设计文档。
+grill 访谈达成共享理解后（或 CONTEXT.md 快速路径下读取已有上下文后）、设计文档生成前，调用需求评审：
+
+```
+/delphi-review --mode requirements
 ```
 
-#### Step 3: 保存设计文档路径
+这是 Agent skill 调用，不是 `xp-gate` npm CLI 子命令。Skill orchestrator 必须分别调用 per-expert runner 三次，每次保留 `--expert <architecture|technical|feasibility> --mode requirements`，再聚合三份结果；禁止用一个 runner 进程执行全部模型。
 
-保存到 `<project-root>/.sprint-state/phase-outputs/design-doc.md`
+**评审配置**：
+- 复用现有 3 专家（architecture/feasibility/technical），`--mode requirements` 切换评审焦点提示词
+- 所有路径固定使用 3 专家，Round 1 独立执行并验证 distinct model IDs，最多 5 轮
+- force level 只调整上下文深度与迭代预算；所有路径都执行 R1，不减少专家数
 
-#### Step 4: R1 requirements review（强制）
+**评审焦点**：
+- 用户场景遗漏
+- 验收标准覆盖度与可测试性
+- 用户画像清晰度
+- 需求边界
 
-```
-skill(name="delphi-review", user_message="--mode requirements [需求陈述 + brainstorming 设计上下文]")
-```
+**阻塞语义（程序化）**：
 
-- 并行执行 Qoder architecture、technical、feasibility 三个 Custom Agent
-- 每个 Custom Agent 调用都使用 requirements mode；三次独立执行后由 skill orchestrator 聚合，禁止单进程执行全部模型
-- 每份成功结果必须包含 `role`、`verdict: APPROVED`、`result_type: delphi_expert_result` 和非空 trimmed `requested_model`
-- 三个角色必须恰好各出现一次，三个 trimmed `requested_model` 必须 distinct
-- 聚合 `consensus_ratio` 必须是 `0.90..1`；任一条件失败则 BLOCK 并继续需求澄清
-- APPROVED evidence 写入 `.sprint-state/phase-outputs/requirements-reviewed.json`，包含非空 `requirements_hash` 与精确 `git rev-parse HEAD`
-- 无法解析 HEAD 时 BLOCK；不得使用 `unknown` 作为可验证身份
+输出 `.sprint-state/phase-outputs/requirements-reviewed.json`：
 
 ```json
 {
-  "verdict": "APPROVED",
-  "timestamp": "2026-08-20T10:30:00Z",
+  "verdict": "APPROVED | GAPS_FOUND",
+  "timestamp": "<ISO 8601>",
   "requirements_statement": "<被评审的原始需求陈述>",
   "context_file_used": "CONTEXT.md | null",
-  "requirements_hash": "<SHA-256 of requirements_statement + context exact UTF-8 content if used + timestamp YYYY-MM-DD>",
-  "head_commit": "<exact git rev-parse HEAD>",
-  "consensus_ratio": 0.90,
+  "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": []
 }
 ```
 
-Phase 2 的 R2 与产出步骤全部完成后、进入 Phase 3 前运行 `npx xp-gate phase-transition 2 completed`。schema-v2 Sprint 未通过该程序化验证不得进入 Phase 3。
+**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: 原生设计文档生成
 
-### 可选补充: office-hours（方向验证）
+orchestrator 基于访谈记录 + CONTEXT.md + R1 评审结论生成设计文档：
 
-当用户输入非常模糊时（如 "我想做一个 AI 工具" 而不是 "开发用户登录功能"），可以先调用 `office-hours` 验证产品方向，再进入 brainstorming 详细设计。
+**路径**: `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 并等待
 
 ### 暂停点
 
 | 暂停点 | 触发条件 | 用户操作 | 自动恢复条件 |
 |--------|---------|---------|-------------|
-| **HARD-GATE** | brainstorming 设计未 APPROVED | 用户审批设计文档 | 设计 APPROVED 后自动进入 Part B |
-| **R1 HARD-GATE** | requirements evidence 缺失、陈旧或专家合同无效 | 补充需求并重新执行三专家 R1 | evidence 通过 `phase-transition 2 completed` |
+| R1 GAPS_FOUND | 需求评审发现缺口 | 补充访谈/上下文 | 重新 R1 评审（最多 5 轮） |
+| **HARD-GATE** | 设计文档未 APPROVED | 用户审批设计文档 | 设计 APPROVED 后自动进入 Part B |
 
 ### 输出
 
-- Design Document (`docs/plans/YYYY-MM-DD-<topic>-design.md`)
-- Implementation Plan（brainstorming 内部 writing-plans 输出）
-- requirements-reviewed.json（Qoder 三 Custom Agent R1 evidence）
+- 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（共识评审）
 
-### 调用 Skills
+### Step 5: 路由分叉（v0.14.0+ — Issue #306, #322）
 
-- `autoplan` (gstack) — CEO → Design → Eng 自动流水线
-- `delphi-review` — 多轮匿名评审直到共识
-- specification.yaml 从 APPROVED 设计文档自动生成（无需独立 skill）
+根据 Phase 1/6 PREP (AUTO-ESTIMATE) 的 `change_type` 决定路径：
+
+```
+读取 .sprint-state/sprint-state.json → auto_estimate.change_type
 
-**Web 前端项目额外注入**:
-- `design-shotgun` (gstack) — 生成多版 UI 设计变体
+IF change_type == "修改已存在代码":
+  → 增量优化路径: SKIP batch-grill-me
+   → 直接进入 Step 7: R2 delphi-review（3 专家，最多 5 轮）
+ELSE (change_type == "新增功能" 或 未定义):
+  → 标准路径: 继续 Step 6 (batch-grill-me) → Step 7
+```
 
-**Mobile 项目额外注入** (`--type mobile-flutter` / `mobile-react-native`):
-- `design-shotgun` (gstack) — 移动端 UI 设计探索
+**路由决策表**:
 
-### 执行步骤
+| change_type | batch-grill-me | R2 delphi-review |
+|------------|----------------|------------------|
+| `修改已存在代码` | ❌ SKIP | 3 专家，最多 5 轮 |
+| `新增功能` | ✅ 执行 | 标准 (3 专家) |
+| `undefined` / 缺失 | ✅ 执行 | 标准 (3 专家) |
 
-#### Step 0: Web 前端项目 — 调用 design-shotgun（如适用）
+**HARD-GATE 不变**: 两条路径最终都必须产出 APPROVED 的 delphi-reviewed.json。
 
-**IF project_type is web-nextjs / web-react / web-vue / mobile-flutter / mobile-react-native:**
-```
-skill(name="design-shotgun", user_message="[Pain Document 内容 + 需求描述]")
-```
+### Step 6: 调用 batch-grill-me（仅标准路径）
 
-#### Step 1: 调用 autoplan skill
+**仅当 change_type != "修改已存在代码" 时执行。**
 
 ```
-skill(name="autoplan", user_message="[Pain Document 内容]")
+skill(name="batch-grill-me", user_message="[设计文档 + 待确认决策列表]")
 ```
 
-autoplan 自动执行 `plan-ceo-review` → `plan-design-review` → `plan-eng-review`，使用 6 个决策原则自动决策：
-
-```yaml
-autoplan_result:
-  taste_decisions: [] | [decision1, decision2, ...]
-  verdict: "AUTO_APPROVED" | "NEEDS_REVIEW"
-```
+batch-grill-me 替代 autoplan 的 taste_decisions 功能：
+- 前置已确定决策整批提出
+- 用户一轮确认
+- 输出批量决策结果
 
-#### Step 2: 条件分支
+### Step 7: R2 设计评审（delphi-review，原生 HARD-GATE）
 
 ```
-┌───────────────────────────────────────────────────────────────────┐
-│ Phase 2/6: 条件分支逻辑                                            │
-├───────────────────────────────────────────────────────────────────┤
-│ IF autoplan_result.verdict == "AUTO_APPROVED"                      │
-│    AND autoplan_result.taste_decisions == []                       │
-│  → 调用轻量上下文 delphi-review（三个 Custom Agent，最多 5 轮）      │
-│                                                                    │
-│ IF autoplan_result.verdict == "NEEDS_REVIEW"                       │
-│    OR autoplan_result.taste_decisions.length > 0                   │
-│  → ⚠️ 暂停等待用户确认 taste_decisions                             │
-│  → 用户确认后，调用标准 delphi-review（3 专家）                     │
-└───────────────────────────────────────────────────────────────────┘
+# 标准路径（3 专家）
+skill(name="delphi-review", user_message="[设计文档 + batch-grill-me 决策结果]")
+
+# 增量优化路径（3 专家，最多 5 轮）
+skill(name="delphi-review", user_message="[设计文档]", experts=3, max_rounds=5)
 ```
 
-#### Step 2a: 如果需要用户确认 taste_decisions
+- **标准路径**: Round 1: 3 专家匿名独立评审 → Round 2+: 交换意见直到共识
+- **增量优化路径**: 3 专家，最多 5 轮
+- ≥90% 共识 + APPROVED 才通过
+- 输出: APPROVED / REQUEST_CHANGES
 
-暂停并提示用户决策选项。
+**如果 REQUEST_CHANGES**: 暂停等待用户处理 → 修复后重新评审 → 直到 APPROVED
 
-#### Step 2b: 调用 delphi-review（强制，orchestrator 直接执行）
+### Step 8: 调用 to-issues（原生保留）
 
 ```
-skill(name="delphi-review", user_message="[设计文档 + taste_decisions 确认结果]")
+skill(name="to-issues")
 ```
 
-- Round 1: architecture、technical、feasibility 三个 Custom Agent 匿名独立评审
-- 验证三份成功结果与三个 distinct trimmed `requested_model`
-- Round 2+: 三个 Agent 交换意见直到共识，最多 5 轮
-- 输出: APPROVED / REQUEST_CHANGES
+垂直切片 Issue 拆分 → `slices-manifest.json`（格式不变，ralph-loop 零改动）
 
-**如果 REQUEST_CHANGES**: 暂停等待用户处理 → 修复后重新评审 → 直到 APPROVED
+to-issues 原生能力：blocked_by/dependency_graph/DAG 循环检测/拓扑排序 → Phase 3/6 BUILD 按 execution_order 执行
+
+### Step 9: 生成 specification.yaml
 
-#### Step 3: 从 APPROVED 设计文档提取 specification.yaml
+从 APPROVED 设计文档提取：
 
 ```yaml
 specification:
@@ -202,7 +227,7 @@ specification:
   acceptance_criteria:
     - id: AC-001
       requirement: REQ-001
-      criteria: [验收标准]
+      criteria: [验收标准]    # #368: 每个 REQ 必须含清晰验收标准
       test_type: [unit/integration/e2e]
   design_decisions:
     - id: DD-001
@@ -211,26 +236,38 @@ specification:
       alternatives_considered: [备选方案]
 ```
 
-#### Step 4: 调用 to-issues
+### Step 10: 保存产出物
 
-```
-skill(name="to-issues")
-```
-垂直切片 Issue 拆分 → `slices-manifest.json` → Phase 3/6 BUILD 按 execution_order 执行
+保存到 `<project-root>/.sprint-state/phase-outputs/`:
+- `specification.yaml`
+- `slices-manifest.json`（to-issues 输出）
 
-#### Step 5: 保存 specification.yaml
+### Web 前端项目额外注入
 
-保存到 `<project-root>/.sprint-state/phase-outputs/specification.yaml`
+**IF project_type is web-nextjs / web-react / web-vue / mobile-flutter / mobile-react-native:**
+
+OPTIONAL: 若检测到 `design-shotgun` skill 已安装，可生成多版 UI 设计变体辅助设计评审。未安装则 SKIP。
 
 ### 暂停点
 
 | 暂停点 | 触发条件 | 用户操作 |
 |--------|---------|---------|
-| taste_decisions 确认 | autoplan 无法自动决策 | 用户确认每个决策 |
-| delphi-review APPROVED | Round 结果 REQUEST_CHANGES | 用户修复并重新评审 |
+| batch-grill-me 决策确认 | 批量决策需要用户确认 | 用户一轮确认所有决策 |
+| R2 delphi-review APPROVED | Round 结果 REQUEST_CHANGES | 用户修复并重新评审 |
 
 ### 输出
 
-- specification.yaml
+- 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 引用校验 |