# ops 独立审查 —— 回审轮数预算

建立：2026-09-29 · 状态：已生效（四份规则副本逐字同步）· 异族审查：kimi 两轮通过

---

## 0. TL;DR

把原条款「**本轮新发现的 P0 → 计数重置，不受上限约束**」换成**两层硬预算**：

- ① 完整审查 ≤2 轮（首审计入此层）
- ② 增量回审 ≤3 轮

到顶仍有未闭环 P0 → **不假装收敛**，一页交 chief 仲裁；不得再自动开新轮。
另加**禁 relitigate**：已闭环的点，没有新的可复跑反例输出就不许重审。

---

## 1. 为什么改（实测数据）

数据源：`~/.hermes/profiles/ops/state.db`，窗口 = 2026-09-19 ~ 09-28。

| 指标 | 首审 | 回审 |
|---|---|---|
| 派发次数 | 58 | 54 |
| 累计时长 | 466 分钟 | 588 分钟 |
| 平均单次 | 482s | 653s |
| 平均工具调用 | 45 | 58 |

三个结论：

1. **回审比首审更重**（653s/58 次 vs 482s/45 次）。§10 写了「增量复审」，实测回审的工具调用数高于首审 —— 名为增量，实为全量重跑。
2. **单主题轮数无上限**。Hermes 3.11→3.14 回滚链产生 **12 份**回审报告（同一 P0 链）；是她热力图审到 **R13**。
3. **根因是条款本身**。原「计数重置」= 只要本轮又发现新 P0 就重置计数、不受上限约束。在判据密集的改动上（每条新 P0 常有后代）必然触发 ⇒ 变相无上限。

单步响应时间在这十天**没有变慢**（9/15-9/18 为 5.5/7.1/6.7/6.7 秒，9/20 后为 4.6/4.7/4.1/3.6/5.3/4.5/5.5 秒）。慢的是**轮数**与**派发频次**，不是单步。

---

## 2. 新条款（四份副本逐字同步）

### 2.1 两层预算

**两层独立计数、任一层到顶即停，不因新发现 P0 而重置。**

- ① **完整审查 ≤2 轮**（**首审计入此层**，原条款保留）
- ② **增量回审 ≤3 轮**

### 2.2 「链」的可判定口径（关键，防拆链绕过）

> **链 = 同一批冻结清单（同一回滚点）下的全部 P0 及其后代。**
> 跨批 = 新链、各自计数。
> **禁止按单个 P0 编号拆链。**

为什么必须写这句：如果不定义「链」，读法 B（链 = 单个 P0 编号）也合文义 —— 每轮出现新编号就开新链、各享 3 轮，预算一轮都拦不住。实测该读法下 3.11→3.14 那批 12 份报告可拆成 ≥4 个链，无一轮被拦，等于旧「计数重置」原样复现。

### 2.3 到顶处置（三件套，缺一即为静默失败）

到顶仍有未闭环 P0 时：

1. **不假装收敛**（claudex-loop 原文：*present unresolved findings instead of manufacturing convergence*）
2. 把**未决项 + 己方立场 + 每轮反例输出**整理成**一页**交 **chief 仲裁**
3. **同时在 `UNREVIEWED.tsv` 开一行 `blocked`**（含复核期限 + 触发条件）—— 无登记 = 无追踪 = 未闭环 P0 蒸发

**chief 裁决书必须显式写出**：

- ① 接受 / 驳回
- ② **授权追加的验证轮数 N**（该 N 轮**从预算豁免、单列计数**）

未裁决前**不开新轮**。**继续修允许，继续以「回审」名义开轮不允许**（除非裁决书显式授权）。
（第 ② 条是为了堵一个洞：真 P0 在第 4 轮才发现时，如果只允许「修」不允许「验证」，那个 P0 就永远无法闭环。）

### 2.4 禁 relitigate

**已判闭环的点在新一轮不再重审，除非提出新证据。**
**新证据 = 新的可复跑反例输出** —— 不是重读一遍代码，不是换个措辞重述原疑点。

### 2.5 回审任务书固定模板（2026-09-29 起）

**禁止写「复核 P0/P1/P2 修复」这类全量措辞** —— 它会让 ops 重读全量。

任务书**只写三项**：

1. diff
2. 指定反例的运行输出
3. 改动所在判据链的相邻判据

**硬前置** = 实现方已跑的反例复跑输出（附在任务书内，不让 ops 自己造）。
**要求** = 逐条判定反例是否被覆盖 + 有新 P0 附可执行反例 + 正文 ≤6KB（P2 一行）。

实测依据：新措辞 **11 次**工具调用 / 2.8 分钟 vs 旧措辞 **57.9 次** / 10.7 分钟（**1 : 5.3**）。脚本见 §4 的 `counterfactual-task-template.sh`。

---

## 3. 落点与冻结值

| # | 文件 | 角色 | 2026-09-29 收工 md5 |
|---|---|---|---|
| ① | `/home/ubuntu/AGENTS.md` §10 | 母本 | `d5df8d67` |
| ② | `~/.hermes/profiles/ops/skills/devops/ops-independent-review/SKILL.md` | 真正驱动 ops 写报告 | `8f27e317` |
| ③ | `~/.hermes/skills/infrastructure/task-channel-routing/SKILL.md` | 派发路由口径 | `f975f38b` |
| ④ | `~/.hermes/skills/infrastructure/multi-profile-workflow/SKILL.md` | 三 profile 协作流程 | `c3947374` |

**四份必须逐关键词一致。**校验口径（母本 11 词，逐项 ≥1，不看总数）：
`相邻判据 / 反事实 / 复核期限 / 无人值守消费者 / 计数重置 / UNREVIEWED / sha256 / 受保护 / 副本清单 / 运行时读取 / 注释不算`

注意「词在 ≠ 规则在」：逐项还要读该词所在句子，确认它带的是规则而不是名单。
本批里「计数重置」这个词**保留在词表中**，但语义由「生效」改为**「已废除」**。

---

## 4. 证据与复跑脚本

全部在 `~/.hermes/backups/ops-retest-budget-20260929-0920/`：

| 文件 | 作用 | 复跑 |
|---|---|---|
| `verify-11words.sh` | 11 词母本校验 + 变异体自证 | `bash verify-11words.sh` |
| `counterfactual.sh` | 政策轨硬前置：真实历史案例跑新旧规则 | `bash counterfactual.sh` |
| `reverse-p01-chain.sh` | P0-1 自证：拆链读法下预算是否失效 | `bash reverse-p01-chain.sh` |
| `evidence-11words.txt` | 四份 0 缺口；变异体（删 6 词）报 6 缺口 | — |
| `evidence-counterfactual.txt` | 3.11→3.14 链 12 份报告 → 新规则省 9 轮 ≈97 分钟 | — |
| `evidence-p01-chain.txt` | 拆链读法：12 份可拆 ≥4 链 ⇒ 无一轮被拦；整批 3 轮 ⇒ 拦下 9 轮 | — |
| `kimi-review.md` | 首审报告（2 P0 / 2 P1 / 1 P2） | — |
| `kimi-review-round2.md` | 增量回审（6 项反例全被覆盖，无新 P0） | — |

**变异体自证**（判校验器本身灵不灵）：删掉 6 个词后，11 词口径必须报出 6 个缺口；若只报 5 词会判「已同步」= 假绿。

---

## 5. 审查记录（kimi 异族，两轮）

### 首审（2026-09-29 09:34-09:44）

| 级别 | 发现 | 修法 |
|---|---|---|
| P0-1 | 「链」未定义 ⇒ 可拆链绕过，预算形同虚设 | 加链的可判定口径 + 明禁按编号拆链 |
| P0-2a | 四副本层数不一致（① 三层 vs ②③④ 两层） | ① 改两层，与 ②③④ 对齐 |
| P0-2b | ① 内部矛盾（「首审 1 轮」与「完整审查 ≤2 轮」冲突，事实废掉后者） | 删「首审 1 轮」层，明确「首审计入完整审查层」 |
| P1-1 | chief 仲裁通道无追踪要求 ⇒ 未闭环 P0 可蒸发 | 加「同时在 UNREVIEWED.tsv 开 blocked 行」 |
| P1-2 | 真 P0 晚发现时修允许、验证被禁 ⇒ 无法闭环 | 加「裁决书须显式授权验证轮数 N，N 从预算豁免」 |
| P2 | ④ 中「59 次回审」笔误（应为 54） | 已改 |

### 增量回审（第 2 轮）

冻结核对一致；**6 项反例全部被覆盖，无新 P0** ⇒ 台账标 `reviewed`。
新增 2 个 P2（证据脚本一处算术自洽 + ④ 措辞补「除非裁决授权」），已顺手修。

### 实现方在本批中的流程违规（记录在案）

派审后改了冻结清单内的文件（AGENTS.md）—— 违反「审查期硬冻结」。两次写入均走 patch + 系统审批通过（不是 terminal 绕闸），但流程错了：正确做法是先 kill 审查、改完重派。
已补一条规则进 ④：**派审前先冻结 —— 批内文件必须已落地且本轮不会再改；等审批的文件要么先落地再派、要么从冻结清单剔除并注明。冻结是派审的前置条件，不是事后核对项。**

---

## 5.5 收敛效果评估（2026-10-13 起）

**评估前提**（owner 判断，2026-09-29）：

> 「提高准确度的收益被繁复的过程消耗过多，收益反而不大」⇒ 必须收敛；且要评估是否**有效**收敛，没效就继续迭代。

**三项判据**（改后 ≥2 周样本）：

1. 硬规则守住：同一 P0 链**最大回审轮数 ≤3**（违反 = 机制失效）
2. 过程成本下降：ops 总时长 / 派发次数低于改前（10 天 **17.5 小时 / 129 次**）
3. **反向指标（最重要）**：没有出现「本该审到却漏掉」的 P0 —— 若出现，说明收敛过头，预算要回退

**未达标时下一根杠杆**（不是继续压轮数）：

4. **回审任务书措辞** —— **已于 2026-09-29 落地（见 §2.5）**；实测这是杠杆最大的一条（1 : 5.3）
5. **触发面执行率** —— §10 只列 5 类风险型触发，实际派发频次远高于触发面

**本日实测：一批规则改动的过程成本**（2026-09-29，主题＝回审任务书固定模板）

- 规则正文 **6 行**；审查 **3 轮**（首审 1 / 增量回审 2，预算内）
- 版本迭代 **v1 → v2 → v3**；用户手动落地 **3 次**（AGENTS.md 受保护，每次写入须人工批）
- 配套脚本 **5 个**；审出真 P0 **4 条** —— 其中 **2 条是实现方写规则时自己引入的**（数字无工件、可判定口径漏掉规则点名的原句）
- ⚠️ **异族复核 0 次**：kimi 周额度耗尽，两次派发被 `fallback_model` 静默兜底成同族（deepseek-flash），外面看不出来 —— 只有验 `sessions.model` 才发现

⇒ 这组数字本身就是「提高准确度的收益被繁复的过程消耗过多」的样本：**3 轮审查 × 3 次人工落地，换来 4 条 P0，其中 2 条是本可避免的自伤**。

---

## 6. 迭代方向（以后可能继续改）

1. **预算数字需实践检验**：2 轮 / 3 轮是照实测分布定的（claudex-loop 用 5/2/2，loop-skills 用 6），本机真 P0 少（9/21 统计：17 份报告里真 P0 只 5 条），3 轮够不够看后续数据。
2. **「链」的跨批边界**：现在按「同一批冻结清单（同一回滚点）」划链。若一个主题被硬拆成两批（各自冻结），理论上可绕开预算 —— 需观察是否真发生。
3. **chief 仲裁通道的实际响应率未验证**：chief 是 on-demand profile，若没人派它，升级会悬置。已用 UNREVIEWED.tsv 登记兜底，但首次实践要盯。
4. **回审任务书模板**：本批次发现的最直接杠杆是**任务书措辞** —— 写「复核 P0/P1/P2 修复」会让 ops 读全量；应固定为「只验 ①diff ②1 个反例 ③相邻判据」。此条尚未写进规则，属下一步。
5. **报告体量**：§10 定「正文 ≤6KB」，实测 evidence 文件常 10-19KB，reviews/ 目录已 99M（其中 93M 是单个 treemap-v6-artifacts）。属清理项，与速度无关。

---

## 7. 规则来源（MIT，可抄）

| 机制 | 来源 | 原文要点 |
|---|---|---|
| 分层轮数预算 | [chaseai-yt/claudex-loop](https://github.com/chaseai-yt/claudex-loop)（2613★） | `MAX_ROUNDS=5` / `MAX_FIX_ROUNDS=2` / `MAX_INSPECTION_ROUNDS=2`；"Stop at MAX_ROUNDS. Present unresolved findings ... instead of manufacturing convergence." |
| 禁 relitigate | 同上 | "Avoid relitigating resolved points without new evidence." |
| 收敛定义 | [donnfelker/loop-skills](https://github.com/donnfelker/loop-skills) multi-llm-convergence | "Stop on real consensus, not the first 'looks good.'"；上限 6 轮 reviewer passes |
| 审查深度分层 | [CodeAlive-AI/pragmatic-orchestration](https://github.com/CodeAlive-AI/pragmatic-orchestration) | "Choose one depth for a review. Do not run every depth sequentially."；昂贵审查不进常规池 |
| reproduce-don't-assert | [awesome-skills/code-review-skill](https://github.com/awesome-skills/code-review-skill)（2014★） | "A test that reproduces the bug ... is worth more than one that was green from birth." |

**社区没有的东西**：增量复审（只有 CodeRabbit 区分 `review` 增量 vs `full review` 全量）。§10 的设计超前于社区，问题是执行没落地 —— 所以这次抄的是**控制机制**，不是审查方法论。