@routerhub/agent-rules 1.5.219 → 1.5.222

package/AGENTS.base.md

@@ -329,6 +329,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（唯一例外：发版载体仓库执行 `./release.sh` 时会在 main 上生成「发布 vX.Y.Z」提交；非发版载体仓库没有该脚本，不存在这个例外）。
 - ⚠️ **从主分支拉/建功能分支之前，必须先直接拉取远程主分支（`git pull origin main`）**，确保基于最新的远程主分支拉分支，禁止基于过期的本地主分支创建分支。
 - ⚠️ **可评审 PR 的合并目标永远是仓库默认分支（如 `main`/`master`），不是 `test`**。`test` 分支只用于部署测试环境，只能通过 `/deploy-test` skill 直接 `merge` 更新（见「部署规则」），不发 PR、不走 code review；`test` 分支同样禁止直接提交代码。commit 必须中文，禁止 `git push --force`。
+- ⚠️ **所有 PR 一律以仓库默认分支（`main`/`master`）为 base，禁止创建「其他分支合并到其他分支」的 PR。** 功能分支的去向只有一条：合回默认分支；不允许出现 `feature/* → test`、`feature/* → develop`、`feature/* → feature/*` 这类以非默认分支为 base 的 PR。需要另一分支的改动时，先把该分支合回默认分支，再从默认分支拉新分支——禁止靠「分支合分支」把改动横向搬运（那样改动绕过了默认分支，主干永远拿不到它，后续发版与团队其他人的分支都会与之脱节）。⚠️ **发现 PR 的 base 不是默认分支（自己建的或别人的），先把 base 改回默认分支（`gh pr edit <PR> --base main`）再继续**，禁止顺着错误的 base 把 PR 合到非默认分支上。
 - ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
 - ⚠️ **提交并推送代码后，若发现与主分支存在冲突，必须主动解决**，不能推送完就算完事、把冲突留给别人处理。
 
@@ -945,7 +946,7 @@ Chrome Helper 会越积越多，表现为“agent-browser 用着用着越来越
 - **一句话：「这条不修，功能会不会错 / 数据会不会坏？」** 会 → 报；不会 → 不报。
 - 每条意见必须引用 diff 中的具体代码行作为证据，禁止臆测。
 - 无法确认 → 不报。宁可漏报一条真问题，也不用十条口味问题刷屏。
-- 每轮 review 的问题数量应当 ≤ 上一轮：修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖。
+- **收敛只看「性质」，不看「数量」：只问「还有没有必须修的真问题」，禁止拿「这轮问题比上轮少几个」当收敛依据。** 修完真问题后没有新的真问题，就直接说「无值得修的新问题」，不要换个角度再挖；但反向同样禁止——不许为了让数量往下走，把本轮真发现的问题压着不报、或降级成口味问题放过去（那是用漏报伪装收敛）。后一轮确实新挖出落在「必须修」范围内的问题（上一轮漏报的角落、修复引入的回归）时照报不误：循环靠「必须修的终将清零」收敛，不靠轮数递减。
 
 ### 审查方法（Review Method）——解决「看 diff 不知从何下手」
 

package/CHANGELOG.md

@@ -2,6 +2,22 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
+## [1.5.221] - 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

package/package.json

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

package/rules/global.md

@@ -329,6 +329,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（唯一例外：发版载体仓库执行 `./release.sh` 时会在 main 上生成「发布 vX.Y.Z」提交；非发版载体仓库没有该脚本，不存在这个例外）。
 - ⚠️ **从主分支拉/建功能分支之前，必须先直接拉取远程主分支（`git pull origin main`）**，确保基于最新的远程主分支拉分支，禁止基于过期的本地主分支创建分支。
 - ⚠️ **可评审 PR 的合并目标永远是仓库默认分支（如 `main`/`master`），不是 `test`**。`test` 分支只用于部署测试环境，只能通过 `/deploy-test` skill 直接 `merge` 更新（见「部署规则」），不发 PR、不走 code review；`test` 分支同样禁止直接提交代码。commit 必须中文，禁止 `git push --force`。
+- ⚠️ **所有 PR 一律以仓库默认分支（`main`/`master`）为 base，禁止创建「其他分支合并到其他分支」的 PR。** 功能分支的去向只有一条：合回默认分支；不允许出现 `feature/* → test`、`feature/* → develop`、`feature/* → feature/*` 这类以非默认分支为 base 的 PR。需要另一分支的改动时，先把该分支合回默认分支，再从默认分支拉新分支——禁止靠「分支合分支」把改动横向搬运（那样改动绕过了默认分支，主干永远拿不到它，后续发版与团队其他人的分支都会与之脱节）。⚠️ **发现 PR 的 base 不是默认分支（自己建的或别人的），先把 base 改回默认分支（`gh pr edit <PR> --base main`）再继续**，禁止顺着错误的 base 把 PR 合到非默认分支上。
 - ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
 - ⚠️ **提交并推送代码后，若发现与主分支存在冲突，必须主动解决**，不能推送完就算完事、把冲突留给别人处理。
 

package/rules/review-boundary.md

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