BackToCimaCoppi 代码评审（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（低中风险符合性核验） |
| 时机 | 开工前（真值待定，找最优） | 开工后（真值已定，查偏差） |
| 真值状态 | 待定——正在探索方案空间 | 已冻结——规格 + 决策表 + 用例已拍板 |
| 模型编制 | 默认 Fable 5 + GPT-5.6-Sol 双席对抗（可点选更多） | GPT-5.5 一席，无对抗 |
| 收口者 | 当前主线程直接裁决（不设裁判） | 分流责任人（对照冻结真值分流） |
| 产出 | 采纳/驳回裁决报告 | 三级分类意见（不自动改码） |
单模型在"符合性核验"这件事上够用，但不要把它当充分代码审查：
符合性核验有标准答案（冻结规格 + 决策表 + 用例规格 + 红线就是答案），是对照答案查偏差，一个强模型够了；硬上多方对抗既贵又会把"已拍板的取舍"翻出来重吵——那正是本 skill 要堵的风险。
但代码评审里最高价值的发现常常是"答案没覆盖到的地方出了 bug"——并发竞态、边界态、错误处理、性能。这些规格通常不下沉到逻辑级（实现细节属代码自由范围），需要正交视角（adversarial-review 的强项），单模型会系统性漏检。所以本 skill 定位是低成本符合性核验，不宣称"一个强模型就够全部代码审查"；这类风险按 §1 升档。
单模型也没有裁判席兜 GPT 的误报——这个位置由分流责任人的对照真值分流（§5）补上，而分流的默认方向是"不改除非已证实"，证据责任在"改"侧。
1. 什么时候用 / 不用 + 升档硬门
用：
- goal 或施工会话写完一段代码，用户想要一道独立的实现核验。
- 改动已落地、决策已冻结，需要查"实现是否符合已拍板的图与决策"。
不用 / 改用：
| 场景 | 改用 |
|---|---|
| 还在定方案 / 设计有待探索 | 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）
□ 工程红线原文（必填）
- 从 CLAUDE.md 摘出适用条款，内嵌原文（不写"参考 CLAUDE.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。现在进入"可改"通道的前提对所有类一视同仁：
任何意见要进入"改"通道，必须能指到下列任一：
- 被违反的冻结条目（规格 §X / 决策表 DP-X / 用例 AC-X / 章程 §X / 红线第 X 条）——分流责任人须核验该条目确实存在且确实被违反，不是贴个沾边编号；
- 客观可验证证据（可复现反例 / 测试失败 / 不变量违反 / 编译错误）。
二者皆无的纯主观"看着不对" → 上浮，不改。"纯逻辑错"A 类若拿不出第 2 项客观证据，降为 B/C，不得直接改。
5.2 三级分流处置
| 类 | 含义 | 处置 |
|---|---|---|
| A·缺陷 | 已带证据（5.1 二选一） | 核验证据成立 → 改；核验不成立（条目不存在/未真被违反/无客观证据）→ 降 B 或 C |
| B·存疑 | 评审者吃不准 | 对照冻结真值裁定：能指到条目/客观证据 → 转可改通道；指不到 → 上浮，不改（不再"确属隐患就转 A 改"——举证责任倒置） |
| C·偏好型异议 | 对偏好取舍不认同 | 不改码，上浮用户待裁 |
| C·冲突型 | 取舍与红线/真值冲突、冻结规格不可实现 | 回炉阻塞，暂停交付，按 §6 回炉 |
5.3 反护短纪律（分流责任人=作者本人，靠纪律对冲）
每个分流动作都留台账证据，不止 B 驳回：
- A 类采纳：写明违反哪条真值或哪个可复现实例（核验过程入台账）。
- A→C 降级：须指冻结条目证明确属已拍板取舍，自证不了不许降级（防真缺陷被洗成"对决策的异议"逃避修改）。
- 驳回：要求"条目内容与意见的具体对应关系"，不止指编号（防宽泛条目驳一大片）。
- 任何重分类：进台账。
- 上浮台账采用可批量速览形态，便于用户廉价复核驳回理由（不让问题淹没在"已驳回"里默认通过）。
- 触承重面 / 上游决策的 A/B 处置：强制走一次非分流责任人确认（与 §6 返闸/§1 升档接线）——这是闭环内唯一的外部校验点，不能省。
分流责任人产出一份分流台账：每条意见 → 去向（改 / 上浮 / 返闸 / 驳回+对应条目），逐条有据，不许某条被悄悄忽略。
6. 复评循环（防无限套 + 返闸出口）
术语（本节起全文一致）：返闸 = 机制——把一条意见移出本评审循环、上推给上游处理；回炉 = 返闸去向里的例外档，特指"退回设计步 → 修设计 → 修用例 → 重写章程 → 重跑"；返闸上游的默认去向是热修——附修改方案经用户一次批准后修订设计/用例并回原执行续跑（goal-charter §4）。二者不是同义词：返闸是动作，回炉/热修是终点。下表三档给出全部去向。
A 类改完、B 转可改改完后：
- 复评范围 = 新改动 + 重新拉取的受影响承重上下文 + 相关验证结果，不机械限制为被改行——A 类修复可能改了被调方签名/状态流/数据兼容，只看 diff 看不到连带回归（轻量设计 §7.1 影响面勘察反复防的"漏改消费方"在复评阶段同样适用）。
- 复评 prompt 必带上一轮分流台账（已驳回项 + 所指条目），指示评审者勿重报已裁定项——codex 每轮是无记忆新进程，不回灌台账它必按同一缺背景逻辑反复刷同类误报、吃掉轮次上限、淹没真问题（人工给无状态评审者补"裁判席的记忆"）。
- 收敛终态定义（达成即结束）：A 类全部关闭或转返闸；B 类全部有去向（驳回有证据 / 转可改 / 上浮）；C 类全部有用户裁决去向。否则为未收敛。
- 本地轮次上限 2 轮；两轮未收敛 → 报告用户，由用户决定继续还是收手。
- 返闸优先于复评，且不旁路计数：触承重面/上游决策的意见不在本循环消化，按下方返闸。返闸返回 = 新评审任务、本地计数重置，但任务级登记累计返闸次数并设上限——防"评审→返闸→重裁→施工→评审"无限循环把"防无限套"架空。
出口完整三档（不是两极——中间档最容易被砍掉，砍了就只剩"删掉它"或"惊动用户重裁"两个极端）：
| 偏离类型 | 出口 |
|---|---|
| 不改真值的实现偏差 | 本地修（A 类改） |
| 章程没授权、但确实该做的合理动作（新增文件 / 新增切片 / 未预见的工程动作） | 补章程授权 + 记飞行日志（中间档——既不当 A 类删掉，也不上推到设计层重裁）。这不是缺陷，是章程写漏了——正是红队 B 问（必卡路径）该在开工前抓出来的那类。 |
| 触及上游已批准决策 / 承重契约面 / 冻结规格本身错了 | 返闸上游：默认热修——附修改方案经业务决策负责人按项目治理批准后修订设计/用例并回原执行续跑；热修不可靠且获相应批准才回炉（退回设计步重来） |
评审 → 分流（不改除非已证实）→ A/B转可改 改 → 触承重面/上游决策/规格错了？
├ 是 → 回炉（出本循环，退回设计步）
├ 章程漏授权 → 补授权 + 记日志，继续
└ 否 → 复评(改动+受影响承重上下文+验证, 带上轮台账, ≤2轮) → 收敛终态 → 结束
中间档存在的意义：没有它，「章程漏写了一条授权」只能二选一——要么把合理的新增当范围蔓延删掉（做错事），要么上推到设计层重裁（惊动用户、卡住流程）。两个都是错的。
7. 调用命令（codex exec）
复用 adversarial-review §5.2 的 codex 机制（-C 工作目录、沙箱审批、stdin 重定向、后台读取），单评审、无并行，故简化报告中转：
# scratch 仍派生（adversarial-review §3.2 同款，作并发安全保险），但单评审可直接 -o 到最终报告路径
SCRATCH='<本轮派生的 SCRATCH 字面值>'
ABS_REPORT='<§3.2 推导的最终报告路径>'
# 评审代码 → -C 指向被评审项目根（让 codex 可补读周边、读到 AGENTS.md/CLAUDE.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
- 用 Bash 工具
run_in_background: true发起（评审可能超 10 分钟，前台 Bash 上限 10 分钟容不下）。 -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 真值指针对应的项目契约层文档（接口契约、表结构）位置 |