@routerhub/agent-rules 1.5.218 → 1.5.221

package/AGENTS.base.md

@@ -945,7 +945,7 @@ Chrome Helper 会越积越多，表现为“agent-browser 用着用着越来越
 - **一句话：「这条不修，功能会不会错 / 数据会不会坏？」** 会 → 报；不会 → 不报。
 - 每条意见必须引用 diff 中的具体代码行作为证据，禁止臆测。
 - 无法确认 → 不报。宁可漏报一条真问题，也不用十条口味问题刷屏。
-- 每轮 review 的问题数量应当 ≤ 上一轮：修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖。
+- **收敛只看「性质」，不看「数量」：只问「还有没有必须修的真问题」，禁止拿「这轮问题比上轮少几个」当收敛依据。** 修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖；但反向同样禁止——不许为了让数量往下走，把本轮真发现的问题压着不报、或降级成口味问题放过去（那是用漏报伪装收敛）。后一轮确实新挖出落在「必须修」范围内的问题（上一轮漏报的角落、修复引入的回归）时照报不误：循环靠「必须修的终将清零」收敛，不靠轮数递减。
 
 ### 审查方法（Review Method）——解决「看 diff 不知从何下手」
 

package/CHANGELOG.md

@@ -2,6 +2,31 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
+## [1.5.220] - 2026-09-16
+
+### Fixed
+
+- **发版时序竞态导致下游全量分发失败（v1.5.218、v1.5.219 两连挂，下游连停在 `^1.5.217`）**：本地 `./release.sh` 的推送顺序是「先 `git push` 触发 CI、后 `npm publish`」（第 114 行 push / 第 122 行 publish），而 CI 被 push 触发后几十秒内就跑到 `distribute` job，此时 registry 上还没有该版本 → `publish-downstream.js` 里的 `pnpm add @routerhub/agent-rules@新版本` 报「No matching version found」，8 个下游仓库**全部**分发失败（脚本对每个仓库独立 try，所以是 8 个一起挂、不是首个失败即停）。
+  - **实测铁证（CI 日志时刻 vs registry 权威 `time` 字段）**：v1.5.218 —— CI 01:41:42 拉包失败 / npm 01:42:32 才可见（早 50 秒）；v1.5.219 —— CI 01:44:20 拉包失败 / npm 01:44:49 才可见（早 29 秒）。两版卡在同一个时序上，不是偶发。
+  - **修复**：`.github/workflows/publish.yml` 的 `distribute` job 在跑分发脚本前新增「等待目标版本在 npm 可见」步骤——每 10 秒探测一次、最多 10 分钟，可见后才开始分发；超时即明确报错中止，而不是让 8 个仓库各自抛一句没头没尾的「No matching version found」。
+  - **判据为什么用 `npm view "@routerhub/agent-rules@<版本>" version` 而不是 `npm view <pkg> version`**：后者只看 `latest` dist-tag，一旦版本号跳号（如本地连跑两次 `release.sh`）就会永远对不上、死等到超时。两种情况均已实测：版本存在时输出该版本（第一轮即退出），不存在时输出空（继续轮询）。
+  - **CI 自己发版时本来就没这个问题**（`distribute` 有 `needs: publish`，而 publish job 内含完整 `release.sh`，天然等 publish 跑完才进 distribute）；本步骤保护的是**本地发版路径**——即「改规则 → `node merge.js sync` → `./release.sh`」这条日常路径，不修则每次都会重演。版本早已可见时第一轮探测即通过，正常发版零额外等待。
+  - **兜底补发**：v1.5.218 与 v1.5.219 两版漏发已通过 `workflow_dispatch` 补发（该分支无条件跑 distribute、脚本幂等，下游已在该版本则 SKIP），下游从 `^1.5.217` 直升 `^1.5.219`。
+
+### Changed
+
+- **审稿边界的收敛判据由「数量递减」改为「性质判定」**：原判据「每轮 review 的问题数量应当 ≤ 上一轮」是计数式的，隐含「轮数递减 = 收敛」。但 bot 每轮全量重读 diff，总能在后一轮挖出落在「必须修」范围内的真问题（上一轮漏报的角落、修复引入的回归），此时数量回升是正常的，不是没收敛。改为只问「还有没有必须修的真问题」，并补上反向约束——**禁止为了让数量往下走而压着真问题不报、或把真问题降级成口味问题放过去**（那是用漏报伪装收敛）。与 `loop-review` 取消轮数上限的口径统一（见 1.5.219）。
+  - 该节只进 `.github/instructions/review-boundary.instructions.md`（`copilot-instructions.md` 不含「审稿边界」一节），已经 `node merge.js sync` 验证改动落点正确。
+
+## [1.5.219] - 2026-09-16
+
+### Changed
+
+- **`loop-review` 取消「最大轮数（默认 5 轮 / 深度循环 8 轮）」上限——循环结束只由「性质」决定，不再由「跑了几轮」决定**：起因是用户提出「循环没必要设这个上限的数，按『必须修复的修复就行，其他不必须修复的走 Won't fix』就行」。原规则把「达到最大轮数仍有值得修的问题 → 停止循环，把剩余问题交给用户决定」当兜底，但这条兜底与循环真正的收敛机制是**打架**的：循环的收敛出口是「本轮没有任何必须修的新问题」，而 bot 每轮全量重读 diff、总能再挖出新层次（上一轮漏报的角落 / 修复引入的回归 / 新代码自带的新毛病）——所以「第 N 轮还有必须修的问题」完全可能只是**真的还有必须修的问题**，此时按轮数停下，等于把仍然必须修的问题挂着交出去；反过来，数字上限还会诱导一条更危险的歪路：为了「跑够轮数就收工」，把真问题降级成口味问题 Won't fix 掉。
+  - **现在的判据**：`skills/loop-review/SKILL.md` 步骤 6 删除「达到最大轮数」条目并显式写明「**循环不设轮数上限——结束只看『这一轮有没有必须修的问题』，不看『已经跑了几轮』**」；步骤 7 开头「循环结束或达到轮数上限后」改为「循环结束后」；「循环终止条件」表格删掉「达到最大轮数」一行；铁律把原「必须设最大轮数**和等待超时**」拆开——轮数上限取消，**等待 bot 出新 review 的 15 分钟超时保留**（它管的是「不要干等」，不是循环上限）。
+  - **同时加了一条反向约束**：禁止为了尽快收工把真问题降级成口味问题 Won't fix 掉——数字上限一去，「必须修的都修完」就成了唯一的收敛出口，这条歪路必须堵住。
+  - **为什么去掉上限后不会无限循环**：真正会无限冒的只是「口味 / 过度设计」那类，而它们每轮都被 Won't fix 回复 + 落盘到 `decisions/` 挡住、进不了「必须修」，所以「必须修的清零」这一条件迟早成立、且不会被轮数提前打断。
+
 ## [1.5.216] - 2026-09-14
 
 ### Added

package/package.json

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

package/rules/review-boundary.md

@@ -30,7 +30,7 @@ outputName: "review-boundary"
 - **一句话：「这条不修，功能会不会错 / 数据会不会坏？」** 会 → 报；不会 → 不报。
 - 每条意见必须引用 diff 中的具体代码行作为证据，禁止臆测。
 - 无法确认 → 不报。宁可漏报一条真问题，也不用十条口味问题刷屏。
-- 每轮 review 的问题数量应当 ≤ 上一轮：修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖。
+- **收敛只看「性质」，不看「数量」：只问「还有没有必须修的真问题」，禁止拿「这轮问题比上轮少几个」当收敛依据。** 修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖；但反向同样禁止——不许为了让数量往下走，把本轮真发现的问题压着不报、或降级成口味问题放过去（那是用漏报伪装收敛）。后一轮确实新挖出落在「必须修」范围内的问题（上一轮漏报的角落、修复引入的回归）时照报不误：循环靠「必须修的终将清零」收敛，不靠轮数递减。
 
 ### 审查方法（Review Method）——解决「看 diff 不知从何下手」
 

package/skills/loop-review/SKILL.md

@@ -207,13 +207,14 @@ done
 
 - **本轮没有任何「值得修」的新问题**（要么 bot 没提新的，要么新问题全是已处理/口味/误报，全部有回复落点）→ 循环结束 ✅，进入步骤 7 收尾
 - **本轮有「值得修」的新问题** → 已修复并回复，回到步骤 5 进入下一轮
-- **达到最大轮数（默认 5 轮；用户明确要求深度循环时最多 8 轮）仍有值得修的新问题** → 停止循环，把剩余问题逐条列给用户，由用户决定（继续 / 放过 / 人工处理），禁止无限循环
+
+⚠️ **循环不设轮数上限——结束只看「这一轮有没有必须修的问题」，不看「已经跑了几轮」。** bot 每轮全量重读 diff，总能再挖出新层次（上一轮漏报的角落 / 修复引入的回归 / 新代码自带的新毛病），**只要它提的还落在「必须修」范围内，就继续修**，禁止因为「都跑到第 N 轮了」就把仍然必须修的问题挂着交出去。循环天然会收敛：真正会无限冒的只是「口味 / 过度设计」那类，而它们每轮都被 Won't fix 回复挡住、进不了「必须修」，所以「必须修的清零」这一条件迟早成立、且不会被轮数提前打断。
 
 ⚠️ 每轮结束向用户汇报：本轮发现什么、改了什么、拒绝了什么、剩什么。
 
 ### 7. 收尾汇报
 
-循环结束或达到轮数上限后，输出汇总报告：
+循环结束后，输出汇总报告：
 
 ```
 循环 review 完成，共 X 轮：
@@ -228,8 +229,7 @@ done
 
 | 条件 | 行为 |
 |------|------|
-| 本轮没有任何「值得修」的新问题 | ✅ 结束（注意：**不是**「严重度清零」——bot 总会挂着几条我们判断过不值得修的） |
-| 达到最大轮数（默认 5 轮；用户明确要求深度循环时最多 8 轮） | ⛔ 停止，剩余问题交用户决定 |
+| 本轮没有任何「值得修」的新问题 | ✅ 结束（注意：**不是**「严重度清零」、**也不是**「跑够多少轮」——bot 总会挂着几条我们判断过不值得修的） |
 | 等待新 review 超时（默认 15 分钟） | ⏸ 停止等待，询问用户 |
 | 连续两轮 review 内容完全相同（bot 疑似卡死） | ⛔ 停止，向用户报告 |
 
@@ -242,7 +242,7 @@ done
 - ⚠️ **每条 review 建议必须有落点**（修复 commit / Won't fix / 误报回复），禁止静默跳过——不回复 bot 下轮必重提，循环无限。
 - ⚠️ **每轮先确认哪些是上一轮已处理过的**，一律不重复改，直接回复「已修复于 <hash>」。
 - ⚠️ **禁止使用 `[skip ci]` / `[skip review]`**——循环依赖「每次 push 触发 review」，跳过就断了。
-- ⚠️ **必须设最大轮数（默认 5；用户明确要求深度循环时最多 8）和等待超时（默认 15 分钟）**，禁止无限循环 / 无限等待。
+- ⚠️ **循环不设轮数上限**：结束只由「本轮有没有必须修的新问题」决定，与轮数无关。**禁止因为「已经跑了好几轮」就把仍然必须修的问题挂着交给用户**；反向同样禁止——为了尽快收工，把真问题降级成口味问题 Won't fix 掉。**等待 bot 返回新一轮 review 的超时保留（默认 15 分钟）**，它管的是「不要干等」，不是循环上限。
 - ⚠️ **已修复的功能性问题单独 commit**，禁止与大量建议级改动混在一起，保证每轮 push 的 diff 可读。
 - ⚠️ **每条 review 修复都必须同 commit 回 PR 对应的 feature 分支并推送远程**，不得只推到 test 分支或只放在工作区不 commit。feature 分支与 test 分支两条线必须同步，缺一不可（详见步骤 3）。
 - ⚠️ **等待 bot 审查期间遵守心跳约定**：超过 1 分钟无输出主动说明在等什么。