@boyingliu01/xp-gate 0.18.5 → 0.19.0

package/plugins/opencode/skills/delphi-review/references/code-walkthrough.md

@@ -14,11 +14,11 @@
 
 ## Five Core Properties
 
-1. **匿名性** — Expert A/B 互不知道对方意见
+1. **匿名性** — Expert A/B/C 在 Round 1 互不知道对方意见
 2. **迭代共识** — 多轮直到 APPROVED
 3. **零容忍** — Critical Issues 必须修复
 4. **零降级** — 环境/资源问题必须阻断，通知用户解决
-5. **强制覆盖** — 超过阈值必须 BLOCK，不能跳过
+5. **强制覆盖** — 变更必须完整评审；大型变更由用户选择完整评审或在评审前拆分
 
 ---
 
@@ -72,11 +72,13 @@ pre-push hook
     │         │
     │         ├─→ Expert B (实现 + 代码质量) 匿名评审 (含 principles_findings)
     │         │
+    │         ├─→ Expert C (可行性) 匿名评审 (含 principles_findings)
+    │         │
     │         ├─→ 共识检查
     │         │      │
-    │         │      ├─→ 2/2 APPROVED → 允许推送
+    │         │      ├─→ 三份成功结果、三个 distinct requested_model、≥90% → 允许推送
     │         │      │
-    │         │      ├─→ 分歧 → Expert C 仲裁
+    │         │      ├─→ 分歧 → 继续下一轮（最多 5 轮）
     │         │      │
     │         │      └─→ REQUEST_CHANGES → 阻塞推送
     │         │
@@ -93,9 +95,9 @@ pre-push hook
 |------|------|------|
 | Expert A | 架构 + 设计评审 | `.delphi-config.json` → `experts.architecture` |
 | Expert B | 实现 + 代码质量 | `.delphi-config.json` → `experts.technical` |
-| Expert C (仲裁) | 冲突裁决 | `.delphi-config.json` → `experts.feasibility` |
+| Expert C | 可行性评审 | `.delphi-config.json` → `experts.feasibility` |
 
-> ⚠️ **注意**: 至少配置 **两个不同 provider** 的模型。详见 [INSTALL.md](./INSTALL.md)。
+> 必须成功执行三个专家角色，并验证三个 distinct trimmed requested_model。Provider、vendor、gateway 和模型国籍均不受限制。`provider: local` fallback 不能计数，local hosted endpoint 可作为普通 callable provider。
 
 ---
 
@@ -171,8 +173,9 @@ pre-push hook
     │         │
     │         └─→ Step 2: Delphi Code Walkthrough
     │                  │
-    │                  ├─→ Expert A 评审 (含 principles_findings)
-    │                  ├─→ Expert B 评审 (含 principles_findings)
+    │                  ├─→ Expert A / architecture 评审 (含 principles_findings)
+    │                  ├─→ Expert B / technical 评审 (含 principles_findings)
+    │                  ├─→ Expert C / feasibility 评审 (含 principles_findings)
     │                  └─→ 共识检查
     │
     └─→ 允许/阻塞推送
@@ -237,10 +240,10 @@ pre-push hook
 
 | 条件 | 结果 |
 |------|------|
-| 2/2 APPROVED + 无 Critical Issues | ✅ 允许推送 |
-| 2/2 APPROVED + 有 Minor Issues | ✅ 允许推送（记录问题） |
-| 1/2 APPROVED | ⚠️ 需要 Expert C 仲裁 |
-| 0/2 APPROVED | ❌ 阻塞推送 |
+| 三份成功结果、三个 distinct requested_model、≥90% 且无 Critical Issues | ✅ 允许推送 |
+| 三份成功结果、≥90% 且有 Minor Issues | ✅ 允许推送（记录问题） |
+| 任一专家失败、缺失或模型重复 | ❌ 阻塞推送 |
+| 共识不足或有 Critical Issues | ❌ 阻塞推送 |
 | 有 Critical Issues | ❌ 阻塞推送 |
 | 有 Major Issues 且未处理 | ❌ 阻塞推送 |
 
@@ -251,26 +254,9 @@ pre-push hook
 | 指标 | 阈值 | 处理 |
 |------|------|------|
 | 单次走查成本 | ~$0.03 | 正常执行 |
-| 最大评审文件数 | 20 个文件 | 超过 → **BLOCK** |
-| 最大 diff 行数 | 500 行 | 超过 → **BLOCK** |
+| 变更规模 | 无硬性文件数或行数上限 | 大型变更必须完整评审或由用户选择拆分 |
 
-**超过阈值处理 (零降级)**：
-
-```
-IF 超过阈值:
-  → BLOCK 推送
-  → 通知用户：变更过大，无法有效评审
-  → 用户选项：
-     A. 拆分变更（推荐）
-     B. 用户明确授权跳过走查（需书面确认风险）
-
-  ❌ 禁止自动跳过走查
-  ❌ 禁止自动分批并批准
-```
-
-**设计原则**：
-- 大变更跳过评审 = 质量风险泄露到生产环境
-- 用户有权决定是否接受风险，AI 不能自动跳过
+大型变更没有自动跳过或绕过路径。用户可以选择完整评审，或在评审前主动拆分变更；每个变更仍须通过完整的走查和证据验证。
 
 ---
 
@@ -282,7 +268,7 @@ IF 超过阈值:
 BEFORE code walkthrough:
   ├─ 检查 Expert A 模型可用性
   ├─ 检查 Expert B 模型可用性
-  ├─ 检查 Expert C 模型可用性（仲裁时需要）
+  ├─ 检查 Expert C 模型可用性
   └─ 检查 OpenCode CLI 可用性
 
 IF 任何检查失败:
@@ -296,8 +282,7 @@ IF 任何检查失败:
 
 | 情况 | 处理 |
 |------|------|
-| Expert A API 错误 | BLOCK + 提示用户检查 API key |
-| Expert B API 错误 | BLOCK + 提示用户检查 API key |
+| 任一专家 API 错误 | BLOCK + 提示用户检查 provider/API key |
 | OpenCode CLI 缺失 | BLOCK + 提示用户安装 OpenCode |
 
 ---
@@ -305,7 +290,7 @@ IF 任何检查失败:
 ## Expert 评审输出格式
 
 ```markdown
-## Code Walkthrough - Expert [A/B]
+## Code Walkthrough - Expert [A/B/C]
 
 ### 变更摘要
 [变更的主要内容]
@@ -340,6 +325,7 @@ IF 任何检查失败:
 ### 专家意见汇总
 - Expert A: [APPROVED / REQUEST_CHANGES]
 - Expert B: [APPROVED / REQUEST_CHANGES]
+- Expert C: [APPROVED / REQUEST_CHANGES]
 
 ### 共识结果
 [CONSENSUS / DISAGREEMENT]
@@ -370,8 +356,9 @@ IF 任何检查失败:
   "verdict": "APPROVED",
   "confidence": 9,
   "experts": [
-    { "id": "Expert A", "verdict": "APPROVED", "confidence": 9 },
-    { "id": "Expert B", "verdict": "APPROVED", "confidence": 8 }
+    { "id": "Expert A", "role": "architecture", "verdict": "APPROVED", "confidence": 9, "result_type": "delphi_expert_result", "requested_model": "provider/model-a", "resolved_model": "provider/model-a" },
+    { "id": "Expert B", "role": "technical", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "provider/model-b", "resolved_model": null },
+    { "id": "Expert C", "role": "feasibility", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "provider/model-c", "resolved_model": "provider/model-c" }
   ],
   "issues": [],
   "consensus_ratio": 1.0,
@@ -409,7 +396,8 @@ Hook 验证以下条件（全部满足才允许 push）：
 2. JSON 格式有效
 3. commit hash 匹配当前 HEAD
 4. verdict = APPROVED
-5. timestamp 未过期 (< 1小时)
+5. timestamp 未过期
+6. expires 必须是 timestamp 之后恰好 1 小时
 
 ---
 
@@ -430,8 +418,7 @@ Hook 验证以下条件（全部满足才允许 push）：
 | 错误 | 正确 |
 |------|------|
 | Expert 不可用时跳过走查 | BLOCK + 提示用户修复环境 |
-| 超过阈值自动跳过走查 | BLOCK + 提示用户拆分变更 |
-| 超过阈值自动分批评审 | BLOCK + 用户决定是否拆分或授权跳过 |
+| 大型变更 | 完整评审或由用户在评审前拆分 |
 | OpenCode CLI 缺失时允许推送 | BLOCK + 提示用户安装 OpenCode |
 | 模型 API 错误时降级单模型 | BLOCK + 提示用户检查 API 配置 |
 | 未写入 `.code-walkthrough-result.json` 就声明完成 | MUST 写入结果文件后才能完成 |
@@ -443,15 +430,17 @@ Hook 验证以下条件（全部满足才允许 push）：
 
 **Pre-requisites (MANDATORY - BLOCK if missing):**
 - [ ] OpenCode CLI 已安装且可用
-- [ ] Expert A 模型 API 可用
-- [ ] Expert B 模型 API 可用
-- [ ] 变更大小在阈值内（文件 ≤20，行数 ≤500）
+- [ ] 三个专家模型 API 均可用
+- [ ] 变更已由用户选择完整评审或拆分为可审阅的变更
 - [ ] Expert A 完成匿名评审
 - [ ] Expert B 完成匿名评审
+- [ ] Expert C 完成匿名评审
 - [ ] 共识检查完成
 
 **CRITICAL - 共识验证 (code-walkthrough):**
-- [ ] 至少 2/2 或 2/3 专家 APPROVED
+- [ ] 三个成功结果均为 `result_type=delphi_expert_result`
+- [ ] 三个 `requested_model` trimmed 后 distinct
+- [ ] 聚合共识 >=90%，并在 exact HEAD 上写入结果
 - [ ] 无 Critical Issues 未解决
 - [ ] 无 Major Issues 未处理（或有处理计划）
 
@@ -471,11 +460,6 @@ Hook 验证以下条件（全部满足才允许 push）：
 - **CANNOT 允许推送**
 - **MUST 修复后重新走查**
 
-**IF 超过大小阈值:**
-- **CANNOT 允许推送**
-- **MUST BLOCK 并提示拆分变更**
-- **用户可明确授权跳过（需确认风险）**
-
 **⭐ APPROVED 后必做 (code-walkthrough mode)：写入结果文件**
 
 IF mode == `code-walkthrough` AND 最终裁决是 APPROVED，评审完成后必须：

package/plugins/opencode/skills/delphi-review/references/requirements.md

@@ -13,7 +13,7 @@
 **设计背景**: Issue #368 识别出原始意图中"需求评审一次 + 设计评审一次"的第一次评审被完全丢弃。本模式恢复该评审点，在需求探索（grill-with-docs）与设计文档生成之间插入一道轻量质量门禁。
 
 **定位**:
-- **轻量**: 2 专家（architecture + feasibility）、最多 1 轮（循环语义下最多 2 轮）
+- **固定三专家**: architecture + technical + feasibility，最多 5 轮
 - **需求焦点**: 评审对象是需求陈述 + CONTEXT.md，不是设计文档或代码
 - **程序化阻塞**: 输出 `requirements-reviewed.json`，由 `phase-transition 2 completed` 校验
 - **防陈旧绑定**: `requirements_hash`（SHA-256）绑定需求内容，防止旧证据复用
@@ -22,11 +22,11 @@
 
 ## Five Core Properties
 
-1. **匿名性** — Expert A/B 互不知道对方意见（Round 1）
-2. **迭代共识** — GAPS_FOUND 时回到 grill-with-docs 补充，最多 2 轮循环
+1. **匿名性** — Expert A/B/C 互不知道对方意见（Round 1）
+2. **迭代共识** — GAPS_FOUND 时回到 grill-with-docs 补充，最多 5 轮循环
 3. **关键缺口零容忍** — Critical requirement gaps 必须在进入设计前解决
 4. **防陈旧绑定** — requirements_hash 绑定需求内容 + CONTEXT.md，旧证据不可复用
-5. **轻量但严格** — 2 专家配置，但共识要求 2/2（100%），不因轻量而降标
+5. **执行可验证** — 三个专家都必须成功返回结构化结果，且 requested_model 三个 distinct
 
 ---
 
@@ -53,7 +53,7 @@ sprint-flow Phase 2 THINK:
   Step 4: HARD-GATE（用户审批设计文档）
 ```
 
-**lightweight sprint 例外**: 当 `change_type == "修改已存在代码"` 时，sprint-flow 跳过 R1 需求评审，需求维度合并入 R2 设计评审。
+所有 Sprint 路径都执行 R1。Force level 只调整上下文深度和后续迭代预算，不跳过需求评审，也不减少三位专家执行。
 
 ---
 
@@ -70,19 +70,21 @@ delphi-review --mode requirements
     ├─→ Expert A (architecture) anonymous review — focus: requirements completeness,
     │                                              requirement→AC coverage, scenario coverage
     │
-    ├─→ Expert B (feasibility) anonymous review — focus: testability of acceptance criteria,
+   ├─→ Expert B (technical) anonymous review — focus: technical clarity and edge cases
+   │
+   ├─→ Expert C (feasibility) anonymous review — focus: testability of acceptance criteria,
     │                                              user persona clarity, scope boundaries
     │
     ├─→ Consensus check
     │      │
-    │      ├─→ Both APPROVED → write requirements-reviewed.json verdict=APPROVED
+    │      ├─→ All three APPROVED → write requirements-reviewed.json verdict=APPROVED
     │      │
-    │      └─→ Either GAPS_FOUND → record gaps, set verdict=GAPS_FOUND
+    │      └─→ Any GAPS_FOUND → record gaps, set verdict=GAPS_FOUND
     │
     └─→ Return to sprint-flow orchestrator
          │
          ├─→ APPROVED → proceed to design doc generation
-         └─→ GAPS_FOUND → loop back to grill-with-docs (1 more round, max 2 total)
+         └─→ GAPS_FOUND → loop back to grill-with-docs (up to 5 total rounds)
 ```
 
 ---
@@ -92,16 +94,15 @@ delphi-review --mode requirements
 | 专家 | 视角 | 配置 |
 |------|------|------|
 | Expert A (architecture) | 需求完整性 + 需求→AC 映射 + 场景覆盖 | `.delphi-config.json` → `experts.architecture` |
-| Expert B (feasibility) | AC 可测试性 + 用户画像 + 范围边界 | `.delphi-config.json` → `experts.feasibility` |
+| Expert B (technical) | 技术清晰度 + 边界条件 + 实现约束 | `.delphi-config.json` → `experts.technical` |
+| Expert C (feasibility) | AC 可测试性 + 用户画像 + 范围边界 | `.delphi-config.json` → `experts.feasibility` |
 
-> ⚠️ **注意**: requirements 模式**不使用** technical 专家。技术实现细节属于设计/实现阶段（design / code-walkthrough 模式），不属于需求评审范畴。
+> 三个角色必须使用三个 distinct trimmed executable model IDs。Provider、vendor、gateway 和模型国籍均不受限制；一个 provider 和 token plan 可以服务全部三个角色。
 
-> ⚠️ **注意**: 至少配置 **两个不同 provider** 的模型。详见 [INSTALL.md](./INSTALL.md)。
-
-**专家选择理由**（设计决策 §16.4 C3）:
+**专家选择理由**:
 - **architecture 专家**: 天然映射范围/覆盖到需求层面——需求完整性、需求→AC 映射、场景覆盖、领域术语一致性
 - **feasibility 专家**: 天然映射可测试性/假设到验收标准——AC 可测试性、用户画像清晰度、范围边界、隐含假设
-- **technical 专家**: 排除——技术实现细节在需求阶段尚未确定，评审无意义
+- **technical 专家**: 检查需求中的技术清晰度、边界条件和实现约束
 
 ---
 
@@ -117,7 +118,7 @@ delphi-review --mode requirements
 | **领域术语一致性** | 需求陈述中的术语是否与 CONTEXT.md 领域模型一致（交叉引用） |
 | **AC 精确度** | 验收标准是否具体、可度量、无歧义 |
 
-### Expert B (feasibility) — 需求模式焦点
+### Expert C (feasibility) — 需求模式焦点
 
 | 维度 | 检查内容 |
 |------|---------|
@@ -133,13 +134,13 @@ delphi-review --mode requirements
 
 | 条件 | 结果 |
 |------|------|
-| 2/2 APPROVED + 无 Critical gaps | ✅ verdict=APPROVED，进入设计文档生成 |
-| 2/2 APPROVED + 有 Minor gaps | ✅ verdict=APPROVED（记录 gaps 供参考） |
-| 1/2 APPROVED, 1/2 GAPS_FOUND | ❌ verdict=GAPS_FOUND，记录 gaps |
-| 0/2 APPROVED | ❌ verdict=GAPS_FOUND，记录 gaps |
+| 3/3 successful APPROVED + 无 Critical gaps | ✅ verdict=APPROVED，进入设计文档生成 |
+| 3/3 successful APPROVED + 有 Minor gaps | ✅ verdict=APPROVED（记录 gaps 供参考） |
+| 任一专家失败或缺失 | ❌ BLOCK，不能聚合或降级 |
+| 任一专家 GAPS_FOUND | ❌ verdict=GAPS_FOUND，记录 gaps |
 | 有 Critical requirement gaps | ❌ verdict=GAPS_FOUND |
 
-**共识要求**: 2/2 一致 APPROVED（100%）。轻量配置不降低共识标准。
+**共识要求**: 三个成功结果全部参与聚合，达到 >=90% 且最终 APPROVED。单个专家结果不能代表全局批准。
 
 ---
 
@@ -167,8 +168,8 @@ Round 2: delphi-review --mode requirements（带 Round 1 gaps 上下文）
 ```
 
 **硬性限制**:
-- **最多 2 轮**（Round 1 + 可选 Round 2）
-- **禁止无界循环** — Round 2 后仍 GAPS_FOUND 必须升级
+- **最多 5 轮**（Round 1 + 可选后续轮次）
+- **禁止无界循环** — Round 5 后仍 GAPS_FOUND 必须升级
 - **Round 2 上下文**: 专家看到 Round 1 的 gaps 列表，评估是否已修复
 - **升级语义**: `escalation_needed: true` 写入 requirements-reviewed.json，sprint-flow 负责 UX
 
@@ -183,14 +184,16 @@ Round 2: delphi-review --mode requirements（带 Round 1 gaps 上下文）
   "mode": "requirements",
   "verdict": "APPROVED",
   "timestamp": "2026-07-25T10:30:00Z",
-  "requirements_hash": "a1b2c3d4e5f6...（SHA-256 hex digest）",
+  "consensus_ratio": 1.0,
+  "requirements_hash": "7f650ddf715ebe75ca0317efa1e8618ae39d2c0bafea7a6f85aacfdbf3735a5f",
   "head_commit": "abc123def456789...",
-  "context_file_used": "CONTEXT.md",
+  "context_file_used": null,
   "round": 1,
-  "expert_verdicts": [
-    { "role": "architecture", "verdict": "APPROVED", "confidence": 9 },
-    { "role": "feasibility", "verdict": "APPROVED", "confidence": 8 }
-  ],
+   "expert_verdicts": [
+     { "role": "architecture", "verdict": "APPROVED", "confidence": 9, "result_type": "delphi_expert_result", "requested_model": "bailian-tp/qwen-plus" },
+     { "role": "technical", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "bailian-tp/deepseek-v3" },
+     { "role": "feasibility", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "bailian-tp/glm-4.5" }
+   ],
   "requirements_statement": "实现用户注册流程，支持邮箱验证和密码重置",
   "gaps_found": [],
   "rounds_used": 1,
@@ -205,13 +208,15 @@ Round 2: delphi-review --mode requirements（带 Round 1 gaps 上下文）
   "mode": "requirements",
   "verdict": "GAPS_FOUND",
   "timestamp": "2026-07-25T10:30:00Z",
-  "requirements_hash": "a1b2c3d4e5f6...",
+  "consensus_ratio": 0.67,
+  "requirements_hash": "7f650ddf715ebe75ca0317efa1e8618ae39d2c0bafea7a6f85aacfdbf3735a5f",
   "head_commit": "abc123def456789...",
-  "context_file_used": "CONTEXT.md",
+  "context_file_used": null,
   "round": 1,
   "expert_verdicts": [
-    { "role": "architecture", "verdict": "APPROVED", "confidence": 8 },
-    { "role": "feasibility", "verdict": "GAPS_FOUND", "confidence": 7 }
+    { "role": "architecture", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "provider/model-a" },
+    { "role": "technical", "verdict": "GAPS_FOUND", "confidence": 7, "result_type": "delphi_expert_result", "requested_model": "provider/model-b" },
+    { "role": "feasibility", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "provider/model-c" }
   ],
   "requirements_statement": "实现用户注册流程，支持邮箱验证和密码重置",
   "gaps_found": [
@@ -231,15 +236,16 @@ Round 2: delphi-review --mode requirements（带 Round 1 gaps 上下文）
 | `mode` | string | 固定值 `"requirements"` |
 | `verdict` | string | `APPROVED` 或 `GAPS_FOUND` |
 | `timestamp` | string | 评审完成时间 (ISO 8601 UTC) |
+| `consensus_ratio` | number | 三位专家的共识比例；APPROVED 必须为 `0.90` 至 `1.0` |
 | `requirements_hash` | string | SHA-256 hex digest（防陈旧绑定，见下文） |
 | `head_commit` | string | 当前 `git rev-parse HEAD` |
-| `context_file_used` | string | 引用的 CONTEXT.md 路径 |
-| `round` | number | 当前轮次（1 或 2） |
-| `expert_verdicts` | array | 各专家裁决（2 项：architecture + feasibility） |
+| `context_file_used` | string \| null | 项目根目录内引用的 context 文件相对路径；未使用时为 `null` 或空字符串 |
+| `round` | number | 当前轮次（1 至 5） |
+| `expert_verdicts` | array | 三位专家的成功结构化结果，包含 `result_type` 和 `requested_model` |
 | `requirements_statement` | string | 被评审需求的简短摘要 |
 | `gaps_found` | array | GAPS_FOUND 时的缺口列表（APPROVED 时为空数组） |
 | `rounds_used` | number | 实际使用的轮次数 |
-| `escalation_needed` | boolean | Round 2 后仍 GAPS_FOUND 时为 `true` |
+| `escalation_needed` | boolean | Round 5 后仍 GAPS_FOUND 时为 `true` |
 
 ### 状态文件: `.sprint-state/delphi-reviewed.json`
 
@@ -267,23 +273,28 @@ requirements_statement + CONTEXT.md content + ISO timestamp prefix (YYYY-MM-DD)
 ```
 
 **计算规则**:
-1. 拼接: `requirements_statement` 字符串 + `CONTEXT.md` 文件完整内容（若存在）+ 当日日期前缀 `YYYY-MM-DD`
-2. 对拼接结果计算 SHA-256 hex digest
-3. 若 CONTEXT.md 不存在，仅拼接 `requirements_statement` + 日期前缀
+1. 从 evidence `timestamp` 解析严格有效的 ISO 8601 UTC 时间，并取其 `YYYY-MM-DD` 前缀
+2. 若 `context_file_used` 非空，只允许项目根目录内的相对路径；拒绝绝对路径、`..` 穿越、缺失/非普通文件，以及 realpath 逃出项目根目录的符号链接
+3. 按 UTF-8 原样读取 context 文件，不添加分隔符或换行；拼接精确字符串 `requirements_statement + context content + YYYY-MM-DD`
+4. 对拼接结果计算 SHA-256；生成值使用 64 位小写 hex，校验时大小写不敏感
+5. 未使用 context 时，精确拼接 `requirements_statement + YYYY-MM-DD`
 
 **目的**: 防止旧证据复用。`phase-transition 2 completed` 校验时：
 - 文件必须存在
 - `verdict` 必须为 `APPROVED`
-- `requirements_hash` 必须为非空字符串
+- `requirements_hash` 必须为 64 位 hex，并与运行时重新计算值匹配
 - 若 hash 与当前需求内容不匹配 → BLOCK（防陈旧绑定）
 
-**与 phase-transition.js 的集成**（v0.17.1 已实现）:
+**与 phase-transition.js 的集成**:
 
 ```javascript
 // EVIDENCE_FILES[2] — 已存在于 phase-transition.js
 {
   path: '.sprint-state/phase-outputs/requirements-reviewed.json',
-  requiredFields: ['verdict', 'requirements_hash'],
+  requiredFields: [
+    'verdict', 'requirements_statement', 'timestamp', 'consensus_ratio',
+    'expert_verdicts', 'head_commit', 'requirements_hash'
+  ],
   blockingCheck: (data) => data.verdict === 'APPROVED',
   blockingMessage: 'Requirements review verdict is not APPROVED',
 }
@@ -306,15 +317,15 @@ requirements_statement + CONTEXT.md content + ISO timestamp prefix (YYYY-MM-DD)
 
 | ❌ Don't | ✅ Do | Why |
 |----------|------|-----|
-| 使用全部 3 个专家 | 仅使用 architecture + feasibility | 轻量配置（设计决策 §16.4 C3），technical 属设计阶段 |
-| 无界循环评审 | 最多 2 轮，之后升级 | 防止无限循环（设计 §5.3 step 3） |
+| 使用少于 3 个专家 | 必须使用 architecture + technical + feasibility | 三个角色共同构成全局证据 |
+| 无界循环评审 | 最多 5 轮，之后升级 | 防止无限循环 |
 | 跳过 CONTEXT.md 交叉引用 | 始终交叉引用领域术语 | 需求应使用 CONTEXT.md 中的规范术语 |
 | 输出泛化批准 | 输出 hash 绑定的需求陈述 | 防陈旧绑定（§8.4，Round 1 设计反馈 #14） |
-| 接受 1/2 APPROVED | 要求 2/2 共识（100%） | 轻量配置仍需严格共识 |
+| 接受单个专家批准 | 要求三份成功结果参与聚合，并达到 >=90% 共识 | 单个结果不能代表全局批准 |
 | Round 2 中复用 Round 1 gaps 作为新发现 | Round 2 专家获得 Round 1 gaps 上下文 | 迭代改进，避免重复劳动 |
 | 评审设计文档或代码 | 仅评审需求陈述 + CONTEXT.md | 设计/代码评审是 design / code-walkthrough 模式的职责 |
 | GAPS_FOUND 时写入 delphi-reviewed.json | 仅 APPROVED 时写入状态文件 | GAPS_FOUND 表示评审未完成 |
-| 在 lightweight sprint 中执行 R1 | `change_type == "修改已存在代码"` 时跳过 R1 | 需求维度合并入 R2 设计评审 |
+| 在 lightweight sprint 中减少或跳过 R1 | 所有路径都执行三专家 R1，仅缩短上下文 | Force level 不改变专家数或批准证据 |
 
 ---
 
@@ -323,7 +334,7 @@ requirements_statement + CONTEXT.md content + ISO timestamp prefix (YYYY-MM-DD)
 - **只读评审**: requirements 模式不修改任何源文件，仅写入证据文件到 `.sprint-state/`
 - **Hash 完整性**: `requirements_hash` 使用 SHA-256，防止需求内容被篡改后复用旧证据
 - **Commit 绑定**: `head_commit` 记录评审时的 git HEAD，提供时间线追溯
-- **无外部 API 泄露**: 评审内容仅传递给配置的国产模型 provider，不经过第三方服务
+- **调用边界**: 评审内容只传递给用户配置的 callable provider；provider、vendor、gateway 和模型国籍不作额外限制
 - **证据不可伪造**: phase-transition.js 程序化校验证据文件，LLM 无法绕过
 
 ---
@@ -350,11 +361,12 @@ requirements_statement + CONTEXT.md content + ISO timestamp prefix (YYYY-MM-DD)
 **Pre-requisites (MANDATORY - BLOCK if missing):**
 - [ ] grill-with-docs 已完成（或 CONTEXT.md 快速路径）
 - [ ] 需求陈述可用（非空）
-- [ ] Expert A (architecture) 模型 API 可用
-- [ ] Expert B (feasibility) 模型 API 可用
+- [ ] Expert A (architecture)、Expert B (technical)、Expert C (feasibility) 均成功执行
+- [ ] 三个 `requested_model` trimmed 后 distinct
+- [ ] 三份结果均为 `result_type=delphi_expert_result`
 
 **CRITICAL - 共识验证 (requirements):**
-- [ ] 2/2 专家 APPROVED
+- [ ] 聚合共识 >=90%，且所有 Critical gaps 已处理
 - [ ] 无 Critical requirement gaps 未解决
 - [ ] requirements_hash 已计算并写入
 
@@ -364,7 +376,7 @@ requirements_statement + CONTEXT.md content + ISO timestamp prefix (YYYY-MM-DD)
 - [ ] verdict 为 APPROVED 或 GAPS_FOUND
 - [ ] IF APPROVED: `.sprint-state/delphi-reviewed.json` 已写入（mode=requirements）
 - [ ] IF GAPS_FOUND: gaps_found 数组非空，escalation_needed 正确设置
-- [ ] IF Round 2 后仍 GAPS_FOUND: escalation_needed = true
+- [ ] IF Round 5 后仍 GAPS_FOUND: escalation_needed = true
 
 **IF 任何 Pre-requisite 缺失:**
 - **CANNOT 完成评审**
@@ -374,7 +386,7 @@ requirements_statement + CONTEXT.md content + ISO timestamp prefix (YYYY-MM-DD)
 - 返回 sprint-flow → grill-with-docs 补充
 - 重新执行 requirements 评审（Round 2）
 
-**IF GAPS_FOUND (Round 2):**
+**IF GAPS_FOUND (Round 5):**
 - **escalation_needed = true**
 - **MUST 升级给用户决策**
 - **CANNOT 自动继续**
@@ -386,5 +398,5 @@ IF mode == `requirements` AND 最终裁决是 APPROVED，评审完成后必须
 1. 写入 `.sprint-state/phase-outputs/requirements-reviewed.json`
 2. 写入 `.sprint-state/delphi-reviewed.json`（状态文件）
 3. 验证 JSON 格式有效
-4. 验证 requirements_hash 非空
+4. 验证 requirements_hash 为 64 位 hex 且运行时重新计算匹配
 5. 验证 head_commit 匹配当前 HEAD

package/plugins/opencode/skills/delphi-review/references/round-templates.md

@@ -47,7 +47,7 @@
 
 ## Round 3: 最终立场（如需要）
 
-触发条件：Round 2 后仍无共识。所有专家提交最终绑定立场。3 专家模式下若仍无完全一致，2/3 或 3/3 多数裁决生效，记录少数派意见。
+触发条件：Round 2 后仍无共识。所有专家提交最终绑定立场。必须基于三份成功结果聚合达到 ≥90% 共识，不能以多数票或单个专家结果替代全局批准。
 
 ### 输出格式
 
@@ -72,12 +72,12 @@
 
 ### 执行方式
 
-2 位专家（architecture + feasibility）独立收到：需求陈述 + CONTEXT.md + grill session 摘要 + "独立评审需求完整性，不知道其他专家意见"。
+architecture、technical、feasibility 三位专家分别独立收到：需求陈述 + CONTEXT.md + grill session 摘要 + "独立评审需求完整性，不知道其他专家意见"。三次执行必须全部成功，且每份结果都记录 `result_type=delphi_expert_result` 和实际请求的 `requested_model`；模型 ID、provider、vendor、gateway 和国籍不受限制。
 
 ### 输出格式
 
 ```markdown
-## Requirements Review - Expert [A(architecture)/B(feasibility)]
+## Requirements Review - Expert [A(architecture)/B(technical)/C(feasibility)]
 
 ### 需求摘要
 [被评审需求的简短概括]
@@ -106,16 +106,16 @@
 
 ### 触发条件
 
-Round 1 裁决为 GAPS_FOUND，grill-with-docs 补充访谈后重新评审。
+前一轮裁决为 GAPS_FOUND，grill-with-docs 补充访谈后重新评审。最多执行 5 轮。
 
 ### 执行方式
 
-2 位专家收到：更新后的需求陈述 + CONTEXT.md + **Round 1 gaps 列表** + "评估 Round 1 缺口是否已修复，是否有新缺口"。
+三位专家分别收到：更新后的需求陈述 + CONTEXT.md + **前一轮 gaps 列表** + "评估已有缺口是否已修复，是否有新缺口"。每轮仍需三份成功、可验证的独立结果，不得减少专家数。
 
 ### 输出格式
 
 ```markdown
-## Requirements Review Round 2 - Expert [A(architecture)/B(feasibility)]
+## Requirements Review Round [2-5] - Expert [A(architecture)/B(technical)/C(feasibility)]
 
 ### Round 1 缺口修复验证
 | Round 1 Gap | 状态 | 说明 |
@@ -131,4 +131,4 @@ Round 1 裁决为 GAPS_FOUND，grill-with-docs 补充访谈后重新评审。
 [与 Round 1 相比的立场变化]
 ```
 
-> ⚠️ Round 2 后仍 GAPS_FOUND → `escalation_needed: true`，升级给用户决策。禁止 Round 3。
+> ⚠️ Round 5 后仍 GAPS_FOUND → `escalation_needed: true`，升级给用户决策。任何较早轮次都不能以两位专家、多数票或单个结果产生 APPROVED 证据。

package/plugins/opencode/skills/sprint-flow/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
-**Generated:** 2026-07-29
-**Commit:** 05d23ae
-**Branch:** main
-**Version:** 0.18.5.0
+**Generated:** 2026-08-24
+**Commit:** a1a4683
+**Branch:** dsh-plugin
+**Version:** 0.19.0.0
 
 ## OVERVIEW
 **6-phase** development pipeline (v2.0 compact redesign, Issue #290): PREP → DESIGN → BUILD → VERIFY → SHIP → CLOSE. Phase 3/6 BUILD default build mode is **ralph-loop** (REQ-level iteration, 40-67% token savings vs parallel). HARD-GATE between DESIGN (2/6) and BUILD (3/6): design must pass Delphi review (≥90% consensus) before any coding.
@@ -64,7 +64,7 @@ skills/sprint-flow/
 
 ## CONVENTIONS
 - **ralph-loop is Phase 3/6 BUILD default**. Each REQ runs in a clean context, saving 40-67% tokens.
-- **delphi-review HARD-GATE in Phase 2/6 DESIGN**: design must reach ≥90% consensus across ≥2 model providers, domestic models only. Unapproved → BLOCK coding.
+- **delphi-review HARD-GATE in Phase 2/6 DESIGN**: all three expert roles must execute with three distinct requested model IDs, then aggregate ≥90% consensus within 5 rounds. Unapproved or unverifiable → BLOCK coding.
 - **`learn` is called twice**: once per REQ in Phase 3/6 (ralph-loop internal) and once in Phase 4/6 VERIFY (Sprint-level retro).
 - **Phase isolation**: each phase has explicit entry/exit criteria documented in its `references/phase-*.md` file.
 - **Emergent Requirements** discovered in Phase 6/6 CLOSE (USER ACCEPTANCE) are explicitly captured via `templates/emergent-issues-template.md` — never silently merged.

package/plugins/opencode/skills/sprint-flow/SKILL.md

@@ -165,14 +165,14 @@ PREP → DESIGN → BUILD → VERIFY → SHIP → CLOSE
 | Phase | Name | Key Actions | Output |
 |-------|------|-------------|--------|
 | 1/6 | PREP | Detect protected branch → Create git worktree → AUTO-ESTIMATE sizing → Classify (lightweight/standard/complex) | Worktree path + impact assessment |
-| 2/6 | DESIGN | CONTEXT.md 预检 (#322) → grill-with-docs → R1 需求评审 → 设计文档+APPROVAL (HARD-GATE) → batch-grill-me → R2 delphi-review (≥90% consensus) → to-issues → specification.yaml | specification.yaml + slices-manifest.json + requirements-reviewed.json |
+| 2/6 | DESIGN | CONTEXT.md 预检 (#322) → grill-with-docs → R1 需求评审 → 设计文档+APPROVAL (HARD-GATE) → batch-grill-me → R2 delphi-review (3 distinct models, ≥90% consensus, max 5 rounds) → to-issues → specification.yaml | specification.yaml + slices-manifest.json + requirements-reviewed.json |
 | 3/6 | BUILD | BUILD-ENTRY-CONTRACT → GITHOOKS-GATE → DELPHI-GATE → ralph-loop (default) or parallel → TDD → blind-review (read-only subagent) → verification | MVP code |
 | 4/6 | VERIFY | delphi-review --mode code-walkthrough → test-specification-alignment (#367 HARD-GATE) → xp-gate check --all → browser (Layer 4) → learnings + xp-gate retro | Review report + feedback-log.md + test-alignment-report.json |
 | 5/6 | SHIP | VERSION-GATE → 分支完成决策 (4选项) → native ship (create PR) → native land (merge + CI + canary) | PR URL + deploy status + merge confirmation |
 | 6/6 | CLOSE | SHIP→CLOSE GATE (merge verified) → Backup sprint-state → #369 返工指标 → USER ACCEPTANCE (⚠️ mandatory manual) → Capture emergent issues → Cleanup worktree + branch | Emergent issues list + cleanup report + metrics |
 
 **Hard Gates**:
-- **DESIGN → BUILD**: R1 需求评审 APPROVED + 设计文档用户 APPROVED + R2 delphi-review APPROVED (≥90% consensus) + GITHOOKS-GATE + DELPHI-GATE + BUILD-ENTRY-CONTRACT (manifest schema + slice↔REQ)
+- **DESIGN → BUILD**: R1 and R2 invoke all three expert roles independently, verify successful results with three distinct requested models, then aggregate APPROVED consensus ≥90% within 5 rounds, plus GITHOOKS-GATE + DELPHI-GATE + BUILD-ENTRY-CONTRACT (manifest schema + slice↔REQ)
 - **VERIFY → SHIP**: feedback-log.md must exist + test-alignment-report.json PASS (#367 程序化 HARD-GATE)
 - **SHIP → CLOSE**: PR must be merged to main + release completed (HARD-GATE)
 
@@ -339,7 +339,7 @@ stateDiagram-v2
     [*] --> PREP : trigger matched
     PREP --> DESIGN : worktree ready
     DESIGN --> BUILD : APPROVED ≥90%
-    DESIGN --> DESIGN : REQUEST_CHANGES (max 3 rounds)
+    DESIGN --> DESIGN : REQUEST_CHANGES (max 5 Delphi rounds)
     BUILD --> VERIFY : tests pass
     BUILD --> BUILD : fix cycle (max 3)
     VERIFY --> SHIP : feedback-log exists
@@ -348,7 +348,7 @@ stateDiagram-v2
     SHIP --> SHIP : CI failed (retry)
     CLOSE --> [*] : UAT confirmed
     BUILD --> BLOCKED : 3 fix cycles exhausted
-    DESIGN --> BLOCKED : 3 redesign rounds exhausted
+    DESIGN --> BLOCKED : 5 Delphi rounds exhausted
     BLOCKED --> [*] : user decision
 ```
 

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

@@ -16,7 +16,7 @@
 | Skill | 来源 | 触发条件 | 输出 |
 |-------|------|---------|------|
 | `grill-with-docs` | Matt Pocock (内置) | CONTEXT.md 不存在时（首个 Skill） | 访谈记录 + CONTEXT.md + ADR |
-| `delphi-review --mode requirements` | xp-gate | R1 需求评审（轻量 2 专家 1 轮） | requirements-reviewed.json |
+| `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 |
 
@@ -25,7 +25,7 @@
 | Skill | 来源 | 触发条件 | 条件分支 |
 |-------|------|---------|---------|
 | `batch-grill-me` | Matt Pocock (内置) | 标准路径（change_type != "修改已存在代码"） | 批量前置决策 |
-| `delphi-review` | xp-gate | R2 设计评审；lightweight 路径使用 2 专家 1 轮 | 必须产生 `.sprint-state/delphi-reviewed.json` 且 verdict=APPROVED |
+| `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