@boyingliu01/xp-gate 0.18.5 → 0.19.0

package/plugins/qoder/skills/delphi-review/SKILL.md

@@ -3,8 +3,9 @@ name: delphi-review
 version: 1.1.0
 description: >
   Performs multi-round anonymous expert consensus review using the Delphi method. Supports
-  design review (default) and code-walkthrough (--mode code-walkthrough) modes. Uses 2-3 experts
-  from at least 2 different domestic model providers with a >=90% statistical consensus threshold.
+  design review (default), code-walkthrough (--mode code-walkthrough), and requirements
+  (--mode requirements) modes. Uses exactly 3
+  successfully executed experts with distinct model IDs and a >=90% statistical consensus threshold.
   Outputs structured verdict (APPROVED/PASS_WITH_CAVEATS/REQUEST_CHANGES/BLOCKED).
 
   WHAT: Anonymous multi-expert review with iterative consensus building for designs, plans,
@@ -169,10 +170,10 @@ tools_denied:
 ## Scope
 
 **In Scope:**
-- Multi-round anonymous expert consensus review (design + code-walkthrough modes)
-- 2-3 experts from different providers with statistical consensus (>= 90%)
+- Multi-round anonymous expert consensus review (design + requirements + code-walkthrough modes)
+- Exactly 3 experts with distinct trimmed executable model IDs and statistical consensus (>= 90%)
 - Structured verdict: APPROVED / PASS_WITH_CAVEATS / REQUEST_CHANGES
-- Domestic models only (no Anthropic/OpenAI/Google)
+- Provider, vendor, gateway, country, and model nationality are unrestricted; any expert execution failure blocks approval
 
 **Out of Scope:**
 - Does NOT implement code changes (review only, implementation is separate)
@@ -226,11 +227,11 @@ tools_denied:
 ## Workflow
 
 1. **Step 0: Input Validation** — Check input contains reviewable content (design doc/code/spec/diff). Empty input → `[DelphiReview:BLOCKED]`.
-2. **Round 1: Anonymous Independent Review** — Experts review without seeing each other's opinions. Output individual verdict JSON.
-3. **Consensus Check** — Consensus >=90% AND all APPROVED → complete.
-4. **Round 2: Exchange Opinions** — Experts see others' opinions, re-evaluate.
-5. **Round 3: Final Positions** — Final stance, output disagreements if any.
-6. **Fix & Re-Review** — REQUEST_CHANGES → fix Critical+Major → restart from Round 2.
+2. **Round 1: Anonymous Independent Review** — Launch the architecture, technical, and feasibility Custom Agents independently. Record three successful `delphi_expert_result` records and each `requested_model`.
+3. **Execution Verification** — Require all three records and three distinct trimmed requested model IDs. Model provider, vendor, gateway, and nationality are unrestricted.
+4. **Consensus Check** — Aggregate all three results; consensus >=90% AND all APPROVED → complete.
+5. **Rounds 2-5** — Exchange evidence and re-evaluate with all three Custom Agents until approved or five rounds are exhausted.
+6. **Failure Handling** — Missing/failed agents, duplicate model IDs, or no consensus after Round 5 → BLOCK; never reduce the expert count.
 7. **Generate Output** — Consensus report + specification.yaml (design) or `.code-walkthrough-result.json` (walkthrough) + `delphi-reviewed.json`.
 
 ## Activation (MANDATORY for L1 Trigger Detection)
@@ -255,7 +256,7 @@ Each round MUST output a structured round marker:
 
 **Rules**:
 - Every round marker MUST appear as a separate, identifiable line
-- Round numbering MUST be sequential (1, 2, 3)
+- Round numbering MUST be sequential (1 through at most 5)
 - After each round, output consensus summary: `consensus_ratio=N/N`, `verdict_status: converging | stable | diverging`
 - Final round MUST output verdict: `APPROVED | PASS_WITH_CAVEATS | REQUEST_CHANGES | PROCESS_BLOCK`
 
@@ -280,9 +281,38 @@ Each round MUST output a structured round marker:
 |------|------|------|------|
 | `design`（默认） | `/delphi-review` | 需求/设计/架构/PR 评审 | 共识报告 + specification.yaml |
 | `code-walkthrough` | `--mode code-walkthrough` | git push 前代码走查 | `.code-walkthrough-result.json` |
+| `requirements` | `--mode requirements` | Phase 2 R1 需求完整性评审 | `.sprint-state/phase-outputs/requirements-reviewed.json` |
 
 **Code Walkthrough 模式**的完整规范 → 详见 `references/code-walkthrough.md`
 
+### Requirements 模式（Qoder Custom Agents）
+
+在 Phase 2 需求探索完成、设计审批前，并行运行 Qoder 的 architecture、technical、feasibility 三个 Custom Agent。Round 1 保持匿名；任一 Agent 未成功返回、任一裁决不是 `APPROVED`、三个 trimmed `requested_model` 不互异，或聚合 `consensus_ratio < 0.90` 时，R1 必须 BLOCK，不能减少专家数或使用仲裁结果代替。
+
+APPROVED 后读取 `git rev-parse HEAD` 的精确结果并写入 `.sprint-state/phase-outputs/requirements-reviewed.json`。无法解析 HEAD 时不得写 APPROVED 证据：
+
+```json
+{
+  "mode": "requirements",
+  "verdict": "APPROVED",
+  "timestamp": "2026-08-20T10:30:00Z",
+  "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,
+  "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" }
+  ]
+}
+```
+
+Schema-v2 对 context 路径执行项目根目录 containment 与 realpath 检查，并在 Phase 2 transition 时重新计算 hash；生成 hash 为小写 hex，比较时大小写不敏感。
+
+`confidence` 可以由 Custom Agent 提供，但不是 R1 evidence contract 的必需字段。Phase 2 全部步骤完成、进入 Phase 3 前必须执行 `npx xp-gate phase-transition 2 completed`；schema-v2 Sprint 只有通过程序化校验才能继续。
+
 ---
 
 ## 参数配置
@@ -291,16 +321,15 @@ Each round MUST output a structured round marker:
 
 | 配置 | 专家 | 适用场景 |
 |------|------|---------|
-| 2 专家（默认） | A(架构) + B(实现) | 代码变更、小型设计 |
-| 3 专家 | A(架构) + B(实现) + C(可行性) | 架构决策、需求文档 |
+| 3 专家（强制） | A(架构) + B(实现) + C(可行性) | 所有评审模式 |
 
 ### 模型选择策略（强制 — 平台适配）
 
 **关键原则**：
-- ✅ 三个专家必须来自 **至少 2 家不同 provider**
+- ✅ 三个专家必须成功执行且使用 **三个 distinct trimmed model IDs**
 - ❌ 禁止 hardcode 模型名称
-- ❌ 禁止三个专家全部使用同一 provider 的模型
-- ❌ 禁止使用 Anthropic/OpenAI/Google 等国外模型
+- ✅ Provider、vendor、gateway 和模型国籍不受限制
+- ❌ `provider: local` fallback 不能计为成功执行
 
 #### Qoder 平台（推荐 — Custom Agent 模式）
 
@@ -393,10 +422,7 @@ Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
 
 ## Output Format (MANDATORY for L3)
 
-**⚠️ Single vs Multi-Expert Output**:
-- **Multi-Expert Mode (default)**: MUST use the full JSON schema below. Each expert outputs independently; the orchestrator aggregates into `consensus_report`.
-- **Single Reviewer Mode** (explicit `--single`): MAY use simplified text template: `[DelphiReview] verdict=APPROVED|REQUEST_CHANGES|BLOCKED confidence=N/10 issues=[critical:N, major:N, minor:N] summary: [1-2 sentences]`.
-- **Never mix formats**.
+Every Delphi mode MUST use the full JSON schema below. Each of the three Qoder Custom Agents outputs independently and the orchestrator aggregates only after execution verification. There is no single-reviewer Delphi approval path.
 
 ```json
 {
@@ -419,6 +445,8 @@ Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
 
 **For code-walkthrough mode**, output follows `.code-walkthrough-result.json` schema (see `references/code-walkthrough.md`).
 
+**For requirements mode**, output follows the Requirements 模式 schema above and includes exact HEAD plus all three successful Custom Agent results.
+
 **Anti-patterns mapping:**
 - `Round 1 → "评审完成"` → MUST NOT have `verdict: APPROVED` if `critical_issues` exist
 - `只处理 Critical，忽略 Major` → MUST include `major_concerns` array
@@ -429,7 +457,7 @@ Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
 ## Terminal State Checklist
 
 - [ ] Phase 0 完成（文档验证 + 专家分配）
-- [ ] Round 1-3 完成（所有专家评审）
+- [ ] 已完成所需轮次（最多 5 轮，每轮三个 Custom Agent 均执行）
 - [ ] 问题共识比例 >=90%
 - [ ] 所有 Critical Issues 已解决，Major Concerns 已处理
 - [ ] 最终裁决是 **APPROVED** 或 **APPROVED_WITH_MINOR**
@@ -452,6 +480,11 @@ Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
 {"mode":"code-walkthrough","commit":"abc123...","timestamp":"...","verdict":"APPROVED","consensus_ratio":1.0}
 ```
 
+**Requirements mode APPROVED** → `.sprint-state/delphi-reviewed.json`:
+```json
+{"mode":"requirements","timestamp":"...","verdict":"APPROVED","consensus_ratio":1.0}
+```
+
 ---
 
 ## Anti-Patterns
@@ -460,11 +493,11 @@ Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
 |---------|---------|
 | Round 1 未 APPROVED 就"评审完成" | 迭代直到 APPROVED，修复后重新评审 |
 | 只处理 Critical，忽略 Major | 零容忍：Critical/Major 全部必须处理 |
-| 单专家自评 | 至少 2 位不同 provider 的专家 |
+| 单专家自评 | 三个 distinct executable models 全部成功执行 |
 | 用户说"时间紧急"就跳过 | 评审是投资不是开销 |
 | "专家几乎一致"就通过 | "几乎" = 不一致，继续到 >=90% |
-| 使用 Anthropic/GPT/Gemini | 必须使用国产开源模型 |
-| 三个专家同一厂家 | 必须来自至少 2 家不同厂家 |
+| 按 provider 或模型国籍限制选择 | 仅强制三个 distinct trimmed model IDs |
+| `provider: local` fallback 计入 | fallback 不算成功执行证据 |
 
 **Code-walkthrough 专属 Anti-Patterns** → 详见 `references/code-walkthrough.md`
 
@@ -477,7 +510,7 @@ Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
 | 要求跳过评审 | "skip review", "不用评审", "跳过评审" | → 提醒评审是投资而非开销 |
 | 时间压力 | "来不及", "时间紧", "emergency" | → 提醒时间紧迫正是需要评审的时刻 |
 | 提前终止 | Round 1 后用户说 "可以了", "够了" | → BLOCK: 评审未达终止条件 |
-| 单专家自评 | 用户仅指定 1 个专家 | → 提醒至少需要 2 位专家 |
+| 单专家自评 | 用户仅指定 1 个专家 | → BLOCK：必须执行 architecture、technical、feasibility 三个 Custom Agent |
 | 无文档输入 | 仅触发词，无设计/代码内容 | → `[DelphiReview:BLOCKED]` |
 
 ---

package/plugins/qoder/skills/delphi-review/opencode.json.delphi.example

@@ -4,7 +4,7 @@
     "===========================================",
     "Copy the relevant 'agent' block below into your opencode.json.",
     "Replace YOUR_PROVIDER/YOUR_MODEL with your actual provider and model names.",
-    "At least 2 of the 3 agents should use different providers for cross-bias protection."
+    "All 3 agents must use distinct trimmed executable model IDs; providers may be shared."
   ],
 
   "$example_providers": {

package/plugins/qoder/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/qoder/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**: design must reach ≥90% consensus from exactly three successfully executed, distinct model IDs. Provider, vendor, and country are unrestricted; any expert execution failure or unapproved result → 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/qoder/skills/sprint-flow/SKILL.md

@@ -160,7 +160,7 @@ Sprint Flow is NOT just a sequential launcher of existing skills. Here's what ma
 
 1. **40-67% Token Savings via Ralph Loop**: Phase 3 BUILD default (`ralph-loop`) processes one REQ at a time with clean context, avoiding the linear context accumulation that costs 150K+ tokens in parallel mode.
 
-2. **HARD-GATE Discipline**: Design must pass Delphi review (≥90% consensus, ≥2 model providers, domestic models only) before Phase 3 BUILD can start. This is enforced both in SKILL.md instructions and via the Claude Code plugin's PreToolUse hook.
+2. **HARD-GATE Discipline**: Design must pass Delphi review (≥90% consensus from exactly three successfully executed, distinct model IDs; provider, vendor, and country unrestricted) before Phase 3 BUILD can start. Any expert execution failure blocks approval. This is enforced both in SKILL.md instructions and via the Claude Code plugin's PreToolUse hook.
 
 3. **Emergent Requirements Acknowledgment**: Based on research showing 78% of failures are invisible to AI (arXiv study), Phase 6 CLOSE includes mandatory manual UAT verification — cannot be automated, skipped, or bypassed.
 
@@ -280,7 +280,7 @@ Sprint Flow: PREP → DESIGN → BUILD → VERIFY → SHIP → CLOSE
 - **Step 4: to-issues** — `skill(name="to-issues")` — 垂直切片 Issue 拆分 → slices-manifest.json
 - **Step 5: specification.yaml** — 从 APPROVED 设计文档自动提取
 - **Web 前端额外注入**: `design-shotgun`
-- **条件分支**: IF autoplan AUTO_APPROVED → lightweight delphi-review (2 专家、1 轮); ELSE → 标准 delphi-review (3 专家)
+- **条件分支**: force level 只调整上下文深度；所有路径都执行 architecture、technical、feasibility 三个 Custom Agent，最多 5 轮
 
 ### Phase 2/6→3/6: GITHOOKS-GATE（质量门禁安装检查）
 

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

@@ -2,12 +2,14 @@
 
 **执行时机**: 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
+- Qoder 上三个角色分别由对应 Custom Agent 执行；force level 只改变传给 Agent 的上下文深度与迭代预算
+- 评审达到 ≥90% 共识，最多 5 轮；失败或无法验证时阻断
 - 自动升级机制：当出现风险信号时强制升级级别
 
 ---
@@ -16,9 +18,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 +28,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 +58,7 @@
 | 触发条件 | 原级别 | 升级至 | 说明 |
 |---------|--------|--------|------|
 | Delphi 评审出现 REQUEST_CHANGES | 轻量 | 标准 | 需要第二轮评审 |
-| 专家意见分歧（1 票反对） | 轻量/标准 | 复杂 | 需要第 3 专家仲裁 |
+| 专家意见分歧 | 轻量/标准 | 复杂 | 增加上下文深度与后续轮次预算，不增加或替换专家 |
 | 涉及公共 API 变更 | 轻量 | 标准 | 影响外部调用方 |
 | 修改文件数 > 5 或 LOC > 200 | 轻量 | 标准 | 改动规模超出轻量范围 |
 | 存在循环依赖 | 轻量/标准 | 复杂 | 架构风险高 |
@@ -81,10 +83,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 +102,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 +124,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 +135,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 +164,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 +185,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/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 属于严重违规。
 
-**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**2 专家、1 轮、2/2 APPROVED、较短上下文**），**不是**跳过 delphi-review，**不是** 1 专家评审。见 references/force-levels.md 的轻量级流程定义。
+**轻量级的正确理解**: 轻量级意味着较短上下文与较低迭代预算，仍由 architecture、technical、feasibility 三个 Custom Agent 独立执行并聚合 ≥90% 共识。它不跳过 delphi-review，也不减少专家数。见 references/force-levels.md。
 
 **自动 escalation 规则**（检测到以下情况时，自动提升流程级别）: