Codex Review

---
name: codex-review
description: 仅手动触发。施工完成后，用 Codex GPT-5.5 对照冻结的 L1–L7、规格物化报告、goal 章程和工程红线做单模型符合性核验；不挂门禁，不替代高风险多视角审查。
---

# 代码评审（codex-review）

本 skill 是**施工链路的收尾核验层**，用户级通用，可跨项目使用。

它解决的问题：施工完成后需要一道独立检查，但**这道检查最危险的失败模式不是"漏看 bug"，而是"把已拍板的正确做法当成 bug 报上来、又被照着改掉"**——评审者缺乏前面多轮讨论的背景，很容易把刻意的取舍误判为缺陷。**而最隐蔽的一种是：评审者根本不知道某做法是已拍板决策，于是理直气壮把它标成"缺陷"。** 本 skill 的全部设计都围绕堵住这个口子，核心是一条默认方向：**不改除非已证实是缺陷**——证据责任压在"改"这一侧，不是压在"不改"这一侧。

> **作用 = 照答案做低成本符合性核验**：标准答案是**冻结的正式 L1–L7 + 规格物化覆盖报告 + goal 章程 + 工程红线**。轻量设计只解释 `SD/DP` 的由来，不能覆盖正式规格。若两者不一致，说明 T5 物化失效，应返闸，不由评审者选边。

在施工链路里的位置：

```
轻量设计（SD-x） → 正式 L7（AC-x） → 真值收敛与规格冻结（覆盖报告全绿）
                                    ↓
                        goal 章程（红队评审过） → goal 自主执行：代码 + 测试 + 交付
                                    ↓
              【本 skill】codex 单模型符合性核验 ← 用户手动触发（goal 之外）
                                    ↓
        分流责任人按"不改除非已证实"分流 ── A 改 / B 待裁 / C 上浮
                                    ↓
        触承重面 / 上游规格错了？──是──→ 回炉（退回设计步，见 §6）
                                    否
                                    ↓
                              修完收口
```

**不是门禁。** 它不卡开工、不卡交付；只在用户说"跑一遍代码评审"时执行。

> **它在 goal 之外，这是有意的。** goal **内部**的审核只能是 loop 闭环内的 AI 自审 + 机器检查器——引入 loop 外的观点会带来场景不同、上下文不同的噪音。本 skill 是**事后**的、用户主动要的第二双眼睛，不是 goal 的工序。

---

## 0. 与 adversarial-review 的分工（单模型够用的边界）

| 维度 | adversarial-review（已有） | codex-review（本 skill） |
|---|---|---|
| 评审什么 | 设计 / 用例 / goal 章程 / 任意方案，或**高风险代码** | 已写完的**代码 diff**（低中风险符合性核验） |
| 时机 | 开工**前**（真值待定，找最优） | 开工**后**（真值已定，查偏差） |
| 真值状态 | **待定**——正在探索方案空间 | **已冻结**——规格 + 决策表 + 用例已拍板 |
| 模型编制 | 触发时按用户本机可用桥接/模型选择至少一席 | **Codex 单席，无多模型对比** |
| 收口者 | 当前主线程直接裁决（不设裁判） | **分流责任人**（对照冻结真值分流） |
| 产出 | 采纳/驳回裁决报告 | 三级分类意见（不自动改码） |

**单模型在"符合性核验"这件事上够用，但不要把它当充分代码审查**：

> 符合性核验有标准答案（冻结规格 + 决策表 + 用例规格 + 红线就是答案），是对照答案查偏差，一个强模型够了；硬上多方对抗既贵又会把"已拍板的取舍"翻出来重吵——那正是本 skill 要堵的风险。
>
> 但代码评审里**最高价值的发现常常是"答案没覆盖到的地方出了 bug"**——并发竞态、边界态、错误处理、性能。这些规格通常不下沉到逻辑级（实现细节属代码自由范围），需要正交视角（adversarial-review 的强项），单模型会系统性漏检。所以本 skill **定位是低成本符合性核验，不宣称"一个强模型就够全部代码审查"**；这类风险按 §1 升档。
>
> 单模型也没有裁判席兜 GPT 的误报——这个位置由**分流责任人的对照真值分流**（§5）补上，而分流的默认方向是"不改除非已证实"，证据责任在"改"侧。

---

## 1. 什么时候用 / 不用 + 升档硬门

**用**：
1. goal 或施工会话写完一段代码，用户想要一道独立的实现核验。
2. 改动已落地、决策已冻结，需要查"实现是否符合已拍板的图与决策"。

**不用 / 改用**：

| 场景 | 改用 |
|---|---|
| 还在定方案 / 设计有待探索 | `adversarial-review`（多方对抗找漏洞） |
| goal 章程开工前评审 | `adversarial-review` 的章程口径卡（红队四问） |
| 既无冻结规格也无决策表、也无退化基线（§3.3） | 先补设计，否则评审失去标准答案、退化为自由心证 |

**升档硬门（运行前强制筛查，命中即升 adversarial-review 代码模式，复用同一份冻结真值）**：

> 本 skill 便宜、能高频跑，定位本身就诱导"默认都走它"。所以"是否该升档"**不是事后自觉，而是运行前的强制筛查门**——证明出来、不是宣称。逐项筛查（本清单已内联于此，不外链）：

| 筛查维度 | 命中即升档 |
|---|---|
| 死亡线 / 钱权数据 / 不可逆 / 对外契约 / 上线安全 | 命中任一 → 升 adversarial-review |
| **逻辑复杂度**（与死亡线正交的一条） | 实现含**并发 / 状态机 / 边界密集逻辑，且冻结规格未下沉到逻辑级**（多数情况如此——实现细节属代码自由范围） → 升 adversarial-review |

> 项目补丁缺失死亡线定义时，用通用兜底：钱、权、数据、不可逆迁移、对外契约、上线安全（§11）。筛查依据要写进评审记录，否则等于没筛。

---

## 2. 三个角色（厘清"谁有背景、谁有护短风险、谁担台账"）

链路里代码由 sonnet 写、评审由 codex 跑、收口由主线程编排者做——三者不是同一个，必须拆清，否则"上下文优势"和"护短嫌疑"会落错人：

| 角色 | 是谁 | 调用 | 默认模型 |
|---|---|---|---|
| **施工作者** | goal 或施工会话（照冻结规格写代码） | — | — |
| **评审者** | codex / GPT-5.5（唯一调用路径） | codex exec | `gpt-5.5` xhigh（降级 medium） |
| **分流责任人** | 当前主线程编排者（触发本 skill、做分流的人） | 主线程本人，**无独立模型** | — |

> **分流责任人 = 主线程本人，无独立模型、不可降级。** 它常常**就是或紧邻施工作者**，所以"作者裁自己代码评审"的护短风险真实存在——§5 的证据纪律全部为对冲它而设。只有分流责任人担**台账义务**，且不默认等于原作者（若编排者另起会话，护短色彩减弱但纪律不松）。

成本提示：默认 gpt-5.5 xhigh 质量最高也最慢（评审常 60–180s，大 diff 更久）。日常快速过一遍可降 medium。

---

## 3. 输入包 ★本 skill 的成败所在

方法论**复用** `adversarial-review` §3（RAM 框架：R 谁读 / A 干什么 / M 最小充分集；评审对象原样内嵌不压缩）。相对对抗评审有实质变化，全部为堵"把已拍板做法当 bug"而设。打包前先过 §3.1 前置门，再按 §3.2 打包。

### 3.1 评审前置门（不满足不得跑本 skill）

冻结真值是"标准答案"，但**答案本身必须先被验明完整、最新、可引用**，否则评审建在沙上——拿过期规格/半成品决策评新代码，会把"按新决策改对的地方"报成"违反旧决策"。逐项确认：

| 前置项 | 要求 |
|---|---|
| 规格状态 | 七层规格已在施工前冻结；正式 L7 有 `spec_hash` 与 `assertion_index` |
| 物化状态 | 规格物化覆盖报告机器检查全绿，`SD → 正式规格 → AC` 闭环且 `known_in_scope_debt = []` |
| **输入新鲜度** | 覆盖报告中的哈希与当前冻结件一致；轻量设计/章程与正式规格无未处理冲突 |
| **goal 飞行决策日志** | 带上 goal 执行期**每一条自愈留痕**（时间 / 类别 / 改了什么 / 依据哪份冻结真值）——**这是"已批准的合法偏离"清单**。不给它，goal 按章程授权做的合法自愈会被整片报成"范围蔓延 / 违反规格" |
| 升档筛查 | §1 升档硬门已筛查，未命中或已升档 |

### 3.2 打包清单

```
□ 评审对象（必填）
  - 代码 diff，原样内嵌，带文件路径 + 行号
  - 工作区真实状态：git status --porcelain + 变更统计 + 未跟踪/删除文件清单 + 关键新增文件最终快照
    （只给 git diff 会漏掉 staged/untracked/新增文件——而新增文件正是范围蔓延最该看的对象）
  - 承重上下文（触发式，见下）
  - 体量逃生口：过大撑爆 prompt 时改"最小必读清单"钉死对象，注明"对象过大，以引用方式钉定"

□ 承重上下文（触发式，非主观裁剪）
  - 不靠打包者主观挑"必需的周边"（作者盲区 = 漏给的上下文，与影响面勘察防的"伪全集"同构）
  - 改触发式：被改文件命中【承重面 / 跨域入口 / 数据结构 / 配置 / 迁移 / 外部契约】时，用类型系统/调用图拉全
    被改方法的直接调用方-被调方，带对应消费类别证据或明确"未知处置"
  - 内嵌为锚定对象；项目根可按需补读（§7 的 -C）；告知评审者"凡判正确性所需上下文若未内嵌，自行补读并在意见里标注所依据的上下文"

□ 已冻结真值（必填——射程边界的依据）
  - **冻结的七层规格**（当前版）：契约面 / 表结构 / 架构骨架与核心链路——**这是"标准答案"的主体**
  - **规格物化覆盖报告**：`design_index_hash` / `spec_hash` / L1-L7 状态 / `SD → 正式规格 → AC` 双向索引
  - **轻量设计方案**：只作 `SD-x/DP-x` 的理由与影响面追溯，不取得规范裁决权
  - **goal 章程**（当前版）：本次目标 / 里程碑切片 / 权限边界 / 文档动作清单
  - 设计追溯索引（见 §3.4）：供意见定位 `SD-x/DP-x`，最终判错必须同时指向正式规格
  - 皆缺且无退化基线（§3.3）→ 按 §1 不用本 skill

□ 验证转录（必填——最硬的客观证据）
  - 已跑的编译/测试/lint/红线机检命令、结果、失败日志摘要、未跑项及原因
  - 未验证项单独列为风险（喂给 §4 的"证据类型=实测失败"）

□ 验收条件 / L7 测试义务清单（必填）
  - lightweight-design §4.1 六要素画像的 ⑥「怎么验证」产出的验收条件+观测信号，是评判"测试覆盖"的标准答案
  - 拿不到 → "测试覆盖"移出射程内（最多判 B，不可判 A）

□ 工程红线原文（必填）
  - 从 AGENTS.md 摘出适用条款，内嵌原文（不写"参考 AGENTS.md"）+ 项目补丁的红线机检命令

□ 真值指针（如有）：规格已引用的契约层/持久化层文档摘要

□ 射程切分声明（必填——§3.5）

□ 输出文件路径
  - 默认用项目补丁声明的任务目录 + 固定命名（与轻量设计/章程同目录，§11）
  - 仅在无法推导或路径冲突时才问用户——不要每次拿低价值路径问题打断链路

□ scratch 隔离：复用 adversarial-review §3.2 派生（mktemp）作并发安全保险；但单评审可直接 -o 到最终报告路径，省报告中转（§7）
```

### 3.3 入口 B 退化形态（无决策表的合法施工）

存在一类合法施工：任务经风险筛查证明**无事故级决策**，因而没走轻量设计、**决策表为空**（有冻结规格、有代码）。这恰恰是评审者最没背景、最易误判的一类，**不能因决策表缺失就拒评**。退化处理：

- 以 **正式 L1–L7 + 规格物化覆盖报告 + goal 章程**作为完整评审基线；轻量设计缺失不影响正式规格地位；
- 射程外区 = "章程明确声明的不改项 / 已知豁免 / 已声明取舍"；
- 其余机制（证据闸、三级分类、分流）不变。

### 3.4 设计追溯索引（不是平行真值）

§5 的证据纪律要求"指到冻结条目"，但上游 lightweight-design 产出的是六要素清算/风险扫描/负面清单/架构归属/假设台账，**不保证有现成的编号表**。打包时定义一层抽取规则：

> 直接复用规格物化覆盖报告的 `SD-x → formal_spec_refs → AC-x`，并附 `DP-x` 理由。A 类判错必须指出正式规格或红线；只指轻量设计不能判 A。若 SD 与正式落点语义不同，标“物化失效·返闸”，不得自动选边。

### 3.5 射程切分声明（决定评审会不会"改错对的"）

| 区 | 范围 | 评审者能做什么 |
|---|---|---|
| **射程内**（可判错） | 实现正确性、是否照冻结规格施工、是否违反已拍板决策、红线、影响面、范围蔓延、**测试断言是否覆盖冻结用例的每个 `AC-x`、有没有被削弱** | 可判为缺陷（A 类，但须带证据，见 §4） |
| **射程外·偏好型**（只可提示） | 已拍板的**偏好型**业务/架构取舍本身 | 只能进 C 类，不算缺陷、不构成改码建议 |
| **射程外·冲突型**（必须报告） | 已拍板取舍**与红线 / 正式真值 / 当前代码事实冲突**，或冻结规格**不可实现 / 自相矛盾** | 必须报告并标"**回炉阻塞**"——不是"仅供参考"，是要停下来 |

> 关键纪律给评审者：偏好型取舍是上游多轮讨论拍板的，你查"实现有没有忠实落实"，不质疑取舍本身；但你**必须**报告"取舍与红线/真值冲突""冻结规格不可实现/自相矛盾"——这类不在压制之列，标回炉阻塞。**别因为"不要误报"就把真矛盾也压成 B/C。**
>
> **另一条同等重要的纪律**：飞行日志里已留痕的自愈**不是缺陷**——它们是章程授权范围内的合法动作。你要核的是"这条自愈有没有超出章程授权 / 有没有改变业务语义"，不是"它为什么没照原样写"。

发包前两条快速校验：(1) 有没有与评审无关的内容（聊天记录、历史上下文）→ 删；(2) 有没有漏掉这轮明确的范围/重点 → 补。

---

## 4. 评审者 prompt 模板

主线程把 §3 输入包配上下面的角色设定发给 codex（§7 调用）。

```
你是一个尖锐、不留情面的代码评审者。代码已经写完，你的任务是对照"已冻结的真值"（正式 L1-L7 + 规格物化覆盖报告 + goal 章程 + 工程红线）核验实现偏差。轻量设计只用于解释 SD/DP，不得覆盖正式规格。

【最重要的纪律——射程切分】
覆盖报告里的每个 SD 都必须落到正式规格。你的职责是检查"代码有没有忠实落实正式规格"，不是重裁偏好型取舍。
- 射程内（你可以判为缺陷）：实现正确性、是否照冻结规格施工、是否违反已拍板决策、是否违反红线、影响面是否漏改、是否范围蔓延、测试断言是否覆盖冻结用例的每个 AC 编号且未被削弱（按下方给你的冻结用例规格，不是按你想象的标准）。
- 射程外·偏好型（只能提示，进 C 类）：已拍板的偏好型取舍本身，你若不认同也不算缺陷。
- 射程外·冲突型（你必须报告，标"回炉阻塞"）：已拍板取舍与红线/正式真值/当前代码事实冲突，或冻结规格不可实现/自相矛盾。这类不在压制之列——别因为"不要误报"就把真矛盾压成 B/C。
- 飞行日志里已留痕的自愈动作**不是缺陷**（那是章程授权的合法偏离）；只有"超出章程授权"或"改变了业务语义"才判缺陷。

把刻意的、已拍板且已物化的做法误报成 A 类缺陷是本次评审最严重的失败。证据责任在"判缺陷"这一侧：你说它是缺陷，就得拿出证据（违反了哪个正式规格锚点/红线，或客观可验证证据）。拿不出 → 标 B（存疑）或 C，不要塞进 A。

【评审规则】
1. 每个意见必须具体——指到 file:line
2. 每个 A 类意见必须填"违反了什么"：①正式规格锚点/红线第X条；或②客观可验证证据。DP/SD 可作追溯，但不能替代正式规格锚点。两者都给不出 → 不许进 A 类
3. 每个意见标"严重度"（高/中/低）和"证据类型"（实测失败/文本违反/逻辑反例/推断风险）
4. 给修正方向，不是完整替代实现
5. 数量不限，但每条都要是实质问题；结尾必须做"覆盖面声明"：逐项说明你是否已覆盖各射程内维度（正确性/红线/影响面/测试），覆盖了而结论少是正常的

【输出格式】
## 代码评审报告
### 总体结论
[照图施工是否达标；A 类高严重度几条；一句话判断]
### A 类·缺陷（违反真值或有客观证据，须改）
#### A-1：[标题]  严重度:高/中/低  证据类型:实测失败/文本违反/逻辑反例
- 位置：file:line
- 违反了什么：[DP-X / 红线第X条 / 客观证据(贴出反例或失败日志)]——A 类此项必填，给不出请改标 B/C
- 问题 + 后果：
- 修正方向：
### B 类·存疑（你吃不准是否符合意图，可能因背景不全）
#### B-1：[标题]  严重度:..  证据类型:推断风险
- 位置 / 疑点 / 不确定的原因（缺哪段背景）
### C 类·对已决策的异议
#### C-1：[标题]  类型:偏好型异议 / 冲突型(返闸阻塞)
- 针对哪个已拍板决策(DP-X) / 异议 / [若冲突型：与哪条红线或正式真值冲突]
### 覆盖面声明
- 正确性[已覆盖/未覆盖]、红线[..]、影响面[..]、测试[..]

每一类没有内容就写"无"。

---
【工程红线】[原文 + 机检命令] 【验收条件/L7测试义务】[...] 【验证转录】[已跑命令与结果]
【真值指针】[契约/持久化层摘要] 【最小必读】[对象与冻结真值已内嵌；可自行补读并标注依据]
【复评专用·上一轮分流台账】[仅复评轮填：已驳回项+所指条目，指示勿重报已裁定项]

=== 已冻结真值·七层规格（契约/表结构/架构骨架与核心链路）===
[规格原文]

=== 规格物化覆盖报告（SD-x → 正式规格 → AC-x）===
[覆盖报告原文]

=== 设计理由追溯·轻量设计（非平行真值）===
[SD/DP 与理由]

=== 已冻结真值·用例规格（spec_hash / AC-x）===
[用例规格原文]

=== 已冻结真值·goal 章程（目标/边界/切片）===
[章程原文]

=== 已批准的合法偏离·goal 飞行决策日志 ===
[飞行日志原文，没有则"无"]
=== 设计追溯索引 ===
[SD/DP → 正式规格锚点]
=== 评审对象·代码 diff + 工作区状态 + 承重上下文 ===
[原样内嵌]
```

---

## 5. 分流裁定 ★替代裁判席的收口（核心防线）

评审报告收齐后，分流责任人逐条分流。**默认方向 = 不改除非已证实是缺陷**——证据责任压在"改"这一侧。这一步把评审者输出收敛成"实际改什么"，堵住"盲目照改把对的改错"。

### 5.1 可改通道的统一证据闸（对称闸）

> 旧设计的致命不对称：B 类驳回要证据，A 类照改零证据——而最危险的误报恰恰是评审者不知道那是决策、理直气壮标 A。现在**进入"可改"通道的前提对所有类一视同仁**：

**任何意见要进入"改"通道，必须能指到下列任一**：

1. **被违反的冻结条目**（规格 §X / 决策表 DP-X / 用例 AC-X / 章程 §X / 红线第 X 条）——分流责任人须核验该条目**确实存在且确实被违反**，不是贴个沾边编号；
2. **客观可验证证据**（可复现反例 / 测试失败 / 不变量违反 / 编译错误）。

二者皆无的纯主观"看着不对" → **上浮，不改**。"纯逻辑错"A 类若拿不出第 2 项客观证据，降为 B/C，不得直接改。

### 5.2 三级分流处置

| 类 | 含义 | 处置 |
|---|---|---|
| **A·缺陷** | 已带证据（5.1 二选一） | 核验证据成立 → **改**；核验不成立（条目不存在/未真被违反/无客观证据）→ 降 B 或 C |
| **B·存疑** | 评审者吃不准 | 对照冻结真值裁定：能指到条目/客观证据 → 转可改通道；指不到 → **上浮，不改**（不再"确属隐患就转 A 改"——举证责任倒置） |
| **C·偏好型异议** | 对偏好取舍不认同 | **不改码**，上浮用户待裁 |
| **C·冲突型** | 取舍与红线/真值冲突、冻结规格不可实现 | **回炉阻塞**，暂停交付，按 §6 回炉 |

### 5.3 反护短纪律（分流责任人=作者本人，靠纪律对冲）

每个分流动作都**留台账证据**，不止 B 驳回：

1. **A 类采纳**：写明违反哪条真值或哪个可复现实例（核验过程入台账）。
2. **A→C 降级**：须指冻结条目证明确属已拍板取舍，**自证不了不许降级**（防真缺陷被洗成"对决策的异议"逃避修改）。
3. **驳回**：要求"**条目内容与意见的具体对应关系**"，不止指编号（防宽泛条目驳一大片）。
4. **任何重分类**：进台账。
5. **上浮台账**采用可批量速览形态，便于用户廉价复核驳回理由（不让问题淹没在"已驳回"里默认通过）。
6. **触承重面 / 上游决策的 A/B 处置**：强制走一次**非分流责任人确认**（与 §6 返闸/§1 升档接线）——这是闭环内唯一的外部校验点，不能省。

分流责任人产出一份**分流台账**：每条意见 → 去向（改 / 上浮 / 返闸 / 驳回+对应条目），逐条有据，不许某条被悄悄忽略。

---

## 6. 复评循环（防无限套 + 返闸出口）

> **术语（本节起全文一致）**：**返闸** = 机制——把一条意见移出本评审循环、上推给上游处理；**回炉** = 返闸去向里的**例外档**，特指"退回设计步 → 修设计 → 修用例 → 重写章程 → 重跑"；返闸上游的**默认去向是热修**——附修改方案经用户一次批准后修订设计/用例并回原执行续跑（goal-charter §4）。二者不是同义词：返闸是动作，回炉/热修是终点。下表三档给出全部去向。

A 类改完、B 转可改改完后：

- **复评范围 = 新改动 + 重新拉取的受影响承重上下文 + 相关验证结果**，不机械限制为被改行——A 类修复可能改了被调方签名/状态流/数据兼容，只看 diff 看不到连带回归（轻量设计 §7.1 影响面勘察反复防的"漏改消费方"在复评阶段同样适用）。
- **复评 prompt 必带上一轮分流台账**（已驳回项 + 所指条目），指示评审者勿重报已裁定项——codex 每轮是无记忆新进程，不回灌台账它必按同一缺背景逻辑反复刷同类误报、吃掉轮次上限、淹没真问题（人工给无状态评审者补"裁判席的记忆"）。
- **收敛终态定义**（达成即结束）：A 类全部关闭或转返闸；B 类全部有去向（驳回有证据 / 转可改 / 上浮）；C 类全部有用户裁决去向。否则为未收敛。
- **本地轮次上限 2 轮**；两轮未收敛 → 报告用户，由用户决定继续还是收手。
- **返闸优先于复评，且不旁路计数**：触承重面/上游决策的意见不在本循环消化，按下方返闸。返闸返回 = **新评审任务、本地计数重置**，但**任务级登记累计返闸次数并设上限**——防"评审→返闸→重裁→施工→评审"无限循环把"防无限套"架空。

**出口完整三档**（不是两极——中间档最容易被砍掉，砍了就只剩"删掉它"或"惊动用户重裁"两个极端）：

| 偏离类型 | 出口 |
|---|---|
| 不改真值的实现偏差 | **本地修**（A 类改） |
| **章程没授权、但确实该做的合理动作**（新增文件 / 新增切片 / 未预见的工程动作） | **补章程授权 + 记飞行日志**（中间档——既不当 A 类删掉，也不上推到设计层重裁）。<br>**这不是缺陷，是章程写漏了**——正是红队 B 问（必卡路径）该在开工前抓出来的那类。 |
| 触及上游已批准决策 / 承重契约面 / 冻结规格本身错了 | **返闸上游**：默认热修——附修改方案经业务决策负责人按项目治理批准后修订设计/用例并回原执行续跑；热修不可靠且获相应批准才回炉（退回设计步重来） |

```
评审 → 分流（不改除非已证实）→ A/B转可改 改 → 触承重面/上游决策/规格错了？
                                              ├ 是 → 回炉（出本循环，退回设计步）
                                              ├ 章程漏授权 → 补授权 + 记日志，继续
                                              └ 否 → 复评(改动+受影响承重上下文+验证, 带上轮台账, ≤2轮) → 收敛终态 → 结束
```

> **中间档存在的意义**：没有它，「章程漏写了一条授权」只能二选一——要么把合理的新增当范围蔓延删掉（做错事），要么上推到设计层重裁（惊动用户、卡住流程）。**两个都是错的。**

---

## 7. 调用命令（codex exec）

复用 `adversarial-review` §5.2 的 codex 机制（`-C` 工作目录、沙箱审批、stdin 重定向、后台读取），**单评审、无并行**，故简化报告中转：

```bash
# scratch 仍派生（adversarial-review §3.2 同款，作并发安全保险），但单评审可直接 -o 到最终报告路径
SCRATCH='<本轮派生的 SCRATCH 字面值>'
ABS_REPORT='<§3.2 推导的最终报告路径>'

# 评审代码 → -C 指向被评审项目根（让 codex 可补读周边、读到 AGENTS.md 工程规约）
CODEX_CWD="$(git rev-parse --show-toplevel 2>/dev/null || echo /tmp)"

cat > "$SCRATCH/codex-prompt.txt" << 'PROMPT_EOF'
[§4 制好的 prompt，含内嵌冻结真值与评审对象；复评轮追加上一轮分流台账]
PROMPT_EOF

# 后台调用；-o 直接写最终报告路径（单评审无并发串台，省去 scratch 中转）；< /dev/null 必须加，否则 stdin 是管道会永久阻塞
codex exec \
  -m gpt-5.5 \
  -c 'approval_policy="never"' \
  -s read-only \
  -C "$CODEX_CWD" \
  --skip-git-repo-check \
  --ephemeral \
  -o "$ABS_REPORT" \
  "$(cat "$SCRATCH/codex-prompt.txt")" \
  < /dev/null \
  > "$SCRATCH/codex-log.txt" 2>&1
```

- 用当前运行时的后台命令或长会话机制发起，并记录进程状态。
- `-s read-only`：只读任务，物理上写不了被评审工作区；**禁止** `--dangerously-bypass-approvals-and-sandbox`。
- 默认 gpt-5.5 xhigh；降级加 `-c 'model_reasoning_effort="medium"'`。
- 进程退出后再起 Bash `cat "$ABS_REPORT"` 读结果；日志在 `$SCRATCH/codex-log.txt`。
- **并发例外**：用户确在并发跑多个 codex-review 任务时，回退 adversarial-review §3.2 的 scratch 中转（codex -o 到 `$SCRATCH/codex-out.txt`，再转写 ABS_REPORT），避免同名报告互相覆盖。

---

## 8. 失败降级

| 失败场景 | 降级 |
|---|---|
| codex 超时（>30min）/ 调用失败 | 重试一次。仍失败 → 报告用户本轮未产出，不伪造结论 |
| 评审产出意见偏少 | **不默认告警**（核验语境"少=可能很干净"，非"少=漏检"）。改看**覆盖面声明**：评审者声明已覆盖各射程内维度而结论少 → 正常；**未做覆盖面声明** → 才告警，建议人工补看或升 adversarial-review |
| 评审把射程外偏好取舍误塞进 A 类 | 分流时按 §5.1 核验"违反了什么"——指不到条目/无客观证据 → 降 C，不照改（这正是 §5 对称闸要拦的） |
| 返回空响应 | 检查 prompt 歧义/信息缺口，修正后重试；仍空报告用户 |
| 输出路径无法推导且冲突 | 问用户拿路径 |

**核心原则**：评审是辅助核验、不是真值裁决者。它的输出永远过分流；默认方向是"不改除非已证实"，宁可漏报让人补看，不可让误报直接改码。

---

## 9. 分流责任人验收清单

```
□ 输出报告存在且非空（mtime 在本轮之后）
□ 报告含 A/B/C 三级分类 + 覆盖面声明（每类有内容或明写"无"）
□ 每条 A 类都带"违反了什么"（冻结条目或客观证据），无证据的 A 已按 §5.1 降级
□ 每条意见有严重度 + 证据类型；高严重度项已优先处理或返闸
□ 分流台账完整：每条意见有去向（改 / 上浮 / 返闸 / 驳回+对应条目），无意见被悄悄忽略
□ 进"改"通道的每条都核验过证据成立（条目确实被违反 / 客观证据确凿）
□ A→C 降级都指到了冻结条目证据；驳回都给了"条目内容↔意见"对应关系，不止编号
□ C 冲突型、裁不动的 B、触承重面/上游决策项已上浮用户或走返闸；触承重面的 A/B 已走非分流责任人确认
□ 上浮台账是可批量速览形态
□ 无越界写入：报告写到指定路径，scratch 产物归本轮；repo 内无意外改动（git status --porcelain）
□ 向用户报告：评审完成 + 报告路径 + A类N条(高M/已改K) / B类(转改/上浮) / C类(偏好上浮/冲突返闸) + 累计返闸次数
```

---

## 10. 与上下游的关系

- **上游 = 冻结的七层规格**：评的代码就是照规格施工的产物。规格在施工前一次冻完（`doc-layer-system` §5.0：**把代码全删了能照文档重做**），它就是标准答案。
- **上游 = 规格物化覆盖报告**：证明轻量设计已完整进入正式 L1–L7；报告是追溯与准入证据，不承载业务规格。
- **上游 = lightweight-design**：仅提供 `SD/DP` 理由和影响面追溯。本 skill 不重裁已物化决策，也不允许它覆盖正式规格。
- **上游 = test-case-design**：冻结用例规格（`spec_hash` + `assertion_index`）是**验收条件的唯一来源**。核"测试覆盖"时按 `AC-x` 逐个对账——**不按评审者想象的标准**。
- **上游 = goal-charter**：章程给出本次的目标 / 权限边界 / 切片。**计划符合性对账以「测试验证器 + 飞行决策日志」为权威**——测试全绿且断言未被削弱 = 计划已落实；飞行日志 = 已批准的合法偏离清单。**本 skill 不另立平行对账台账**，自身只就"实现正确性"做判断。
- **生命周期咬合**：飞行日志与章程随任务归档。codex-review 用户手动触发，**应在任务归档前跑**；若在归档后才触发，须从已归档产物恢复基线并标注"基线可能已偏离当前真值"（否则 §3 的冻结真值来源落空）。
- **平级 = adversarial-review**：方法论同源（RAM 框架、codex 调用、scratch 隔离、驳回留痕的证据纪律），但分工——对抗评审开工前评设计 / 用例 / 章程，或评高风险代码；本 skill 开工后做低中风险符合性核验（§0）。§1 升档硬门命中即升 adversarial-review。
- **不在 goal 循环内**：goal 内部的审核只能是 loop 闭环内的 AI 自审 + 机器检查器。本 skill 是**用户手动触发的事后核验**，引入的是 loop 外视角——这在"用户主动要第二双眼睛"时是价值，塞进 goal 里就是噪音。
- **下游 = 修完收口**：评审收敛、代码定稿。**没有"回补正式真值层"这一步**——规格已在施工前冻结；若核验证明规格本身错了，走 §6 返闸上游（默认热修，经业务决策负责人按项目治理批准后修订规格；不可靠才回炉），不是私自反写规格。

---

## 11. 项目补丁挂载点

以下由各项目的项目级补丁声明：

| 挂载项 | 内容 |
|---|---|
| 存放路径 | 评审报告与分流台账的落盘目录 + 命名规则（与任务的轻量设计/章程同目录，供 §3.2 输出路径默认推导） |
| 死亡线 / 升档筛查清单 | §1 升档硬门的项目死亡线定义；缺失时的通用兜底（钱/权/数据/不可逆迁移/对外契约/上线安全） |
| 红线机检命令 | §3 入包的项目红线原文 + 可执行机检命令 |
| 承重契约面枚举 | §3.2 承重上下文触发判定、§5/§6 返闸判定里"承重契约面"的项目真实形态（HTTP/RPC/Facade 签名、跨域 DTO、DB 表/字段、配置 key 等） |
| 设计追溯索引来源 | §3.4 在本项目的覆盖报告位置、`SD/DP` 编号约定与正式规格锚点；轻量设计只提供理由追溯 |
| 验证基建 | §3.2 验证转录依赖的项目编译/测试/lint/机检命令 |
| 验收条件来源 | §3.2 验收条件/L7 测试义务在本项目的存放位置 |
| 契约/持久化层指针 | §3 真值指针对应的项目契约层文档（接口契约、表结构）位置 |