@boyingliu01/xp-gate 0.18.5 → 0.19.1

package/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/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/skills/sprint-flow/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
-**Generated:** 2026-07-29
-**Commit:** 05d23ae
+**Generated:** 2026-08-30
+**Commit:** 0848858
 **Branch:** main
-**Version:** 0.18.5.0
+**Version:** 0.19.1.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/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/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

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

@@ -2,12 +2,13 @@
 
 **执行时机**: Phase 2/6 DESIGN 之前，PREP AUTO-ESTIMATE 完成后。
 
-**目的**: 根据需求规模匹配适度评审流程，平衡质量保障与效率。
+**目的**: 根据需求规模调整上下文深度与迭代预算，平衡质量保障与效率。Force level 永远不改变专家数量或批准语义。
 
 **核心原则**:
 - 所有级别**必须经过 Delphi 评审**，不可跳过
-- 轻量级采用**简化 Delphi**（2 专家、1 轮），仍需 2/2 批准
-- 标准/复杂采用**完整 Delphi**（2-3 专家、多轮）
+- 所有级别都采用 architecture、technical、feasibility 三专家 Delphi；Round 1 独立执行并验证三份成功结果
+- 模型 ID、provider、vendor、gateway 和国籍不受限制；`requested_model` trimmed 后必须 distinct
+- 评审达到 ≥90% 共识，最多 5 轮；失败或无法验证时阻断
 - 自动升级机制：当出现风险信号时强制升级级别
 
 ---
@@ -16,9 +17,9 @@
 
 | 级别 | 适用场景 | 专家数 | 最多轮数 | 通过条件 | 预计耗时 |
 |------|---------|--------|---------|----------|---------|
-| **轻量** | 小改动、局部修改、删除代码 | 2 | 1 | 2/2 批准 | 10-20 分钟 |
-| **标准** | 常规功能开发、模块重构 | 2 | 2 | 2/2 批准 | 30-60 分钟 |
-| **复杂** | 核心模块、跨模块变更、新增架构 | 3 | 3 | 3/3 批准 | 1-2 小时 |
+| **轻量** | 小改动、局部修改、删除代码 | 3 | 1-5 | ≥90% 聚合共识 | 10-20 分钟 |
+| **标准** | 常规功能开发、模块重构 | 3 | 1-5 | ≥90% 聚合共识 | 30-60 分钟 |
+| **复杂** | 核心模块、跨模块变更、新增架构 | 3 | 1-5 | ≥90% 聚合共识 | 1-2 小时 |
 
 ---
 
@@ -26,9 +27,9 @@
 
 | 级别 | delphi-review 调用 | 预计 Token 消耗 | 成本说明 |
 |------|-------------------|--------------|---------|
-| **轻量** | 1 次（2 专家、1 轮） | ~8,000 | 简化流程，单轮评审 |
-| **标准** | 1-2 次（2 专家、1-2 轮） | ~15,000-25,000 | 可能需要 1 轮反馈 |
-| **复杂** | 1-3 次（3 专家、1-3 轮） | ~30,000-60,000 | 多轮深度评审 |
+| **轻量** | 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 位专家的输入输出）。
 
@@ -56,7 +57,7 @@
 | 触发条件 | 原级别 | 升级至 | 说明 |
 |---------|--------|--------|------|
 | Delphi 评审出现 REQUEST_CHANGES | 轻量 | 标准 | 需要第二轮评审 |
-| 专家意见分歧（1 票反对） | 轻量/标准 | 复杂 | 需要第 3 专家仲裁 |
+| 专家意见分歧 | 轻量/标准 | 复杂 | 增加上下文深度与后续轮次预算，不增加或替换专家 |
 | 涉及公共 API 变更 | 轻量 | 标准 | 影响外部调用方 |
 | 修改文件数 > 5 或 LOC > 200 | 轻量 | 标准 | 改动规模超出轻量范围 |
 | 存在循环依赖 | 轻量/标准 | 复杂 | 架构风险高 |
@@ -81,10 +82,10 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 
 | AUTO-ESTIMATE 指标 | 建议级别 | Force Levels 执行 |
 |-------------------|---------|------------------|
-| 引用计数 ≤ 3 + 跨模块 ≤ 1 | 轻量 | 2 专家、1 轮 Delphi |
-| 引用计数 4-10 或 跨模块 2 | 标准 | 2 专家、最多 2 轮 Delphi |
-| 引用计数 > 10 或 跨模块 ≥ 3 | 复杂 | 3 专家、最多 3 轮 Delphi |
-| 存在循环依赖 | 强制复杂 | 3 专家、最多 3 轮 + 架构评审 |
+| 引用计数 ≤ 3 + 跨模块 ≤ 1 | 轻量 | 3 专家、最多 5 轮 Delphi |
+| 引用计数 4-10 或 跨模块 2 | 标准 | 3 专家、最多 5 轮 Delphi |
+| 引用计数 > 10 或 跨模块 ≥ 3 | 复杂 | 3 专家、最多 5 轮 Delphi |
+| 存在循环依赖 | 强制复杂 | 3 专家、最多 5 轮 + 架构评审 |
 
 **关键区别**:
 - AUTO-ESTIMATE: **客观指标分析**（代码结构、引用计数）
@@ -100,15 +101,15 @@ AUTO-ESTIMATE 输出 → 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`（2 专家、1 轮、2/2 批准） | 2 专家、1 轮、写入门禁文件 |
-| 标准级评审 | 生成 `delphi-reviewed.json`（2 专家、最多 2 轮、2/2 批准） | 2 专家、最多 2 轮、写入门禁文件 |
-| 复杂级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 3 轮、3/3 批准） | 3 专家、最多 3 轮、写入门禁文件 |
+| 轻量级评审 | 生成 `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 定义评审强度**：轻量/标准/复杂决定用 2 专家 1 轮还是 3 专家 3 轮来**产生**门禁文件
-- **轻量级不是跳过评审**：而是简化流程（2 专家、1 轮），但仍需生成门禁文件
+- **Force Levels 定义上下文强度**：所有级别都用三专家、distinct model IDs 和最多 5 轮来**产生**门禁文件
+- **轻量级不是跳过评审**：只缩短上下文，不减少专家或共识验证
 - **LIGHTWEIGHT ≠ ONE-EXPERT**: 1 专家违反 Delphi 核心原则，禁止
 
 ---
@@ -122,9 +123,9 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 - 无循环依赖
 
 **执行流程**:
-1. 2 位专家独立评审（DeepSeek-v4-pro + Kimi-K2.6）
-2. 单轮评审，无需多轮迭代
-3. **2/2 批准**才通过（不允许 1/2 批准）
+1. 三位专家独立评审并验证 distinct requested_model
+2. 最多 5 轮迭代，直到达到 ≥90% 聚合共识
+3. 三份成功结果且 APPROVED 才通过
 4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
 
 **输出文件** (`.sprint-state/delphi-reviewed.json`):
@@ -133,13 +134,14 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
   "sprint_id": "sprint-2026-06-05-01",
   "level": "轻量",
   "delphi_review": {
-    "experts": ["deepseek-v4-pro", "kimi-k2.6"],
+    "experts": ["architecture-model", "technical-model", "feasibility-model"],
     "rounds": 1,
     "votes": {
       "expert_a": "APPROVED",
-      "expert_b": "APPROVED"
+      "expert_b": "APPROVED",
+      "expert_c": "APPROVED"
     },
-    "consensus": "2/2 APPROVED",
+    "consensus": ">=90% APPROVED",
     "timestamp": "2026-06-05T10:30:00Z"
   },
   "status": "passed"
@@ -161,13 +163,13 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 - 中等规模改动（5-15 个文件、200-500 行改动）
 
 **执行流程**:
-1. 2 位专家独立评审（Round 1）
-2. 如有 REQUEST_CHANGES，进入 Round 2（最多 2 轮）
-3. **2/2 批准**才通过
+1. 三位专家独立评审（Round 1）
+2. 如有 REQUEST_CHANGES，继续后续轮次（最多 5 轮）
+3. 三份成功结果聚合达到 ≥90% 才通过
 4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
 
 **升级至复杂级条件**:
-- Round 2 仍有分歧（1 票反对）→ 升级至复杂级（第 3 专家仲裁）
+- Round 5 仍未达到共识 → BLOCK，不能以仲裁或多数票绕过
 - 涉及核心模块（core/handlers）→ 升级至复杂级
 - 存在循环依赖 → 升级至复杂级
 
@@ -182,14 +184,14 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 - 公共 API 重大变更
 
 **执行流程**:
-1. 3 位专家独立评审（DeepSeek-v4-pro + Kimi-K2.6 + Qwen3.6-Plus）
-2. 最多 3 轮评审（Round 1-3）
-3. **3/3 批准**才通过
+1. architecture、technical、feasibility 三位专家使用用户配置的任意可执行模型独立评审
+2. 最多 5 轮评审
+3. 三份成功结果聚合达到 ≥90% 且全部 APPROVED 才通过
 4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
 
-**仲裁机制**:
-- Round 2 仍有分歧 → 第 3 专家（Qwen3.6-Plus）加入仲裁
-- Round 3 必须达成一致，否则 BLOCK 进入 Phase 3/6 BUILD
+**分歧处理**:
+- 每轮都保持同一组 architecture、technical、feasibility 三个角色，不新增仲裁者，也不减少执行
+- Round 5 仍未达到批准共识时 BLOCK 进入 Phase 3/6 BUILD
 
 ---
 

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

@@ -50,7 +50,7 @@
 
 **Phase 2/6 DESIGN 执行模式（全部 orchestrator 直接执行）**：
 1. **Orchestrator 直接执行 grill-with-docs**：`skill(name="grill-with-docs")` → 访谈 + CONTEXT.md/ADR
-2. **Orchestrator 执行 R1 需求评审**：`npx xp-gate delphi-review --mode requirements` → requirements-reviewed.json
+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

package/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 属于严重违规。
 
-**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**2 专家、1 轮、2/2 APPROVED、较短上下文**），**不是**跳过 delphi-review，**不是** 1 专家评审。见 references/force-levels.md 的轻量级流程定义。
+**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**3 专家、最多 5 轮、≥90% 聚合共识、较短上下文**），**不是**跳过 delphi-review，**不是**减少专家或模型执行。见 references/force-levels.md 的轻量级流程定义。
 
 **自动 escalation 规则**（检测到以下情况时，自动提升流程级别）: