blast-radius

影响范围

在变更发布前，找出它会在其他地方破坏什么。适用于“X 的影响范围”“这可能会破坏什么”，或审查你还不敢信任的小型差异。在设计前就运行它，而不只是发布前；当需求简报对现有代码作出断言（“将端点 X 设为公开”）时尤其如此：这个断言只是一个假设，消费者普查才决定设计。

它是 how 和 why 的补充。how 告诉你代码做什么。why 告诉你代码为何如此设计。影响范围告诉你它会在其他地方破坏什么。

列出调用方不是这项工作的重点。Agent 可以稍后用 grep 找到它们。这项工作的重点是找出 grep 无法发现的破坏。

别相信自己的报告

一份听起来有理有据的影响范围报告毫无价值。无论它是否属实，读起来都很有说服力。因此，不要直接交付报告。找出整份报告赖以成立的一两个事实，并通过运行代码来证明它们。

你有多确定

对于变更安全性所依赖的每一项事实，尽可能以低成本将它验证到下面列表中的更高层级，并说明验证停在哪一步。

1. 你这么说了。单凭这一点毫无价值。
2. 你指出了代码行。提供真实的 file:line，或库自身的源代码。
3. 你证明了坏情况不可能发生。你逐步检查了失败路径，并证明它无法到达。
4. 你实际运行了。编写脚本或测试，调用真实代码，并在你错了时明确失败。
5. 你在运行中的应用里复现了。

第 4 步通常只需一个小脚本：导入应用实际使用的同一个库，并调用你担心的确切函数。

步骤

1. 阅读变更。检查差异、新增、修改和删除的符号，以及现在行为上的变化，包括差异没有明确说明的部分。使用 why 的第 2 步拉取 PR 和提交。
2. 找出它安全的那个事实。大多数看起来有风险的变更之所以安全，是因为一个单一事实，例如“这个调用只会删除已失效的缓存条目，不做其他事”。找到这个事实。如果它成立，大多数风险案例就能一次性排除。把时间花在这里，而不是列出一长串可能性。
3. 检查 grep 无法触及的部分。阅读你所调用库的源代码，并检查其固定版本以及任何本地补丁。弄清楚代码何时运行：微任务、卸载和清理、Solid 与 React 的区别。追踪符号搜索会遗漏的内容：API 返回的 JSON、数据库列、传输格式、用另一种语言读取的相同字节、功能标志，以及下游第三层的代码。
4. 对每项风险如实评估。判断它实际发生的可能性，以及发生后的真实代价。保留已确认的风险；将你检查后排除的风险单独列出。遵循 why 的相同规则。引用真实的 file:line；搜索无结果也仍然是答案；绝不要编造调用方或 API。
5. 证明那个事实。编写脚本或测试来运行真实代码，运行它，并粘贴运行结果。
6. 对于大型或影响广泛的变更，将其作为 arena 运行。向多个模型提出相同问题，然后整合答案。不同模型能发现不同的真实漏洞。

需要交付的内容

• 它做什么。 说明变更内容，包括不明显的部分。
• 它安全所依赖的那个事实。 陈述该事实，说明验证到了哪一步，并展示证据。如果无法证明，请写明未证实。
• 风险。 对每项风险说明它会如何导致破坏、对应的 file:line、发生可能性和影响严重程度，以及如何检查。粘贴重要风险的证据。
• 已排除。 说明你检查了什么，以及为何没有问题。
• 合并前。 给出能发现真实漏洞的最低成本测试或复现，包括你编写的脚本。

通过 unslop 撰写，引用真实代码，并在公开发布前删除任何私人内容。

回复： 上述报告，并将那个安全事实标记为已证实或未证实。