@routerhub/agent-rules 1.5.212 → 1.5.213

package/AGENTS.base.md

@@ -292,7 +292,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 ## Git 规范
 
 - 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
-- ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（发版除外：`./release.sh` 会在 main 上生成「发布 vX.Y.Z」提交）。
+- ⚠️ **一般情况下，主分支（`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`。
 - ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
@@ -359,18 +359,18 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **PR 创建即进入可评审状态**：直接创建正式 PR（非 Draft），创建完成、冲突检查与静态编译通过后即可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review。
 - ⚠️ **创建 PR 后必须先过 CI 再进入后续流程**：创建完成后第一时间执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若有任一检查 `failure`，必须先定位并修复失败项、推送新提交并复查到全部 `success`，然后才能进入循环 review、测试验证、交付 review 等后续步骤，禁止带红 CI 继续往下走。
 - ⚠️ **每次修改 PR 后（含创建 PR、push 新提交、响应 review 意见重新推送等所有改动 PR 的动作之后），都必须检查与主分支（默认分支）是否有冲突**：用 `gh pr view <PR> --json mergeable -q .mergeable` 检查（`MERGEABLE`=无冲突可合并，`CONFLICTING`=存在冲突，`UNKNOWN`=GitHub 尚未判定，稍后复查）。若存在冲突，必须先解决冲突再交付 review——`git merge origin/main`（或 `git rebase origin/main`）→ 解决冲突文件 → 测试通过 → 推送，确保 PR 处于可合并状态，禁止把带冲突的 PR 抛给 reviewer。主分支随时可能前进，一个创建时无冲突的 PR 可能在后续 push 后悄悄变冲突，因此每次改动 PR 后都必须重新检查，禁止只在创建时查一次就以为高枕无忧。
-- ⚠️ **每次修改 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后发新版本**，三步收尾缺一不可：
+- ⚠️ **每次修改 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后交付测试环境**，三步收尾缺一不可：
 1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
 2. **GitHub 静态编译检查**：用 `gh pr checks <PR>` 查看 CI 检查状态（`success`=通过，`failure`=失败，`pending`=进行中）。存在失败项时，必须定位失败根因、修改代码并重新推送，直到全部通过，禁止把静态编译未通过的 PR 抛给 reviewer。
-3. **发新版本**：PR 合并后按项目发布流程发布新版本（本项目统一执行根目录 `./release.sh`，自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。
-- ⚠️ **创建完 PR 后自动走完整闭环流程，未走完不算完成**：创建 PR → **链路预演** → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发 PR 链接给用户 → 发新版本，七步缺一不可，全程自动执行：
+3. **交付测试环境**：PR 合并后把最新代码交付到**测试环境**（走 `/deploy-test` skill），交付终点到此为止。⚠️ **业务仓库一律只交付测试环境，不发布生产**——`./release.sh`（patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）是**发版载体仓库自己**的机制，**仅当本仓库根目录确实存在 `./release.sh`（如 `@routerhub/agent-rules` 包自身）时才执行**；根目录没有这个脚本 = 本仓库不是发版载体，此步只做测试环境交付，**禁止据此推断出「那大概是生产部署吧」再补一个替代动作，禁止自行启动任何生产发布**（呼应「⚠️ 环境配置禁止推断」）。
+- ⚠️ **创建完 PR 后自动走完整闭环流程，未走完不算完成**：创建 PR → **链路预演** → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发 PR 链接给用户 → 交付测试环境，七步缺一不可，全程自动执行：
 0. **先走「链路预演」（在循环 review 之前，轻量）**：PR 创建后**立刻**判断是否命中「⚠️ 跨系统真实链路验收铁律」的 4 条触发条件。命中 → 触发 `/real-chain-verify` 的**阶段 1**：只画链路、逐环节快速过一遍，回答「**这条链路成不成立、需求口径对不对**」，**不写 6 段报告、不做截图标注**（约阶段 2 的 20~30% 工作量）。⚠️ **这一步的目的是尽早暴露「需要大改」的问题**（需求口径反转、默认值不对、跨仓库语义不成立、schema 要改）——**大改放在 review 之后发现，等于前面 N 轮 review 全白跑**。发现需大改 → 先改完再进循环 review，禁止带着「可能推翻重做」的设计去跑 review。未命中 → 本步跳过，直接进第 1 步，并在 PR 描述里勾选豁免项。
 1. **自动走循环 review**：创建完 PR 后自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束，禁止只跑一轮就收工。**循环 review 走完后，必须显式输出「✅ 循环 review 完成，进入发布收尾闭环」，并调用 `/pr-release-loop` skill 走完后续步骤。**
-2. **重新部署到测试环境（循环 review 后最容易漏掉的一步）**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。⚠️ **循环 review 期间每次修复都会 push 新 commit；不重新部署 = 测试环境跑的还是 review 之前的旧代码 = 用旧代码验证新改动 = 结论无效。因此循环 review 结束后禁止直接发 PR 链接 / 发版，必须先 `/deploy-test` 重部署。**
+2. **重新部署到测试环境（循环 review 后最容易漏掉的一步）**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。⚠️ **循环 review 期间每次修复都会 push 新 commit；不重新部署 = 测试环境跑的还是 review 之前的旧代码 = 用旧代码验证新改动 = 结论无效。因此循环 review 结束后禁止直接发 PR 链接 / 交付，必须先 `/deploy-test` 重部署。**
 3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：真实视口 + `fullPage` 全页、URL 可见、存盘到 `screenshots/` 临时目录），并在每张截图上用**坐标换算后的箭头标注**（走 `/screenshot-annotate` skill）关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。⚠️ **命中「⚠️ 跨系统真实链路验收铁律」触发条件的，本步即该铁律的「阶段 2 链路验收」**：按 `/real-chain-verify` 走完整取证与 6 段报告，把阶段 1 画出的链路逐环节补上下游可观测事实与下游真实生效证据（阶段 1 只判「通不通」，本步必须交出「下游留下了什么痕迹」）。
 4. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
-5. **把 PR 链接发给用户**：确认没问题后，先把 PR 链接发送给用户（`gh pr view <PR> --json url -q .url`），让用户能直接打开查看，再执行发版。
-6. **发新版本**：确认没问题、PR 链接已发送后，按上面三步收尾完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
+5. **把 PR 链接发给用户**：确认没问题后，先把 PR 链接发送给用户（`gh pr view <PR> --json url -q .url`），让用户能直接打开查看，再执行交付。
+6. **交付测试环境**：确认没问题、PR 链接已发送后，按上面三步收尾完成冲突检查与静态编译检查，PR 合并后把最新代码交付到测试环境（走 `/deploy-test` skill）。⚠️ **交付终点就是测试环境，不发布生产**；仅当本仓库根目录确实存在 `./release.sh`（发版载体仓库，如 `@routerhub/agent-rules` 包自身）时，才在这一步额外执行 `./release.sh` 发版。
 - ⚠️ **私有仓库的 PR/Issue 正文中插入截图，禁止使用 `raw.githubusercontent.com` 链接，必须使用 `github.com/OWNER/REPO/blob/BRANCH/path?raw=true` 格式。** 原因：`raw.githubusercontent.com` 不识别 GitHub 网页端的登录态（session cookie），GitHub 渲染 PR/Issue 正文图片时走的是 camo 图片代理服务器端匿名拉取——对私有仓库该链接返回 404，导致图片框显示为普通文字链接而非图片；`github.com/.../blob/...?raw=true` 走的是 github.com 主域名，能通过登录态正确鉴权，图片才能正常渲染。凡是「先 `git add -f` 把截图提交进 `screenshots/` 目录、再在 PR 描述里用 Markdown 引用」的流程，图片链接一律拼接为后一种格式。
 
 ## 安全
@@ -723,7 +723,8 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 
 ## 部署规则
 
-- 发版统一执行 `./release.sh`。（自包含铁律见上方「⚠️ 可部署性自包含铁律」章节）
+- ⚠️ **交付终点是测试环境，不是生产**：日常需求 / 修复的交付到「部署测试环境 + 测试环境验证通过」为止，**业务仓库不发布生产**（要上生产由用户另行明确要求，按下方生产部署铁律走）。测试环境部署见下一条。
+- ⚠️ **`./release.sh` 只属于发版载体仓库**：根目录存在 `./release.sh` 的仓库（如 `@routerhub/agent-rules` 包自身——它靠 npm publish 发版、下游仓库靠依赖升级拿到新规则）才执行 `./release.sh` 发版；**业务仓库根目录没有这个脚本，禁止执行、也禁止推断出一个替代的发版动作**。（自包含铁律见上方「⚠️ 可部署性自包含铁律」章节）
 - ⚠️ 部署测试环境必须使用 `/deploy-test` skill，严禁跳过 skill 直接执行部署操作（合并/推送/部署/切回的具体流程见该 skill）。
 - ⚠️ **部署生产前必须通读一遍部署脚本再执行，禁止盲跑。** 部署脚本是多人接力的产物，其中任何一行环境值（PROJECT / 服务名 / Nacos namespace / 数据库 / 域名 / 后端 Host / VPC / 密钥名）都可能被中途改错、与线上真实环境脱节——脚本能跑、能编译、甚至能部署成功，但连的是错环境。执行前逐行核对脚本配置与线上实际（`gcloud config get-value project`、`gcloud run services list`、Nacos 配置），对不上 → 先改脚本或停下来问，禁止带着疑似错误的配置直接部署（呼应「环境配置禁止推断」）。
 - ⚠️ **部署脚本必须内置「环境自检」：在真正执行部署动作之前，先自动校验脚本配置与线上环境一致，不一致即中止（abort），禁止在环境未验证的情况下执行 deploy。** 校验项至少包括：① PROJECT 与 `gcloud config get-value project` 一致；② 目标 Cloud Run 服务真实存在；③ Nacos namespace / 库名与线上一致；④ 前端代理的后端 Host（BACKEND_RUN_HOST）指向本环境后端，而非 Dockerfile 默认值或他环境。**目标脚本若没有自检逻辑，执行者必须先补上再跑——禁止「无自检的脚本直接部署」。** 参照 agent-rules 自身 `release.sh` 的「规则漂移检查」（发版前强制校验规则已同步、未同步即中止），把「人记得校验」升级为「脚本强制校验」。
@@ -848,8 +849,6 @@ Chrome Helper 会越积越多，表现为“agent-browser 用着用着越来越
 
 ## 前端规则
 
-我测试下看看能不能发新版本
-
 - ⚠️ **默认隐藏滚动条**：页面/容器出现滚动需求时，滚动条默认隐藏（内容仍可正常滚动），不得让滚动条可见。仅当用户明确说「需要滚动条」「可以有滚动条」「显示滚动条」等表述时，才允许显示。
 - ⚠️ **依赖安装统一 `pnpm`**，禁止 `npm install` / `yarn install`（pnpm workspace 混合安装会破坏依赖结构）。
 - ⚠️ **API 请求严格使用 OpenAPI 生成的方法，禁止手写请求或直接拼接路径**；接口变更后先更新 OpenAPI 定义并重新生成 API 代码，再进行业务开发。

package/CHANGELOG.md

@@ -2,6 +2,20 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
+## [1.5.213] - 2026-09-14
+
+### Changed
+
+- **把闭环流程的交付终点从「发新版本」改成「交付测试环境」，并把 `./release.sh` 限定为「只属于发版载体仓库」**：原规则把 PR 闭环的收尾写成「发新版本：本项目统一执行根目录 `./release.sh`（自动 patch +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）」，并且是**无条件**分发给 8 个下游业务仓库的。问题在于 `./release.sh` 是 **agent-rules 自己**的发版机制（它靠 npm publish 发版、下游靠依赖升级拿到新规则），业务仓库根目录根本没有这个脚本、也从不发布 npm 包。下游 AI 读到「七步缺一不可」后只有两条路：**要么凭空推断出一个替代动作**（实测发生过：把不存在的 `./release.sh` 猜成「那大概是生产部署吧」，进而把生产部署当成可选项提给用户），**要么卡住不动**——两种都不是规则想要的。现在明确：**业务仓库的交付终点就是测试环境**，收尾第三步是「交付测试环境（走 `/deploy-test`）」；`./release.sh` **仅当本仓库根目录确实存在该脚本时**（如 `@routerhub/agent-rules` 包自身）才执行，并显式写明**根目录没有该脚本时禁止推断替代动作、禁止自行启动生产发布**（呼应「⚠️ 环境配置禁止推断：来源都找不到的就写『待确认』，禁止自行补全」）。
+  - **`AGENTS.base.md`**：三步收尾的第 3 项、闭环七步的最后一步（第 6 步）与流程标题、「部署规则」章首、Git 规范里 main 分支「发版除外」的例外说明，全部同步改写；闭环流程内的「禁止直接发 PR 链接 / 发版」改为「/ 交付」。
+  - **`skills/pr-release-loop/SKILL.md`**：frontmatter description、完成定义清单第 10 项、第 6/7 步与「判断边界」三条边界，统一把「发版」改为「交付测试环境」。
+  - **`skills/create-pr/SKILL.md`**：步骤 7、步骤 8 标题与「③ 发新版本」小节、重要规则区两条闭环描述。
+  - **`skills/deploy-test/SKILL.md`**：**本次最自相矛盾的一处**——一个专门负责「部署测试环境」的 skill，原第 6 步部署完 test 分支后紧接着第 7 步却是「发新版本（如 `./release.sh`）」，等于自己给「测试环境交付」续了一个发版尾巴。现已改为「第 6 步部署 test 分支」即终点，并显式写明本 Skill 不碰 `./release.sh`。
+
+### Fixed
+
+- **删除 `AGENTS.base.md`「前端规则」章节里的一行残留测试文本**（`我测试下看看能不能发新版本`）：这行字原本夹在 `<!-- @domain: frontend -->` 与第一条前端规则之间，会被 `generateRulesFromBase()` 一起带进 `rules/frontend.md` 和 `.github/instructions/frontend.instructions.md`，分发给所有前端仓库——既污染规则正文，又正好是一句与发版有关的误导性内容。已随本次一并清除。
+
 ## [1.5.205] - 2026-09-10
 
 ### Changed

package/package.json

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

package/rules/frontend.md

@@ -6,8 +6,6 @@ outputName: "frontend"
 
 ## 前端规则
 
-我测试下看看能不能发新版本
-
 - ⚠️ **默认隐藏滚动条**：页面/容器出现滚动需求时，滚动条默认隐藏（内容仍可正常滚动），不得让滚动条可见。仅当用户明确说「需要滚动条」「可以有滚动条」「显示滚动条」等表述时，才允许显示。
 - ⚠️ **依赖安装统一 `pnpm`**，禁止 `npm install` / `yarn install`（pnpm workspace 混合安装会破坏依赖结构）。
 - ⚠️ **API 请求严格使用 OpenAPI 生成的方法，禁止手写请求或直接拼接路径**；接口变更后先更新 OpenAPI 定义并重新生成 API 代码，再进行业务开发。

package/rules/global.md

@@ -292,7 +292,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 ## Git 规范
 
 - 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
-- ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（发版除外：`./release.sh` 会在 main 上生成「发布 vX.Y.Z」提交）。
+- ⚠️ **一般情况下，主分支（`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`。
 - ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
@@ -359,18 +359,18 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **PR 创建即进入可评审状态**：直接创建正式 PR（非 Draft），创建完成、冲突检查与静态编译通过后即可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review。
 - ⚠️ **创建 PR 后必须先过 CI 再进入后续流程**：创建完成后第一时间执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若有任一检查 `failure`，必须先定位并修复失败项、推送新提交并复查到全部 `success`，然后才能进入循环 review、测试验证、交付 review 等后续步骤，禁止带红 CI 继续往下走。
 - ⚠️ **每次修改 PR 后（含创建 PR、push 新提交、响应 review 意见重新推送等所有改动 PR 的动作之后），都必须检查与主分支（默认分支）是否有冲突**：用 `gh pr view <PR> --json mergeable -q .mergeable` 检查（`MERGEABLE`=无冲突可合并，`CONFLICTING`=存在冲突，`UNKNOWN`=GitHub 尚未判定，稍后复查）。若存在冲突，必须先解决冲突再交付 review——`git merge origin/main`（或 `git rebase origin/main`）→ 解决冲突文件 → 测试通过 → 推送，确保 PR 处于可合并状态，禁止把带冲突的 PR 抛给 reviewer。主分支随时可能前进，一个创建时无冲突的 PR 可能在后续 push 后悄悄变冲突，因此每次改动 PR 后都必须重新检查，禁止只在创建时查一次就以为高枕无忧。
-- ⚠️ **每次修改 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后发新版本**，三步收尾缺一不可：
+- ⚠️ **每次修改 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后交付测试环境**，三步收尾缺一不可：
 1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
 2. **GitHub 静态编译检查**：用 `gh pr checks <PR>` 查看 CI 检查状态（`success`=通过，`failure`=失败，`pending`=进行中）。存在失败项时，必须定位失败根因、修改代码并重新推送，直到全部通过，禁止把静态编译未通过的 PR 抛给 reviewer。
-3. **发新版本**：PR 合并后按项目发布流程发布新版本（本项目统一执行根目录 `./release.sh`，自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。
-- ⚠️ **创建完 PR 后自动走完整闭环流程，未走完不算完成**：创建 PR → **链路预演** → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发 PR 链接给用户 → 发新版本，七步缺一不可，全程自动执行：
+3. **交付测试环境**：PR 合并后把最新代码交付到**测试环境**（走 `/deploy-test` skill），交付终点到此为止。⚠️ **业务仓库一律只交付测试环境，不发布生产**——`./release.sh`（patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）是**发版载体仓库自己**的机制，**仅当本仓库根目录确实存在 `./release.sh`（如 `@routerhub/agent-rules` 包自身）时才执行**；根目录没有这个脚本 = 本仓库不是发版载体，此步只做测试环境交付，**禁止据此推断出「那大概是生产部署吧」再补一个替代动作，禁止自行启动任何生产发布**（呼应「⚠️ 环境配置禁止推断」）。
+- ⚠️ **创建完 PR 后自动走完整闭环流程，未走完不算完成**：创建 PR → **链路预演** → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发 PR 链接给用户 → 交付测试环境，七步缺一不可，全程自动执行：
 0. **先走「链路预演」（在循环 review 之前，轻量）**：PR 创建后**立刻**判断是否命中「⚠️ 跨系统真实链路验收铁律」的 4 条触发条件。命中 → 触发 `/real-chain-verify` 的**阶段 1**：只画链路、逐环节快速过一遍，回答「**这条链路成不成立、需求口径对不对**」，**不写 6 段报告、不做截图标注**（约阶段 2 的 20~30% 工作量）。⚠️ **这一步的目的是尽早暴露「需要大改」的问题**（需求口径反转、默认值不对、跨仓库语义不成立、schema 要改）——**大改放在 review 之后发现，等于前面 N 轮 review 全白跑**。发现需大改 → 先改完再进循环 review，禁止带着「可能推翻重做」的设计去跑 review。未命中 → 本步跳过，直接进第 1 步，并在 PR 描述里勾选豁免项。
 1. **自动走循环 review**：创建完 PR 后自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束，禁止只跑一轮就收工。**循环 review 走完后，必须显式输出「✅ 循环 review 完成，进入发布收尾闭环」，并调用 `/pr-release-loop` skill 走完后续步骤。**
-2. **重新部署到测试环境（循环 review 后最容易漏掉的一步）**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。⚠️ **循环 review 期间每次修复都会 push 新 commit；不重新部署 = 测试环境跑的还是 review 之前的旧代码 = 用旧代码验证新改动 = 结论无效。因此循环 review 结束后禁止直接发 PR 链接 / 发版，必须先 `/deploy-test` 重部署。**
+2. **重新部署到测试环境（循环 review 后最容易漏掉的一步）**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。⚠️ **循环 review 期间每次修复都会 push 新 commit；不重新部署 = 测试环境跑的还是 review 之前的旧代码 = 用旧代码验证新改动 = 结论无效。因此循环 review 结束后禁止直接发 PR 链接 / 交付，必须先 `/deploy-test` 重部署。**
 3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：真实视口 + `fullPage` 全页、URL 可见、存盘到 `screenshots/` 临时目录），并在每张截图上用**坐标换算后的箭头标注**（走 `/screenshot-annotate` skill）关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。⚠️ **命中「⚠️ 跨系统真实链路验收铁律」触发条件的，本步即该铁律的「阶段 2 链路验收」**：按 `/real-chain-verify` 走完整取证与 6 段报告，把阶段 1 画出的链路逐环节补上下游可观测事实与下游真实生效证据（阶段 1 只判「通不通」，本步必须交出「下游留下了什么痕迹」）。
 4. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
-5. **把 PR 链接发给用户**：确认没问题后，先把 PR 链接发送给用户（`gh pr view <PR> --json url -q .url`），让用户能直接打开查看，再执行发版。
-6. **发新版本**：确认没问题、PR 链接已发送后，按上面三步收尾完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
+5. **把 PR 链接发给用户**：确认没问题后，先把 PR 链接发送给用户（`gh pr view <PR> --json url -q .url`），让用户能直接打开查看，再执行交付。
+6. **交付测试环境**：确认没问题、PR 链接已发送后，按上面三步收尾完成冲突检查与静态编译检查，PR 合并后把最新代码交付到测试环境（走 `/deploy-test` skill）。⚠️ **交付终点就是测试环境，不发布生产**；仅当本仓库根目录确实存在 `./release.sh`（发版载体仓库，如 `@routerhub/agent-rules` 包自身）时，才在这一步额外执行 `./release.sh` 发版。
 - ⚠️ **私有仓库的 PR/Issue 正文中插入截图，禁止使用 `raw.githubusercontent.com` 链接，必须使用 `github.com/OWNER/REPO/blob/BRANCH/path?raw=true` 格式。** 原因：`raw.githubusercontent.com` 不识别 GitHub 网页端的登录态（session cookie），GitHub 渲染 PR/Issue 正文图片时走的是 camo 图片代理服务器端匿名拉取——对私有仓库该链接返回 404，导致图片框显示为普通文字链接而非图片；`github.com/.../blob/...?raw=true` 走的是 github.com 主域名，能通过登录态正确鉴权，图片才能正常渲染。凡是「先 `git add -f` 把截图提交进 `screenshots/` 目录、再在 PR 描述里用 Markdown 引用」的流程，图片链接一律拼接为后一种格式。
 
 ## 安全
@@ -723,7 +723,8 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 
 ## 部署规则
 
-- 发版统一执行 `./release.sh`。（自包含铁律见上方「⚠️ 可部署性自包含铁律」章节）
+- ⚠️ **交付终点是测试环境，不是生产**：日常需求 / 修复的交付到「部署测试环境 + 测试环境验证通过」为止，**业务仓库不发布生产**（要上生产由用户另行明确要求，按下方生产部署铁律走）。测试环境部署见下一条。
+- ⚠️ **`./release.sh` 只属于发版载体仓库**：根目录存在 `./release.sh` 的仓库（如 `@routerhub/agent-rules` 包自身——它靠 npm publish 发版、下游仓库靠依赖升级拿到新规则）才执行 `./release.sh` 发版；**业务仓库根目录没有这个脚本，禁止执行、也禁止推断出一个替代的发版动作**。（自包含铁律见上方「⚠️ 可部署性自包含铁律」章节）
 - ⚠️ 部署测试环境必须使用 `/deploy-test` skill，严禁跳过 skill 直接执行部署操作（合并/推送/部署/切回的具体流程见该 skill）。
 - ⚠️ **部署生产前必须通读一遍部署脚本再执行，禁止盲跑。** 部署脚本是多人接力的产物，其中任何一行环境值（PROJECT / 服务名 / Nacos namespace / 数据库 / 域名 / 后端 Host / VPC / 密钥名）都可能被中途改错、与线上真实环境脱节——脚本能跑、能编译、甚至能部署成功，但连的是错环境。执行前逐行核对脚本配置与线上实际（`gcloud config get-value project`、`gcloud run services list`、Nacos 配置），对不上 → 先改脚本或停下来问，禁止带着疑似错误的配置直接部署（呼应「环境配置禁止推断」）。
 - ⚠️ **部署脚本必须内置「环境自检」：在真正执行部署动作之前，先自动校验脚本配置与线上环境一致，不一致即中止（abort），禁止在环境未验证的情况下执行 deploy。** 校验项至少包括：① PROJECT 与 `gcloud config get-value project` 一致；② 目标 Cloud Run 服务真实存在；③ Nacos namespace / 库名与线上一致；④ 前端代理的后端 Host（BACKEND_RUN_HOST）指向本环境后端，而非 Dockerfile 默认值或他环境。**目标脚本若没有自检逻辑，执行者必须先补上再跑——禁止「无自检的脚本直接部署」。** 参照 agent-rules 自身 `release.sh` 的「规则漂移检查」（发版前强制校验规则已同步、未同步即中止），把「人记得校验」升级为「脚本强制校验」。

package/skills/create-pr/SKILL.md

@@ -153,9 +153,9 @@ gh pr create \
 4. **重新部署到测试环境**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。
 5. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：真实视口 + `fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并在每张截图上用**坐标换算后的箭头标注**（走 `/screenshot-annotate` skill）关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。⚠️ **命中链路验收触发条件的，本步即「阶段 2 链路验收」**：按 `/real-chain-verify` 走完整取证与 6 段报告，并**回填 PR 描述里的「跨系统链路验收」栏目**（阶段 1 的链路图 + 下游真实生效证据 + 默认值对照）。
 6. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
-7. **发新版本**：确认没问题后，回到下方步骤 8 完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
+7. **交付测试环境**：确认没问题后，回到下方步骤 8 完成冲突检查与静态编译检查，PR 合并后把最新代码交付到**测试环境**（走 `/deploy-test` skill）。⚠️ **交付终点就是测试环境，不发布生产**。
 
-### 8. 每次修改 PR 后收尾检查（冲突 + 静态编译 + 发版本）
+### 8. 每次修改 PR 后收尾检查（冲突 + 静态编译 + 交付测试环境）
 
 ⚠️ 创建 PR 后、以及每次 push 新提交/响应 review 意见重新推送后，三步收尾缺一不可，禁止改完 PR 就直接抛给 reviewer 或当作完事。
 
@@ -175,9 +175,9 @@ gh pr checks <PR>
 - 存在失败项：定位失败根因 → 修改代码 → 重新推送，直到全部通过
 - 禁止把静态编译未通过的 PR 抛给 reviewer
 
-**③ 发新版本**：
-- PR 合并后按项目发布流程发布新版本
-- 本项目统一执行根目录 `./release.sh`（自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）
+**③ 交付测试环境**：
+- PR 合并后把最新代码交付到**测试环境**（走 `/deploy-test` skill）——**业务仓库的交付终点到此为止，不发布生产**
+- ⚠️ **`./release.sh` 只属于发版载体仓库**：仅当本仓库根目录**确实存在** `./release.sh`（如 `@routerhub/agent-rules` 包自身）时，才额外执行它（自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。**根目录没有该脚本 = 本仓库不是发版载体，禁止执行、也禁止推断出一个替代的发版动作**（呼应 AGENTS.base.md「⚠️ 环境配置禁止推断」）
 
 ## 重要规则
 
@@ -189,8 +189,8 @@ gh pr checks <PR>
 - ⚠️ **PR Description 顶部必须附「详细实现文档」链接（截图版 HTML，见步骤 5）**：PR 正文只承载快速浏览，链接展开「做了什么 + 为什么 + 每一步怎么做的」完整细节；**链接旁必须同时给出「点链接 → 点右上角 Download raw file 下载 → 双击打开」三步说明**（GitHub 对 HTML 只显示源码，不说明对方会以为链接坏了）
 - ⚠️ 截图禁止提交到 Git 仓库
 - ⚠️ PR 截图直接内嵌在 Description 正文中（Markdown 图片语法）
-- ⚠️ 每次修改 PR 后（含创建、push 新提交、响应 review 意见）都必须做三步收尾：冲突检查 → 静态编译检查 → PR 合并后发新版本（见步骤 8）
-- ⚠️ **创建完 PR 后必须自动走完整闭环流程（见步骤 7.5）**：创建 PR → 先做 CI 闸门检查并修复失败项 → **链路预演（命中跨系统链路验收触发条件时，在循环 review 之前先跑，只为尽早暴露需要大改的问题）** → 自动循环 review → 重新部署测试环境验证（全程截图 + 箭头标注，命中触发条件的走 `/real-chain-verify` 阶段 2）→ 确认没问题 → 发新版本，七步缺一不可，未走完不算完成
+- ⚠️ 每次修改 PR 后（含创建、push 新提交、响应 review 意见）都必须做三步收尾：冲突检查 → 静态编译检查 → PR 合并后交付测试环境（见步骤 8）
+- ⚠️ **创建完 PR 后必须自动走完整闭环流程（见步骤 7.5）**：创建 PR → 先做 CI 闸门检查并修复失败项 → **链路预演（命中跨系统链路验收触发条件时，在循环 review 之前先跑，只为尽早暴露需要大改的问题）** → 自动循环 review → 重新部署测试环境验证（全程截图 + 箭头标注，命中触发条件的走 `/real-chain-verify` 阶段 2）→ 确认没问题 → 交付测试环境，七步缺一不可，未走完不算完成。⚠️ **交付终点是测试环境，不发布生产**；仅当本仓库根目录确实存在 `./release.sh`（发版载体仓库，如 `@routerhub/agent-rules` 包自身）时才额外执行它发版。
 - ⚠️ **PR 描述里必须填「跨系统链路验收」栏目**（PR 模板已内置）：命中 4 条触发条件的填链路预演链路图 + 下游真实生效证据 + 默认值对照；未命中的勾选豁免项。**留痕是给 reviewer 看的——不填等于这一环做了也没人知道。**
 - ⚠️ **PR 描述里必须填「缺陷复现」栏目**（PR 模板已内置）：修 bug / 修故障的 PR 必须填**改动前**的复现证据（环境版本 → 可重演步骤 → 坏现象 + 可复查标识）与「同一套步骤复验后坏现象消失」；非修 bug 的勾选豁免项。⚠️ **复现的交付物是「逐步截图 + 箭头标注」的可视化走查（放在详细实现文档的「复现步骤」一节），不是一串文字步骤**——文字说不清「点在哪、界面长什么样、坏现象在屏幕哪个位置」，看的人只能自己拼图。⚠️ **动手改代码之前就要先复现并当场存图**，改完再补的不算复现。见「⚠️ 缺陷复现铁律」。
 - ⚠️ **直接创建正式 PR（非 Draft）**：PR 创建完成即进入可评审状态，可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review

package/skills/deploy-test/SKILL.md

@@ -132,13 +132,11 @@ git push origin test
 
 ### 6. 部署 test 分支
 
-按项目自己的部署方式执行（Cloud Run / 容器 / npm publish 等）。
+按项目自己的部署方式执行（Cloud Run / 容器 / 静态资源等）。
 
-### 7. 发新版本
+⚠️ **本 Skill 的终点就是「测试环境部署完成」，到此为止——不发布生产、不执行 `./release.sh`。** 业务仓库的交付终点是测试环境；`./release.sh` 是**发版载体仓库自己**的机制，只有根目录确实存在该脚本的仓库（如 `@routerhub/agent-rules` 包自身）才在它自己的发版流程里执行，**本 Skill 一律不碰**（呼应 AGENTS.base.md「⚠️ 环境配置禁止推断」：根目录没有这个脚本，禁止推断出一个替代的发版/生产部署动作）。
 
-按项目发版规则执行（如 `./release.sh`）。
-
-### 8. 切回原功能分支
+### 7. 切回原功能分支
 
 ```bash
 git checkout "$ORIGINAL_BRANCH"

package/skills/pr-release-loop/SKILL.md

@@ -3,8 +3,10 @@ name: pr-release-loop
 description: >-
   PR 发布完整闭环（循环 review 之后的收尾，也是跨系统链路验收的「阶段 2」）——创建 PR 后按 AGENTS.base.md
   「⚠️ 创建完 PR 后自动走完整闭环流程」自动走完 链路预演 → 循环 review → 重新部署测试环境 → 测试环境复测 →
-  确认 → 发 PR 链接 → 发新版本。核心防线：**循环 review 走完后，必须重新部署到测试环境并复测，确认没问题之后
-  才能发链接/发版**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
+  确认 → 发 PR 链接 → 交付测试环境。核心防线：**循环 review 走完后，必须重新部署到测试环境并复测，确认没问题之后
+  才能发链接/交付**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
+  ⚠️ **交付终点是测试环境，不发布生产**：业务仓库不执行 `./release.sh`；仅发版载体仓库（根目录确实存在
+  `./release.sh`，如 `@routerhub/agent-rules` 包自身）才在最后一步额外执行它发版。
   复测环节命中「跨系统真实链路验收铁律」触发条件时，自动触发 `real-chain-verify` **阶段 2**（完整验收）验到下游，
   并回填 PR 描述里的「跨系统链路验收」栏目（页面全绿 ≠ 链路跑通）。阶段 1「链路预演」应在循环 review 之前已完成，
   没做则先补做。
@@ -34,8 +36,8 @@ description: >-
   7. ✅ 与主分支无冲突（`gh pr view <PR> --json mergeable -q .mergeable` = `MERGEABLE`）
   8. ✅ GitHub 静态编译通过（`gh pr checks <PR>` 无 `failure`）
   9. ✅ PR 链接已发送给用户
-  10. ✅ 发新版本（`./release.sh`）
-- ⚠️ **循环 review 走完后，显式输出「✅ 循环 review 完成，进入发布收尾闭环」，然后逐项执行下面第 2～8 步，禁止在循环 review 结束后直接发链接/发版。** 若发现某一步没做（典型：忘了重新部署、复测是旧数据），必须停下来补齐再继续，禁止把「漏掉的第 3/4 步」带进交付。
+  10. ✅ 最新代码已交付到测试环境（`/deploy-test`）——**交付终点到此为止**；仅当本仓库根目录确实存在 `./release.sh`（发版载体仓库，如 `@routerhub/agent-rules` 包自身）时，才额外执行 `./release.sh` 发版
+- ⚠️ **循环 review 走完后，显式输出「✅ 循环 review 完成，进入发布收尾闭环」，然后逐项执行下面第 2～8 步，禁止在循环 review 结束后直接发链接/交付。** 若发现某一步没做（典型：忘了重新部署、复测是旧数据），必须停下来补齐再继续，禁止把「漏掉的第 3/4 步」带进交付。
 
 ## 核心流程
 
@@ -93,7 +95,7 @@ git push origin "$(git branch --show-current)"
 
 ### 6. 冲突检查 + 静态编译检查（三步收尾）
 
-用 `gh pr view <PR> --json mergeable -q .mergeable` 检查冲突（`CONFLICTING` 必须先解决），用 `gh pr checks <PR>` 检查 CI（有 `failure` 必须修复重推）。两者都通过后才发链接/发版。
+用 `gh pr view <PR> --json mergeable -q .mergeable` 检查冲突（`CONFLICTING` 必须先解决），用 `gh pr checks <PR>` 检查 CI（有 `failure` 必须修复重推）。两者都通过后才发链接/交付。
 
 ### 7. 发 PR 链接给用户
 
@@ -101,17 +103,19 @@ git push origin "$(git branch --show-current)"
 gh pr view <PR> --json url -q .url
 ```
 
-一般按下流程：循环 review 全部通过 → 部署测试环境复测 → 确认后**先发 PR 链接，再发版**。
+一般按下流程：循环 review 全部通过 → 部署测试环境复测 → 确认后**先发 PR 链接，再交付测试环境**。
 
-### 8. 发新版本
+### 8. 交付测试环境（不是发版）
 
-PR 合并后按项目发布流程执行根目录 `./release.sh` 发新版本（自动完成 patch 号 +1、更新 `package.json`、`git commit`/`push`、打 tag、`npm publish`）。
+PR 合并后把最新代码交付到**测试环境**（走 `/deploy-test` skill）。⚠️ **业务仓库的交付终点就是测试环境，不发布生产**。
+
+⚠️ **`./release.sh` 只属于发版载体仓库**：仅当本仓库根目录**确实存在** `./release.sh`（如 `@routerhub/agent-rules` 包自身——它靠 npm publish 发版，下游仓库靠依赖升级拿到新规则）时，才在这一步额外执行它（自动完成 patch 号 +1、更新 `package.json`、`git commit`/`push`、打 tag、`npm publish`）。**根目录没有该脚本 = 本仓库不是发版载体，此步到此结束；禁止据此推断出「那大概是生产部署吧」再补一个替代动作**（呼应 AGENTS.base.md「⚠️ 环境配置禁止推断」）。
 
 ## 判断边界
 
-- ⚠️ **如果循环 review 走完但没有重新部署测试就发链接/发版 → 直接违背闭环，必须停下并报告缺失项**（你没说过「跳过复测」，这属于该做而没做）。
-- ⚠️ **用户明确说「不用部署测试」「跳过复测，直接发版」等显式指令** → 按用户指令执行，不必拦（但要在交付时说明「本次跳过了测试环境复测」）。
-- ⚠️ **纯文档/无逻辑改动（如只改 README）** → 可以跳过复测，但发链接/发版前仍要完成冲突+编译检查。
+- ⚠️ **如果循环 review 走完但没有重新部署测试就发链接/交付 → 直接违背闭环，必须停下并报告缺失项**（你没说过「跳过复测」，这属于该做而没做）。
+- ⚠️ **用户明确说「不用部署测试」「跳过复测，直接交付」等显式指令** → 按用户指令执行，不必拦（但要在交付时说明「本次跳过了测试环境复测」）。
+- ⚠️ **纯文档/无逻辑改动（如只改 README）** → 可以跳过复测，但发链接/交付前仍要完成冲突+编译检查。
 
 ## 相关