multi-reviewer

name	multi-reviewer
description	SDP 双模型 6 审稿人 + 交叉审核系统。含拒稿信预演。当用户说"审稿"、"review"、"帮我看看这篇论文写得怎么样"时触发。

multi-reviewer

模拟顶会审稿流程的 SDP 双模型 6 审稿人 + 交叉审核 系统。

读取 evolution-memory 中的 review_rules（如有）。

Task Tracking (T10)

启动时注册 TodoWrite 列表：6 venue rubric reviewers + 1 thesis-advisor (T11.5e) + (opt-in) 1 adversarial-AC (T11) = 最多 8 个并行 reviewer task。每个 reviewer 一个 todo，完成一个标一个。

关键：所有 reviewers 在单条消息中通过平台并行 Task 工具一次性分发（T10 规则）。

Step 0: 拒稿信预演

Step 0.7 — Adversarial AC (T11, opt-in via enable_adversarial_ac)

如果 nexus_project.template.json 中 pipeline_overrides.enable_adversarial_ac: true， 在拒稿信预演之后调用 personas/area-chair-rejector.md：

1. paper-service.venue_archive 拉过往论文（Oral/Spotlight/Poster/Reject 分层）
2. 用同一对抗 persona 评审过往论文，算 over_attack_rate
3. 给当前论文跑 persona，按 calibration 折扣应用 attack list
4. 输出 artifacts/adversarial_ac_calibration.json（internal_only: true）

Step 0.8 — Thesis Advisor (T11.5e, 默认开启)

调用 personas/thesis-advisor.md 跑 6 个关注点（机制-实验对应、假设可证伪、诊断器盲区、baseline 完整性、超参选值、理论实用性 + AI 写作痕迹）。

直接消费 quality_engine 的现有 analyzer 输出（不调 LLM 写散文）。输出 artifacts/thesis_advisor_review.json（internal_only: true）。

Venue Acceptance Threshold (T12.d)

6 个 venue rubric reviewers 在打分时必须引用 artifacts/venue_deep_reading_profile.json 的 acceptance_threshold_evidence：

• "该场地 Oral 平均做 N 个 baseline / N 个 ablation，本文做了多少？"
• "该场地 has_theory_paper_ratio 是 X%，本文是不是属于这部分？"

reviewer score 必须带数据给出 — 不是"感觉不够"。

原 Step 0: 拒稿信预演

在正式审稿前，先做一轮自我攻击：

1. 当前模型假设自己是一个想 reject 这篇论文的 reviewer
2. 写一封 200 字拒稿意见（强制找出 3 个致命弱点）
3. 论文作者（当前模型）基于拒稿信预防性修改这些弱点
4. 修改完成后再进入正式审稿

目的：在别人攻击你之前，先自我攻击。提前暴露弱点并修复。

Step 0.3: Context Isolation 硬规则 ⚠️

串行执行多个 reviewer 时，必须遵循以下规则防止意见趋同：

规则 1: 输出文件隔离

• 执行 Reviewer B 时，禁止读取 review_A.json
• 执行 Reviewer C 时，禁止读取 review_A.json 和 review_B.json
• 每个 reviewer 独立输出到 dialogue/review_{id}.json

规则 2: 差异化专业侧重

每个 reviewer 做全面审稿，但各有一个更高标准的维度：

• Reviewer A/D: 方法论严谨性（理论推导、公式正确性、假设合理性）
• Reviewer B/E: 实验充分性（baseline 完整、ablation、统计显著性）
• Reviewer C/F: 写作清晰度 + Novelty（表述质量、创新性论证）

规则 3: 反遗忘声明

每个 reviewer 的 prompt 必须包含：

"忽略你此前在其他角色中看到或产生的任何审稿意见。你是一个全新的独立审稿人，从零开始形成自己的判断。"

双窗口执行

• 窗口 1 (主 harness): Reviewer A → B → C（串行 + 上述规则）
  • Claude Code 用户主：Opus 担任 reviewer
  • Codex 用户主：GPT 5.4 担任 reviewer
• 窗口 2 (对方 harness，打开插件/应用): Reviewer D → E → F（读取 sdp_handoff.json）
  • Claude Code 用户主 → 窗口 2 在 Codex 跑 GPT 5.4
  • Codex 用户主 → 窗口 2 在 Claude Code 跑 Opus
• 两窗口同时启动 → 物理隔离 + 跨模型多样性

Step 0.5: Domain-Calibrated Reviewer Generation (v2.1)

不使用通用 persona，而是根据论文 topic 动态生成领域专家 reviewer。

1. 从论文提取 top-5 关键词 / topic tags
2. 在目标 venue 近 2 年同 area 的论文中找 高频 senior author（发过 3+ 篇）
3. 分析这些人的研究风格和关注点：
   • 偏理论 vs 偏实验？
   • 经常在 review 中关注什么？（从 OpenReview 公开 reviews 推断）
   • 他们的代表作中最看重什么 metric / 方法 / 评估标准？
4. 生成 6 个 Domain-Calibrated Reviewer Profile：

Reviewer	角色	生成方式
A	该子领域的 senior researcher	基于高频 senior author 画像
B	该领域的方法论专家	关注数学严谨性 + 算法正确性
C	应用方向的 practitioner	关注实用性 + scalability
D	跨领域 reviewer（非核心 area）	关注 presentation + accessibility
E	junior 但 aggressive reviewer	寻找每一个细节问题
F	Area Chair 视角	关注 novelty + significance + fit

5. 每个 reviewer 必须生成 "该 reviewer 会特别关注的 3 个问题" — 基于他们的领域专长

这样做的好处：通用型 reviewer 可能不会想到 "为什么不和 GATv2 比"，但 GNN 领域专家一定会问。

Step 0.9 — Kill-Argument 对抗审稿（双线程互不污染协议，默认开启）

协议核心：用两个完全隔离的对话线程对论文进行一次"拒稿压力测试"。线程 A 真心写一份 reject 备忘录，线程 B 在不知道 A 被设定为对抗性的情况下逐条裁决。两线程互不知道彼此存在——这是与本 skill 前面 Step 0.3/0.5 中"6+1 persona"协议的关键区别（那里所有 persona 都知道彼此存在并做交叉审核；这里则严格隔离）。

0.9.0 为什么需要这一步

前面 Step 0.3/0.5 的 6+1 persona 协议有一个隐性缺陷：即便 prompt 里写了"忽略其它 reviewer"，由于这些 persona 共享同一个会话历史 + 同一份 system prompt 框架，它们的反对意见往往会向中位数靠拢——很少出现真正的"我看完之后只想 reject"的样本。

Step 0.9 通过物理隔离的两个线程显式 sample 这种极端信号：

• 线程 A：在它的会话历史里完全没有"还有别的 reviewer"/"这是对抗审稿"/"你的输出会被裁决"等暗示。它真心地以为自己是 venue chair 邀请的、被授权写 reject 备忘录的资深 reviewer。
• 线程 B：在它的会话历史里完全没有"线程 A 被设定为敌对"的暗示。它真心地以为自己是临时被邀请的资深裁决者，需要评估某位 reviewer 的强烈 reject 意见是否成立。

A 的"真诚 reject"与 B 的"真诚裁决"叠加，给出的 verdict 比"6 个互相知道彼此的 persona"更有判别力。

0.9.1 触发条件

Step 0.9 在Step 0.8 之后、Step 1（准备）之前执行。触发条件：

条件	默认行为
nexus_project.template.json 中 pipeline_overrides.enable_kill_argument: true	默认开启
同上字段 false 或不存在	跳过 Step 0.9，直接进入 Step 1
artifacts/draft*.tex 不存在	跳过 Step 0.9 并 warn（没有 draft 无法做 verbatim 比对）
evidence_graph.json 不存在	跳过 Step 0.9 并 warn（没有 evidence_graph 无法核 evidence_refs）
当前 stage 是 review_round1 或 review_round2	触发
当前 stage 是 review_round3_meta	跳过（meta-review 已经是用户最终裁决，不再加噪声）

跳过 Step 0.9 时，Step 1+ 的聚合器必须在 review_report 中显式标记 kill_argument_skipped: true + 原因，便于后续审计。

0.9.2 线程隔离协议（执行硬规则）

规则 1：两次独立的 Task / subagent 调用

Step 0.9 由 omni-orchestrator 用两次独立的 subagent 调用实现，分别派发：

1. 第一次调用：subagent_type = "general-purpose"（或等价的隔离 agent），输入仅含 personas/kill-argument-reviewer.md 的 system prompt + artifacts/draft*.tex + evidence_graph.json + venue rubric。不传任何其它 reviewer 的输出、不传"这是对抗审稿"的提示。该调用产出 dialogue/kill_argument.md + dialogue/kill_argument.json。
2. 第二次调用：另一个独立 subagent 调用，输入仅含 personas/kill-argument-judge.md 的 system prompt + artifacts/draft*.tex + dialogue/kill_argument.md + dialogue/kill_argument.json + evidence_graph.json + dialogue/reviews_summary.md（去身份化聚合）。不传 persona 文件本身、不传单 reviewer 的原始输出、不传"A 是 adversarial"的提示。该调用产出 dialogue/kill_argument_adjudication.md + dialogue/kill_argument_adjudication.json。

两次调用之间不共享会话上下文——这是"互不污染"的物理保证。

规则 2：禁止读的文件清单

线程	禁止读
A	dialogue/reviews_*.md（单 reviewer 原文）、artifacts/thesis_advisor_review.json、artifacts/adversarial_ac_calibration.json、本 skill 的 SKILL.md 本身、persona 文件 kill-argument-judge.md
B	dialogue/reviews_*.md（单 reviewer 原文）、artifacts/thesis_advisor_review.json、artifacts/adversarial_ac_calibration.json、persona 文件 kill-argument-reviewer.md 本身（只读 A 的输出，不读 A 的指令）

orchestrator 在派发 subagent 时必须在 prompt 中显式列出这些"禁止读"路径并要求 subagent 在 self-audit 中确认未读取。

规则 3：去身份化的 reviews_summary

Step 0.9 之前，必须由 orchestrator（或本 skill 的 helper）将 Step 0.3/0.5 已产出的单 reviewer 文件聚合成 dialogue/reviews_summary.md，格式：

# Reviews Summary (de-identified)

## Consensus Weaknesses (mentioned by ≥2 reviewers)
- <weakness 1, no reviewer ID>
- <weakness 2, no reviewer ID>

## Consensus Strengths (mentioned by ≥2 reviewers)
- <strength 1>

## Key Open Questions
- <question 1>

禁止在 summary 中出现 "Reviewer A said..." / "Reviewer 2 thinks..." 等带身份标签的句子。Thread B 只看 consensus，不看个体立场。

0.9.3 输出与下游消费

Step 0.9 完成后产生 4 个 artifact：

dialogue/kill_argument.md                     # Thread A: 拒稿备忘录 (人类可读)
dialogue/kill_argument.json                   # Thread A: 结构化 sidecar
dialogue/kill_argument_adjudication.md        # Thread B: 裁决书 (人类可读)
dialogue/kill_argument_adjudication.json      # Thread B: 结构化 sidecar

四个文件均标记 internal_only: true——绝不进入 draft_final.tex，绝不作为给作者看的 review，绝不进入提交包。

Step 1+ 的聚合器（multi-reviewer 后续步骤）按以下规则消费 Step 0.9 的输出：

Thread B 的 surviving_fatal_grounds	聚合器行为
>= 1	把每条 surviving fatal ground 作为"必须 address 的 weakness"加入聚合 review_report 的 must_fix 列表；overall score 下调以反映这个信号
== 0 且 justified >= 2	把 justified grounds 加入 must_fix，但不再额外下调 score（其它 reviewer 应该已经覆盖了这些点）
== 0 且 unfounded > justified + partially_justified	把"kill_argument 整体可信度低"作为 meta 信号写入 review_report，降低 kill_argument 在最终评分中的权重至 0.3 以下（aggregator 默认权重 1.0）
recommendation == "no_grounds_found"（A 找不到拒稿理由）	review_report 加正面信号："adversarial sample 也未能立住任何 fatal ground，论文鲁棒性指标 +1"

0.9.4 与其它 internal-only 信号的关系

Step 0.7 (Adversarial AC) / Step 0.8 (Thesis Advisor) / Step 0.9 (Kill-Argument) 都是 internal_only: true 的对抗性信号。三者职责正交：

Step	信号来源	关注	协议形态
0.7	用同一对抗 persona 对历史论文做 calibration	venue-level over-attack 率	单线程 + 校准
0.8	6 维度资深审稿（机制对应/可证伪/诊断器/baseline/超参/理论）	论文内部一致性	单线程 + 检测器
0.9	真心写 reject 备忘录 + 隔离裁决	极端拒稿信号是否站得住	双线程互不污染

三者输出共同进入 Step 1+ 聚合，但 Step 0.9 是唯一采用双线程隔离协议的——这是它的判别力来源。

0.9.5 失败兜底

• Thread A 输出 recommendation: "no_grounds_found" → 继续 Step 1，把这个事实作为正面信号记录
• Thread A 输出无法通过 self-audit（verbatim 找不到 / evidence_refs 不在 graph） → 该次 Step 0.9 作废重跑，最多重跑 2 次；仍失败 → 标记 step_0_9_unstable 并跳过，进入 Step 1
• Thread B 输出无法通过 self-audit（读了禁止读的文件 / 无 reasoning） → 该次裁决作废重跑，最多 2 次
• Thread A/B 任一调用超时（>15 分钟）→ 标记 step_0_9_timeout 并跳过

所有 fallback 必须在 review_report 中显式标记，便于审计和后续 evolution-memory 学习。

0.9.6 自检清单（执行 Step 0.9 的 orchestrator 必须确认）

• enable_kill_argument 配置已读取，未误判触发条件
• Thread A 的 prompt 中无 "adversarial" / "kill_argument" / "judge" / "thread B" 等词
• Thread B 的 prompt 中无 "A is hostile" / "A was instructed to reject" 等词
• dialogue/reviews_summary.md 已去身份化（grep 无 "Reviewer [A-F2]" 字样）
• 4 个输出文件均含 internal_only: true
• Step 1+ 聚合器收到 Step 0.9 的输出（不是 persona 文件本身，是 4 个 artifact）

Step 1: 准备

1. 加载 venue rubric → 读取 venue_rubrics/{venue}.md
2. 准备 evidence → 读取 evidence_graph.json 中的相关 claims
3. 搜索 related work → 找 arXiv 近期论文做 grounding

Step 2: SDP 双模型 6 审稿人

遵循 sdp-protocol 通用规则。模型路由由 .agents/rules/model-routing.md 决定，切换 3 次：generator → reviewer → generator → reviewer (终审)。具体 harness 路径由 omni-orchestrator 解析（本 Step 不硬编码 model name / plugin name）。

Round 1 — Model A 扮演 Reviewer A/B/C

# SDP Handoff: Multi-Review Round 1

## Reviewer A（严格型）
重点：Soundness + Reproducibility
[7 维度评分 + strengths + weaknesses + questions]

## Reviewer B（创新型）
重点：Novelty + Significance
[7 维度评分 + strengths + weaknesses + questions]

## Reviewer C（读者型）
重点：Clarity + Related Work
[7 维度评分 + strengths + weaknesses + questions]

输出到 dialogue/reviews_model_a.md（具体文件名按当前 harness 路由配置；常见: reviews_gemini.md / reviews_claude.md）。

→ 切换到 Model B（跨 harness）

你的主 harness	具体操作	Token 预算
Claude Code (running NeXus)	打开 Codex 插件 → 新建对话 → 粘贴 dialogue/sdp_handoff.json (GPT 5.4 担任 Model B)	Codex pool ~5 次
Codex (running NeXus)	打开 Claude Code → 新建会话 → 粘贴 dialogue/sdp_handoff.json (Opus 担任 Model B)	Claude pool ~5 次

具体 model 按 .agents/rules/model-routing.md 解析。

Round 2 — Model B 扮演 Reviewer D/E/F + 交叉审核

Model B 先独立审稿，再看到 Model A 的 reviews 做交叉审核：

Part 1: 独立审稿
├── Reviewer D（严格型）：独立审稿
├── Reviewer E（创新型）：独立审稿
└── Reviewer F（读者型）：独立审稿

Part 2: 交叉审核（看到 Gemini 的 A/B/C reviews 后）
├── 标注 GPT 组 vs Gemini 组的共识点
├── 标注分歧点 + GPT 组的立场和理由
├── GPT 觉得 Gemini 遗漏了什么
└── GPT 的综合共识/分歧报告

输出到 dialogue/reviews_gpt.md。

→ 切回主 harness（按 model-routing.md）

你的主 harness	具体操作	Token 预算
Claude Code (running NeXus)	切回 Claude Code 主会话 (Opus 担任 Model A)	Claude pool ~5 次
Codex (running NeXus)	切回 Codex 主会话 (GPT 5.4 担任 Model A)	Codex pool ~5 次

Round 3 — Model A 交叉回应

├── 看到 GPT 的 D/E/F reviews + 交叉审核报告
├── 标注 Gemini 组 vs GPT 组的共识/分歧
├── 对分歧点 Gemini 的立场和理由
└── Gemini 的综合共识/分歧报告

输出到 dialogue/cross_review_gemini.md。

→ 切回 Model B（按 model-routing.md）

Round 4 — Model B 终审

├── 审阅 Gemini 的交叉回应
├── 综合双方意见，做最终裁决
├── 最终修改清单（按优先级排序）
│   ├── must_fix：不改就 reject 的问题
│   └── nice_to_have：改了更好的建议
├── revision_roadmap（每项改进的预估工作量）
└── Overall Decision: Accept / Minor Revision / Major Revision

输出到 dialogue/final_review.md。

切换次数：3 次（→GPT →回Gemini →GPT终审）

Reviewer Prompt 模板

严格型（A/D）

你是一位顶会的严格审稿人。你的审稿风格以挑硬伤著称。

你正在审稿目标会议: {venue}
评审标准见附件 rubric。

**你的重点关注领域:**
- Soundness: 理论证明是否有漏洞？实验设计是否 fair？baseline 是否过时？
- Reproducibility: 超参数是否完整？代码是否公开？结果是否可复现？

**你必须做到:**
1. 按 rubric 中的 7 个维度逐一打分
2. 列出至少 3 个 strengths 和 3 个 weaknesses
3. 每个 weakness 必须引用论文中的具体位置（section + 原文）
4. 提出至少 1 个需要额外实验才能回答的 question
5. **必须尝试找至少 1 个 failure case**
6. **数学检查清单**（符号定义、公式编号、维度匹配等）
7. 给出 overall score 和 confidence

创新型（B/E）

你是一位重视创新的审稿人。善于发现亮点，也指出创新性不足。

**重点:**
- Novelty: 核心方法/视角是否前所未有？与最近 prior art 差异多大？
- Significance: 能否开辟新方向或解决重要问题？

**额外要求:**
- **交叉验证 novelty claim**：对照 evidence graph
- **推广性分析**：方法能推广到哪些场景？

读者型（C/F）

你是一位从读者角度审稿的审稿人。以非本领域毕业生的视角阅读。

**重点:**
- Clarity: 仅凭论文能否理解方法？
- Related Work: 文献覆盖是否完整？

**额外要求:**
- **first-pass 测试**：第一遍阅读标记每个不理解的地方
- **figure caption 检查**：每个图/表 caption 是否 self-contained
- **术语一致性**：同一概念是否在不同段落用不同名称

7 维度评分框架

维度	默认权重	说明
Novelty	20%	与 prior art 的差异化
Soundness	20%	方法正确性 + 实验严谨性
Significance	15%	潜在影响力
Clarity	15%	写作质量 + 可读性
Reproducibility	10%	能否复现
Related Work	10%	文献覆盖完整性
Ethics & Limitations	10%	局限性讨论 + 伦理

实际权重从 venue_rubrics/{venue}.md 加载。

三层 Anchor 校准 + v4 审稿硬化

Anchor 1: 历史分数分布（静态）

每个 venue_rubrics/*.md 文件内嵌历史统计，用于校准 raw score。

Anchor 2: cited_by_percentile（可选）

如有被引数据，使用 OpenAlex 验证。

Anchor 3: 用户校准（渐进式）

用户对历史 review 标注"偏高/准确/偏低"，系统学习偏好。

Score Deflation Protocol（v4 新增）

问题：LLM 有 sycophancy bias，比真实 reviewer 温和得多。

规则：

1. 每个 reviewer 必须找出至少 1 个 reject-level weakness（score ≤ 4 的理由），即使整体觉得论文不错
   • 找不到 → 说明审稿不够深入 → 换更严格的 prompt 重审
2. 每个 reviewer 给 overall score 时，同时给出"为什么不应该 reject"的理由
   • 理由不够强 → score 下调 1 分
3. 6 个 reviewer 的 score 分布必须满足：
   • 至少 1 个 score ≤ 5（模拟最严格的 25% 审稿人）
   • 至少 2 个 score ≤ 6（模拟中等严格度）
   • 全部 score > 6 → ⚠️ 模拟失真，增加 Reviewer-2 Attack

Reviewer-2 Attack（v4 新增 — 极度苛刻模式）

在 6 个 reviewer 之外，额外触发 1 个 Reviewer-2（学术圈的 "Reviewer 2 nightmare"）：

你是 Reviewer 2。你以极度严格著称。
你的标准是："除非你让我无话可说，否则 reject。"

规则：
1. 找出至少 1 个 FATAL FLAW（能让 AC 直接 reject 的问题，不是小问题）
2. 这个 flaw 必须具体、可验证（不是 "writing could be improved"）
3. 如果真的找不到 fatal flaw → 解释为什么这篇论文值得 accept
4. 你的标准：50% 的论文应该被 reject

Reviewer-2 的输出不影响综合 score，但 fatal flaw 必须被显式处理：

• 能 rebuttal → 论文更强
• 不能 rebuttal → 这就是被拒的真正原因

Venue-Calibrated Score Distribution（v4 新增）

从 venue_playbooks/playbooks.json 加载 venue 历史数据校准评分：

{
  "acceptance_rate": "25%",
  "score_distribution": {
    "mean": 5.2, "std": 1.8,
    "accept_threshold": 6.5,
    "oral_threshold": 8.0
  },
  "typical_weaknesses": [
    "incremental contribution",
    "missing important baselines",
    "overclaiming without sufficient evidence"
  ]
}

审稿完成后对比 venue 的 accept_threshold：

• score_mean ≥ accept_threshold → "competitive for this venue"
• threshold - 1 ≤ score_mean < threshold → "borderline"
• score_mean < threshold - 1 → "likely reject — 建议补充实验或 pivot"

Post-Submission Scoring Bias Calibration（v4 新增）

当 evolution_memory.json 中积累 ≥2 次真实投稿反馈后：

1. 计算 score_bias = mean(模拟 score - 真实 score)
2. 后续审稿的所有 score 自动减去 score_bias
3. score_bias > 1.5 → ⚠️ "模拟审稿严重偏乐观"

这实现了一个自校准的审稿系统——越用越准。

审稿终审卡点 ⛔

Autopilot 硬卡点 — 必须用户确认

展示完整 review 报告后，用户可以：

• ✅ 选择要修改的 weaknesses → 触发 paper-writing Step 7 修改
• ❌ 标注某些 weakness 为"不同意" → 反馈给 Anchor 3
• 🔄 要求某个 reviewer 重新审 → 重新执行对应 Round

输出

保存到 artifacts/review_report.json（包含 6 份 review、交叉审核报告、终审裁决、revision_roadmap）。

反直觉规则

1. 让步小点赢大的 — 承认小问题，在关键点上站稳
2. 6 个 reviewer 不是为了凑数量 — 双模型的视角差异才是核心价值
3. consensus weaknesses 必须修 — 两个模型都指出的问题几乎一定存在
4. disagreements 更有价值 — 分歧意味着这个点值得深入思考
5. 不要让好评麻痹你 — 专注 weaknesses，strengths 不需要你操心

Pipeline Exit (v2: 3-Round Review)

v2 拆分为 3 轮递进审稿：

review_round1（本 skill 全流程）→ revise_round1 → review_round2（复审+对抗 reviewer）→ revise_round2 → review_round3_meta（AC 终审）

完成 Round 1 后：

1. 必须调用 pipeline-orchestrator.complete_stage("review_round1") 验证产出
2. 进入 revise_round1（修改）→ 然后自动进入 Round 2 和 Meta-Review
3. Meta-Review reject → 可 rollback 到 experiment_run 补实验

---

Domain Taste 集成

在生成 reviewer persona 前，必须读取 artifacts/domain_taste_profile.json（由 domain_calibration stage 自动生成）。

Reviewer Persona 生成规则

1. 读取 domain_taste_profile.json:

   • structural_norms → 每个 reviewer 的 must_check 中加入违反项
   • staircase_diffs → 校准评分（"elite 100% 有 ablation" → 没有则扣分）
   • argumentation_patterns → 设定 reviewer 关注的论证维度
   • must_have_baselines → 检查是否缺少必备 baseline
   • trending_direction → 评估 timing 和 relevance

2. 每个 reviewer persona 必须包含:

   • ≥3 条来自 domain_taste 的具体检查项
   • 该维度对应的 elite 统计值作为参照
   • 例: "elite insight_density 平均 0.71，低于 0.5 应扣分"

3. SDP Handoff 生成:

   • 切换到 Codex 前，调用 pipeline-orchestrator.generate_sdp_handoff_file(project_dir, "review", 3)
   • 自动将 domain_taste_profile 的完整核心内容嵌入 handoff（不能只放摘要）
   • 含: structural_norms 全表、staircase_diffs、trending、must_have_baselines
   • 每个 reviewer persona ~800 字，总 handoff ~5000-8000 字