@routerhub/agent-rules 1.5.148 → 1.5.149

package/AGENTS.base.md

@@ -404,6 +404,36 @@
 - 无法确认 → 不报。宁可漏报一条真问题，也不用十条口味问题刷屏。
 - 每轮 review 的问题数量应当 ≤ 上一轮：修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖。
 
+### 审查方法（Review Method）——解决「看 diff 不知从何下手」
+
+⚠️ 本章是写给审稿方的**审查方法**，与上述「该报什么、不报什么」的边界配套：先按本章方法**找**到可疑点，再按边界判断**报不报**。「审稿边界」只规定收敛，本章规定怎么挖——两者缺一不可。审查时对 diff 里**新增的每个字段、常量、判定条件**，默认按下面三条方法过一遍：
+
+**① 新增量全局跟进（审稿版数据链路核对）**
+
+⚠️ 新增的每个字段/常量/判定，必须从「出生」跟到「终极使用处」走完一条完整链路再下结论，禁止只看定义或只看调用处就完事。快速定位：`grep 字段名` 列出全部引用点，逐个看「谁赋值 → 谁读它 → 落在哪」。默认检查点按改动性质对号入座：
+
+- **新字段写进响应体** → 查序列化点（`json:"-"` / `omitempty` / 手工 Marshal）是否与「不对外」的意图对齐；
+- **新常量参与定价/判定** → 查数值核对来源（上游报价文档 / 配置中心 / 硬编码是否写明出处），禁止凭拍脑袋认可数值；
+- **新字段同时进扣费和审计** → 查异常路径下两条记录是否自洽：成功/失败分支分开写时，重点看 `defer`、失败早退、`if xxx != nil` 这类「写入时机不同」的点，可能出现「CostUsdMicros=0 但审计字段非 0」的自相矛盾；
+- **新判定有金钱/权限/路由后果** → 查判据字段是不是该数据的「规范载体」：有没有别名、厂商前缀（`openai/gpt-4o`）、date 快照（`gpt-4o-2024-11-20`）、大小写写法（`GPT-4O`）等变体没被覆盖。
+
+原理：好的 review 意见从来不是「这一行写错了」，而是「你新增了 A，就必须同步处理 A′」。这类缺口是结构性的，读 diff 就能推出，不需要真正读懂整个系统——这也是「看了很懵也能 review」的依据。
+
+**② 数值判定先问三个「反面」**
+
+⚠️ diff 出现带金钱/权限/路由后果的数值判定（`==`、`!=`、`HasPrefix`、`>=`、`default:` 等），必须对判定的反面和补集提三问，确认覆盖再认可：
+
+1. **排除项的孪生项**：`if status == "failed"` 排除后，同级的 `in_progress` / `searching` / 空串走哪个分支？判定的全集是什么？只盯着被排除的那一个，会漏掉其余状态的归属。
+2. **默认分支的安全方向**：未命中（`default:` / 最后 return）在金钱上朝哪边偏？朝「漏收」还是「多收」？哪个方向会造成静默的账面偏差。
+3. **数值有核对来源吗**：常量数值（如 10_000 / 25_000）是对过上游公开报价，还是随手拍的？没核对来源的定价常量 → 必须报（呼应「环境配置禁止推断」）。
+
+**③ 以行为变更表为主攻目标**
+
+⚠️ PR 描述有「行为变更表 / 改前改后对比表」时，审查以它为靶心，逐行问「这条真的成立吗」，用 diff 逐行验证；PR 没列表的，review 意见至少覆盖「改了什么行为 / 不变的行为有没有被误伤」两个面。
+⚠️ 对作者标注「不在本 PR 范围」的内容（如相关子系统计费、其它仓库同步）：不要求作者修，但必须判断是否构成「已知缺口被静默放过」——已暴露的边界缺口，作者必须在 PR 里显式记录后续动作、或至少点明仍待处理，禁止「提了不等于了」。
+
+**与审稿边界的配合**：本章找出的问题，是否上报仍按「必须报 / 禁止报」判断（真问题、真实风险、违反铁律 → 报；口味、防御、无法确认真假 → 不报）。每条意见必须带「新增量全局跟进」的链路证据（具体 diff 行 + 谁赋值谁读谁落库），禁止只给结论不给路径。
+
 ---
 
 When performing a code review, ONLY report issues that would cause an actual bug, data loss, or security vulnerability with a concrete, reproducible trigger path visible in the diff.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@routerhub/agent-rules",
-  "version": "1.5.148",
+  "version": "1.5.149",
   "description": "Shared Copilot agent rules and guidelines for RouterHub projects",
   "main": "AGENTS.base.md",
   "bin": {

package/rules/review-boundary.md

@@ -28,6 +28,36 @@ outputName: "review-boundary"
 - 无法确认 → 不报。宁可漏报一条真问题，也不用十条口味问题刷屏。
 - 每轮 review 的问题数量应当 ≤ 上一轮：修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖。
 
+### 审查方法（Review Method）——解决「看 diff 不知从何下手」
+
+⚠️ 本章是写给审稿方的**审查方法**，与上述「该报什么、不报什么」的边界配套：先按本章方法**找**到可疑点，再按边界判断**报不报**。「审稿边界」只规定收敛，本章规定怎么挖——两者缺一不可。审查时对 diff 里**新增的每个字段、常量、判定条件**，默认按下面三条方法过一遍：
+
+**① 新增量全局跟进（审稿版数据链路核对）**
+
+⚠️ 新增的每个字段/常量/判定，必须从「出生」跟到「终极使用处」走完一条完整链路再下结论，禁止只看定义或只看调用处就完事。快速定位：`grep 字段名` 列出全部引用点，逐个看「谁赋值 → 谁读它 → 落在哪」。默认检查点按改动性质对号入座：
+
+- **新字段写进响应体** → 查序列化点（`json:"-"` / `omitempty` / 手工 Marshal）是否与「不对外」的意图对齐；
+- **新常量参与定价/判定** → 查数值核对来源（上游报价文档 / 配置中心 / 硬编码是否写明出处），禁止凭拍脑袋认可数值；
+- **新字段同时进扣费和审计** → 查异常路径下两条记录是否自洽：成功/失败分支分开写时，重点看 `defer`、失败早退、`if xxx != nil` 这类「写入时机不同」的点，可能出现「CostUsdMicros=0 但审计字段非 0」的自相矛盾；
+- **新判定有金钱/权限/路由后果** → 查判据字段是不是该数据的「规范载体」：有没有别名、厂商前缀（`openai/gpt-4o`）、date 快照（`gpt-4o-2024-11-20`）、大小写写法（`GPT-4O`）等变体没被覆盖。
+
+原理：好的 review 意见从来不是「这一行写错了」，而是「你新增了 A，就必须同步处理 A′」。这类缺口是结构性的，读 diff 就能推出，不需要真正读懂整个系统——这也是「看了很懵也能 review」的依据。
+
+**② 数值判定先问三个「反面」**
+
+⚠️ diff 出现带金钱/权限/路由后果的数值判定（`==`、`!=`、`HasPrefix`、`>=`、`default:` 等），必须对判定的反面和补集提三问，确认覆盖再认可：
+
+1. **排除项的孪生项**：`if status == "failed"` 排除后，同级的 `in_progress` / `searching` / 空串走哪个分支？判定的全集是什么？只盯着被排除的那一个，会漏掉其余状态的归属。
+2. **默认分支的安全方向**：未命中（`default:` / 最后 return）在金钱上朝哪边偏？朝「漏收」还是「多收」？哪个方向会造成静默的账面偏差。
+3. **数值有核对来源吗**：常量数值（如 10_000 / 25_000）是对过上游公开报价，还是随手拍的？没核对来源的定价常量 → 必须报（呼应「环境配置禁止推断」）。
+
+**③ 以行为变更表为主攻目标**
+
+⚠️ PR 描述有「行为变更表 / 改前改后对比表」时，审查以它为靶心，逐行问「这条真的成立吗」，用 diff 逐行验证；PR 没列表的，review 意见至少覆盖「改了什么行为 / 不变的行为有没有被误伤」两个面。
+⚠️ 对作者标注「不在本 PR 范围」的内容（如相关子系统计费、其它仓库同步）：不要求作者修，但必须判断是否构成「已知缺口被静默放过」——已暴露的边界缺口，作者必须在 PR 里显式记录后续动作、或至少点明仍待处理，禁止「提了不等于了」。
+
+**与审稿边界的配合**：本章找出的问题，是否上报仍按「必须报 / 禁止报」判断（真问题、真实风险、违反铁律 → 报；口味、防御、无法确认真假 → 不报）。每条意见必须带「新增量全局跟进」的链路证据（具体 diff 行 + 谁赋值谁读谁落库），禁止只给结论不给路径。
+
 ---
 
 When performing a code review, ONLY report issues that would cause an actual bug, data loss, or security vulnerability with a concrete, reproducible trigger path visible in the diff.