@routerhub/agent-rules 1.5.201 → 1.5.203

package/AGENTS.base.md

@@ -194,6 +194,38 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - 反面示例：验证「强制改密后重新登录」，只测「改密成功 → 页面稳定 → 输入新密码登录」正常路径，不造 `must_change_password=1` 账号、不在改密成功被弹回的 1.5s 窗口里抢点登录——bug 永远复现不了，上线后用户一操作就卡在 Signing in…。
   - 自查：验证这类流程前先自问——「前置的『被强制状态』我造了吗？切换后的『不等落定立即抢』我试了吗？」任一为否 = 时序路径没测全，先补再交付。
 
+## ⚠️ 跨系统真实链路验收铁律（页面全绿 ≠ 链路跑通）
+
+- ⚠️ **核心认知：功能验证是两层，缺第二层等于没验。** 第一层「本系统对不对」——本系统的页面/接口用真实数据、真实交互走一遍（见「页面功能验证铁律」「可视化验证铁律」，已覆盖）；第二层「整条链路成不成立」——从**用户动作的起点**，一路穿到**最终生效的下游系统**，用真实流量走完整流程。**第二层只有真跑一遍才有答案：代码 review 看的是 diff（静态），页面截图看的是本系统（局部），两者都给不出「下游到底接没接住」。**
+- **类比：验收一台新装的净水器，不能只看「水龙头拧开有水出来」（本系统页面全绿），得真的接一杯水去测——水有没有经过滤芯、滤芯有没有装反、是不是走了旁路直通，只有把水接出来验过才知道。只看水龙头出水就签字，等于没验。**
+- ⚠️ **触发条件（命中任一 → 本次必须做跨系统真实链路验收，禁止只交本系统页面截图）：**
+  1. **改动跨系统 / 跨仓库**：本次改动让某个动作流向下游消费方（网关路由、定价、计费、限流、监控、外部上游），而**消费方代码在别的仓库**；
+  2. **新增「默认值类」字段**：priority / 限额 / 状态 / 开关 / 优先级等「不填就用默认值」的字段；
+  3. **涉及金额、路由、权限、限流**：改动会影响谁被扣钱、谁被放行、请求走到哪；
+  4. **新增表 / 字段参与「对外可见 / 放行」判定**：官网展示、模型目录、可调用列表等。
+- ⚠️ **硬性动作（四步缺一不算完成）：**
+  1. **先画链路再验证**：动手验收前，先把本次改动从「用户动作起点」到「最终生效处」穿过哪些系统逐环节列出来（如：门户点启用 → 本系统后端 → 网关选路 → 上游 → 计费落库 → 监控归因）。链路没画出来 = 不知道该验哪些环节 = 必然漏。
+  2. **每个环节取一条「下游可观测事实」**：证据必须是**下游系统里能看到的东西**，不是本系统的回显。❌「门户页面显示 Active」✅「网关 `/v1/models` 里精确出现了这个模型」；❌「Dashboard 说发了请求」✅「请求计数 / Top Errors 归因到了这个账号」。
+  3. **至少一条「下游真实生效」证据**：真实请求打进去，且在**最终生效的下游**留下痕迹（列表增减、请求计数、归因、计费落库、监控曲线）。只有本系统日志、没有下游痕迹 = 只能证明「我发了」，不能证明「它接住了」。
+  4. **「默认值类」字段必须额外回答**：这个默认值和**线上存量数据**放一起是什么效果？（案例：新账号 priority 默认 100，平台存量账号是 10，按升序排永远轮不到它——门户显示 Active、模型已绑定，实际长期零流量且无任何提示。单看这行代码完全正确，错在与已有数据的关系。）
+- ⚠️ **四类只有真实链路能暴露的问题（写代码时就该预判，别等验收才发现）：**
+  1. **跨仓库 / 跨系统**：根因代码不在本次 diff 里，review 结构上审不到（如门户把「绑模型」开放给 vendor，而该模型缺定价时网关直接 503——定价查询在网关仓库）。
+  2. **默认值 × 存量数据**：代码本身正确，错在默认值与已有数据的相互作用（见上条 priority 案例）。
+  3. **需求口径变化**：代码自洽，但产品预期是另一回事（如「删账号时挂着模型该不该拦」——产品前后改过口径，代码没错，只是对不上当前预期）。
+  4. **精度 / 规模临界**：只在真实的小数值、低用量场景显形（如成本 $0.004 按两位小数显示成 $0.00，用户看到「有请求但成本是 0」）。
+- ⚠️ **反模式（命中即视为未验收）：**
+  - ❌ **把「门户页面全绿」当「链路跑通」**——页面是本系统的回显，跑通是下游真的接住了。
+  - ❌ **把「循环 review 全过」当「功能成立」**——review 审的是代码有没有缺陷，管不了「这套组合在真实系统里行不行」。
+  - ❌ **把「部署成功 + 截图」当「验收完成」**——部署证明代码上线了，不证明功能用得了。
+- ⚠️ **与循环 review 的分工（两者不可互相替代）**：**循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。**
+- ⚠️ **执行时机：拆成两段，禁止合并成一次（顺序错了会白跑 review）。**
+  - **阶段 1「链路预演」——创建 PR 后、循环 review 之前，轻量。** 只回答两件事：**这条链路成不成立、需求口径对不对**。产出只要「链路图 + 每个环节能不能通」的判断，**不写 6 段报告、不做截图箭头标注、不出交付文档**（约为阶段 2 的 20~30% 工作量）。
+  - **阶段 2「链路验收」——循环 review 收敛、重新部署之后，完整。** 走完整取证、6 段报告与截图标注，作为交付证据。
+  - ⚠️ **为什么必须两段而不是一次**：本流程要暴露的四类问题（跨仓库语义 / 需求口径 / 默认值×存量 / 精度临界）**修复代价都是「大改」**（改需求、改默认值、改 schema、改交互），而 review 修的是「代码写得对不对」（小改）。**把大改的发现压到最后，等于先用 N 轮把一个可能要推翻重做的东西打磨到没有代码缺陷，再发现它根本不该这么做**——review 成果直接作废，改完还得重跑 review。真实案例：PR #158 的问题 B 是需求口径反转（09-04 要求拦截 → 09-08 改成顺带清绑定）、问题 C 要改默认值并和存量数据对齐，两者都会让前面已 review 通过的代码整体作废。
+  - ⚠️ **为什么阶段 2 不能提前到 review 之前**：验的必须是「最终要发布的那个版本」。review 会 push 新 commit，提前验完的代码后面会被改，那次证据直接作废、还得再验一遍。阶段 2 的位置是硬的，只能压在最后。
+  - ⚠️ **不命中触发条件的改动，两段都不走**（纯文案、纯展示类改动不受影响）。
+- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、两段各自做到什么程度、证据怎么组织成报告）。
+
 ## Git 规范
 
 - 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
@@ -264,10 +296,11 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 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 链接给用户 → 发新版本，六步缺一不可，全程自动执行：
+- ⚠️ **创建完 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` 重部署。**
-3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：真实视口 + `fullPage` 全页、URL 可见、存盘到 `screenshots/` 临时目录），并在每张截图上用**坐标换算后的箭头标注**（走 `/screenshot-annotate` skill）关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
+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` 发新版本。
@@ -780,12 +813,13 @@ Chrome Helper 会越积越多，表现为“agent-browser 用着用着越来越
 - 🟡 **真实风险**：有明确触发条件，且触发后后果严重（如并发竞态、错误被静默吞掉、未处理空值导致崩溃）。
 - **违反本项目已固化规则**：AGENTS.base.md / AGENTS.private.md 里的 ⚠️ 铁律（DELETE 铁律、部署自包含、数据链路核对、环境配置禁止推断、测试环境验证前置等），diff 中明确违反 → 必须报。
 - **外部事实核查确认的配置错误**：按「审查方法 → ④ 外部事实核查」查出的事实性错误（死域名、环境归属不一致、对外死值等），即使 diff 内部自洽也必须报——这正是「指向错误环境」类问题的唯一暴露途径（呼应「环境配置禁止推断」）。
+- **跨仓库 / 跨系统的行为变更（diff 内自洽、静态审不出的那一类）**：本次改动**把某个动作开放到了新入口**（如把管理员专有操作开放给外部自助用户），而该动作的**下游消费方在别的仓库**（网关路由 / 定价 / 计费 / 限流 / 外部上游）时，必须报「下游系统语义需人工确认」——这类问题 diff 内部完全自洽、静态审不出来，只有真实链路能暴露（呼应「跨系统真实链路验收铁律」的四类问题①）。⚠️ **报的同时必须给出具体指向：下游在哪个仓库/哪个模块、要确认哪个具体行为、确认不了会导致什么后果**（正例：「门户把『绑模型』开放给 vendor，但该模型未登记定价时网关定价查询会直接 503——需确认 `<下游仓库>` 的 pricing lookup 对未登记模型的行为，以及门户是否该在绑定时校验定价存在」）。**禁止**只写「建议确认一下」这类没有指向的空泛意见——没给出具体仓库 + 具体行为 + 具体后果的，一律按「无法确认真假」不报（见下方禁止报）。
 
 ### 禁止报（不是问题，报了只会拉长循环）
 
 - 🔵 **口味 / 风格偏好**：换个命名更好、建议用某设计模式、提取公共函数、重构建议——作者规则已规范，审稿人不要另立标准。
 - 🛡️ **纯防御性建议**：以「如果未来 / 万一 / 边界情况下」开头、当前代码没有实际触发路径的「潜在风险」（如「序号 99999 溢出」「未来可能有人改这里」），一律不报。
-- ❓ **无法确认真假的问题**：读 diff 不能确认会导致 bug 的，默认按「不是问题」处理，禁止报「建议确认一下」这类空泛意见。
+- ❓ **无法确认真假的问题**：读 diff 不能确认会导致 bug 的，默认按「不是问题」处理，禁止报「建议确认一下」这类空泛意见。（**唯一例外**：跨仓库 / 跨系统的行为变更——见上方「必须报」最后一条，但必须带「哪个仓库 + 哪个具体行为 + 什么后果」的完整指向，缺少任一项仍按本条不报。）
 - 🔁 **重复已处理的问题**：已在评论 / 历史中标记 Won't fix 或「已修复于 &lt;hash&gt;」的问题，不再重提。
 - 🔒 **「文档内嵌真实敏感值」**：AGENTS.base.md 明文规定「示例命令 / 文档内嵌真实 Token/密钥」为**有意为之的既定规则**，不属于安全漏洞，**禁止**作为密钥泄露 / 安全漏洞上报，也**禁止**建议删除该条或改回占位符。与「密钥配到 Nacos」「禁止 cat 密钥文件」互不冲突：后者约束运行时配置与终端处理，本条约束文档示例的可复制性，两个场景互不重叠。
 - 🔧 **「AGENTS.base.md 未同步」**：下游业务仓库的 AGENTS.md / CLAUDE.md / .github/copilot-instructions.md 由 **@routerhub/agent-rules 发版同步**（npm 包 postinstall 自动生成），业务仓库内**不存在** `AGENTS.base.md` 源文件，`node merge.js sync` 只在 agent-rules 仓库执行。审稿方**禁止**因「diff 修改了 AGENTS.md / CLAUDE.md 但未出现 AGENTS.base.md 改动」而报错——业务仓库本就没有此文件，规则改动由 agent-rules 发版统一管理，属正常流程。
@@ -841,6 +875,8 @@ Chrome Helper 会越积越多，表现为“agent-browser 用着用着越来越
 
 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.
 
+DO report cross-repo / cross-system behavior changes: when the diff opens an existing action to a NEW entry point (e.g. exposing an admin-only operation to external self-service users) and that action's downstream consumer lives in ANOTHER repository (gateway routing, pricing, billing, rate limiting, external upstream), report it as "downstream semantics need human confirmation" — these are self-consistent inside the diff and invisible to static review, yet only surface on a real end-to-end run. You MUST name the specific repo/module, the specific behavior to confirm, and the consequence of not confirming. A vague "please verify" without that detail is NOT reportable.
+
 Do NOT report:
 
 - Style, naming, or personal-preference opinions.

package/CHANGELOG.md

@@ -2,6 +2,29 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
+## [1.5.203] - 2026-09-10
+
+### Changed
+
+- **「跨系统真实链路验收」改为两段式执行（阶段 1 在循环 review 之前，阶段 2 在之后）**：原先只在循环 review 收敛、重新部署之后做一次完整验收。改为**阶段 1「链路预演」提前到创建 PR 后、循环 review 之前**（轻量：只画链路 + 逐环节判通不通，不写 6 段报告、不做截图标注，约阶段 2 的 20~30% 工作量），目的只有一个——**尽早暴露需要「大改」的问题**（需求口径反转、默认值不对、跨仓库语义不成立、schema 要改）。**阶段 2「链路验收」位置不变**（必须验最终要发布的那个版本，review 会 push 新 commit，提前验的证据会作废）。理由：本流程要暴露的四类问题修复代价都是大改，而 review 修的是小改；把大改压到最后 = 先用 N 轮把一个可能要推翻重做的东西打磨到没有代码缺陷，再发现它根本不该这么做（PR #158 问题 B/C 即此）。闭环流程由六步扩为七步（新增步骤 0「链路预演」）。
+
+### Added
+
+- **PR 模板新增「跨系统链路验收」栏目**：命中 4 条触发条件的，须填 ① 链路预演（链路图 + 各环节归属系统 + 能否走通）② 链路验收（下游真实生效证据 + 默认值类字段与存量数据对照）；未命中的勾选豁免项。Checklist 同步新增一项。**作用是把链路验收从「AI 自查完就没了」变成 PR 里留痕、reviewer 能看见，不填等于这一环做了也没人知道。**
+- `real-chain-verify` skill 新增「两段式」章节（两段各自时机/回答什么/做到什么程度/工作量对照表，以及为什么两段、为什么阶段 2 不能提前）；`create-pr`、`pr-release-loop` skill 同步挂钩（阶段 1 挂到创建 PR 后的闭环步骤 2，阶段 2 挂到复测步骤并回填 PR 栏目）。
+
+## [1.5.202] - 2026-09-10
+
+### Added
+
+- **新增「跨系统真实链路验收铁律」**：根治「本系统页面全绿、下游根本没接住」——核心认知是功能验证分两层，第一层「本系统对不对」（页面能跑、接口 200），第二层「整条链路成不成立」（从用户动作起点一路穿到最终生效的下游系统，用真实流量走完整流程）。**第二层只有真跑一遍才有答案：代码 review 看的是 diff（静态），页面截图看的是本系统（局部），两者都给不出「下游到底接没接住」。** 规则列出 4 条触发条件（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定），命中即必须做跨系统真实链路验收，并给出四步硬性动作（先画链路再验证 / 每个环节取一条「下游可观测事实」/ 至少一条「下游真实生效」证据 / 默认值类字段必须与线上存量数据对照效果）。
+- **新增 `real-chain-verify` skill**：跨系统真实链路验收的完整操作流程——判定触发 → 画链路图 → 逐环节取证（网关/路由、计费、限流、数据库、Redis、监控、外部上游各自的取证方式）→ 取下游真实生效证据 → 默认值字段与存量数据对照 → 按 6 段结构组织验收报告 → 发现问题按四类归属（跨仓库/默认值×存量/需求口径变化/精度规模临界）分派修复。
+- **`pr-release-loop` skill 挂钩真实链路验收**：复测环节先判断是否命中触发条件，命中则必须触发 `/real-chain-verify` 验到下游，禁止只交本系统页面截图就当作复测完成；完成定义清单同步收紧。
+
+### Changed
+
+- **审稿边界新增「跨仓库 / 跨系统的行为变更」为必须报项**：本次改动把某个动作开放到了新入口（如把管理员专有操作开放给外部自助用户），而该动作的下游消费方在别的仓库（网关路由/定价/计费/限流/外部上游）时，review 必须报「下游系统语义需人工确认」——这类问题 diff 内自洽、静态审不出，只有真实端到端跑一遍才暴露。**同时硬性要求必须给出「哪个仓库 + 哪个具体行为 + 什么后果」的完整指向，缺少任一项仍按「无法确认真假」不报**，防止退化成「建议确认一下」式的空泛意见拖长循环。
+
 ## [1.5.201] - 2026-09-08
 
 ### Fixed

package/PULL_REQUEST_TEMPLATE.md

@@ -7,6 +7,30 @@
 
 Closes #
 
+## 跨系统链路验收
+
+<!-- 先判断是否命中 AGENTS.base.md「⚠️ 跨系统真实链路验收铁律」的 4 条触发条件（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定）。 -->
+<!-- 未命中：把下面那个勾选框打上，本栏目到此为止。 -->
+<!-- 命中：链路预演（循环 review 之前）与链路验收（review 收敛后）两段的证据都要在此留痕。 -->
+
+- [ ] 本次改动**未命中**上述 4 条触发条件，无需跨系统链路验收
+
+**① 链路预演**（创建 PR 后、循环 review 之前，轻量：只回答「链路成不成立、需求口径对不对」）
+
+```
+链路：<用户动作起点> → <本系统> → <下游环节> → <最终生效处>
+```
+
+| 环节 | 归属系统/仓库 | 能否走通 | 观察到的事实 |
+|---|---|---|---|
+| | | | |
+
+**② 链路验收**（循环 review 收敛、重新部署之后，完整：作为交付证据）
+
+- **下游真实生效证据**（必须来自下游系统，不是本系统回显）：
+  - ❌「门户页面显示 Active」 ✅「网关 `/v1/models` 里精确出现了这个模型」
+- **默认值类字段与存量数据对照**（命中触发条件 2 时必填）：默认值 → 下游消费规则 → 线上存量数据 → 叠加效果
+
 ## Test Plan
 
 <!-- 硬性必填：如何验证改动正确，附可复现步骤或证据（命令 + 结果、手动操作步骤、日志、请求响应、修复前后对比）。 -->
@@ -22,6 +46,7 @@ Closes #
 - [ ] 一个 PR 只做一件事，无夹带无关改动
 - [ ] Description 已说明 What / Why / How
 - [ ] Test Plan 完整且带证据
+- [ ] 跨系统链路验收已按上方栏目填完（未命中触发条件则勾选豁免项）
 - [ ] UI 改动已贴截图（或注明无界面变化）
 - [ ] 本地编译 / lint / 测试通过，CI 全绿
 - [ ] 已关联 issue、指定 reviewer

package/package.json

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

package/rules/global.md

@@ -194,6 +194,38 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - 反面示例：验证「强制改密后重新登录」，只测「改密成功 → 页面稳定 → 输入新密码登录」正常路径，不造 `must_change_password=1` 账号、不在改密成功被弹回的 1.5s 窗口里抢点登录——bug 永远复现不了，上线后用户一操作就卡在 Signing in…。
   - 自查：验证这类流程前先自问——「前置的『被强制状态』我造了吗？切换后的『不等落定立即抢』我试了吗？」任一为否 = 时序路径没测全，先补再交付。
 
+## ⚠️ 跨系统真实链路验收铁律（页面全绿 ≠ 链路跑通）
+
+- ⚠️ **核心认知：功能验证是两层，缺第二层等于没验。** 第一层「本系统对不对」——本系统的页面/接口用真实数据、真实交互走一遍（见「页面功能验证铁律」「可视化验证铁律」，已覆盖）；第二层「整条链路成不成立」——从**用户动作的起点**，一路穿到**最终生效的下游系统**，用真实流量走完整流程。**第二层只有真跑一遍才有答案：代码 review 看的是 diff（静态），页面截图看的是本系统（局部），两者都给不出「下游到底接没接住」。**
+- **类比：验收一台新装的净水器，不能只看「水龙头拧开有水出来」（本系统页面全绿），得真的接一杯水去测——水有没有经过滤芯、滤芯有没有装反、是不是走了旁路直通，只有把水接出来验过才知道。只看水龙头出水就签字，等于没验。**
+- ⚠️ **触发条件（命中任一 → 本次必须做跨系统真实链路验收，禁止只交本系统页面截图）：**
+  1. **改动跨系统 / 跨仓库**：本次改动让某个动作流向下游消费方（网关路由、定价、计费、限流、监控、外部上游），而**消费方代码在别的仓库**；
+  2. **新增「默认值类」字段**：priority / 限额 / 状态 / 开关 / 优先级等「不填就用默认值」的字段；
+  3. **涉及金额、路由、权限、限流**：改动会影响谁被扣钱、谁被放行、请求走到哪；
+  4. **新增表 / 字段参与「对外可见 / 放行」判定**：官网展示、模型目录、可调用列表等。
+- ⚠️ **硬性动作（四步缺一不算完成）：**
+  1. **先画链路再验证**：动手验收前，先把本次改动从「用户动作起点」到「最终生效处」穿过哪些系统逐环节列出来（如：门户点启用 → 本系统后端 → 网关选路 → 上游 → 计费落库 → 监控归因）。链路没画出来 = 不知道该验哪些环节 = 必然漏。
+  2. **每个环节取一条「下游可观测事实」**：证据必须是**下游系统里能看到的东西**，不是本系统的回显。❌「门户页面显示 Active」✅「网关 `/v1/models` 里精确出现了这个模型」；❌「Dashboard 说发了请求」✅「请求计数 / Top Errors 归因到了这个账号」。
+  3. **至少一条「下游真实生效」证据**：真实请求打进去，且在**最终生效的下游**留下痕迹（列表增减、请求计数、归因、计费落库、监控曲线）。只有本系统日志、没有下游痕迹 = 只能证明「我发了」，不能证明「它接住了」。
+  4. **「默认值类」字段必须额外回答**：这个默认值和**线上存量数据**放一起是什么效果？（案例：新账号 priority 默认 100，平台存量账号是 10，按升序排永远轮不到它——门户显示 Active、模型已绑定，实际长期零流量且无任何提示。单看这行代码完全正确，错在与已有数据的关系。）
+- ⚠️ **四类只有真实链路能暴露的问题（写代码时就该预判，别等验收才发现）：**
+  1. **跨仓库 / 跨系统**：根因代码不在本次 diff 里，review 结构上审不到（如门户把「绑模型」开放给 vendor，而该模型缺定价时网关直接 503——定价查询在网关仓库）。
+  2. **默认值 × 存量数据**：代码本身正确，错在默认值与已有数据的相互作用（见上条 priority 案例）。
+  3. **需求口径变化**：代码自洽，但产品预期是另一回事（如「删账号时挂着模型该不该拦」——产品前后改过口径，代码没错，只是对不上当前预期）。
+  4. **精度 / 规模临界**：只在真实的小数值、低用量场景显形（如成本 $0.004 按两位小数显示成 $0.00，用户看到「有请求但成本是 0」）。
+- ⚠️ **反模式（命中即视为未验收）：**
+  - ❌ **把「门户页面全绿」当「链路跑通」**——页面是本系统的回显，跑通是下游真的接住了。
+  - ❌ **把「循环 review 全过」当「功能成立」**——review 审的是代码有没有缺陷，管不了「这套组合在真实系统里行不行」。
+  - ❌ **把「部署成功 + 截图」当「验收完成」**——部署证明代码上线了，不证明功能用得了。
+- ⚠️ **与循环 review 的分工（两者不可互相替代）**：**循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。**
+- ⚠️ **执行时机：拆成两段，禁止合并成一次（顺序错了会白跑 review）。**
+  - **阶段 1「链路预演」——创建 PR 后、循环 review 之前，轻量。** 只回答两件事：**这条链路成不成立、需求口径对不对**。产出只要「链路图 + 每个环节能不能通」的判断，**不写 6 段报告、不做截图箭头标注、不出交付文档**（约为阶段 2 的 20~30% 工作量）。
+  - **阶段 2「链路验收」——循环 review 收敛、重新部署之后，完整。** 走完整取证、6 段报告与截图标注，作为交付证据。
+  - ⚠️ **为什么必须两段而不是一次**：本流程要暴露的四类问题（跨仓库语义 / 需求口径 / 默认值×存量 / 精度临界）**修复代价都是「大改」**（改需求、改默认值、改 schema、改交互），而 review 修的是「代码写得对不对」（小改）。**把大改的发现压到最后，等于先用 N 轮把一个可能要推翻重做的东西打磨到没有代码缺陷，再发现它根本不该这么做**——review 成果直接作废，改完还得重跑 review。真实案例：PR #158 的问题 B 是需求口径反转（09-04 要求拦截 → 09-08 改成顺带清绑定）、问题 C 要改默认值并和存量数据对齐，两者都会让前面已 review 通过的代码整体作废。
+  - ⚠️ **为什么阶段 2 不能提前到 review 之前**：验的必须是「最终要发布的那个版本」。review 会 push 新 commit，提前验完的代码后面会被改，那次证据直接作废、还得再验一遍。阶段 2 的位置是硬的，只能压在最后。
+  - ⚠️ **不命中触发条件的改动，两段都不走**（纯文案、纯展示类改动不受影响）。
+- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、两段各自做到什么程度、证据怎么组织成报告）。
+
 ## Git 规范
 
 - 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
@@ -264,10 +296,11 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 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 链接给用户 → 发新版本，六步缺一不可，全程自动执行：
+- ⚠️ **创建完 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` 重部署。**
-3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：真实视口 + `fullPage` 全页、URL 可见、存盘到 `screenshots/` 临时目录），并在每张截图上用**坐标换算后的箭头标注**（走 `/screenshot-annotate` skill）关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
+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` 发新版本。

package/rules/review-boundary.md

@@ -14,12 +14,13 @@ outputName: "review-boundary"
 - 🟡 **真实风险**：有明确触发条件，且触发后后果严重（如并发竞态、错误被静默吞掉、未处理空值导致崩溃）。
 - **违反本项目已固化规则**：AGENTS.base.md / AGENTS.private.md 里的 ⚠️ 铁律（DELETE 铁律、部署自包含、数据链路核对、环境配置禁止推断、测试环境验证前置等），diff 中明确违反 → 必须报。
 - **外部事实核查确认的配置错误**：按「审查方法 → ④ 外部事实核查」查出的事实性错误（死域名、环境归属不一致、对外死值等），即使 diff 内部自洽也必须报——这正是「指向错误环境」类问题的唯一暴露途径（呼应「环境配置禁止推断」）。
+- **跨仓库 / 跨系统的行为变更（diff 内自洽、静态审不出的那一类）**：本次改动**把某个动作开放到了新入口**（如把管理员专有操作开放给外部自助用户），而该动作的**下游消费方在别的仓库**（网关路由 / 定价 / 计费 / 限流 / 外部上游）时，必须报「下游系统语义需人工确认」——这类问题 diff 内部完全自洽、静态审不出来，只有真实链路能暴露（呼应「跨系统真实链路验收铁律」的四类问题①）。⚠️ **报的同时必须给出具体指向：下游在哪个仓库/哪个模块、要确认哪个具体行为、确认不了会导致什么后果**（正例：「门户把『绑模型』开放给 vendor，但该模型未登记定价时网关定价查询会直接 503——需确认 `<下游仓库>` 的 pricing lookup 对未登记模型的行为，以及门户是否该在绑定时校验定价存在」）。**禁止**只写「建议确认一下」这类没有指向的空泛意见——没给出具体仓库 + 具体行为 + 具体后果的，一律按「无法确认真假」不报（见下方禁止报）。
 
 ### 禁止报（不是问题，报了只会拉长循环）
 
 - 🔵 **口味 / 风格偏好**：换个命名更好、建议用某设计模式、提取公共函数、重构建议——作者规则已规范，审稿人不要另立标准。
 - 🛡️ **纯防御性建议**：以「如果未来 / 万一 / 边界情况下」开头、当前代码没有实际触发路径的「潜在风险」（如「序号 99999 溢出」「未来可能有人改这里」），一律不报。
-- ❓ **无法确认真假的问题**：读 diff 不能确认会导致 bug 的，默认按「不是问题」处理，禁止报「建议确认一下」这类空泛意见。
+- ❓ **无法确认真假的问题**：读 diff 不能确认会导致 bug 的，默认按「不是问题」处理，禁止报「建议确认一下」这类空泛意见。（**唯一例外**：跨仓库 / 跨系统的行为变更——见上方「必须报」最后一条，但必须带「哪个仓库 + 哪个具体行为 + 什么后果」的完整指向，缺少任一项仍按本条不报。）
 - 🔁 **重复已处理的问题**：已在评论 / 历史中标记 Won't fix 或「已修复于 &lt;hash&gt;」的问题，不再重提。
 - 🔒 **「文档内嵌真实敏感值」**：AGENTS.base.md 明文规定「示例命令 / 文档内嵌真实 Token/密钥」为**有意为之的既定规则**，不属于安全漏洞，**禁止**作为密钥泄露 / 安全漏洞上报，也**禁止**建议删除该条或改回占位符。与「密钥配到 Nacos」「禁止 cat 密钥文件」互不冲突：后者约束运行时配置与终端处理，本条约束文档示例的可复制性，两个场景互不重叠。
 - 🔧 **「AGENTS.base.md 未同步」**：下游业务仓库的 AGENTS.md / CLAUDE.md / .github/copilot-instructions.md 由 **@routerhub/agent-rules 发版同步**（npm 包 postinstall 自动生成），业务仓库内**不存在** `AGENTS.base.md` 源文件，`node merge.js sync` 只在 agent-rules 仓库执行。审稿方**禁止**因「diff 修改了 AGENTS.md / CLAUDE.md 但未出现 AGENTS.base.md 改动」而报错——业务仓库本就没有此文件，规则改动由 agent-rules 发版统一管理，属正常流程。
@@ -75,6 +76,8 @@ outputName: "review-boundary"
 
 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.
 
+DO report cross-repo / cross-system behavior changes: when the diff opens an existing action to a NEW entry point (e.g. exposing an admin-only operation to external self-service users) and that action's downstream consumer lives in ANOTHER repository (gateway routing, pricing, billing, rate limiting, external upstream), report it as "downstream semantics need human confirmation" — these are self-consistent inside the diff and invisible to static review, yet only surface on a real end-to-end run. You MUST name the specific repo/module, the specific behavior to confirm, and the consequence of not confirming. A vague "please verify" without that detail is NOT reportable.
+
 Do NOT report:
 
 - Style, naming, or personal-preference opinions.

package/skills/create-pr/SKILL.md

@@ -117,11 +117,12 @@ gh pr create \
 ⚠️ 创建完 PR 后，禁止只做完步骤 8 收尾就交付。必须自动依次走完下方闭环，全程自动执行，未走完不算完成：
 
 1. **先做 CI 闸门检查**：创建 PR 后立即执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若存在任一 `failure`，必须先定位失败根因并修复，推送后复查到全部 `success`，再继续后续步骤；禁止带红 CI 进入下一步。
-2. **自动走循环 review**：自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束。
-3. **重新部署到测试环境**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。
-4. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：真实视口 + `fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并在每张截图上用**坐标换算后的箭头标注**（走 `/screenshot-annotate` skill）关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
-5. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
-6. **发新版本**：确认没问题后，回到下方步骤 8 完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
+2. **链路预演（在循环 review 之前，轻量）**：判断本次改动是否命中「⚠️ 跨系统真实链路验收铁律」的 4 条触发条件（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定）。命中 → 触发 `/real-chain-verify` 的**阶段 1**：只画链路、逐环节快速过一遍，回答「这条链路成不成立、需求口径对不对」，**不写 6 段报告、不做截图标注**。⚠️ **发现需要大改（需求口径反转、默认值不对、跨仓库语义不成立、schema 要改）时，先改完再进循环 review**——大改放在 review 之后发现 = 前面 N 轮 review 全白跑。未命中 → 跳过本步，在 PR 描述里勾选豁免项。
+3. **自动走循环 review**：自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束。
+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` 发新版本。
 
 ### 8. 每次修改 PR 后收尾检查（冲突 + 静态编译 + 发版本）
 
@@ -156,6 +157,7 @@ gh pr checks <PR>
 - ⚠️ 截图禁止提交到 Git 仓库
 - ⚠️ PR 截图直接内嵌在 Description 正文中（Markdown 图片语法）
 - ⚠️ 每次修改 PR 后（含创建、push 新提交、响应 review 意见）都必须做三步收尾：冲突检查 → 静态编译检查 → PR 合并后发新版本（见步骤 8）
-- ⚠️ **创建完 PR 后必须自动走完整闭环流程（见步骤 7.5）**：创建 PR → 先做 CI 闸门检查并修复失败项 → 自动循环 review → 重新部署测试环境验证（全程截图 + 箭头标注）→ 确认没问题 → 发新版本，六步缺一不可，未走完不算完成
+- ⚠️ **创建完 PR 后必须自动走完整闭环流程（见步骤 7.5）**：创建 PR → 先做 CI 闸门检查并修复失败项 → **链路预演（命中跨系统链路验收触发条件时，在循环 review 之前先跑，只为尽早暴露需要大改的问题）** → 自动循环 review → 重新部署测试环境验证（全程截图 + 箭头标注，命中触发条件的走 `/real-chain-verify` 阶段 2）→ 确认没问题 → 发新版本，七步缺一不可，未走完不算完成
+- ⚠️ **PR 描述里必须填「跨系统链路验收」栏目**（PR 模板已内置）：命中 4 条触发条件的填链路预演链路图 + 下游真实生效证据 + 默认值对照；未命中的勾选豁免项。**留痕是给 reviewer 看的——不填等于这一环做了也没人知道。**
 - ⚠️ **直接创建正式 PR（非 Draft）**：PR 创建完成即进入可评审状态，可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review
 - 作者不能 Approve 自己的 PR

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

@@ -1,11 +1,15 @@
 ---
 name: pr-release-loop
 description: >-
-  PR 发布完整闭环（循环 review 之后的收尾）——创建 PR 后按 AGENTS.base.md「⚠️ 创建完 PR 后自动走完整闭环流程」自动走完
-  循环 review → 重新部署测试环境 → 测试环境复测 → 确认 → 发 PR 链接 → 发新版本 六步。核心防线：**循环 review 走完后，
-  必须重新部署到测试环境并复测，确认没问题之后才能发链接/发版**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
+  PR 发布完整闭环（循环 review 之后的收尾，也是跨系统链路验收的「阶段 2」）——创建 PR 后按 AGENTS.base.md
+  「⚠️ 创建完 PR 后自动走完整闭环流程」自动走完 链路预演 → 循环 review → 重新部署测试环境 → 测试环境复测 →
+  确认 → 发 PR 链接 → 发新版本。核心防线：**循环 review 走完后，必须重新部署到测试环境并复测，确认没问题之后
+  才能发链接/发版**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
+  复测环节命中「跨系统真实链路验收铁律」触发条件时，自动触发 `real-chain-verify` **阶段 2**（完整验收）验到下游，
+  并回填 PR 描述里的「跨系统链路验收」栏目（页面全绿 ≠ 链路跑通）。阶段 1「链路预演」应在循环 review 之前已完成，
+  没做则先补做。
   触发场景包括但不限于：
-  「PR闭环」「闭环走完」「完整闭环」「六步闭环」「走完整流程」「收尾」「发布闭环」「发布收尾」「循环review完再部署测一遍」「测试环境再测一遍」。
+  「PR闭环」「闭环走完」「完整闭环」「六步闭环」「七步闭环」「走完整流程」「收尾」「发布闭环」「发布收尾」「循环review完再部署测一遍」「测试环境再测一遍」。
   以及「创建PR后的完整流程」「走完循环review流程」「循环review完之后」。
   当循环 review 显示「无值得修的新问题」、进入收尾阶段时，**自动触发本 Skill**，无需用户再开口。
 ---
@@ -19,15 +23,17 @@ description: >-
 ## ⚠️ 核心铁律（违反即错误）
 
 - ⚠️ **循环 review 结束 ≠ 完成。** review 期间会 push 新 commit，**只有把最新代码重新部署到测试环境、在测试环境复测通过，才算真正完成**。跳过复测直接用旧代码下结论 = 白 review。
+- ⚠️ **本 Skill 是「链路验收」的阶段 2。** 跨系统真实链路验收分两段：阶段 1「链路预演」应在**创建 PR 后、循环 review 之前**已完成（轻量：只画链路 + 判通不通）；阶段 2 就是本 Skill 的第 3、4 步（完整取证 + 6 段报告 + 截图标注）。⚠️ **若命中触发条件却没做过阶段 1，必须先补做**——阶段 1 的作用是尽早暴露「需要大改」的问题，漏掉它意味着 review 可能跑在会推翻重做的设计上。
 - ⚠️ **完成定义清单（终局前必须逐项自查并输出）：**
   1. ✅ 循环 review 走完（`/loop-review`，直到某一轮不再冒出值得修的新问题）
   2. ✅ 最新代码已提交并推送到 PR 分支
   3. ✅ 已通过 `/deploy-test` 重新部署到测试环境（部署的是 review 之后的最终代码）
-  4. ✅ 测试环境用真实数据 + 真实交互复测通过（每张截图浏览器真实视口全页、箭头标注、URL 可见）
-  5. ✅ 与主分支无冲突（`gh pr view <PR> --json mergeable -q .mergeable` = `MERGEABLE`）
-  6. ✅ GitHub 静态编译通过（`gh pr checks <PR>` 无 `failure`）
-  7. ✅ PR 链接已发送给用户
-  8. ✅ 发新版本（`./release.sh`）
+  4. ✅ 测试环境用真实数据 + 真实交互复测通过，**且命中的跨系统链路环节已按 `/real-chain-verify` 阶段 2 验完下游**（每张截图浏览器真实视口全页、箭头标注、URL 可见）
+  5. ✅ PR 描述里的「跨系统链路验收」栏目已填完（未命中触发条件的已勾选豁免项）
+  6. ✅ 与主分支无冲突（`gh pr view <PR> --json mergeable -q .mergeable` = `MERGEABLE`）
+  7. ✅ GitHub 静态编译通过（`gh pr checks <PR>` 无 `failure`）
+  8. ✅ PR 链接已发送给用户
+  9. ✅ 发新版本（`./release.sh`）
 - ⚠️ **循环 review 走完后，显式输出「✅ 循环 review 完成，进入发布收尾闭环」，然后逐项执行下面第 2～8 步，禁止在循环 review 结束后直接发链接/发版。** 若发现某一步没做（典型：忘了重新部署、复测是旧数据），必须停下来补齐再继续，禁止把「漏掉的第 3/4 步」带进交付。
 
 ## 核心流程
@@ -75,6 +81,8 @@ git push origin "$(git branch --show-current)"
 ### 4. 测试环境复测 + 全程截图标注
 
 - 在测试环境用**真实数据 + 真实交互**测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。
+- ⚠️ **先判断是否命中「⚠️ 跨系统真实链路验收铁律」的触发条件**（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定）。**命中则必须触发 `/real-chain-verify` 的阶段 2**（完整验收），从「用户动作起点」一路验到「最终生效的下游系统」，取到下游真实生效证据——**禁止只交本系统页面截图就当作复测完成**。阶段 1（链路预演）应在循环 review 之前已完成；若没做，先补做。
+- ⚠️ **本步结束后必须回填 PR 描述里的「跨系统链路验收」栏目**：命中触发条件的填「② 链路验收」的下游真实生效证据与默认值对照；未命中的勾选豁免项。这是留给 reviewer 的痕迹——不填等于这一环做了也没人知道。
 - 每步截图保留（遵循「⚠️ 截图规范」：浏览器真实视口宽（需要更清晰时提高 DPR）、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
 - 若本次改动是纯后端/基础设施，按「非 UI / 后端 / 基础设施改动的效果截图获取方法」把 curl 响应渲染成暗色终端 HTML 截图。
 
@@ -107,6 +115,7 @@ PR 合并后按项目发布流程执行根目录 `./release.sh` 发新版本（
 ## 相关
 
 - 循环 review 细节：`loop-review` skill
+- 跨系统真实链路验收：`real-chain-verify` skill
 - 部署测试环境：`deploy-test` skill
 - 创建 PR / 截图上传：`create-pr` skill
 - 验证证据产出：`visual-report` skill

package/skills/real-chain-verify/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: real-chain-verify
+description: >-
+  跨系统真实链路验收——功能做完后，从「用户动作起点」一路穿到「最终生效的下游系统」，用真实流量走完整流程，
+  确认下游真的接住了（而不只是本系统页面全绿）。核心防线：**代码 review 看 diff（静态）、页面截图看本系统（局部），
+  两者都回答不了「这套组合在真实系统里成不成立」**——跨仓库根因、默认值与存量数据的冲突、产品口径变化、
+  小数值精度临界，这四类问题只有真跑一遍才会暴露。
+  触发场景包括但不限于：
+  「整链路验收」「真实链路」「走一遍真实流程」「端到端验收」「跨系统验证」「链路跑通」「真打一次请求」
+  「下游有没有生效」「这套跑起来行不行」「验收一下」「跑一遍完整流程」「链路预演」。
+  **当改动命中「跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定」
+  任一条件时，自动触发本 Skill，无需用户再开口。**
+  **本 Skill 分两段执行**：阶段 1「链路预演」在**创建 PR 后、循环 review 之前**自动触发（轻量：只画链路 +
+  逐环节判通不通，尽早暴露需要大改的问题）；阶段 2「链路验收」在**循环 review 收敛、重新部署之后**自动触发
+  （完整：全部步骤 + 6 段报告 + 截图标注，作为交付证据）。
+---
+
+# 跨系统真实链路验收
+
+⚠️ **本 Skill 已触发。在用户回复中第一句话必须输出：「🔧 已触发 `real-chain-verify`，开始跨系统真实链路验收…」然后严格按照以下步骤执行，不得跳过。**
+
+## ⚠️ 核心铁律（违反即错误）
+
+- ⚠️ **本系统页面全绿 ≠ 链路跑通。** 门户显示 Active，不等于网关选路里有它；Dashboard 说发了请求，不等于下游真的接住并计费了。**证据必须是「下游系统里能看到的东西」，不是本系统的回显。**
+- ⚠️ **本流程与循环 review 不可互相替代。** 循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。
+- ⚠️ **禁止用「我以为下游会接住」代替「我看到下游接住了」。** 没取到下游痕迹 = 这一步没验完，不是「应该没问题」。
+- ⚠️ **先画链路再验证。** 链路没列出来就开测 = 不知道该验哪些环节 = 必然漏一整个下游。
+
+## ⚠️ 两段式：阶段 1 在 review 前，阶段 2 在 review 后（禁止合并成一次）
+
+本流程**分两段执行**，位置是硬的——顺序错了会白跑 review。
+
+| | 阶段 1「链路预演」 | 阶段 2「链路验收」 |
+|---|---|---|
+| **时机** | 创建 PR 后、**循环 review 之前** | 循环 review 收敛、**重新部署之后** |
+| **回答什么** | 这条链路**成不成立**、需求口径**对不对** | 下游**真的接住了吗** |
+| **做到什么程度（本 skill 的哪些步）** | 只做第 1、2 步 + 第 3 步的**快速版**（每环节判「通/不通」，不追完整证据） | 第 1～7 步**全做**，含 6 段报告 + 截图箭头标注 |
+| **工作量** | 约阶段 2 的 20~30% | 100%（交付证据） |
+| **产出** | 链路图 + 逐环节通/不通判断 | 完整验收报告（交付物） |
+| **不做** | ❌ 不写 6 段报告 ❌ 不做截图箭头标注 ❌ 不出交付文档 | — |
+
+**为什么阶段 1 必须在前面**：本流程要暴露的四类问题（跨仓库语义 / 需求口径 / 默认值×存量 / 精度临界），**修复代价都是「大改」**（改需求、改默认值、改 schema、改交互），而 review 修的是小改（补判空、改错误码）。**把大改的发现压到最后 = 先用 N 轮把一个可能要推翻重做的东西打磨到没有代码缺陷，再发现它根本不该这么做**——review 成果直接作废，改完还得重跑 review。阶段 1 的成本很低（只画链路 + 快速过一遍），换来的是「review 跑在已经确认方向正确的代码上」。
+
+**为什么阶段 2 不能提前**：验的必须是「最终要发布的那个版本」。review 会 push 新 commit，提前验完的代码后面会被改，那次证据直接作废、还得再验一遍。阶段 2 只能压在最后。这也是「阶段 1 轻量、阶段 2 完整」的分工依据——轻的那段先跑，重的那段只跑一次。
+
+⚠️ **阶段 1 发现「需要大改」时，禁止带着它进循环 review**：先改完（改需求口径 / 改默认值 / 补下游能力），再进 review。这正是阶段 1 存在的意义。
+
+## 核心流程
+
+### 1. 判定是否触发
+
+先按「跨系统真实链路验收铁律」的触发条件自查，**命中任一即必须走完本流程**：
+
+| # | 触发条件 | 本次是否命中 |
+|---|---|---|
+| 1 | 改动跨系统/跨仓库（下游消费方代码在别的仓库） | |
+| 2 | 新增「默认值类」字段（priority / 限额 / 状态 / 开关 / 优先级） | |
+| 3 | 涉及金额、路由、权限、限流 | |
+| 4 | 新增表/字段参与「对外可见 / 放行」判定 | |
+
+全不命中（如纯文案、纯样式、纯内部重构且无对外行为变化）→ 可只走「页面功能验证铁律」，但仍需在交付时说明「本次未触发跨系统验收，原因是 X」。
+
+### 2. 画链路（动手前必做，输出成清单）
+
+把本次改动从**用户动作的起点**到**最终生效处**逐环节列出来，并给每个环节标注「归谁管、在哪个仓库」：
+
+```
+用户动作起点            本系统                      下游系统（逐个列出）
+例：[门户点「启用」] → [vendor 后端写库] → [网关选路池] → [上游 provider] → [计费落库] → [监控归因]
+                        routerhub-ui        pomex-gateway    外部            pomex-gateway   BQ/监控
+```
+
+⚠️ **凡是「归谁管」写在别的仓库的环节，就是本次验收的重点环节**——那些地方的代码不在你的 diff 里，review 审不到，只能靠真跑。
+
+### 3. 逐环节取证（每个环节一条「下游可观测事实」）
+
+对链路清单里的每个环节，取一条**该环节自己的系统里能看到的事实**。取证方式按系统类型对号入座：
+
+| 环节类型 | 取什么证据 | 怎么取 |
+|---|---|---|
+| **网关 / 路由 / 选路** | 该对象是否出现在选路结果里 | 调 `/v1/models` 等公开列表接口，A/B 对比启停前后的**精确增减**（增了哪个、减了哪个） |
+| **计费 / 扣费** | 是否真的扣了、扣了多少 | 查计费落库记录 / 账单明细，用**执行 ID / 时间戳**锚定本次请求 |
+| **限流 / 配额** | 限制是否真的生效 | 制造超限请求，看**返回码分布**（如并发打 6 发 → 精确 2 通 + 4 个 429） |
+| **数据库** | 行是否真的写进去了 | 直连库查表（不是看接口回显），比对改动前后的值 |
+| **Redis / 缓存** | key 的值是否符合预期 | 直接看运行时 key/value，A/B 对比改动前后 |
+| **监控 / 归因** | 这次流量是否归到了这个对象 | 看监控页面的归因维度（Top Errors、按对象分组的计数），**截图** |
+| **外部上游** | 上游是否真的被调到 | 看上游侧记录 / 请求日志 / 上游返回的 usage |
+
+⚠️ **每一环节的截图/记录必须能回答「这一步证明了什么」**，遵循「⚠️ 截图规范」（浏览器真实视口、`fullPage` 全页、URL 可见、箭头标注走 `/screenshot-annotate`）。
+
+### 4. 下游真实生效证据（最关键的一步）
+
+⚠️ **至少取一条**「真实请求打进去 → 在**最终生效的下游**留下痕迹」的证据。**
+
+- ✅ 正例：启停该绑定时 `/v1/models` **精确增减**目标模型；真实请求跑通后在 Dashboard Top Errors 里 **100% 归因**到该对象，带 tokens 和 cost 返回。
+- ❌ 反例：只看本系统日志说「已发送请求」；只看门户页面显示「Active」。
+
+**只有本系统日志、没有下游痕迹 = 只能证明「我发了」，不能证明「它接住了」。**
+
+### 5. 默认值类字段：与存量数据对照（命中触发条件 2 时必做）
+
+⚠️ 凡是新增了「不填就用默认值」的字段，必须额外回答：
+
+> **这个默认值，和线上已有的存量数据放一起，是什么效果？**
+
+- 查清三件事：① 默认值是多少；② 下游按什么规则消费它（排序？阈值？优先级？）；③ **线上存量数据在这个规则下处于什么位置**。
+- 案例（真实踩坑）：新账号 `priority` 默认 100，平台存量账号是 10，选路按 priority 升序 → 前面还活着就永远轮不到新账号。**门户显示 Active、模型已绑定，实际长期零流量且无任何提示**——单看 `Priority: 100` 这行代码完全正确。
+- ⚠️ **顺带检查默认值与「缺失」的语义**：默认值是「未配置」还是「一个真实的数值」？两者的下游行为常常不同（呼应「跨系统字段设计原则」——禁止用哨兵值同时表达两种语义）。
+
+### 6. 组织验收报告
+
+报告结构（缺一不算完成）：
+
+1. **链路清单**：第 2 步画出的完整链路，逐环节标注归谁管。
+2. **逐环节证据**：每个环节一节，含 ① 怎么做的（可复制粘贴的完整命令）② 结果（含执行 ID / 时间戳 / 返回码）③ 这一步证明了什么。
+3. **下游真实生效证据**：第 4 步的证据，单独一节突出。
+4. **默认值对照**（如命中）：默认值 / 下游消费规则 / 存量数据位置 三者对照。
+5. **发现的问题**：按下节四分类归档。
+6. **结论**：逐条列出证据关键数值 + 可复查标识，明确说「通过」或「发现 N 个问题」。
+
+报告优先走 `/visual-report` 的产出规范（真实数据 + 真实交互 + 可视化证据）。
+
+### 7. 发现问题时的归类与去向
+
+发现的问题按四类归档，**这个分类决定了该找谁修**：
+
+| 类别 | 特征 | 去向 |
+|---|---|---|
+| ① **跨仓库 / 跨系统** | 根因代码不在本次 diff 里 | 记录到 PR，明确「不在本 PR 范围」+ 后续动作；必要时开对侧仓库的 issue/PR |
+| ② **默认值 × 存量数据** | 代码正确，错在与已有数据的关系 | 本次就必须修（改默认值 / 加校验 / 加提示） |
+| ③ **需求口径变化** | 代码自洽，产品预期不同 | 找产品确认口径，确认后按新口径改，**结论写进接口注释** |
+| ④ **精度 / 规模临界** | 只在真实小数值/低用量显形 | 本次修（改显示精度 / 加量纲说明） |
+
+⚠️ **四类问题一律禁止「测到了但不记」**——即使判定为「不在本 PR 范围」（如 ① 类），也必须在 PR 里显式记录并点明后续动作，禁止「提了不等于了」。
+
+## 四类问题的预判清单（写代码阶段就自查，别等验收才发现）
+
+写完代码、开 PR 之前，对着这次改动过一遍：
+
+- [ ] **① 有没有让某个动作流向下游、而下游代码在别的仓库？** → 去读下游那个仓库的对应逻辑，确认它对本次新入口的行为。
+- [ ] **② 有没有新增「不填就用默认值」的字段？** → 默认值是多少 + 下游怎么消费 + 存量数据在哪。
+- [ ] **③ 有没有「产品之前说过一次、后来又改过口径」的地方？** → 回到最新的产品结论，别按旧口径实现。
+- [ ] **④ 有没有涉及小数值 / 低用量 / 首次使用的显示或计算？** → 用真实的小数字试一遍（如 $0.004 的显示）。
+
+## 判断边界
+
+- ⚠️ **改动命中触发条件但没走本流程就宣称完成 → 直接违背铁律，必须停下并报告缺失项。**
+- ⚠️ **下游环境不可用（如测试环境网关挂了）导致验不了** → 如实说明「哪一环节没验、为什么」，禁止用本系统证据替代下游证据。
+- ⚠️ **用户明确说「不用验下游，只测本系统」** → 按用户指令执行，但交付时必须显式说明「本次跳过了跨系统验收」及跳过了哪些环节。
+- **纯文档 / 纯样式 / 无对外行为变化的内部重构** → 不触发本流程。
+
+## 相关
+
+- 规则出处：`AGENTS.base.md`「⚠️ 跨系统真实链路验收铁律」
+- 本系统内的功能验证：`AGENTS.base.md`「⚠️ 页面功能验证铁律」「⚠️ 可视化验证铁律」
+- 生产存量数据预演：`AGENTS.base.md`「⚠️ 存量数据预演铁律」
+- 证据截图规范：`screenshot-annotate` skill
+- 验证证据产出：`visual-report` skill
+- PR 收尾闭环（本流程嵌在其中）：`pr-release-loop` skill