@routerhub/agent-rules 1.5.202 → 1.5.203

package/AGENTS.base.md

@@ -217,8 +217,14 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - ❌ **把「门户页面全绿」当「链路跑通」**——页面是本系统的回显，跑通是下游真的接住了。
   - ❌ **把「循环 review 全过」当「功能成立」**——review 审的是代码有没有缺陷，管不了「这套组合在真实系统里行不行」。
   - ❌ **把「部署成功 + 截图」当「验收完成」**——部署证明代码上线了，不证明功能用得了。
-- ⚠️ **与循环 review 的分工（两者不可互相替代）**：**循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。** 循环 review 走完只说明「代码层面没问题了」，此时**必须**继续走跨系统真实链路验收，禁止在 review 收敛后直接发链接 / 发版。
-- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、证据怎么组织成报告）。
+- ⚠️ **与循环 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 规范
 
@@ -290,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/CHANGELOG.md

@@ -2,6 +2,17 @@
 
 所有对 @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

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.202",
+  "version": "1.5.203",
   "description": "Shared Copilot agent rules and guidelines for RouterHub projects",
   "main": "AGENTS.base.md",
   "bin": {

package/rules/global.md

@@ -217,8 +217,14 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - ❌ **把「门户页面全绿」当「链路跑通」**——页面是本系统的回显，跑通是下游真的接住了。
   - ❌ **把「循环 review 全过」当「功能成立」**——review 审的是代码有没有缺陷，管不了「这套组合在真实系统里行不行」。
   - ❌ **把「部署成功 + 截图」当「验收完成」**——部署证明代码上线了，不证明功能用得了。
-- ⚠️ **与循环 review 的分工（两者不可互相替代）**：**循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。** 循环 review 走完只说明「代码层面没问题了」，此时**必须**继续走跨系统真实链路验收，禁止在 review 收敛后直接发链接 / 发版。
-- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、证据怎么组织成报告）。
+- ⚠️ **与循环 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 规范
 
@@ -290,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/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,12 +1,15 @@
 ---
 name: pr-release-loop
 description: >-
-  PR 发布完整闭环（循环 review 之后的收尾）——创建 PR 后按 AGENTS.base.md「⚠️ 创建完 PR 后自动走完整闭环流程」自动走完
-  循环 review → 重新部署测试环境 → 测试环境复测 → 确认 → 发 PR 链接 → 发新版本 六步。核心防线：**循环 review 走完后，
-  必须重新部署到测试环境并复测，确认没问题之后才能发链接/发版**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
-  复测环节命中「跨系统真实链路验收铁律」触发条件时，自动触发 `real-chain-verify` skill 验到下游（页面全绿 ≠ 链路跑通）。
+  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**，无需用户再开口。
 ---
@@ -20,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. ✅ 测试环境用真实数据 + 真实交互复测通过，**且命中的跨系统链路环节已按 `/real-chain-verify` 验完下游**（每张截图浏览器真实视口全页、箭头标注、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 步」带进交付。
 
 ## 核心流程
@@ -76,7 +81,8 @@ git push origin "$(git branch --show-current)"
 ### 4. 测试环境复测 + 全程截图标注
 
 - 在测试环境用**真实数据 + 真实交互**测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。
-- ⚠️ **先判断是否命中「⚠️ 跨系统真实链路验收铁律」的触发条件**（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定）。**命中则必须触发 `/real-chain-verify`**，从「用户动作起点」一路验到「最终生效的下游系统」，取到下游真实生效证据——**禁止只交本系统页面截图就当作复测完成**。
+- ⚠️ **先判断是否命中「⚠️ 跨系统真实链路验收铁律」的触发条件**（改动跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定）。**命中则必须触发 `/real-chain-verify` 的阶段 2**（完整验收），从「用户动作起点」一路验到「最终生效的下游系统」，取到下游真实生效证据——**禁止只交本系统页面截图就当作复测完成**。阶段 1（链路预演）应在循环 review 之前已完成；若没做，先补做。
+- ⚠️ **本步结束后必须回填 PR 描述里的「跨系统链路验收」栏目**：命中触发条件的填「② 链路验收」的下游真实生效证据与默认值对照；未命中的勾选豁免项。这是留给 reviewer 的痕迹——不填等于这一环做了也没人知道。
 - 每步截图保留（遵循「⚠️ 截图规范」：浏览器真实视口宽（需要更清晰时提高 DPR）、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
 - 若本次改动是纯后端/基础设施，按「非 UI / 后端 / 基础设施改动的效果截图获取方法」把 curl 响应渲染成暗色终端 HTML 截图。
 

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

@@ -7,9 +7,12 @@ description: >-
   小数值精度临界，这四类问题只有真跑一遍才会暴露。
   触发场景包括但不限于：
   「整链路验收」「真实链路」「走一遍真实流程」「端到端验收」「跨系统验证」「链路跑通」「真打一次请求」
-  「下游有没有生效」「这套跑起来行不行」「验收一下」「跑一遍完整流程」。
+  「下游有没有生效」「这套跑起来行不行」「验收一下」「跑一遍完整流程」「链路预演」。
   **当改动命中「跨系统/跨仓库、新增默认值类字段、涉及金额/路由/权限/限流、新增表字段参与对外可见判定」
   任一条件时，自动触发本 Skill，无需用户再开口。**
+  **本 Skill 分两段执行**：阶段 1「链路预演」在**创建 PR 后、循环 review 之前**自动触发（轻量：只画链路 +
+  逐环节判通不通，尽早暴露需要大改的问题）；阶段 2「链路验收」在**循环 review 收敛、重新部署之后**自动触发
+  （完整：全部步骤 + 6 段报告 + 截图标注，作为交付证据）。
 ---
 
 # 跨系统真实链路验收
@@ -19,10 +22,29 @@ description: >-
 ## ⚠️ 核心铁律（违反即错误）
 
 - ⚠️ **本系统页面全绿 ≠ 链路跑通。** 门户显示 Active，不等于网关选路里有它；Dashboard 说发了请求，不等于下游真的接住并计费了。**证据必须是「下游系统里能看到的东西」，不是本系统的回显。**
-- ⚠️ **本流程与循环 review 不可互相替代。** 循环 review 保证「代码没有明显缺陷」（静态、看 diff）；本流程保证「功能在真实系统里真的成立」（动态、看运行）。循环 review 收敛后**必须**继续走本流程，禁止直接发链接/发版。
+- ⚠️ **本流程与循环 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. 判定是否触发