变更发布前评估爆炸半径并用运行真实代码证明安全依赖事实时用

在变更发布前找出 diff 之外可能被破坏的地方，并通过运行真实代码证明其安全性所依赖的关键事实。

适用场景

解决思路

1. 读取变更：查看 diff、它新增/修改/删除的符号，以及它现在行为有何不同，包括 diff 没有明确写出的部分；用 `why` 的第 2 步拉取 PR 和 commits。
2. 不要只列出调用者；调用者可以用 grep 一秒找出，真正的任务是找出 grep 看不到的破坏。
3. 不要信任自己的书面分析；听起来正确的爆炸半径报告无论真假都很有说服力，因此不要只交回报告。
4. 找出整个变更安全性所依赖的一两个事实，并通过运行代码来证明它们。
5. 对变更安全性依赖的每个事实，按确信度阶梯尽量降到成本可接受的最低级别，并说明停在哪一级。
6. 确信度第 1 级：你只是这么说；单独看毫无价值。
7. 确信度第 2 级：你指向具体行；给出真实 `file:line`，或库自身的源码。
8. 确信度第 3 级：你证明坏情况不会发生；逐步走完失败路径，确认它到不了。
9. 确信度第 4 级：你运行了它；写脚本或测试调用真实代码，如果判断错了就大声失败。
10. 确信度第 5 级：你在运行中的应用里复现了它。
11. 第 4 级通常是一个小脚本，导入应用实际发布的同一个库，并调用你担心的那个确切函数。
12. 找出变更之所以安全所依赖的那一个事实；大多数看起来有风险的变更之所以安全，是因为某个单一事实，例如“这个调用只会丢弃已经死亡的缓存项，不做其他事”；如果该事实成立，大多数风险场景会一次性排除；把时间花在这里，而不是一长串可能项。
13. 查看 grep 停止的地方：阅读你调用的库的源码，检查其 pinned version 和任何本地 patch。
14. 弄清运行时机：microtasks、unmount 和 teardown、Solid 与 React。
15. 追踪符号搜索会漏掉的东西：API 返回的 JSON、DB column、wire format、读取同一字节的另一门语言、feature flag、下游三跳之外的代码。
16. 对每个风险诚实：给出真实发生概率和一旦发生的真实代价。
17. 保留已确认的风险；把你检查过并排除的风险单独列出。
18. 遵循与 `why` 相同的规则：引用真实 `file:line`；搜索不到结果仍然是一个答案；绝不编造调用者或 API。
19. 证明那一个事实：写一个脚本或测试来运行真实代码，运行它，并粘贴发生了什么。
20. 对大型或影响面广的变更，把它作为 `arena` 运行：问多个模型同一个问题并合并答案；不同模型会抓到不同的真实 bug。
21. 交付“它做什么”：说明改了什么，包括不明显的那部分。
22. 交付“它之所以安全所依赖的那一个事实”：陈述该事实，说明你把它推进到哪一级，并展示证明；如果无法证明，写 unproven。
23. 交付“风险”：每条风险说明它如何破坏、`file:line`、发生概率和严重程度，以及如何检查；对重要的风险粘贴证明。
24. 交付“已排除”：你检查了什么，以及为什么没问题。
25. 交付“合并前”：能抓到真实 bug 的最便宜测试或复现，包括你写的脚本。
26. 通过 `unslop` 撰写，引用真实代码，并在任何公开之前剥离私有内容。
27. 回复：上述报告，并让那一个安全事实要么已被证明，要么标记为 unproven。

适用边界 · 注意事项

• 只想知道代码做什么时，不用它；应使用 `how`。
• 只想知道代码为什么形成这样时，不用它；应使用 `why`。
• 只需要列出调用者时，不用它；grep 即可，这不是本任务。