@routerhub/agent-rules 1.5.215 → 1.5.217

package/AGENTS.base.md

@@ -208,6 +208,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   3. **图间配过渡说明**：每张 caption 讲清「上一步发生了什么 → 这一步点哪里 → 预期看到什么」，报告内按操作顺序成段排布，读者能跟着连点；
   4. **逐张自检**：只看这张图 + 说明，能否照着点出下一步？能 = 合格；不能 = 补一张步骤图或补标注，直到整条流程读者不靠你就能走完。
   5. **就近嵌入（位置铁律）**：分步演示必须紧跟在「该操作对应概念/证据在报告中第一次出现、读者正要问『那到底怎么操作』」的地方之后（如展示「账户挂映射删除被 400 拒绝」的证据图 → 该图下方紧跟「先解绑再删除」的完整演示），禁止把演示单独堆到报告末尾或附录里——读者在定义处看不到演示、不知道下文还有、得自己翻到最后去找，等于没配演示。
+  6. **「差别可辨识」自检——读者照着做完，能看出你说的那个现象吗？** 光「能照着做出来」还不够，还得「做完能看懂」。凡文档描述了某种**对比 / 变化 / 前后差异**的步骤，必须自问：读者照着执行完，能不能一眼看出这个差异？**看不出 → 文字讲不清，必须补一张带箭头标注的执行现场截图，把「哪一行 / 哪个数字 / 哪一列」变了、变成了什么，直接圈出来。** 最容易翻车的是**肉眼看几乎一样的对比**：如 `UPDATE 1` 与 `UPDATE 0` 只差一个数字、同一段命令两次执行的输出几乎雷同、两次探测返回同一状态——作者自己心里清楚哪行对应哪句，读者对着一屏几乎相同的输出根本对不上号，只能回头来问「我执行了咋没看出有啥不同」。**判据是读者，不是作者——作者知道 ≠ 读者看得出。**
   - **类比**：交付报告像给菜谱——一道菜（一个功能）从备料到出锅（完整操作流程）必须给出「第 1 步切什么、第 2 步放多少油」的步骤图，读者照做能做出同一道菜；只贴一张成品照让读者猜过程，等于没教。
   - 反面示例：演示「删不掉挂着映射的账户」，只贴「删除被拒」和「最终删除成功」两张图、不展示中间「打开 Models → Remove(Unbind) → 确认」的顺序，读者仍不知道卡住时该点哪里。
 - ⚠️ **时序抢跑类 bug（表象像「坏了」、根因是「两个动作抢同一个瞬间被吞」）：测试中要能嗅出来，解释要先翻成人话。** 这类 bug 的表象（如「登录转圈 / 点按钮没反应 / 偶发失败」）离根因隔着好几层抽象——AI 测试功能过程中碰到此类现象，必须按时序根因去查，禁止当「偶发 / 环境问题」放掉；定位到根因后向用户解释时，必须先给一版「人话」（读者能顺着走一遍、能当场确认「对，就是它」），再附机制细节（路由守卫 / persist / token 生命周期……），禁止只甩机制清单、让用户自己翻译根因。识别指纹（命中越多越是这类）：
@@ -272,9 +273,26 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
      - ⚠️ **禁止用 `<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 行」。所以「不该动的地方一行没动」必须**单独取证**，不能由「功能正常」推出来。
@@ -632,6 +650,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 ### HTML 文档截图与 curl 命令规范
 
 - ⚠️ **HTML 页面/文档中的外部链接默认用新标签页打开**：所有指向外部资源（其他网站、GitHub 文档、私有文档仓库等）的链接一律写成 `<a target="_blank" rel="noopener" href="...">`，禁止不加 `target` 让用户点击后直接跳出当前页面。**类比：逛商场拿着一份导购地图，每个店名都标着「在新窗口查看」——点一家店不会把你从地图里踢出去，地图还在，能连续逛好几家；不新开窗口的话，每点一家店整张地图就没了，得反复按返回。** `rel="noopener"` 是安全兜底，防止新页面通过 `window.opener` 反向控制当前页（tabnabbing 钓鱼攻击）。
+- ⚠️ **文档正文里每一个「让读者去打开」的地址，后面都要紧跟一个显式的「在新标签页打开」按钮。** 光把已有链接写成 `target="_blank"` 不够——文档里大量地址是以**裸文本**出现的（如步骤里写「打开 `https://github.com/.../postgres.go#L651-L660`」「访问 `https://test-admin.horizonapi.ai/models/accounts`」），读者只能手动选中、复制、切浏览器、粘贴，一步一断。**判断标准：这句话是不是在让读者去打开某个地址？是 → 那个地址后面就得跟一个按钮**（`<a class="open-btn" target="_blank" rel="noopener" href="...">在新标签页打开 ↗</a>`）——点一下直接过去，文档还留在原地，能连着核对好几条。**反面示例：把 `打开 https://.../report.go#L58-L64` 这类纯文字丢给读者，等于让他自己搬运地址。**
 - ⚠️ **截图版 HTML 文档中的截图必须自动加箭头标注**：当用户要求写「截图版 HTML」文档（以截图为主体、图文结合说明实现/操作步骤的文档，如部署实现说明、操作指南等）时，嵌入的每张截图都必须自动用醒目的箭头 + 简短文字标签标注出关键区域/验证点/操作位置，让读者一眼看懂这张图对应文档的哪一步、证明了什么，禁止只贴裸图不标注。箭头标注放在不遮挡原内容的位置。
 - ⚠️ **HTML 文档中的截图必须以 `data:image/png;base64,...` 内嵌，禁止用文件路径或相对链接引用外部 PNG 文件。** 文档会被打开、移动、分享，外部图片路径一旦脱离原目录就全部失效，文档里全是裂图。生成文档后，散落的零散 PNG 文件应一并清理，只保留 HTML 本身。
 - ⚠️ **curl 命令必须完整可复制执行，禁止省略关键参数。** 包括但不限于：API Key / Token、请求体中的图片数据、完整的 URL。禁止用 `...` 或「省略其余参数」代替——看的人无法区分「这里不重要所以省略了」还是「这里我不会写所以跳过了」，前者让命令不可执行，后者掩盖了潜在的错误。
@@ -641,6 +660,8 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **测试用的图片等静态资源统一放到 `screenshots/` 临时目录，curl 命令中用相对路径引用**（如 `@screenshots/test.jpg`），确保命令在项目根目录下可直接执行。
 - ⚠️ **一键执行脚本/命令必须能直接复制到终端执行，且文档中必须配「一键复制」按钮。** 每条命令必须完整可执行（禁止省略参数、禁止用 `...` 占位、禁止只给片段），在项目根目录下可直接运行；文档中命令块右上角必须提供复制按钮，点击即可将完整命令复制到剪贴板并给出「已复制」反馈。
 - ⚠️ **文档中给出的每条命令/脚本，写入前必须亲自在终端实际执行验证过，确认确实可行后才能写入。** 执行失败的命令一律不得写入文档，禁止凭推断「应该能跑」就写进文档——推断得出的结论不能作为生成依据，必须实际测试过才能下结论。
+- ⚠️ **不止命令——文档里写的每一个操作步骤，都必须亲自真实走过一遍，并把这一次的执行现场截下来。** 「命令能跑通」和「跑出来长什么样」是两件事：读者要的是照着做出同一个结果，而你只有亲手做过，才知道中间会弹什么、输出长什么样、哪一步最容易看错。**执行过程本身就是配图的来源**——每写一步，手里就得有一步对应的现场截图（带箭头标注，圈出这一步的输出里哪一行是关键、它证明了什么）；**禁止事后凭印象补画，更禁止拿推断出的「应该会输出什么」当截图**。**没执行过就别写这一步**：没跑过就写进文档的步骤，轻则读者照着一路卡住，重则把错的做法教给了人。**自查一句话：文档里每一个「你来操作一下」的步骤，我能不能指出它对应的是我哪一次真实执行时截的图？指不出 = 这一步还不该出现在文档里。**
+  - **由来（真实案例）**：一份实现文档里写「第 1 次返回 `UPDATE 1`、第 2 次返回 `UPDATE 0`，证明幂等」——作者确实跑过、也确实知道哪行是哪行，但两行输出只差一个数字、psql 一屏几乎一模一样，读者照着敲完对不上号，只能回头问「我执行了咋没看出有啥不同」。**根因不是命令不对，而是少了那张把「哪一行」圈出来的现场截图**——执行过不等于交付清楚了（可辨识性要求见「⚠️ 可视化验证铁律」分步操作教学演示第 6 条）。
 
 ## Go 规则
 

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

package/rules/global.md

@@ -208,6 +208,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   3. **图间配过渡说明**：每张 caption 讲清「上一步发生了什么 → 这一步点哪里 → 预期看到什么」，报告内按操作顺序成段排布，读者能跟着连点；
   4. **逐张自检**：只看这张图 + 说明，能否照着点出下一步？能 = 合格；不能 = 补一张步骤图或补标注，直到整条流程读者不靠你就能走完。
   5. **就近嵌入（位置铁律）**：分步演示必须紧跟在「该操作对应概念/证据在报告中第一次出现、读者正要问『那到底怎么操作』」的地方之后（如展示「账户挂映射删除被 400 拒绝」的证据图 → 该图下方紧跟「先解绑再删除」的完整演示），禁止把演示单独堆到报告末尾或附录里——读者在定义处看不到演示、不知道下文还有、得自己翻到最后去找，等于没配演示。
+  6. **「差别可辨识」自检——读者照着做完，能看出你说的那个现象吗？** 光「能照着做出来」还不够，还得「做完能看懂」。凡文档描述了某种**对比 / 变化 / 前后差异**的步骤，必须自问：读者照着执行完，能不能一眼看出这个差异？**看不出 → 文字讲不清，必须补一张带箭头标注的执行现场截图，把「哪一行 / 哪个数字 / 哪一列」变了、变成了什么，直接圈出来。** 最容易翻车的是**肉眼看几乎一样的对比**：如 `UPDATE 1` 与 `UPDATE 0` 只差一个数字、同一段命令两次执行的输出几乎雷同、两次探测返回同一状态——作者自己心里清楚哪行对应哪句，读者对着一屏几乎相同的输出根本对不上号，只能回头来问「我执行了咋没看出有啥不同」。**判据是读者，不是作者——作者知道 ≠ 读者看得出。**
   - **类比**：交付报告像给菜谱——一道菜（一个功能）从备料到出锅（完整操作流程）必须给出「第 1 步切什么、第 2 步放多少油」的步骤图，读者照做能做出同一道菜；只贴一张成品照让读者猜过程，等于没教。
   - 反面示例：演示「删不掉挂着映射的账户」，只贴「删除被拒」和「最终删除成功」两张图、不展示中间「打开 Models → Remove(Unbind) → 确认」的顺序，读者仍不知道卡住时该点哪里。
 - ⚠️ **时序抢跑类 bug（表象像「坏了」、根因是「两个动作抢同一个瞬间被吞」）：测试中要能嗅出来，解释要先翻成人话。** 这类 bug 的表象（如「登录转圈 / 点按钮没反应 / 偶发失败」）离根因隔着好几层抽象——AI 测试功能过程中碰到此类现象，必须按时序根因去查，禁止当「偶发 / 环境问题」放掉；定位到根因后向用户解释时，必须先给一版「人话」（读者能顺着走一遍、能当场确认「对，就是它」），再附机制细节（路由守卫 / persist / token 生命周期……），禁止只甩机制清单、让用户自己翻译根因。识别指纹（命中越多越是这类）：
@@ -272,9 +273,26 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
      - ⚠️ **禁止用 `<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 行」。所以「不该动的地方一行没动」必须**单独取证**，不能由「功能正常」推出来。
@@ -632,6 +650,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 ### HTML 文档截图与 curl 命令规范
 
 - ⚠️ **HTML 页面/文档中的外部链接默认用新标签页打开**：所有指向外部资源（其他网站、GitHub 文档、私有文档仓库等）的链接一律写成 `<a target="_blank" rel="noopener" href="...">`，禁止不加 `target` 让用户点击后直接跳出当前页面。**类比：逛商场拿着一份导购地图，每个店名都标着「在新窗口查看」——点一家店不会把你从地图里踢出去，地图还在，能连续逛好几家；不新开窗口的话，每点一家店整张地图就没了，得反复按返回。** `rel="noopener"` 是安全兜底，防止新页面通过 `window.opener` 反向控制当前页（tabnabbing 钓鱼攻击）。
+- ⚠️ **文档正文里每一个「让读者去打开」的地址，后面都要紧跟一个显式的「在新标签页打开」按钮。** 光把已有链接写成 `target="_blank"` 不够——文档里大量地址是以**裸文本**出现的（如步骤里写「打开 `https://github.com/.../postgres.go#L651-L660`」「访问 `https://test-admin.horizonapi.ai/models/accounts`」），读者只能手动选中、复制、切浏览器、粘贴，一步一断。**判断标准：这句话是不是在让读者去打开某个地址？是 → 那个地址后面就得跟一个按钮**（`<a class="open-btn" target="_blank" rel="noopener" href="...">在新标签页打开 ↗</a>`）——点一下直接过去，文档还留在原地，能连着核对好几条。**反面示例：把 `打开 https://.../report.go#L58-L64` 这类纯文字丢给读者，等于让他自己搬运地址。**
 - ⚠️ **截图版 HTML 文档中的截图必须自动加箭头标注**：当用户要求写「截图版 HTML」文档（以截图为主体、图文结合说明实现/操作步骤的文档，如部署实现说明、操作指南等）时，嵌入的每张截图都必须自动用醒目的箭头 + 简短文字标签标注出关键区域/验证点/操作位置，让读者一眼看懂这张图对应文档的哪一步、证明了什么，禁止只贴裸图不标注。箭头标注放在不遮挡原内容的位置。
 - ⚠️ **HTML 文档中的截图必须以 `data:image/png;base64,...` 内嵌，禁止用文件路径或相对链接引用外部 PNG 文件。** 文档会被打开、移动、分享，外部图片路径一旦脱离原目录就全部失效，文档里全是裂图。生成文档后，散落的零散 PNG 文件应一并清理，只保留 HTML 本身。
 - ⚠️ **curl 命令必须完整可复制执行，禁止省略关键参数。** 包括但不限于：API Key / Token、请求体中的图片数据、完整的 URL。禁止用 `...` 或「省略其余参数」代替——看的人无法区分「这里不重要所以省略了」还是「这里我不会写所以跳过了」，前者让命令不可执行，后者掩盖了潜在的错误。
@@ -641,6 +660,8 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **测试用的图片等静态资源统一放到 `screenshots/` 临时目录，curl 命令中用相对路径引用**（如 `@screenshots/test.jpg`），确保命令在项目根目录下可直接执行。
 - ⚠️ **一键执行脚本/命令必须能直接复制到终端执行，且文档中必须配「一键复制」按钮。** 每条命令必须完整可执行（禁止省略参数、禁止用 `...` 占位、禁止只给片段），在项目根目录下可直接运行；文档中命令块右上角必须提供复制按钮，点击即可将完整命令复制到剪贴板并给出「已复制」反馈。
 - ⚠️ **文档中给出的每条命令/脚本，写入前必须亲自在终端实际执行验证过，确认确实可行后才能写入。** 执行失败的命令一律不得写入文档，禁止凭推断「应该能跑」就写进文档——推断得出的结论不能作为生成依据，必须实际测试过才能下结论。
+- ⚠️ **不止命令——文档里写的每一个操作步骤，都必须亲自真实走过一遍，并把这一次的执行现场截下来。** 「命令能跑通」和「跑出来长什么样」是两件事：读者要的是照着做出同一个结果，而你只有亲手做过，才知道中间会弹什么、输出长什么样、哪一步最容易看错。**执行过程本身就是配图的来源**——每写一步，手里就得有一步对应的现场截图（带箭头标注，圈出这一步的输出里哪一行是关键、它证明了什么）；**禁止事后凭印象补画，更禁止拿推断出的「应该会输出什么」当截图**。**没执行过就别写这一步**：没跑过就写进文档的步骤，轻则读者照着一路卡住，重则把错的做法教给了人。**自查一句话：文档里每一个「你来操作一下」的步骤，我能不能指出它对应的是我哪一次真实执行时截的图？指不出 = 这一步还不该出现在文档里。**
+  - **由来（真实案例）**：一份实现文档里写「第 1 次返回 `UPDATE 1`、第 2 次返回 `UPDATE 0`，证明幂等」——作者确实跑过、也确实知道哪行是哪行，但两行输出只差一个数字、psql 一屏几乎一模一样，读者照着敲完对不上号，只能回头问「我执行了咋没看出有啥不同」。**根因不是命令不对，而是少了那张把「哪一行」圈出来的现场截图**——执行过不等于交付清楚了（可辨识性要求见「⚠️ 可视化验证铁律」分步操作教学演示第 6 条）。
 
 ## Go 规则
 

package/skills/create-doc/SKILL.md

@@ -124,6 +124,12 @@ description: >-
 
 ⚠️ **交付「需求实现 / 修复验证 / 取证」类文档时，正文骨架必须以需求原话为第一层**（规则见 `AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求原文（保留原用词与标点），按句拆成「需求原文 / 我们的实现 / 截图证据」三列表并排——**最右列把带箭头标注的截图直接内嵌在同一行**（点击可放大到全屏），而不是只写「证据见下图 N」让读者自己去翻；引用块头部给需求单号 + 可点 URL；原文之外额外做的另起一张「原文之外我们额外做的 / 它服务于原文的哪一句」两列表逐条回连。纯操作指南 / 纯设计文档不受此限。
 
+⚠️ **三列表的每一行正下方，还要挂一个「你自己怎么复核这一条」的流程面板**（规则见 `AGENTS.base.md`「⚠️ 主张自带复核流程铁律」）。**少了它，用户看完只会问「这个我咋验证呢？光看到你写的 A/B 对照了」**——截图和结论都是你的断言，他没法自己检查。面板的排法与硬性要求：
+
+- **位置**：紧贴该行、跨整行铺开（`<tr><td colspan="3">…</td></tr>`），**禁止另起一节或堆到文末附录**——堆到末尾，用户读完满篇结论还得自己回头找对应关系，等于没配。
+- **每步三件套**：① 可复制粘贴的完整命令（禁止 `...` / 占位符 / 本机私有地址）② **对错两种预期结果**——✅ 该看到什么、❌ 看到什么就说明这条主张不成立 ③ 这一步证明了什么。**只给成功输出 = 用户跑出别的东西时无法判断是环境问题还是你说的不对，又退回「信或不信」。**
+- **样式建议**（已验证可用）：绿框面板 + 编号圆形步骤标记 + 深色 `<pre>` 命令块 + 三色预期结果框（绿 ✅ / 红 ❌ / 琥珀 ℹ️ 边界说明），让「照做即可」这件事在视觉上一眼可辨。
+
 ```html
 <!DOCTYPE html>
 <html lang="zh-CN">
@@ -133,11 +139,14 @@ description: >-
   <style>
     /* lightbox 样式 */
     /* 正文排版样式 */
+    /* 复核流程面板样式：绿框 + 编号圆点 + 三色预期结果框 */
   </style>
 </head>
 <body>
   <h1>文档标题</h1>
   <!-- 说明文字 + 配图 紧密组合 -->
+  <!-- 三列表：每行 = 需求原文 | 我们的实现 | 截图证据 -->
+  <!-- 紧随该行：tr.vrow > td[colspan=3] > 复核流程面板 -->
   <!-- 重复：说明 → 配图 → 说明 → 配图 -->
   <script>
     // lightbox 交互脚本
@@ -151,6 +160,7 @@ description: >-
 - 截取整页（full page），不是可视区域；用真实视口宽度（4K 屏自然宽 3840），禁止强制把视口拉宽
 - 截图结果必须在图上写出文字版完整 URL（走 `/screenshot-annotate --url`，叠进截图标题条），不得只靠地址栏；且该 URL 必须是别人能直接打开的地址（测试环境 / 线上域名），禁止 `localhost` / `127.0.0.1` / `file:///` 等本机地址；截图一律在测试环境取证，本地效果不作交付证据
 - 文档里每张截图旁再给一个可点击的跳转入口（`<a target="_blank" rel="noopener" href="...">打开页面</a>` 渲染成按钮），让别人一点就在新标签页打开该页面亲自复核，不用从图里抄地址
+- ⚠️ **正文里出现的每一个地址，后面都要紧跟一个「在新标签页打开」按钮**——不只是截图旁那个页面入口：步骤里写的 GitHub 代码行链接（`.../postgres.go#L651-L660`）、要复核的后台页面地址、需求单 URL，**只要这句话是在让读者去打开它，就得跟一个按钮**（`<a class="open-btn" target="_blank" rel="noopener" href="...">在新标签页打开 ↗</a>`）。**禁止把地址当纯文本丢在正文里**——读者得选中、复制、切浏览器、粘贴，一步一断，还容易复制漏字符。（规则见 `AGENTS.base.md`「HTML 文档截图与 curl 命令规范」）
 - ⚠️ **截图版 HTML 的每张截图都必须加箭头（或红框）标注**，指向该图要说明的关键操作点或关键数据，禁止放无标注的「裸截图」；标注放在页面空白区域，不遮挡关键内容。⚠️ **标注坐标必须精确**：用 `/screenshot-annotate` skill（浏览器 DOM 测得的坐标 → `annotate.js` 换算到截图像素），禁止肉眼估位
 - 制作过程中产生的中间截图文件统一放到 `screenshots/` 目录
 
@@ -162,6 +172,8 @@ description: >-
   2. **配截图**：该步骤对应的界面截图，必须带箭头/红框/提示文字标注指向关键操作点或关键数据，标注放在页面空白区域，不遮挡关键内容
   3. **详细说明结果**：这一步执行后出现了什么结果、验证了什么、为什么重要
 - ⚠️ 步骤之间用编号衔接（步骤 1 → 步骤 2 → …），说明文字必须一图一句、逐张不同，禁止用一句套话覆盖所有步骤的截图
+- ⚠️ **每个步骤都必须是「我真跑过的那一次」**：写入文档前，这一步必须亲自真实执行一遍，且**这次执行的现场截图就是该步骤配图的唯一来源**——禁止事后凭印象补画，禁止拿推断出的「应该会输出什么」当截图。**没执行过就别写这一步**：没跑过就写进文档的步骤，轻则读者照着一路卡住，重则把错的做法教给了人。**自查：文档里每个「你来操作一下」的步骤，我能不能指出它对应哪一次真实执行时截的图？指不出 = 不该出现在文档里。**（规则见 `AGENTS.base.md`「HTML 文档截图与 curl 命令规范」）
+- ⚠️ **「差别可辨识」自检——读者照着做完，能看出你说的那个现象吗？** 凡步骤涉及**对比 / 变化 / 前后差异**（两次执行、修复前后、A/B 两组输出），必须自问：读者照做之后，能不能一眼看出这个差异？**看不出 → 文字讲不清，必须在现场截图上用箭头把「哪一行 / 哪个数字 / 哪一列」变了、变成了什么直接圈出来。** 最容易翻车的是**肉眼看几乎一样的对比**：如 `UPDATE 1` 与 `UPDATE 0` 只差一个数字、同一段命令两次执行输出几乎雷同、两次探测返回同一状态——作者自己清楚哪行对应哪句，读者对着一屏几乎相同的输出根本对不上号，只能回头问「我执行了咋没看出有啥不同」。**判据是读者，不是作者——作者知道 ≠ 读者看得出。**（规则见 `AGENTS.base.md`「⚠️ 可视化验证铁律」分步操作教学演示第 6 条）
 - 截图统一用 base64 data URI 内嵌，禁止引用外部图片文件
 
 ### 命令与复制按钮

package/skills/forensic-report/SKILL.md

@@ -179,6 +179,40 @@ SELECT provider_id, count(*) FROM provider_model_pricing
 
 ⚠️ **判断标准：用户拿着这份报告、不问你任何一句话，能不能自己把那几个数字核对一遍？** 能 = 合格；不能 = 补导航，别急着交付。
 
+⚠️ **导航表里的每个 URL 都要渲染成可点的按钮，不能只当文本写在格子里。** 「直达 URL」这一列若是裸地址，用户还得选中、复制、切标签页、粘贴——一步一断，还容易复制漏字符。写成 `<a class="open-btn" target="_blank" rel="noopener" href="...">在新标签页打开 ↗</a>`，一点就在新标签页打开、报告留在原地，能连着核下一条。**正文里其它「让读者去打开」的地址同样处理**（GitHub 代码行链接、需求单 URL、要复核的后台页面）——判断标准只有一句：这句话是不是在让读者去打开某个地址？是 → 后面就跟一个按钮。（规则见 `AGENTS.base.md`「HTML 文档截图与 curl 命令规范」）
+
+⚠️ **导航只解决「去哪儿看」，不解决「怎么验」——两者都要有，别拿导航当复核流程交付。** 导航给的是门牌号（哪个页面、点哪几下），复核流程给的是进门之后的动线（按什么顺序做什么、看到什么算对）。只说「去 `/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 看的）：
@@ -208,19 +242,24 @@ SELECT provider_id, count(*) FROM provider_model_pricing
 
 ⚠️ **禁止用脚本模拟点击、直接改数据库、或调内部接口去造出「改动后」的状态。** 那不是「用户这么操作会发生什么」，而是「我造了一个我希望看到的结果」——两者的差别正是这个 Skill 要防的东西。**报告里要能让读者看出每一步点的是哪个按钮。**
 
+⚠️ **图必须是那一次真实执行的现场截图，不允许事后补画。** 步骤走完再回头凭印象截图、或拿推断出的「应该会输出什么」当图，等于把「我造了一个我希望看到的结果」从「操作」搬到了「配图」——同样是造出来的。**自查：这一步的配图，我能不能指出它是哪一次真实执行时截的？指不出 = 这一步等于没做。**
+
+⚠️ **「差别可辨识」自检——读者照着做完，能看出你说的那个现象吗？** 凡步骤涉及**对比 / 变化 / 前后差异**（两次执行、修复前后、A/B 两组输出），必须自问：读者照做之后，能不能一眼看出这个差异？**看不出 → 文字讲不清，必须在现场截图上用箭头把「哪一行 / 哪个数字 / 哪一列」变了、变成了什么直接圈出来。** 最容易翻车的是**肉眼看几乎一样的对比**：如 `UPDATE 1` 与 `UPDATE 0` 只差一个数字、同一段命令两次执行输出几乎雷同、两次探测返回同一状态——作者自己清楚哪行对应哪句，读者对着一屏几乎相同的输出根本对不上号，只能回头问「我执行了咋没看出有啥不同」。**判据是读者，不是作者——作者知道 ≠ 读者看得出。**（见规则「⚠️ 可视化验证铁律」分步操作教学演示第 6 条）
+
 ⚠️ **遇到「必须先做某个前置动作才能走到目标操作」时，要把前置原因一并写清**（如「删除接口有硬前置校验 `if account.IsActive` → 400 `account must be disabled before deletion`，所以第 ② 步不是可选项」）——否则读者自己复现时会卡在第一步，以为报告是错的。
 
 ## 报告骨架（缺一不算完成）
 
 1. **需求原文 ↔ 实现 ↔ 截图证据**（骨架的第一层，见规则「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求单原文（保留原用词与标点，错别字照抄并注明「逐字保留原文」），按句拆成三列表并排——「需求原文（逐字） / 我们的实现 / 截图证据」，**最右列把带箭头标注的截图直接内嵌在同一行**（点击可放大到全屏），而不是只写「证据见下图 N」把读者支使到别处翻；引用块头部给出需求单号 + 可点 URL；原文之外我们额外做的另起一张两列表「原文之外我们额外做的 / 它服务于原文的哪一句」，逐条回连。
-2. **产品自己的承诺**（可选但强烈建议）：产品在界面上对用户承诺了什么（如确认框文案原文）。**先摆产品的承诺，再用证据逐条验证它有没有兑现**——这比自说自话有说服力得多。
-3. **去哪儿看**（可复核导航）：N 个入口的实拍位置 + 点哪几下 + 直达 URL + 搜索词。
-4. **证据分层结论**：三层（页面数字 / 逐像素 / 数据库）各自的关键数值，并按「从软到硬」说明**每一层会被什么骗过、为什么需要下一层**。
-5. **差异归因**：每一处差异的定位 + 放大图 + 归因结论。
-6. **数据库逐行对照**：基线 → 事后 → 增减量 → 是否等于预期。
-7. **真实的操作链**：逐步截图 + 前置条件说明。
-8. **副作用范围上界表**：逐条 DELETE 的三个问题 + 实测值。
-9. **结论**：逐条列出证据关键数值与可复查标识，量化说清「该变的变了多少、不该动的 0 变化」。
+2. **每条主张旁的复核流程**（见规则「⚠️ 主张自带复核流程铁律」）：**紧贴第 1 层表格的每一行正下方**，跨整行（`colspan`）插一个流程面板——逐步编号的操作 + 可复制粘贴的完整命令 + **对错两种预期结果**（✅ 该看到什么 / ❌ 看到什么就是不成立）+ 这一步证明了什么；因果链尽量落在「脚本注释里的 trace_id」这类可自查锚点上；复现不出来的显式标注原因 + 自查当前状态的命令。**面板就在那一行下面，不另起一节、不堆附录。**
+3. **产品自己的承诺**（可选但强烈建议）：产品在界面上对用户承诺了什么（如确认框文案原文）。**先摆产品的承诺，再用证据逐条验证它有没有兑现**——这比自说自话有说服力得多。
+4. **去哪儿看**（可复核导航）：N 个入口的实拍位置 + 点哪几下 + 直达 URL + 搜索词。
+5. **证据分层结论**：三层（页面数字 / 逐像素 / 数据库）各自的关键数值，并按「从软到硬」说明**每一层会被什么骗过、为什么需要下一层**。
+6. **差异归因**：每一处差异的定位 + 放大图 + 归因结论。
+7. **数据库逐行对照**：基线 → 事后 → 增减量 → 是否等于预期。
+8. **真实的操作链**：逐步截图 + 前置条件说明。
+9. **副作用范围上界表**：逐条 DELETE 的三个问题 + 实测值。
+10. **结论**：逐条列出证据关键数值与可复查标识，量化说清「该变的变了多少、不该动的 0 变化」。
 
 ⚠️ **报告要在靠前位置放一张「为什么这样验证成立」的原理卡**：先讲清「本次变更的本质是哪一个动作」，再论证「手动模拟该动作 = 真实场景」。**本次的核心论证是**：这个修复的唯一改动点，可以精确映射成一个可手动触发的原子操作（如「对一个还挂着 Active 模型映射的账户执行删除」）——它在旧代码上必定失败、在新代码上必定成功，**是一个天然的「版本判别器」**。所以并不是「删了账户再回头证明表没被动」，而是**刻意构造了一个只有新版本才做得成的动作**：动作做成了 = 新版在跑；副作用范围正确 = 级联被限制住了。**两件事一起成立，才等于「修复按预期生效」。**
 
@@ -236,13 +275,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