Delphi评审

---
name: delphi-review
version: 1.1.0
description: >
  Performs multi-round anonymous expert consensus review using the Delphi method. Supports
  design review (default), code-walkthrough (--mode code-walkthrough), and requirements
  (lightweight, --mode requirements) modes. Uses exactly three experts with distinct executable
  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,
  architecture, code changes, and PRs. NOT a single-reviewer pass, NOT a linter, NOT a test runner.
  WHEN: User explicitly requests a review, design validation, multi-expert consensus, code walkthrough
  before push, architecture evaluation, or "/delphi-review".
  NOT WHEN: Asking HOW to review something (educational), mentioning "review" in passing without intent,
  requesting a simple code check or lint, asking about the Delphi process itself, or mentioning
  "review" as part of a different workflow (e.g., "code review" without multi-expert intent),
  asking for review guidelines/checklists/formats, individual peer review, or casual review requests.

  TRIGGERS: "/delphi-review", "review this design", "评审这个需求", "评审这个设计", "design review",
  "多专家评审", "consensus review", "code walkthrough", "push review", "architecture review",
  "delphi review", "run delphi", "start delphi", "评审这个架构", "review this architecture",
  "评审PR", "review this PR with delphi", "delphi评审", "delphi 评审", "run delphi review",
  "执行delphi", "启动delphi评审", "review the requirements", "评审需求", "requirements review",
  "/requirements-review".
  NEGATIVE TRIGGERS: "how does delphi work", "what is delphi review", "code review checklist",
  "review my code quickly", "can you review this", "peer review", "I need a review",
  "explain the review process", "review guidelines", "how to review a design",
  "code review template", "review format", "PR review", "帮我review一下",
  "just review this", "quick review", "review steps", "review my requirements document".
maturity: beta
auto_continue: true
triggers:
  - "/delphi-review"
  - "review this design"
  - "评审这个需求"
  - "评审这个设计"
  - "design review"
  - "多专家评审"
  - "consensus review"
  - "code walkthrough"
  - "push review"
  - "architecture review"
  - "delphi review"
  - "run delphi"
  - "start delphi"
  - "评审这个架构"
  - "review this architecture"
  - "评审PR"
  - "review this PR with delphi"
  - "delphi评审"
  - "delphi 评审"
  - "run delphi review"
  - "执行delphi"
  - "启动delphi评审"
  - "review the requirements"
  - "评审需求"
  - "requirements review"
  - "/requirements-review"
triggers_negative_examples:
  - "how does delphi work"       # educational question about the process
  - "what is delphi review"      # asking for explanation, not execution
  - "code review checklist"      # asking for a checklist, not running review
  - "review my code quickly"     # single-pass quick review, not Delphi multi-round
  - "can you review this"        # ambiguous — could be casual peer review
  - "peer review"                # different process from Delphi
  - "I need a review"            # too vague, casual request
  - "explain the review process" # educational, not executional
  - "review guidelines"          # asking about guidelines, not executing
  - "how to review a design"     # educational
  - "PR review"                  # single-reviewer PR check, not multi-expert Delphi
  - "review my PR"               # informal PR review request, not Delphi
  - "帮我review一下"             # casual Chinese review request, no multi-expert intent
  - "just review this"           # casual, single-pass review request
  - "quick review"               # explicitly contradicts multi-round Delphi process
  - "review steps"               # asking for review instructions, not running review
  - "code review template"       # asking for a template, not executing review
  - "review format"              # asking about format, not executing
  - "show me how to review"      # educational request about reviewing
  - "review checklist example"   # asking for examples, not running review
  - "review my requirements document"  # educational discussion about requirements, not executing review
triggers_negative_test_cases:
  - input: "how does delphi work"
    expect: "NOT triggered"
  - input: "code review checklist"
    expect: "NOT triggered"
  - input: "review my code quickly"
    expect: "NOT triggered"
  - input: "can you review this"
    expect: "NOT triggered"
  - input: "peer review"
    expect: "NOT triggered"
  - input: "I need a review"
    expect: "NOT triggered"
  - input: "explain the review process"
    expect: "NOT triggered"
  - input: "review guidelines"
    expect: "NOT triggered"
  - input: "/delphi-review"
    expect: "triggered"
  - input: "review this design"
    expect: "triggered"
  - input: "评审这个需求"
    expect: "triggered"
  - input: "评审这个设计"
    expect: "triggered"
  - input: "design review"
    expect: "triggered"
  - input: "多专家评审"
    expect: "triggered"
  - input: "consensus review"
    expect: "triggered"
  - input: "code walkthrough"
    expect: "triggered"
  - input: "architecture review"
    expect: "triggered"
  - input: "delphi review"
    expect: "triggered"
  - input: "评审这个架构"
    expect: "triggered"
  - input: "delphi 评审"
    expect: "triggered"
  - input: "run delphi review"
    expect: "triggered"
  - input: "review my PR"
    expect: "NOT triggered"
  - input: "帮我review一下"
    expect: "NOT triggered"
  - input: "just review this"
    expect: "NOT triggered"
  - input: "quick review"
    expect: "NOT triggered"
  - input: "review steps"
    expect: "NOT triggered"
  - input: "code review template"
    expect: "NOT triggered"
  - input: "run delphi"
    expect: "triggered"
  - input: "review the requirements"
    expect: "triggered"
  - input: "评审需求"
    expect: "triggered"
  - input: "requirements review"
    expect: "triggered"
  - input: "/requirements-review"
    expect: "triggered"
  - input: "review my requirements document"
    expect: "NOT triggered"
workflow_steps:
  - "Step 0: Input Validation → Output: [DelphiReview] or [DelphiReview:BLOCKED]"
  - "Round 1: Anonymous Independent Review → Output: [DelphiReview Round 1] expert JSON verdicts"
  - "Consensus Check → Output: consensus_ratio, verdict summary"
  - "Round 2: Exchange Opinions (if needed) → Output: [DelphiReview Round 2] revised verdicts"
  - "Round 3: Final Positions (if needed) → Output: [DelphiReview Round 3] final verdicts"
  - "Fix & Re-Review (if REQUEST_CHANGES) → restart from Round 2"
  - "Generate Output: consensus report + specification.yaml (design) or .code-walkthrough-result.json (walkthrough)"
hooks:
  security:
    - "/careful": "Safety guardrails for destructive commands — ensure review is read-only"
    - "/freeze": "Restrict edits to review scope — prevent accidental changes during review"
    - "/guard": "Full safety mode combining careful + freeze for maximum protection"
  operational:
    - "/context-save": "Save review context before pause or handoff"
    - "/context-restore": "Restore review context on resume"
tools_allowed:
  - "Read"                       # read design docs, code, configs, specification.yaml
  - "Glob"                       # find files by pattern
  - "Grep"                       # search code content
  - "Bash"                       # read-only: git diff, git log, file stats
  - "Task(subagent_type=oracle)" # dispatch oracle for deep analysis
  - "Task(subagent_type=delphi-reviewer-architecture)"    # dispatch architecture expert
  - "Task(subagent_type=delphi-reviewer-technical)"     # dispatch technical expert
  - "Task(subagent_type=delphi-reviewer-feasibility)"   # dispatch feasibility expert
  - "Write(specification.yaml, .code-walkthrough-result.json, delphi-reviewed.json)"  # write output artifacts only
  - "Skill"                      # invoke related skills for context
  - "Question"                   # ask user at decision points
tools_denied:
  - "Edit(source code)"           # NEVER edit implementation code during review
  - "Write(source code)"          # NEVER write implementation code
  - "Bash(git commit, git push)"  # NEVER commit or push during review
  - "Task(category=*, subagent_type=build)"  # NEVER delegate build/implementation
---

# Delphi Consensus Review

## Scope

**In Scope:**
- Multi-round anonymous expert consensus review (design + code-walkthrough modes)
- Exactly three experts with distinct normalized executable model IDs and statistical consensus (>= 90%)
- Structured verdict: APPROVED / PASS_WITH_CAVEATS / REQUEST_CHANGES
- Model nationality, vendor, provider, and gateway are unrestricted.

**Out of Scope:**
- Does NOT implement code changes (review only, implementation is separate)
- Does NOT replace testing or CI/CD verification
- Does NOT handle deployment or release decisions

## Triggers

- /delphi-review
- review this design
- 评审这个需求
- 评审这个设计
- design review
- 多专家评审
- consensus review
- code walkthrough
- push review
- architecture review
- delphi review
- run delphi
- start delphi
- 评审这个架构
- review this architecture
- 评审PR
- review this PR with delphi
- delphi评审
- delphi 评审
- run delphi review
- 执行delphi
- 启动delphi评审
- review the requirements
- 评审需求
- requirements review
- /requirements-review

**NOT triggered by:**
- "how does delphi work" (educational)
- "code review checklist" (asking for a list)
- "review my code quickly" (single-pass, not multi-expert)
- "can you review this" (ambiguous casual review)
- "peer review" (different process)
- "I need a review" (too vague)
- "explain the review process" (educational)
- "review guidelines" (asking about guidelines)
- "PR review" (single-reviewer PR check)
- "review my PR" (informal PR review)
- "帮我review一下" (casual Chinese request)
- "just review this" (casual single-pass)
- "quick review" (contradicts multi-round process)
- "review steps" (asking for instructions)
- "code review template" (asking for template)
- "review format" (asking about format)
- "show me how to review" (educational)
- "review my requirements document" (educational discussion, not execution)

## 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** — Invoke architecture, technical, and feasibility independently without exposing their opinions to one another. Every successful result must use `result_type=delphi_expert_result`.
3. **Execution Verification** — Verify that all three results succeeded and that their `requested_model` values are three distinct trimmed IDs, confirmed against the platform's execution record rather than expert self-report alone (OpenCode: the provider call log; Qoder: the `model` field of `model.request.started` events under `~/.qoder/logs/sessions/<project>/<sessionId>/segments/*.jsonl` — the `--model` argv in `~/.qoder/logs/runs/*/manifest.json` is the session model and proves nothing about subagents). A local fallback (`provider: local`) is not an executed expert and cannot satisfy this check; a local hosted endpoint configured as an ordinary callable provider can. Each expert record must also carry an explicit `channel` of either `external` or `local`; the value is a whitelist and a missing or unknown value fails the gate (it is never defaulted, since defaulting would let a forged record pass by simply omitting the field). Where the platform pins subagents to the session model (current Qoder Custom Agent dispatch, see the Qoder section below), the check cannot pass on built-in models at all and the external provider path is required.
4. **Consensus Check** — Aggregate all three successful expert results. Consensus >=90% AND all APPROVED → complete. One expert result is never global approval.
5. **Rounds 2-5: Exchange and Final Positions** — If needed, expose prior aggregate evidence, re-evaluate, and stop at the first approved consensus or after five rounds.
6. **Failure Handling** — Any expert failure, missing result, duplicate model ID, or unverifiable execution blocks the review. Do not substitute a local fallback or silently reduce the expert count.
7. **Generate Output** — Write the consensus report and mode-specific evidence only after aggregation. For code walkthrough, bind the exact-HEAD result after aggregation.

## Activation (MANDATORY for L1 Trigger Detection)

Every delphi-review response MUST begin with an activation marker as the first line:

| Marker | Meaning |
|--------|---------|
| `[DelphiReview]` | Standard entry — review proceeding |
| `[DelphiReview:BLOCKED]` | Step 0 input validation failure |
| `[DelphiReview:WARNING]` | Red flag detected (reserved) |

## Round Markers (MANDATORY for L3 Step Adherence)

Each round MUST output a structured round marker:

```
[DelphiReview Round 1] Anonymous Independent Review
[DelphiReview Round 2] Exchange Opinions
[DelphiReview Round 3] Final Positions
```

**Rules**:
- Every round marker MUST appear as a separate, identifiable line
- 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`

## 核心原则

**Delphi 方法只有一个目的：得到所有专家一致认可的可行方案。**

| 特性 | 说明 |
|------|------|
| **匿名性** | Round 1 专家互不知道对方意见 |
| **迭代** | 多轮直到共识，不是固定轮数 |
| **受控反馈** | 每轮看到其他专家意见 |
| **统计共识** | >=90% 一致才算共识 |
| **Token 是投资** | 相比后期修复成本，评审消耗微不足道 |
| **零容忍** | Critical/Major 全部必须处理，不可跳过 |

---

## 评审模式

| 模式 | 触发 | 用途 | 输出 |
|------|------|------|------|
| `design`（默认） | `/delphi-review` | 需求/设计/架构/PR 评审 | 共识报告 + specification.yaml |
| `code-walkthrough` | `--mode code-walkthrough` | git push 前代码走查 | `.code-walkthrough-result.json` |
| `requirements` | `--mode requirements` | Phase 2 THINK 阶段需求评审 | `.sprint-state/phase-outputs/requirements-reviewed.json` |

**Code Walkthrough 模式**的完整规范 → 详见 `references/code-walkthrough.md`

**Requirements 模式**的完整规范 → 详见 `references/requirements.md`

---

## 参数配置

### 专家配置

| 配置 | 专家 | 适用场景 |
|------|------|---------|
| 3 专家（固定） | A(架构) + B(实现) + C(可行性) | 所有评审模式 |

### 模型选择策略（强制 — 平台适配）

**关键原则**：
- ✅ 必须配置 architecture、technical、feasibility 三个专家角色
- ✅ 三个角色必须使用三个不同的 trimmed、可执行模型 ID
- ✅ 模型国籍、厂商、provider 和 gateway 不受限制
- ✅ 三个角色可以共享一个 provider 和 token 计划
- ❌ `provider: local` 的特殊 fallback 不能计为一次成功执行

#### Qoder 平台（Custom Agent 模式 — 只能做到同模型三角色）

**通道契约（native-first + external fallback，#414）**：每轮评审开始先探测 native 通道——三个 Custom Agent（`delphi-architecture/technical/feasibility`）是否存在且绑定互异（`xp-gate doctor delphi` 一条命令给出全部判定）。但 **native 通道已被实测证伪**（见下）：subagent 派发采纳 agent 提示词、丢弃 model 绑定，三席永远是会话模型。因此 Qoder 的通道决策表实际收敛为：

| 探测结果 | 通道 | 处置 |
|---|---|---|
| 需要 distinct-models 证据的评审 | **external** | `.delphi-config.json` + `scripts/delphi-external-review.cjs`（外部 provider 三模型） |
| 仅需同模型三角色自查（不计入共识证据） | native | 三 Custom Agent 并行，报告中注明「同模型自查，不构成多模型凭据」 |

降级证据落盘 `delphi-reviewed.json`：`channel`（native/external）、`fallback_reason`（如 `qoder_native_drops_model_binding`）、`probe_evidence`（doctor/日志摘录）。两通道同不变量：三专家齐全、`requested_model` 互异（external）、consensus ≥90%、**无单专家路径**。

Qoder 的内置模型**没有本地推理端点**：推理请求由 Qoder 客户端经服务端代理发出，凭证是一次性 job token。所以不能照搬 OpenCode 的 `base_url + api_key` 直连方式；Qoder 侧内置模型的唯一入口是 **Custom Agent** —— 每个专家一个独立 agent 文件，frontmatter 用 `model` 字段声明模型。

**契约结论（先说结论）**：这条路径**不满足**"三个不同可执行模型 ID"契约。2026-09-23 做过一次排除混杂因素的复测：先把 `~/.qoder/agents/delphi-*.md` 三份文件绑成三个不同的 0.1× 内置模型（`qfmodel` / `dfmodel` / `gfmodel`；架构角与会话模型同名，所以真正有判别力的是技术角与可行性角），**再**新开会话——新 CLI 进程，`session.config.loaded` 记录 `model: "qfmodel"`，注册表加载的必然是已修好的绑定——然后只派发三个 subagent，各回一句话、不调工具。结果：三个独立的 `is_subagent: true` turn，`turn.started` / `model.request.started` / `model.response.completed` 三处的 `model` 全为会话模型 `qfmodel`，`dfmodel` / `gfmodel` 出现 0 次；同时三份回复分别命中架构 / 技术 / 可行性视角，说明角色提示词确实生效、agent 也确实被加载。即 `subagent_type` 派发路径采纳 Custom Agent 的提示词，但**丢弃**它的 `model` 绑定。

因此 Qoder 原生模式只能作为**同模型、三角色（persona）的自查**，其共识比例不能当作多模型交叉验证的证据，也不应用作 Gate MW 的三模型凭据。需要契约合规的 Delphi 时，按上面的外部 provider 方式配置 `.delphi-config.json`（Qoder 与 OpenCode 同用，条件是模型确有可调端点）。

| 角色 | Agent 文件 | 绑定的 modelId | 实际执行模型 |
|------|-----------|---------------|-------------|
| Architecture (A) | `.qoder/agents/delphi-architecture.md` | `qfmodel` | 会话模型 |
| Technical (B) | `.qoder/agents/delphi-technical.md` | `gfmodel` | 会话模型 |
| Feasibility (C) | `.qoder/agents/delphi-feasibility.md` | `dfmodel` | 会话模型 |

**安装位置**（`xp-gate init` 自动部署，已存在的文件不覆盖）：
- 项目级：`<project>/.qoder/agents/`（`xp-gate init`）
- 用户级：`~/.qoder/agents/`（`xp-gate init --global`）

**model 字段格式**：仍须写成 `"[DisplayName](modelId)"`。裸名字或已下线 ID 不会报错，会被平台静默忽略。`xp-gate init` 会审计已部署的 `delphi-*.md`，格式非法或 modelId 与本版本模板不一致时点名文件并给出"删除 → 重跑 `init` → 重启会话"提示；因为部署语义是"已存在不覆盖"，从 #417 之前的版本升级必须手工删旧文件再重跑 `init`。注意：修好绑定也只是让角色声明规范，并不改变上表的执行模型结论。

**执行方式**：用 Agent tool 并行派发 3 个 subagent，`subagent_type` 分别取 `delphi-architecture`、`delphi-technical`、`delphi-feasibility`。**新建或修改 agent 文件后必须重开会话**——注册表只在会话启动时加载，否则报 `Unknown agent type`。

**客观验证（不要采信专家自述）**：`~/.qoder/logs/runs/*/manifest.json` 的 argv `--model` 记录的是**会话/进程启动模型**，对 subagent 没有判别力（历史上所有运行都是同一个 ID）。真正的证据在按会话分段的日志里：

```bash
grep '"type":"model.request.started"' ~/.qoder/logs/sessions/<project>/<sessionId>/segments/*.jsonl \
  | grep -oE '"model":"[^"]*"' | sort | uniq -c
```

同一文件里的 `turn.started`（`is_subagent:true`）与 `model.response.completed` 可交叉核对：前者证明三个角色各自起了独立 turn，后者带 `provider` 字段。两个坑：(1) 被验证的那个 modelId 必须**不等于会话模型**，否则该角色测不出判别力（会话模型通常是 `qfmodel`）；(2) 改完 agent 文件必须**换新会话**再测，注册表只在会话启动时加载，用旧会话的数据下结论会被旧绑定污染。专家自述的 `requested_model` 只是在复述自己 frontmatter 里的声明，不构成证据。

**成本**：走这条路径不消耗外部 API key，只计 Qoder Credits。

#### OpenCode 平台（External API 模式）

OpenCode 环境下通过 `opencode.json` 的 agent 配置 + `.delphi-config.json` 调用外部 API：
- **MUST 从 `opencode.json` 的 agent 配置中读取模型**
- 通过 `scripts/delphi-external-review.cjs` 调用各 provider 的兼容 API（注意：该脚本目前在仓库根 `scripts/` 下，尚未随 skill 目录分发）
- 需要用户自行配置 API key（环境变量注入）

#### DeepSeek Harness 平台（`delphi-review` 工具 — 推荐）

DSH 里**不要**用 `subagent` 工具派发三个专家。原因和 Qoder 同源：DSH 的 subagent
继承宿主配置的**单一**模型（`SubagentModelSelectionConfig.enabled` 默认 `false`），
三个"专家"会是同一模型的三个实例 —— 按本 skill 的规则必须 BLOCK。

DSH 的正确入口是插件提供的 **`delphi-review` 工具**（`@boyingliu01/dsh-plugin-xp-gate`）：

```
delphi-review(
  subject:   <待评审材料：diff / 设计 / 规格>,
  addressed: <可选：上一轮之后改了什么，用于后续轮次>,
  maxRounds: <可选：覆盖默认 5 轮>
)
```

> **先确认该工具真的存在（#574）**：不是所有 DSH profile 都装了它。若当前会话的工具列表里
> 没有 `delphi-review`，说明插件未安装 —— 此时**不要**推断"那就用 subagent / workflow 吧"。
> 按下方【通道白名单】处理：要么装插件（`dsh plugin add @boyingliu01/dsh-plugin-xp-gate`），
> 要么走 external 脚本路径，要么 BLOCK。

该工具**直连外部 OpenAI 兼容网关**，每个席位绑定一个不同模型，因此不依赖宿主配置即可
满足不变量。它复用**同一份** `.delphi-config.json`，无需额外配置。

**代码强制的不变量**（不是文档约定，违反即报错）：

| 不变量 | 违反时 |
|---|---|
| 恰好 3 位专家 | `DelphiConfigError` |
| 3 个 `requested_model` 去空白后两两不同 | `DelphiConfigError` |
| 模型不得为未展开的 `${...}` 占位符 | `DelphiConfigError`（在**任何网络调用之前**） |
| 缺密钥 / 缺 provider / 专家跨网关 | `DelphiSetupError`，报变量名而非回显配置 |
| 报告缺 `### VERDICT` 段 | 记为 `INVALID_NO_VERDICT`，**不计入共识** |
| 退出码 0 但内容为空 | 记为 ERROR（推理模型可能把预算全烧在隐藏 token 上） |

**轮次语义与本 skill 一致**：Round 1 匿名且并发；Round 2+ 回传**汇总票型**与"已修改项"，
个体报告始终匿名。达到阈值即停，否则到 `max_review_rounds` 为止并如实返回 `NO CONSENSUS`。

**推理模型注意**：`g-glm-5.3-flash` 这类模型会先产出隐藏推理 token。
实测 `max_tokens=4000` 时 `finish_reason=length` 且 **content 为空**；
席位需独立预算（该席位配置为 32000）。工具把"空内容"记为 ERROR 而非空评审。

> 备选：若希望 DSH **原生** `subagent` 也能选模型，需同时满足
> (1) `dsh-tool-subagent` 的 `modelSelectionSettings: true`（仅能力开关），
> (2) 宿主设置 `SubagentModelSelectionConfig.enabled = true` 且 `allowedModels` ≥3 个不同模型。
> 该路线依赖宿主配置，CI / 一次性会话不可靠，故不作为默认路径。

**DSH 双通道契约（native-first + external fallback，#443）**：评审开始先探测 native 通道，两层开关缺一不可——

| 探测步骤 | 方法 | 判定 |
|---|---|---|
| ① 工具 schema | 当前会话 `subagent` 工具的参数里是否暴露 `provider` / `model` 字段 | 无 → native 不可用（`enabled` 默认 `false`） |
| ② 模型清单 | `list_subagent_models` 工具是否注册；可用时返回条数是否 ≥3 且互异 | 未注册或 <3 条 → native 不可用 |
| ③ 运行时兜底 | 上述任一不满足时调用 subagent 会抛 `child model selection is disabled` | 直接判定，不试错 |

- **native 可用**：三个专家并行派发，每个显式传 `model`（取自 `allowedModels` 三个互异条目）；`resolved_model` 以平台日志/回执为准，无日志时按 #437 过渡标准注明「执行层验证待平台支持」。
- **native 不可用**：降级 **external**（本 skill 的 `delphi-review` 插件工具，或 `.delphi-config.json` + `scripts/delphi-external-review.cjs`）。缺 API key 时必须给出明确指引（导出环境变量），不得静默失败。
- 降级证据落盘 `delphi-reviewed.json`：`channel`、`fallback_reason`（如 `dsh_subagent_model_selection_disabled`）、`probe_evidence`（①②③ 的实测摘录）。
- 两通道同不变量：三专家齐全、`requested_model` 互异、consensus ≥90%、**无单专家路径**。
- 可用性探测可用 `xp-gate doctor delphi` 复核（DSH 环境下含 `subagentModelSelection` 持久化设置检查）。

##### 通道白名单（default-deny，#574）

上面的双通道契约是**允许清单**，不是"除 subagent 外都能用"。**只有这两条通道合法**：
`subagent`（native，需通过 ①②③）与 external（插件工具 / `delphi-external-review.cjs`）。

**其余一切扇出机制一律禁止**，包括但不限于：

| 禁止的通道 | 为什么禁止 |
|---|---|
| `workflow` 工具的 `agent()` 扇出 | `agent()` 的 `provider`/`model` **不受** `allowedModels` 约束（`dsh-workflow-ptc` 里没有任何白名单校验，直达 `subagents.start`）。脚本里写什么模型就真的跑什么模型。 |
| 手写脚本 / 循环里逐个调 `subagent` 但省略 `model` | 缺 `model` 时子代理**静默继承宿主会话模型**，三席变一席。 |
| Agent Teams / `spawn_teammate` | 团队成员模型不可逐条指定，且 `TeamMemberView.model` 是输出字段、可能是继承值。 |
| 任何"从网关模型清单里挑三个"的做法 | 网关可能注册上百个模型，任意三个互异都满足旧不变量 —— 这正是 #574 的事故形态。 |

**推荐通道不可用时，必须 BLOCK 并如实报告，不得自行选一条"看起来能跑"的路径。**
判定句：*如果我正在用的派发机制不在上面两条之内，立即停止，输出 BLOCK 并说明缺什么。*

##### 席位解析（派发前强制步骤，#574）

模型 ID **只能来自 `.delphi-config.json`**，不得来自会话默认模型、网关模型清单、
记忆、或上一次评审的残留。派发前依次执行：

1. 读取 `<项目根>/.delphi-config.json`，取 `active_profile` 指向的 profile。
   （查找顺序：项目根 → `~/.config/xp-gate/.delphi-config.json`；多份存在时以项目根为准。）
2. 解出 `architecture` / `technical` / `feasibility` 三个席位的 `model`，**去空白**。
3. **原样打印**这三个 ID 与 `active_profile`，作为本轮派发的凭据。
4. 只用这三个字面量派发；脚本里**不得出现配置中不存在的模型 ID**。
5. 三席位必须互异 —— 若配置本身有重复，这是配置错误，BLOCK，不要去"挑一个换掉"。

> 反例（2026-10-22 实测事故）：某次 code-walkthrough 的 workflow 脚本硬编码了
> `s-deepseek-v4.1-flash` / `g-deepseek-v4-pro` / `doubao-seed-2.0-pro`，
> 而配置写的是三个 `local-*` 免费席位。三者互异、评审"成功"、Gate MW 判 APPROVED，
> 但付费模型被真实调用，而 `local-*` 只落了 1/3。16 次 workflow 运行中读取配置的次数为 **0**。

##### 执行后核验（#574）

评审结束后必须逐席位核对**实际解析到的模型**，不能只看请求值：

- 证据来源：子会话的 `request/header`（平台日志）或 external 脚本的回执 `resolved_model`。
- 三席 `requested_model` 必须**逐一等于**配置中同角色的席位（按角色对应，不是"三者在集合里"）。
- 任一不匹配 → 本次评审**作废**，不得写入 `.code-walkthrough-result.json`，按 BLOCK 处理。
- Gate MW 会独立复核这一点（#574）：存在 `.delphi-config.json` 时，
  证据里每个 `requested_model` 必须等于该角色的配置席位，否则 pre-push 直接 BLOCK。

#### WorkBuddy 平台（Expert 团队模式）

WorkBuddy 侧以 Team 型专家团（示例：`delphi-review-team`，安装在 `~/.workbuddy/plugins/marketplaces/my-experts/plugins/`，创建方式见 [docs/platform-workbuddy.md](../../docs/platform-workbuddy.md)）承载评审，触发本技能后按此路由执行：

| 角色 | Agent ID | 绑定模型 | 倍率 |
|------|----------|---------|------|
| 主理人（衡定一，会话自身） | delphi-review-team-team-lead | 会话模型，固定用 `local-deepseek-v4-flash` | 零 credits |
| Architecture (A) | delphi-arch-reviewer | `deepseek-v4.1-flash` | x0.11 |
| Technical (B) | delphi-tech-reviewer | `glm-5.3-flash` | x0.06 |
| Feasibility (C) | delphi-feasibility-reviewer | `hy3` | x0.00（免费） |

**执行方式**：
- 主理人开场自检：会话模型不是 `local-deepseek-v4-flash` 时，先提醒用户切换再开始。
- 已启用专家团 → 按其团队机制 spawn 3 位成员；未启用 → 用 `Agent` 工具同一消息**并行** spawn 3 个 `general-purpose` 子代理，prompt = 对应专家 MD 全文人设（读专家团 `agents/` 目录）+ 匿名评审模板 + 待评审材料，`model` 参数按上表传。
- Round 1 三个子代理互不见对方输出（匿名铁律不变）。

**执行验证（适配本平台，2026-09-29 校准）**：
- 参数层路由 ✅ 已实测：`Agent` 工具 `model` 参数传 `deepseek-v4.1-flash` / `glm-5.3-flash` / `hy3` 三个 ID 均被接受，3 个 general-purpose 子代理并行执行成功。
- 执行层证据 ⚠️ 平台暂缺：WorkBuddy 审计日志（`~/.workbuddy/audit-log/`）只记 command-safety 事件，无 per-request 模型路由记录，无法像 Qoder/OpenCode 那样从日志取证 distinct models。
- **WorkBuddy 过渡验证标准**：参数级校准（model ID 被平台接受且子代理成功执行）+ 专家 `requested_model` 自述如实记录；报告中必须注明「执行层验证待平台日志支持」。若 `model` 参数被拒绝（报错/回落会话模型），按本技能 Failure Handling 处理，不得静默降级冒充三模型共识。
- 契约合规兜底：需要严格证据时，走外部 provider 路径（`.delphi-config.json` + 兼容 API，如 whalecloud 网关 3 个模型 ID）。

**成本**：3 专家合计 x0.17/轮；主理人选 local 会话模型则零 credits。

### 席位 prompt 上限与降序裁剪（强制 — #481）

prompt 字节上限是 **席位×模型路由 属性**，不是全局安全值（2026-10-05 实测：同一网关下
`g-glm-5.3-flash` 席 32-39KB 连续 6 次断连，他席 36KB 一次通过）。编排规则：

1. **发送前硬闸**：runner 按 expert 条目的 `max_prompt_bytes`（默认 40000 字节，UTF-8 计）
   拒发超限请求，输出 `error_type: "prompt_budget_exceeded"`。
2. **失败分类**：响应前断连且字节数超过该席位标定的 `last_pass_bytes` →
   `error_type: "SIZE_EXCEEDED"`（不是网络故障，重试同一 payload 无意义）；
   其余失败输出 `network_error` / `retryable_error`，编排层按 `error_type` 字段断言，不解析散文。
3. **超限时按降序裁剪，每步只做一步**：
   ① 去附录（探针填充、日志附录、非必需长引用）→ ② 去非本轮 AC 原文 →
   ③ 去测试清单（枚举 → 计数）→ ④ 拆分两次调用（按 diff 对半，同报告合并）→
   ⑤ 仍失败 → `PROCESS_BLOCK` 交人裁定。**不得以两席结果冒充 3/3 共识。**
4. **标定**：上限按「固定语义核心 + 确定性填充附录」构造探针，在
   `[last_pass, last_fail]` 区间二分 3-5 次测得；记录行含
   `seat_id × model_id × gateway × max_passing_bytes × measured_at`；
   模型或网关变更即重标。协议全文与种子标定表见
   [docs/plans/2026-10-14-sprint-c-design.md](../../docs/plans/2026-10-14-sprint-c-design.md) §2。

### 共识阈值

| 阈值 | 说明 |
|------|------|
| **>=90%** | 推荐默认 |
| 100% | 完全一致（更严格） |

---

## 评审执行过程

```
Phase 0: 准备 → Round 1: 匿名独立评审 → 共识检查
    │
    ├─ 一致 + >=90% + APPROVED → ✅ 完成
    │
    └─ 不一致 或 <90% 或 REQUEST_CHANGES
          │
          ▼
       Round 2: 交换意见 → 共识检查
          │
          ├─ 一致 + >=90% + APPROVED → ✅ 完成
          │
          └─ 仍分歧 或 REQUEST_CHANGES
                │
                ▼
             Round 3: 最终立场 → 共识检查
                │
                ├─ APPROVED → ✅ 完成
                │
                └─ REQUEST_CHANGES → 修复方案 → 回到 Round 2 重新评审
```

### Step 0: Input Validation (MANDATORY — 必须在任何评审前执行)

检查用户 prompt 中是否包含可评审内容（设计文档、代码、specification.yaml、PR diff）：

1. **有完整输入** → 直接进入 Phase 0（准备阶段），开始 Round 1
2. **有部分输入**（占位符、描述性文本）→ 按输入内容执行评审，标注 `[INPUT: PARTIAL]`，但继续执行
3. **无输入**（仅触发词，无文档/代码）→ 输出阻断响应

**Detection heuristics**:
- **Complete**: >=1 structural element (##, requirement, AC-, function, class, interface, YAML frontmatter, code block) AND >=50 non-whitespace chars.
- **Partial**: Descriptive text referencing a design/code artifact BUT lacks structure, OR contains placeholders.
- **None**: Only trigger words with zero additional content, OR questions about the review process itself.

**Partial input constraint**: Cap review to 1 round with `confidence=low` annotation.

---

## 修复与重新评审

如果最终裁决是 REQUEST_CHANGES 或 REJECTED：
1. 修复所有 Critical Issues + 处理所有 Major Concerns
2. 重新评审（从 Round 2 起步，不是 Round 1）
3. 迭代直到 APPROVED

---

## 终止条件

| 参数 | 默认值 | 说明 |
|------|--------|------|
| `max_review_rounds` | 5 | 超过后生成"未达成共识报告"，交人决策 |
| `timeout` | 60min | 单次评审超时 |

---

## Output Format (MANDATORY for L3)

Every Delphi mode MUST use the full JSON schema below. Architecture, technical, and feasibility each output independently; the orchestrator verifies all three executions before aggregating `consensus_report`. There is no single-reviewer Delphi approval path.

```json
{
  "expert_id": "A|B|C",
  "round": 1,
  "mode": "design",
  "verdict": "APPROVED|REQUEST_CHANGES|REJECTED",
  "confidence": 9,
  "critical_issues": ["..."],
  "major_concerns": ["..."],
  "minor_concerns": ["..."],
  "consensus_report": {
    "agreed_items": ["..."],
    "disagreed_items": ["..."],
    "final_verdict": "APPROVED|REQUEST_CHANGES",
    "consensus_ratio": 0.95
  }
}
```

**For code-walkthrough mode**, output follows `.code-walkthrough-result.json` schema (see `references/code-walkthrough.md`).

**For requirements mode**, output follows `requirements-reviewed.json` schema (see `references/requirements.md`):

```json
{
  "mode": "requirements",
  "verdict": "APPROVED|GAPS_FOUND",
  "timestamp": "2026-07-25T10:30:00Z",
  "consensus_ratio": 1.0,
  "requirements_hash": "<SHA-256 hex digest>",
  "head_commit": "<git rev-parse HEAD>",
  "context_file_used": "CONTEXT.md",
  "round": 1,
  "expert_verdicts": [
    { "role": "architecture", "verdict": "APPROVED", "confidence": 9, "result_type": "delphi_expert_result", "requested_model": "provider/model-a", "resolved_model": "provider/model-a", "channel": "external" },
    { "role": "technical", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "provider/model-b", "resolved_model": "provider/model-b", "channel": "external" },
    { "role": "feasibility", "verdict": "APPROVED", "confidence": 8, "result_type": "delphi_expert_result", "requested_model": "provider/model-c", "resolved_model": "provider/model-c", "channel": "external" }
  ],
  "requirements_statement": "<short summary of what was reviewed>",
  "gaps_found": [],
  "rounds_used": 1,
  "escalation_needed": false
}
```

Schema-v2 Phase 2 requires `requirements_statement`, `timestamp`, `consensus_ratio`, `expert_verdicts`, `head_commit`, and `requirements_hash`. The hash is SHA-256 of the exact concatenation `requirements_statement + project-relative context file UTF-8 content if used + timestamp YYYY-MM-DD`; context paths must remain inside the project after realpath resolution.

**Anti-patterns mapping:**
- `Round 1 → "评审完成"` → MUST NOT have `verdict: APPROVED` if `critical_issues` exist
- `只处理 Critical，忽略 Major` → MUST include `major_concerns` array
- `用户说"时间紧急"就跳过` → MUST include `round` field proving multi-round process

---

## Terminal State Checklist

- [ ] Phase 0 完成（文档验证 + 专家分配）
- [ ] 已完成所需轮次（最多 5 轮，每轮三位专家均执行）
- [ ] 问题共识比例 >=90%
- [ ] 所有 Critical Issues 已解决，Major Concerns 已处理
- [ ] 最终裁决是 **APPROVED** 或 **APPROVED_WITH_MINOR**
- [ ] 共识报告生成并保存
- [ ] IF REQUEST_CHANGES → 已修复 → 已重新评审 → APPROVED
- [ ] ⭐ **IF APPROVED (design mode): 生成 specification.yaml**
- [ ] ⭐ **状态文件**: 写入 `.sprint-state/delphi-reviewed.json`

**IF REQUEST_CHANGES/REJECTED → CANNOT claim complete**

### 状态文件格式

**Design mode APPROVED** → `.sprint-state/delphi-reviewed.json`:
```json
{"mode":"design","timestamp":"...","verdict":"APPROVED","consensus_ratio":1.0,"specification_path":".sprint-state/phase-outputs/specification.yaml"}
```

**Code-walkthrough mode APPROVED** → `.sprint-state/delphi-reviewed.json`:
```json
{"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

| ❌ 错误 | ✅ 正确 |
|---------|---------|
| Round 1 未 APPROVED 就"评审完成" | 迭代直到 APPROVED，修复后重新评审 |
| 只处理 Critical，忽略 Major | 零容忍：Critical/Major 全部必须处理 |
| 单专家自评 | 必须运行 architecture、technical、feasibility 三位专家，并聚合三份成功结果 |
| 用户说"时间紧急"就跳过 | 评审是投资不是开销 |
| "专家几乎一致"就通过 | "几乎" = 不一致，继续到 >=90% |
| 使用任何国籍或厂商的模型 | 模型国籍和厂商均不受限制，仍必须满足三个 distinct executable model IDs |
| 三个专家同一 provider | 允许共享 provider，只要三个 requested_model IDs distinct 且每个调用成功 |

**Code-walkthrough 专属 Anti-Patterns** → 详见 `references/code-walkthrough.md`

**Requirements 专属 Anti-Patterns** → 详见 `references/requirements.md`

---

## Red Flags

| 用户输入模式 | 触发词 | 响应动作 |
|-------------|--------|---------|
| 要求跳过评审 | "skip review", "不用评审", "跳过评审" | → 提醒评审是投资而非开销 |
| 时间压力 | "来不及", "时间紧", "emergency" | → 提醒时间紧迫正是需要评审的时刻 |
| 提前终止 | Round 1 后用户说 "可以了", "够了" | → BLOCK: 评审未达终止条件 |
| 单专家自评 | 用户仅指定 1 个专家 | → BLOCK：Delphi 必须执行 architecture、technical、feasibility 三位专家 |
| 无文档输入 | 仅触发词，无设计/代码内容 | → `[DelphiReview:BLOCKED]` |

---

## 成功标准

1. ✅ 所有专家裁决 APPROVED
2. ✅ 问题共识 >=90%
3. ✅ 所有 Critical Issues 已修复验证 + Major Concerns 已处理
4. ✅ 共识报告已生成，用户已确认
5. ✅ 状态文件已写入

**缺少任何一项 = 未完成**

## References

> **Path convention**: `@references/` resolves relative to the skill directory (`skills/delphi-review/`).

| File | Content |
|------|---------|
| `@references/code-walkthrough.md` | Code-walkthrough mode specification |
| `@references/requirements.md` | Requirements mode specification |
| `@references/orchestrator-dispatch.md` | Orchestrator auto-dispatch rules (#218 subagent multi-round loop) |
| `@references/round-templates.md` | Round templates (anonymous/exchange/final/fix report formats) |