@routerhub/agent-rules 1.5.201 → 1.5.202

package/AGENTS.base.md

@@ -194,6 +194,32 @@ 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 走完只说明「代码层面没问题了」，此时**必须**继续走跨系统真实链路验收，禁止在 review 收敛后直接发链接 / 发版。
+- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、证据怎么组织成报告）。
+
 ## Git 规范
 
 - 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
@@ -780,12 +806,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 +868,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,18 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
+## [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/package.json

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

package/rules/global.md

@@ -194,6 +194,32 @@ 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 走完只说明「代码层面没问题了」，此时**必须**继续走跨系统真实链路验收，禁止在 review 收敛后直接发链接 / 发版。
+- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、证据怎么组织成报告）。
+
 ## Git 规范
 
 - 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。

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/pr-release-loop/SKILL.md

@@ -4,6 +4,7 @@ description: >-
   PR 发布完整闭环（循环 review 之后的收尾）——创建 PR 后按 AGENTS.base.md「⚠️ 创建完 PR 后自动走完整闭环流程」自动走完
   循环 review → 重新部署测试环境 → 测试环境复测 → 确认 → 发 PR 链接 → 发新版本 六步。核心防线：**循环 review 走完后，
   必须重新部署到测试环境并复测，确认没问题之后才能发链接/发版**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
+  复测环节命中「跨系统真实链路验收铁律」触发条件时，自动触发 `real-chain-verify` skill 验到下游（页面全绿 ≠ 链路跑通）。
   触发场景包括但不限于：
   「PR闭环」「闭环走完」「完整闭环」「六步闭环」「走完整流程」「收尾」「发布闭环」「发布收尾」「循环review完再部署测一遍」「测试环境再测一遍」。
   以及「创建PR后的完整流程」「走完循环review流程」「循环review完之后」。
@@ -23,7 +24,7 @@ description: >-
   1. ✅ 循环 review 走完（`/loop-review`，直到某一轮不再冒出值得修的新问题）
   2. ✅ 最新代码已提交并推送到 PR 分支
   3. ✅ 已通过 `/deploy-test` 重新部署到测试环境（部署的是 review 之后的最终代码）
-  4. ✅ 测试环境用真实数据 + 真实交互复测通过（每张截图浏览器真实视口全页、箭头标注、URL 可见）
+  4. ✅ 测试环境用真实数据 + 真实交互复测通过，**且命中的跨系统链路环节已按 `/real-chain-verify` 验完下游**（每张截图浏览器真实视口全页、箭头标注、URL 可见）
   5. ✅ 与主分支无冲突（`gh pr view <PR> --json mergeable -q .mergeable` = `MERGEABLE`）
   6. ✅ GitHub 静态编译通过（`gh pr checks <PR>` 无 `failure`）
   7. ✅ PR 链接已发送给用户
@@ -75,6 +76,7 @@ git push origin "$(git branch --show-current)"
 ### 4. 测试环境复测 + 全程截图标注
 
 - 在测试环境用**真实数据 + 真实交互**测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。
+- ⚠️ **先判断是否命中「⚠️ 跨系统真实链路验收铁律」的触发条件**（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定）。**命中则必须触发 `/real-chain-verify`**，从「用户动作起点」一路验到「最终生效的下游系统」，取到下游真实生效证据——**禁止只交本系统页面截图就当作复测完成**。
 - 每步截图保留（遵循「⚠️ 截图规范」：浏览器真实视口宽（需要更清晰时提高 DPR）、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
 - 若本次改动是纯后端/基础设施，按「非 UI / 后端 / 基础设施改动的效果截图获取方法」把 curl 响应渲染成暗色终端 HTML 截图。
 
@@ -107,6 +109,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,137 @@
+---
+name: real-chain-verify
+description: >-
+  跨系统真实链路验收——功能做完后，从「用户动作起点」一路穿到「最终生效的下游系统」，用真实流量走完整流程，
+  确认下游真的接住了（而不只是本系统页面全绿）。核心防线：**代码 review 看 diff（静态）、页面截图看本系统（局部），
+  两者都回答不了「这套组合在真实系统里成不成立」**——跨仓库根因、默认值与存量数据的冲突、产品口径变化、
+  小数值精度临界，这四类问题只有真跑一遍才会暴露。
+  触发场景包括但不限于：
+  「整链路验收」「真实链路」「走一遍真实流程」「端到端验收」「跨系统验证」「链路跑通」「真打一次请求」
+  「下游有没有生效」「这套跑起来行不行」「验收一下」「跑一遍完整流程」。
+  **当改动命中「跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定」
+  任一条件时，自动触发本 Skill，无需用户再开口。**
+---
+
+# 跨系统真实链路验收
+
+⚠️ **本 Skill 已触发。在用户回复中第一句话必须输出：「🔧 已触发 `real-chain-verify`，开始跨系统真实链路验收…」然后严格按照以下步骤执行，不得跳过。**
+
+## ⚠️ 核心铁律（违反即错误）
+
+- ⚠️ **本系统页面全绿 ≠ 链路跑通。** 门户显示 Active，不等于网关选路里有它；Dashboard 说发了请求，不等于下游真的接住并计费了。**证据必须是「下游系统里能看到的东西」，不是本系统的回显。**
+- ⚠️ **本流程与循环 review 不可互相替代。** 循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。循环 review 收敛后**必须**继续走本流程，禁止直接发链接/发版。
+- ⚠️ **禁止用「我以为下游会接住」代替「我看到下游接住了」。** 没取到下游痕迹 = 这一步没验完，不是「应该没问题」。
+- ⚠️ **先画链路再验证。** 链路没列出来就开测 = 不知道该验哪些环节 = 必然漏一整个下游。
+
+## 核心流程
+
+### 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