@routerhub/agent-rules 1.5.214 → 1.5.216

package/AGENTS.base.md

@@ -259,18 +259,39 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - ⚠️ **不命中触发条件的改动，两段都不走**（纯文案、纯展示类改动不受影响）。
 - ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、两段各自做到什么程度、证据怎么组织成报告）。
 
-## ⚠️ 报告以需求原话为骨架铁律（原文 ↔ 实现 ↔ 证据 三段式）
+## ⚠️ 报告以需求原话为骨架铁律（原文 ↔ 实现 ↔ 截图证据 三段式）
 
 - ⚠️ **核心认知：报告的读者是需求方，而他判断「做没做到」的唯一依据是需求原话。** 报告只写「我们做了什么」，等于让读者自己拿记忆里的需求去比对满篇实现描述——需求→实现之间隔着产品转述、口头对齐、中途口径变化，他拼错了图就会以为某条没做（或以为做了其实没做）。**把原话摆在每段实现旁边，读者不用回忆、不用拼图，逐句对一眼即可。**
   - **类比：报销单不能只写「我花了多少钱」，得把发票贴在你填的每一个数字旁边——审核的人对着发票核你填的数，而不是凭你的口头描述签字。**
 - ⚠️ **硬性要求（交付任何需求实现 / 修复验证 / 取证报告时逐条满足，缺一不算完成）：**
   1. **逐字引用需求原文**：从需求单（Jira / Notion / 需求文档）**原样摘录**，保留原文用词与标点，**禁止润色、提炼、转述**。原文有错别字 / 用词不统一（如「装填维度」实为「筛选维度」）也照抄，旁边用括号注明「此处逐字保留原文」——**改写会让读者无法确认你引的是不是他要的那句**。
-  2. **按句拆解，三列并排**：「需求原文（逐字） / 我们的实现 / 证据」——每句原文独占一行，右侧写明这句对应改了哪块代码 / 哪个页面，以及**证据落在哪**（哪张图、哪条命令、哪个数字）。禁止把多句原文压成一段再笼统配一句「已实现」。
+  2. **按句拆解，三列并排：「需求原文（逐字） / 我们的实现 / 截图证据」**——每句原文独占一行；中间列写明这句对应改了哪块代码 / 哪个页面；**最右列把对应的证据直接内嵌在同一行里**（能截图的一律放带箭头标注的截图，纯后端的放命令输出 / 关键数字），让「原话 ↔ 实现 ↔ 证据」横向对齐，读者一行一行对过去即可。禁止把多句原文压成一段再笼统配一句「已实现」；也禁止右列只写一句「证据见下图 3」把读者支使到别处去翻——**翻过去就断了「这句配这张图」的对应关系，等于没配。**
   3. **原文之外我们额外做的必须单列并回连原文**：自研 / 顺带修的部分另起一张表（两列：「原文之外我们额外做的 / 它服务于原文的哪一句」），**逐条说明它服务于原文哪一句**。禁止让自研内容脱离原文独立成章——读者看不出它跟需求的关系，就会当成「夹带私货」或「跑偏了」。
   4. **原话出处给到可点链接**：需求单号 + URL 写在引用块头部（如 `MP-160 · https://.../browse/MP-160`），让读者能自己回去核对原话，而不是只能信你摘的这段。
-- ⚠️ **与相邻铁律的分工**：**本条管「报告怎么组织」——骨架必须是需求原文**；「⚠️ 取证报告铁律」管「报告要证明什么」（该变的变了 + 不该动的一行没动）；「⚠️ 修复验证铁律」管「怎么证明」（主验证 + 真实链路佐证）。三者叠加，报告才是「有骨架、有证据、有对照」的。
+  5. **右列截图必须「点击即放大」**：三列排版下截图只占版心约 1/3 宽，缩略图仅够「对上号」，细节根本看不清——所以每张截图必须支持点击放大到全屏（lightbox 遮罩层：点图 → 半透明黑底居中大图 → ESC / 点背景关闭）。**这是硬要求，不是加分项**：放不大 = 读者拿到一张看不清的图 = 证据链断在最后一步。
+     - ⚠️ **禁止用 `<a href="data:image/png;base64,...">` 包一层冒充「可放大」**：主流浏览器（Chrome 60+ / Firefox 59+）为防钓鱼**拦截 data: URI 的顶层导航**，点了毫无反应——看着写了，实际等于没做。必须用内联 JS lightbox。
+     - ⚠️ **lightbox 的 CSS 与 JS 必须内联写在文档里**：文档是离线双击打开的自包含单文件，引 CDN 一断网就失效。
+     - **类比：把发票缩印在报销单那一行旁边是为了「对得上」，但缩印件看不清金额——所以还得能拿起来凑近看。给不了这个动作，缩印就只是个装饰。**
+- ⚠️ **与相邻铁律的分工**：**本条管「报告怎么组织」——骨架必须是需求原文**；「⚠️ 主张自带复核流程铁律」管「读者能不能自己验」（每条主张旁挂一份可照做的流程）；「⚠️ 取证报告铁律」管「报告要证明什么」（该变的变了 + 不该动的一行没动）；「⚠️ 修复验证铁律」管「怎么证明」（主验证 + 真实链路佐证）。四者叠加，报告才是「有骨架、有证据、有对照、可复核」的。
 - ⚠️ **具体操作流程见 `/forensic-report` skill 与 `/create-doc` skill**（需求原文从哪取、引用块与三列表怎么排、自研部分怎么回连）。
 
+## ⚠️ 主张自带复核流程铁律（读者得能自己走一遍，而不是只能信你）
+
+- ⚠️ **核心认知：报告里的每一条主张——A/B 截图、前后对比、那个数字——都是你的结论，不是读者能自己检查的东西。** 他看完手里只有两个选项：信，或者不信。**一份只能「信或不信」的报告，等于把「可核实」偷偷降级成了「请相信我」。** 判据只有一句话：**把报告发给他、你不说任何一句话，他能不能自己把这条主张跑一遍、亲眼看到同样的结果？** 不能 = 这条主张没交付。
+  - **类比：体检报告不能只印一句「各项指标正常」就让人签字——得把每项指标的数值、参考范围、以及「你自己去哪个科室能复查这一项」都写上，家属才可能拿着它去另一家医院复核。只给结论的报告是「请相信我」，不是「你可以自己看」。**
+- ⚠️ **硬性要求：每一条主张旁边，都要挂一份「你自己怎么复核这一条」的操作流程。** 适用范围 = 每条需求原话对应的实现、每个「已修复 / 已生效」的断言、每组前后对比。流程由**逐步编号的操作**组成，每步三件套缺一不可：
+  1. **可复制粘贴的完整命令 / 操作**：参数写全，**禁止用 `...` 或占位符省略**（呼应「⚠️ 截图规范」的命令完整性要求）；且**不得引用只有你本机才有的东西**（`localhost`、本机路径、容器名、未提交的文件、正在跑的本机服务）——否则读者一跑就断（呼应「⚠️ 验收环境铁律」）。
+  2. **预期结果，对错两种都要给**：不只写「应该看到 X」（✅），还要写「**看到 Y 就是这条主张不成立**」（❌）。⚠️ **这是全篇最关键的一项**：只给成功输出，读者跑出任何别的东西时都无从判断是「我环境不对」还是「你说的不对」，最后又退回「信或不信」——**给了他反例，他才能自己宣判。**
+  3. **这一步证明了什么**（一句话点明证据含义），让读者不必读完整篇才知道自己在验什么。
+- ⚠️ **必须就近嵌入，禁止堆到附录。** 流程要紧贴它要证明的那条主张（同一行，或该行的正下方），读者读到那句主张时当场就能验。堆到文末 = 读者读完满篇结论、再自己回头找对应关系——跟「⚠️ 报告以需求原话为骨架铁律」的「禁止把读者支使到别处去翻」是同一条道理（也呼应「⚠️ 可视化验证铁律」分步演示的「就近嵌入（位置铁律）」）。
+- ⚠️ **让因果链在代码 / 数据里自证，而不是靠你断言「是这个改动修好的」。** 报告里「问题 → 修复」的那一环，优先落到读者能自己打开的可自查锚点上——如**修复脚本 / 部署脚本的注释里逐字引用了问题日志的 trace_id**、迁移文件里写了对应的表名、配置项当年的错值就摆在 diff 里。**最好的形式是：读者顺着你给的文件路径和行号点进去，能看到「问题」与「修复」被同一份代码同时提到。** 只有确实找不到这种锚点时，才退而用你的叙述把因果讲清楚。
+  - **类比：说「这把锁是为那次失窃换的」没人能核；但换锁记录上就写着那次失窃的报案号，谁都能对一下——证据链自己闭上了，不需要你在旁边解释。**
+- ⚠️ **复现不出来的必须显式标注，并给出「读者怎么自查当前状态」。** 有些主张在读者动手时确实跑不出同样结果（功能开关当时没开、数据事后被人工改过、线上版本已前进、依赖的环境已下线）。这类**禁止悄悄略过或含糊带过**，必须：① 明说复现不出来的原因；② 给出读者**自行确认当前状态**的命令（查当前版本号、查那个开关的现值）；③ 写明当时的环境版本 / 时间戳，让他能判断差异来自环境变化、而不是你的结论不成立。**含糊的边界比诚实标注的边界危险得多**——前者要么让读者把正常的环境差异误判成造假，要么反过来把造假误判成环境差异。
+- ⚠️ **作者自己的验证 ≠ 读者的复核，两者都要有、不可互相替代。** 「⚠️ 修复验证铁律」的三要素（怎么做的 / 结果 / 证明了什么）是**你给自己留的记录**；本条要的是**读者照着能重跑的操作流程**。你写「我用命令 X 得到了 Y」不等于读者拿到了那条命令——前者是记录，后者是交付。
+- ⚠️ **与相邻铁律的分工**：**本条管「读者能不能自己验」**；「⚠️ 报告以需求原话为骨架铁律」管「骨架是不是需求原文」（读者能不能对上号）；「⚠️ 取证报告铁律」管「报告要证明什么」（该变的变了 + 不该动的一行没动）；「⚠️ 修复验证铁律」管「你自己怎么证明」。四条叠加，读者才是「能对上号、看得懂结论、能自己复核」的。
+- ⚠️ **与「可复核导航」的分工（同属取证报告体系，别混为一谈）**：可复核导航回答**「去哪儿看」**（哪个页面、哪张表、点哪几下、直达 URL）；本条回答**「到了之后按什么顺序做什么、看到什么算对、看到什么算错」**。只给导航 = 读者到了现场仍不知道该验哪一项；只给流程没有导航 = 读者走完了流程，却不知道最终状态该去哪个页面看。**两者是「门牌号」与「进门之后的动线」，缺一个都到不了终点。**
+- ⚠️ **具体操作流程见 `/forensic-report` skill 与 `/create-doc` skill**（复核流程怎么排在需求原话那一行的正下方、命令与预期结果的三件套怎么给、复现不出来的边界怎么标注）。
+
 ## ⚠️ 取证报告铁律（证明「该变的变了」+「不该动的地方一行没动」）
 
 - ⚠️ **核心认知：功能验证只回答了一半问题。** 「页面功能验证铁律」「跨系统真实链路验收铁律」证明的都是**该变的地方变了**；但一次写操作真正危险的部分是它的**副作用范围**——级联删除、批量更新、绑定清理会不会顺手把不该动的数据一起带走。**副作用失控是静默的**：页面照常渲染、功能照常用、接口照常 200，只有被顺带删掉的那几张表知道出过事，而没有任何页面会主动告诉你「我多删了 3 行」。所以「不该动的地方一行没动」必须**单独取证**，不能由「功能正常」推出来。

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
+## [1.5.216] - 2026-09-14
+
+### Added
+
+- **新增「⚠️ 主张自带复核流程铁律」——报告的每条主张旁边必须挂一份读者能自己走一遍的操作流程**：起因是用户看完一份「原话 ↔ 实现 ↔ A/B 截图」三列表的详细实现文档后问了一句「**这个我咋验证呢？光看到你写的 AB 对照了**」。问题不在文档不详细，而在于**A/B 截图、前后对比、那个数字全是作者的结论，不是读者能自己检查的东西**——他手里只有「信」或「不信」两个选项，一份只能信或不信的报告，等于把「可核实」偷偷降级成了「请相信我」。现在明确判据：**把报告发给他、你不说任何一句话，他能不能自己把这条主张跑一遍、亲眼看到同样的结果？** 不能 = 这条主张没交付。
+  - **每步三件套缺一不可**：① 可复制粘贴的完整命令 / 操作（禁止 `...` 与占位符，且不得引用只有作者本机才有的东西）；② **预期结果，对错两种都要给**——不只写「应该看到 X」（✅），还要写「看到 Y 就是这条主张不成立」（❌），⚠️ **这是最关键的一项**：只给成功输出，读者跑出任何别的东西时都无从判断是「我环境不对」还是「你说的不对」，最后又退回信或不信；③ 这一步证明了什么。
+  - **就近嵌入，禁止堆到附录**：流程要紧贴它要证明的那条主张（三列表里就是那一行正下方、跨整行铺开），跟「报告以需求原话为骨架铁律」的「禁止把读者支使到别处去翻」是同一条道理。
+  - **让因果链在代码 / 数据里自证**：报告里「问题 → 修复」那一环，优先落到读者能自己打开的可自查锚点上——**最强的形式是修复脚本的注释里逐字引用了问题日志的 trace_id**，读者顺着文件路径和行号点进去，「问题」与「修复」被同一份代码同时提到，证据链自己闭上，不需要作者在旁边解释。
+  - **复现不出来的必须显式标注 + 给出「自查当前状态」的命令**：有些主张在读者动手时确实跑不出同样结果（功能开关当时没开、数据事后被人工改过、线上版本已前进）。这类禁止含糊带过，必须说明原因、给出读者自行确认当前状态的命令、写明当时的环境版本 / 时间戳。**含糊的边界比诚实标注的边界危险得多**——要么让读者把正常的环境差异误判成造假，要么反过来把造假误判成环境差异。
+  - **与「可复核导航」的分工**（都在取证报告体系里，容易混）：导航回答**「去哪儿看」**（哪个页面、点哪几下、直达 URL），本条回答**「到了之后按什么顺序做什么、看到什么算对、看到什么算错」**——两者是「门牌号」与「进门之后的动线」，缺一个都到不了终点。
+  - **落地**：`AGENTS.base.md` 新增该章节，并同步更新「报告以需求原话为骨架铁律」的相邻分工（三者 → 四者叠加）；`skills/forensic-report/SKILL.md` 新增「主张自带复核流程」专节 + 报告骨架新增第 2 项（原 2~9 顺延）+ 判断边界新增「只给结论没给复核流程」的失败信号；`skills/create-doc/SKILL.md` 报告结构补面板排法与样式建议；`PULL_REQUEST_TEMPLATE.md` 取证报告栏目注释与 Checklist 各加一条核对项。
+
 ## [1.5.213] - 2026-09-14
 
 ### Changed

package/PULL_REQUEST_TEMPLATE.md

@@ -63,6 +63,8 @@ Closes #
      页面全绿、接口全 200，都不代表没有别的数据被静默带走（级联删除、批量更新最典型）。
      ⚠️ 证据强度按改动类型自动分级（三层：动了数据本身 / 两层：普通业务逻辑 / 一层：纯文案样式）。
      ⚠️ 可复核导航一级都不可降级——它是所有级别必带项。
+     ⚠️ 每条主张还必须自带「你自己怎么复核」的流程面板（AGENTS.base.md「⚠️ 主张自带复核流程铁律」），
+        就近嵌在三列表那一行正下方——只给结论、只给 A/B 截图，用户只会问「这个我咋验证呢？光看到你写的 A/B 对照了」。
      ⚠️ 本栏目是「摘要 + 链接」：完整报告并入 PR 顶部那份「详细实现文档」；不走 PR 的即时修复给桌面 HTML 绝对路径。 -->
 
 - [ ] 本次为**一层**改动（纯文案 / 纯样式 / 无数据变化），只需功能证据 + 可复核导航，无需三层取证
@@ -99,6 +101,7 @@ Closes #
 - [ ] 修 bug 的 PR 已按「缺陷复现」栏目写下改动前的复现证据（非修 bug 的已勾选豁免项）
 - [ ] 跨系统链路验收已按上方栏目填完（未命中触发条件则勾选豁免项）
 - [ ] 已按「取证报告」栏目给出取证数据（或勾选一层豁免项）
+- [ ] 详细实现文档里，**每条主张旁都挂了「你自己怎么复核」的流程面板**（可复制命令 + 对错两种预期结果 + 这一步证明了什么；就近嵌在三列表该行正下方）——只给结论 / 只给 A/B 截图 = 用户没法自己验证，等于没交付
 - [ ] UI 改动已贴截图（或注明无界面变化）
 - [ ] 截图与证据取自测试环境（无截图 / 本地例外已注明原因），且每张图里都写了文字版完整 URL（不是只靠地址栏），该 URL 是别人能直接打开的地址（非 localhost）
 - [ ] 本地编译 / lint / 测试通过，CI 全绿

package/package.json

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

package/rules/global.md

@@ -259,15 +259,19 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - ⚠️ **不命中触发条件的改动，两段都不走**（纯文案、纯展示类改动不受影响）。
 - ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、两段各自做到什么程度、证据怎么组织成报告）。
 
-## ⚠️ 报告以需求原话为骨架铁律（原文 ↔ 实现 ↔ 证据 三段式）
+## ⚠️ 报告以需求原话为骨架铁律（原文 ↔ 实现 ↔ 截图证据 三段式）
 
 - ⚠️ **核心认知：报告的读者是需求方，而他判断「做没做到」的唯一依据是需求原话。** 报告只写「我们做了什么」，等于让读者自己拿记忆里的需求去比对满篇实现描述——需求→实现之间隔着产品转述、口头对齐、中途口径变化，他拼错了图就会以为某条没做（或以为做了其实没做）。**把原话摆在每段实现旁边，读者不用回忆、不用拼图，逐句对一眼即可。**
   - **类比：报销单不能只写「我花了多少钱」，得把发票贴在你填的每一个数字旁边——审核的人对着发票核你填的数，而不是凭你的口头描述签字。**
 - ⚠️ **硬性要求（交付任何需求实现 / 修复验证 / 取证报告时逐条满足，缺一不算完成）：**
   1. **逐字引用需求原文**：从需求单（Jira / Notion / 需求文档）**原样摘录**，保留原文用词与标点，**禁止润色、提炼、转述**。原文有错别字 / 用词不统一（如「装填维度」实为「筛选维度」）也照抄，旁边用括号注明「此处逐字保留原文」——**改写会让读者无法确认你引的是不是他要的那句**。
-  2. **按句拆解，三列并排**：「需求原文（逐字） / 我们的实现 / 证据」——每句原文独占一行，右侧写明这句对应改了哪块代码 / 哪个页面，以及**证据落在哪**（哪张图、哪条命令、哪个数字）。禁止把多句原文压成一段再笼统配一句「已实现」。
+  2. **按句拆解，三列并排：「需求原文（逐字） / 我们的实现 / 截图证据」**——每句原文独占一行；中间列写明这句对应改了哪块代码 / 哪个页面；**最右列把对应的证据直接内嵌在同一行里**（能截图的一律放带箭头标注的截图，纯后端的放命令输出 / 关键数字），让「原话 ↔ 实现 ↔ 证据」横向对齐，读者一行一行对过去即可。禁止把多句原文压成一段再笼统配一句「已实现」；也禁止右列只写一句「证据见下图 3」把读者支使到别处去翻——**翻过去就断了「这句配这张图」的对应关系，等于没配。**
   3. **原文之外我们额外做的必须单列并回连原文**：自研 / 顺带修的部分另起一张表（两列：「原文之外我们额外做的 / 它服务于原文的哪一句」），**逐条说明它服务于原文哪一句**。禁止让自研内容脱离原文独立成章——读者看不出它跟需求的关系，就会当成「夹带私货」或「跑偏了」。
   4. **原话出处给到可点链接**：需求单号 + URL 写在引用块头部（如 `MP-160 · https://.../browse/MP-160`），让读者能自己回去核对原话，而不是只能信你摘的这段。
+  5. **右列截图必须「点击即放大」**：三列排版下截图只占版心约 1/3 宽，缩略图仅够「对上号」，细节根本看不清——所以每张截图必须支持点击放大到全屏（lightbox 遮罩层：点图 → 半透明黑底居中大图 → ESC / 点背景关闭）。**这是硬要求，不是加分项**：放不大 = 读者拿到一张看不清的图 = 证据链断在最后一步。
+     - ⚠️ **禁止用 `<a href="data:image/png;base64,...">` 包一层冒充「可放大」**：主流浏览器（Chrome 60+ / Firefox 59+）为防钓鱼**拦截 data: URI 的顶层导航**，点了毫无反应——看着写了，实际等于没做。必须用内联 JS lightbox。
+     - ⚠️ **lightbox 的 CSS 与 JS 必须内联写在文档里**：文档是离线双击打开的自包含单文件，引 CDN 一断网就失效。
+     - **类比：把发票缩印在报销单那一行旁边是为了「对得上」，但缩印件看不清金额——所以还得能拿起来凑近看。给不了这个动作，缩印就只是个装饰。**
 - ⚠️ **与相邻铁律的分工**：**本条管「报告怎么组织」——骨架必须是需求原文**；「⚠️ 取证报告铁律」管「报告要证明什么」（该变的变了 + 不该动的一行没动）；「⚠️ 修复验证铁律」管「怎么证明」（主验证 + 真实链路佐证）。三者叠加，报告才是「有骨架、有证据、有对照」的。
 - ⚠️ **具体操作流程见 `/forensic-report` skill 与 `/create-doc` skill**（需求原文从哪取、引用块与三列表怎么排、自研部分怎么回连）。
 

package/skills/create-doc/SKILL.md

@@ -115,12 +115,20 @@ description: >-
 ### 图片处理
 
 - ⚠️ 所有图片以 base64 data URI 形式内嵌到 HTML 中，禁止引用外部图片文件
-- ⚠️ 所有图片必须支持点击放大、全屏查看（lightbox 遮罩层）
+- ⚠️ 所有图片必须支持点击放大、全屏查看（lightbox 遮罩层）——三列排版的缩略图只够「对上号」，放不大等于给了张看不清的图
 - lightbox 实现：图片绑定 click → 弹出半透明黑色遮罩 → 图片居中自适应 → ESC/点击背景关闭
+- ⚠️ **禁止用 `<a href="data:image/png;base64,...">` 实现放大**：Chrome 60+ / Firefox 59+ 为防钓鱼**拦截 data: URI 的顶层导航**，点击后毫无反应，看着像实现了其实没做。必须用内联 JS lightbox
+- ⚠️ **lightbox 的 CSS 与 JS 必须内联写在文档里**：文档是离线双击打开的自包含单文件，引 CDN 一断网就失效
 
 ### 报告结构
 
-⚠️ **交付「需求实现 / 修复验证 / 取证」类文档时，正文骨架必须以需求原话为第一层**（规则见 `AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求原文（保留原用词与标点），按句拆成「需求原文 / 我们的实现 / 证据」三列表并排，引用块头部给需求单号 + 可点 URL；原文之外额外做的另起一张「原文之外我们额外做的 / 它服务于原文的哪一句」两列表逐条回连。纯操作指南 / 纯设计文档不受此限。
+⚠️ **交付「需求实现 / 修复验证 / 取证」类文档时，正文骨架必须以需求原话为第一层**（规则见 `AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求原文（保留原用词与标点），按句拆成「需求原文 / 我们的实现 / 截图证据」三列表并排——**最右列把带箭头标注的截图直接内嵌在同一行**（点击可放大到全屏），而不是只写「证据见下图 N」让读者自己去翻；引用块头部给需求单号 + 可点 URL；原文之外额外做的另起一张「原文之外我们额外做的 / 它服务于原文的哪一句」两列表逐条回连。纯操作指南 / 纯设计文档不受此限。
+
+⚠️ **三列表的每一行正下方，还要挂一个「你自己怎么复核这一条」的流程面板**（规则见 `AGENTS.base.md`「⚠️ 主张自带复核流程铁律」）。**少了它，用户看完只会问「这个我咋验证呢？光看到你写的 A/B 对照了」**——截图和结论都是你的断言，他没法自己检查。面板的排法与硬性要求：
+
+- **位置**：紧贴该行、跨整行铺开（`<tr><td colspan="3">…</td></tr>`），**禁止另起一节或堆到文末附录**——堆到末尾，用户读完满篇结论还得自己回头找对应关系，等于没配。
+- **每步三件套**：① 可复制粘贴的完整命令（禁止 `...` / 占位符 / 本机私有地址）② **对错两种预期结果**——✅ 该看到什么、❌ 看到什么就说明这条主张不成立 ③ 这一步证明了什么。**只给成功输出 = 用户跑出别的东西时无法判断是环境问题还是你说的不对，又退回「信或不信」。**
+- **样式建议**（已验证可用）：绿框面板 + 编号圆形步骤标记 + 深色 `<pre>` 命令块 + 三色预期结果框（绿 ✅ / 红 ❌ / 琥珀 ℹ️ 边界说明），让「照做即可」这件事在视觉上一眼可辨。
 
 ```html
 <!DOCTYPE html>
@@ -131,11 +139,14 @@ description: >-
   <style>
     /* lightbox 样式 */
     /* 正文排版样式 */
+    /* 复核流程面板样式：绿框 + 编号圆点 + 三色预期结果框 */
   </style>
 </head>
 <body>
   <h1>文档标题</h1>
   <!-- 说明文字 + 配图 紧密组合 -->
+  <!-- 三列表：每行 = 需求原文 | 我们的实现 | 截图证据 -->
+  <!-- 紧随该行：tr.vrow > td[colspan=3] > 复核流程面板 -->
   <!-- 重复：说明 → 配图 → 说明 → 配图 -->
   <script>
     // lightbox 交互脚本

package/skills/forensic-report/SKILL.md

@@ -179,6 +179,38 @@ SELECT provider_id, count(*) FROM provider_model_pricing
 
 ⚠️ **判断标准：用户拿着这份报告、不问你任何一句话，能不能自己把那几个数字核对一遍？** 能 = 合格；不能 = 补导航，别急着交付。
 
+⚠️ **导航只解决「去哪儿看」，不解决「怎么验」——两者都要有，别拿导航当复核流程交付。** 导航给的是门牌号（哪个页面、点哪几下），复核流程给的是进门之后的动线（按什么顺序做什么、看到什么算对）。只说「去 `/accounts` 看那一行」，用户到了现场还是不知道该验哪一项、看到什么算通过——见下一节。
+
+## 主张自带复核流程（每条主张旁边挂一份能照做的流程）
+
+⚠️ **这是用户第二个会问的问题，紧跟「去哪儿看」之后：「你写的这个 A/B 对照，我咋验证呢？」** ——A/B 截图、前后对比、那个数字，全是**你的结论**，不是他能自己检查的东西。他看完手里只有两个选项：信，或者不信。**只给结论 = 把「可核实」降级成了「请相信我」。**
+
+**判据一句话：把报告发给他、你不说任何一句话，他能不能自己把这条主张跑一遍、亲眼看到同样的结果？** 不能 = 这条主张没交付。
+
+**每一条主张旁边（每条需求原话对应的实现、每个「已修复 / 已生效」的断言、每组前后对比）都要挂一份流程面板**，由逐步编号的操作组成，每步三件套缺一不可：
+
+| # | 给什么 | 硬性要求 |
+|---|---|---|
+| ① | **可复制粘贴的完整命令 / 操作** | 参数写全，禁止 `...` 或占位符省略；**不得引用只有你本机才有的东西**（`localhost`、本机路径、容器名、未提交的文件、正在跑的本机服务）——否则用户一跑就断 |
+| ② | **预期结果，对错两种都要给** | 不只写「应该看到 X」（✅），还要写「**看到 Y 就是这条主张不成立**」（❌）。⚠️ **最关键的一项**：只给成功输出，用户跑出任何别的东西时都无从判断是「我环境不对」还是「你说的不对」，最后又退回「信或不信」 |
+| ③ | **这一步证明了什么** | 一句话点明证据含义，让他不必读完整篇就知道自己在验什么 |
+
+⚠️ **位置铁律：就近嵌入，禁止堆到附录。** 面板要紧贴它要证明的那条主张——**在「需求原文 / 我们的实现 / 截图证据」三列表里，就是那一行的正下方，跨整行（`colspan`）铺开**。用户读到那句主张时当场就能验；堆到文末 = 他读完满篇结论、再自己回头找对应关系。
+
+⚠️ **让因果链在代码 / 数据里自证，而不是靠你断言「是这个改动修好的」。** 「问题 → 修复」那一环，优先落到用户能自己打开的可自查锚点上——**最强的形式是修复脚本 / 部署脚本的注释里逐字引用了问题日志的 trace_id**，用户顺着文件路径和行号点进去，能看到「问题」与「修复」被同一份代码同时提到。退而求其次：迁移文件里写了对应表名、配置项当年的错值就摆在 diff 里。只有确实找不到锚点时，才用你的叙述把因果讲清楚。
+
+> 实例：某次修复的 `deploy.sh` 注释里逐字写着 `trace_id f0aaf7f89cf29f6d69bc8180118de23e`，而那正是此前报 `permission denied (42501)` 那条日志的 trace_id。用户点开脚本第 317-319 行自己一看，「问题日志 → 修复动作」这条链就闭上了，完全不需要信作者的转述。
+
+⚠️ **复现不出来的必须显式标注，并给出「怎么自查当前状态」。** 有些主张用户动手时确实跑不出同样结果（功能开关当时没开、数据事后被人工改过、线上版本已前进、依赖的环境已下线）。这类**禁止悄悄略过或含糊带过**，必须：
+
+1. 明说复现不出来的原因；
+2. 给出用户**自行确认当前状态**的命令（查当前版本号、查那个开关的现值）——这是把「你说了算」换回「他自己能核」的关键一步；
+3. 写明当时的环境版本 / 时间戳，让他能判断差异来自环境变化、而不是你的结论不成立。
+
+⚠️ **含糊的边界比诚实标注的边界危险得多**：前者要么让用户把正常的环境差异误判成造假，要么反过来把造假误判成环境差异。
+
+⚠️ **作者自己的验证 ≠ 用户的复核。** 本 Skill 前面各节（三层证据、负向取证、操作链真点）产出的都是**你给自己留的记录**；本节要的是**用户照着能重跑的操作流程**。你写「我用命令 X 得到了 Y」不等于他拿到了那条命令——前者是记录，后者是交付。
+
 ## 副作用范围上界表
 
 ⚠️ **每条 DELETE / 每次写操作，都要在报告里逐条列表回答三个问题**（这是把「数据库 DELETE 铁律」要求的注释内容搬进报告——注释只有写代码的人看得到，报告是给用户和 reviewer 看的）：
@@ -212,15 +244,16 @@ SELECT provider_id, count(*) FROM provider_model_pricing
 
 ## 报告骨架（缺一不算完成）
 
-1. **需求原文 ↔ 实现 ↔ 证据**（骨架的第一层，见规则「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求单原文（保留原用词与标点，错别字照抄并注明「逐字保留原文」），按句拆成三列表并排——「需求原文（逐字） / 我们的实现 / 证据（哪张图 / 哪条命令 / 哪个数字）」，引用块头部给出需求单号 + 可点 URL；原文之外我们额外做的另起一张两列表「原文之外我们额外做的 / 它服务于原文的哪一句」，逐条回连。
-2. **产品自己的承诺**（可选但强烈建议）：产品在界面上对用户承诺了什么（如确认框文案原文）。**先摆产品的承诺，再用证据逐条验证它有没有兑现**——这比自说自话有说服力得多。
-3. **去哪儿看**（可复核导航）：N 个入口的实拍位置 + 点哪几下 + 直达 URL + 搜索词。
-4. **证据分层结论**：三层（页面数字 / 逐像素 / 数据库）各自的关键数值，并按「从软到硬」说明**每一层会被什么骗过、为什么需要下一层**。
-5. **差异归因**：每一处差异的定位 + 放大图 + 归因结论。
-6. **数据库逐行对照**：基线 → 事后 → 增减量 → 是否等于预期。
-7. **真实的操作链**：逐步截图 + 前置条件说明。
-8. **副作用范围上界表**：逐条 DELETE 的三个问题 + 实测值。
-9. **结论**：逐条列出证据关键数值与可复查标识，量化说清「该变的变了多少、不该动的 0 变化」。
+1. **需求原文 ↔ 实现 ↔ 截图证据**（骨架的第一层，见规则「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求单原文（保留原用词与标点，错别字照抄并注明「逐字保留原文」），按句拆成三列表并排——「需求原文（逐字） / 我们的实现 / 截图证据」，**最右列把带箭头标注的截图直接内嵌在同一行**（点击可放大到全屏），而不是只写「证据见下图 N」把读者支使到别处翻；引用块头部给出需求单号 + 可点 URL；原文之外我们额外做的另起一张两列表「原文之外我们额外做的 / 它服务于原文的哪一句」，逐条回连。
+2. **每条主张旁的复核流程**（见规则「⚠️ 主张自带复核流程铁律」）：**紧贴第 1 层表格的每一行正下方**，跨整行（`colspan`）插一个流程面板——逐步编号的操作 + 可复制粘贴的完整命令 + **对错两种预期结果**（✅ 该看到什么 / ❌ 看到什么就是不成立）+ 这一步证明了什么；因果链尽量落在「脚本注释里的 trace_id」这类可自查锚点上；复现不出来的显式标注原因 + 自查当前状态的命令。**面板就在那一行下面，不另起一节、不堆附录。**
+3. **产品自己的承诺**（可选但强烈建议）：产品在界面上对用户承诺了什么（如确认框文案原文）。**先摆产品的承诺，再用证据逐条验证它有没有兑现**——这比自说自话有说服力得多。
+4. **去哪儿看**（可复核导航）：N 个入口的实拍位置 + 点哪几下 + 直达 URL + 搜索词。
+5. **证据分层结论**：三层（页面数字 / 逐像素 / 数据库）各自的关键数值，并按「从软到硬」说明**每一层会被什么骗过、为什么需要下一层**。
+6. **差异归因**：每一处差异的定位 + 放大图 + 归因结论。
+7. **数据库逐行对照**：基线 → 事后 → 增减量 → 是否等于预期。
+8. **真实的操作链**：逐步截图 + 前置条件说明。
+9. **副作用范围上界表**：逐条 DELETE 的三个问题 + 实测值。
+10. **结论**：逐条列出证据关键数值与可复查标识，量化说清「该变的变了多少、不该动的 0 变化」。
 
 ⚠️ **报告要在靠前位置放一张「为什么这样验证成立」的原理卡**：先讲清「本次变更的本质是哪一个动作」，再论证「手动模拟该动作 = 真实场景」。**本次的核心论证是**：这个修复的唯一改动点，可以精确映射成一个可手动触发的原子操作（如「对一个还挂着 Active 模型映射的账户执行删除」）——它在旧代码上必定失败、在新代码上必定成功，**是一个天然的「版本判别器」**。所以并不是「删了账户再回头证明表没被动」，而是**刻意构造了一个只有新版本才做得成的动作**：动作做成了 = 新版在跑；副作用范围正确 = 级联被限制住了。**两件事一起成立，才等于「修复按预期生效」。**
 
@@ -236,13 +269,14 @@ SELECT provider_id, count(*) FROM provider_model_pricing
 ## 判断边界
 
 - ⚠️ **改动命中「三层」条件却没做负向取证就宣称完成 → 直接违背铁律，必须停下并补齐。**
+- ⚠️ **只给了结论、没给复核流程 → 违背「⚠️ 主张自带复核流程铁律」，等于没交付。** 典型信号是用户看完问出「**这个我咋验证呢？光看到你写的 A/B 对照了**」——他手里只剩「信」或「不信」。补齐动作：给每条主张补一个紧贴该行的流程面板（可复制命令 + 对错两种预期结果 + 这一步证明了什么），而不是回一句「我验证过了」。
 - ⚠️ **改完才发现没取基线** → 如实说明「基线缺失、本次无法证明未变更」，并说明补救方案（如在下一个可对照的时点重新取基线跑一次），禁止用「应该没动」搪塞过去。
 - ⚠️ **用户明确说「不用取证，我就要结果」** → 按用户指令执行，但交付时必须显式说明「本次跳过了取证」及跳过了哪几层。
 - **纯文案 / 纯样式 / 无数据变化的改动** → 走一级轻量版（功能证据 + 可复核导航）即可，不必强上三层。
 
 ## 相关
 
-- 规则出处：`AGENTS.base.md`「⚠️ 取证报告铁律」；报告骨架第一层（需求原文 ↔ 实现 ↔ 证据）出处：`AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」
+- 规则出处：`AGENTS.base.md`「⚠️ 取证报告铁律」；报告骨架第一层（需求原文 ↔ 实现 ↔ 证据）出处：`AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」；每条主张旁的复核流程出处：`AGENTS.base.md`「⚠️ 主张自带复核流程铁律」
 - 改之前证明问题存在：`AGENTS.base.md`「⚠️ 缺陷复现铁律」
 - 改之后证明问题消失：`AGENTS.base.md`「⚠️ 修复验证铁律」
 - 链路成不成立（下游接住了吗）：`AGENTS.base.md`「⚠️ 跨系统真实链路验收铁律」+ `real-chain-verify` skill