audit-tests

审计测试

审计测试的独立证明力：如果删除这个测试，什么 bug 会漏掉？ 结果是一张契约与仍能覆盖它的测试的映射，并附上决定保留、修复、合并或删除的证据。目标不是减少测试数量，而是在保持或提升信心的同时减少维护工作。

write-tests 负责说明如何编写测试并验证测试是否有效。 本技能负责判断测试是否增加了证明力，以及这份证明力应归属何处。 review 负责完成由此产生的更改。

工作流

1. 界定审计范围。 阅读仓库和适用的说明，然后选定一项生产职责。找出相关测试、固定装置、共享测试套件和 CI 选择规则。编辑前记录起始修订版本、本地更改和测试结果。区分已有失败与无法运行的检查。聚焦审计时，选择少数有充分依据的候选项；全面扫描子系统时，遵循下方的完整性规则。
2. 追溯主张。 完整阅读每个候选测试，包括参数行，并对照生产入口及其调用到的代码。检查调用方、同级实现、重叠覆盖，以及说明测试存在原因的历史记录。如果主张依赖依赖项的行为，应检查依赖项的代码或类型。写明断言实际能检测到什么，即使测试名称承诺了其他内容也不例外。
3. 编辑前记录处理结论。 使用下方的证据记录。发现逐渐明确时及时分享；工作流不得隐瞒重大发现。仅要求审计的请求应以这份证据和建议的批次结束，不应进行删除。
4. 选定保留测试的归属。 对照各项记录，查找整层冗余，而不只是单条薄弱断言。指出由哪个测试套件负责覆盖每项契约，以及该套件必须吸收的所有独特案例。优先选择依赖受控外部依赖项的真实路径，而非重放内部协作者。只有当选定的测试套件无法暴露某项故障（例如路由或生命周期行为）时，其他层才有必要承担覆盖。
5. 更改一个连贯的边界。 如果实现也在范围内，应先使用 write-tests 将独特案例迁移到保留的测试套件，再移除原有归属。扩展现有案例和固定装置，而不是克隆设置代码。在同一批次中移除不再需要的测试钩子和支持代码；删除导出、包装器、重置函数、全局变量或注入参数前，先验证生产环境中的使用方。迁移测试套件时，更新测试发现和 CI 注册。
6. 证明覆盖得以保留。 将已删除的断言与保留的断言进行比较，查找丢失的契约，以及无法因预期原因失败的断言。使用 write-tests 验证修复或迁移后的回归覆盖。隔离临时生产代码更改，在不影响其他工作的前提下恢复原始字节，并确认目标证明仍然通过。单独报告基线失败，并调查任何新失败。运行归属测试套件和同级测试套件，然后运行仓库要求的检查。替换静态检查时，应执行它所声称检查其契约的实际命令或试运行。测试运行器读取文件期间，应保持文件稳定。
7. 完成批次。 运行 review，然后根据已交付内容核对证据记录。明确报告未解决的失败和未运行的检查。更小且干净的测试套件并不能证明被删除的覆盖是冗余的；真正能证明这一点的是契约映射和覆盖保留证据。

证据记录

对每个候选项，记录其位置和名称、实际可检测到的故障、其存在的原因、任何辅助钩子的生产使用方，以及处理决定：

• **保留：**指出受到独立保护的契约。仅移动文件不会改变此决定。
• **修复：**保留契约，但替换薄弱、容易误导或边界不当的断言。
• **合并：**指出目标测试套件，以及原测试移除前必须验证的独特场景。
• **移除：**指出仍然有效的更强证明，或证明不存在需要保护的契约。仅怀疑重复不足以作为依据。

附上支持该决定的源代码／历史证据、由此可清理的内容、风险和验证命令。缺失的证据应作为待解决问题，而不是删除理由。

虚假信心

将以下内容作为调查提示，而非自动删除规则：

• **循环论证。**预期输出来自正在测试的同一辅助函数；测试夹具复制了生产环境中的清单；测试将一个值与自身比较。应寻找独立于实现的预期结果。
• **没有主张的练习。**执行代码行、复制标识符或列出导出项，可能提高覆盖率，却无法检测可信的缺陷。应确定仅执行代码本身是否能强制保证任何有意义的行为。
• **测试框架包办了工作。**模拟对象实现了本应由产品保证的行为；测试夹具提供了生产代码必须生成的确认或顺序；或者持久化断言读取了真实路径从不写入的存储。对不同依赖 API 使用同一个模拟对象，可能掩盖它们之间的差异。
• **错误原因导致测试失败。**负向用例触发了不同的保护逻辑，或根本没有进入目标分支。应验证失败条件，而不只是确认输入被拒绝。检查每一行参数是否都能验证其对应主张。
• **将声明当成行为。**源码搜索、导入列表、能力标志和内部调用形式，可能证明了声明本身，却无法证明用户路径正常。应追踪该声明所承诺的行为。
• **重复同一项证明。**私有辅助函数测试、针对每个提供方重复执行共享逻辑，以及多个层级测试同一回归，都可能保护同一个契约。应保留不同的传输和生命周期风险，而不是将同一场景以不同文件名重复测试。
• **测试让代码继续存在。**某个辅助函数或生产环境的逃生口只因测试调用它才存在。应将验证移至真实入口点，并移除已废弃的机制；不要用另一个仅供测试使用的抽象替代它。

哪些内容值得保留

行为包括兼容性和运维契约：API 和 SDK 形式、线路字节、提示词、默认值、配置、迁移、存储、安全、平台行为、生成的跨语言一致性、包内容、发布规则和架构边界。静态断言可能是验证这些内容最简单且独立的方式。可观察到的顺序也属于这一范畴。

应考虑测试能否在内部重命名后继续发现外部承诺遭到破坏。对于协议，精确字节可能至关重要；对于私有标识符，通常并非如此。速度慢或与实现相似，都不足以作为删除依据。如果能直接测试真实契约，就不要添加对重构敏感的覆盖。

现有失败可能是产品缺陷。应复现并调查，绝不要为了让审计通过而删除有效的主张。应在范围内单独修复缺陷，并在同一测试框架上先运行失败的对照测试，再验证修复通过。将无关缺陷记录为后续事项，并保留其覆盖。

全子系统清理

先核算，再扩大修改范围：

• 清点所有归属本项目的测试，包括共享测试套件以及集成、QA 或线上测试框架中的用例。将每个测试分配给一项生产职责，即使文件前缀不一致也不例外。记录基线结果以及测试和支持代码的规模。
• 为每条声明确定处置方式并提供证据。只有在参数表的所有行都应得到相同决策时，才能共用一条记录。然后再次审查所有记录，选出要保留的测试套件和要退役的层。
• 条件允许时，按职责委派只读调研。共享夹具的修改由一名负责人统一管理。每个批次都不得引入无法解释的失败；已记录的基线失败须继续保持可见，以便修复。
• 请独立审查者将已移除的覆盖与新的负责方进行对照。对于报告的每个缺口，都要通过恢复证明或提供反驳它的源码证据来解决。展示每项恢复的契约都能捕获一个蓄意引入的缺陷。
• 如果基线有所更新，请检查任何待移除文件中的新增用例，并将其契约纳入后续工作。遵循代码库的集成策略，然后在最终版本上重新运行子系统检查和必需的集成检查。在开始下一批之前，刷新调研结果。

完成

交接契约映射、决策及理由、生产代码简化内容、有价值且刻意保留的测试、覆盖保留方面的缺口及其解决方式，以及实际运行的验证。对于大范围清理，分别列出生产代码、测试和支持代码的前后规模，并说明剩余批次和集成状态。规模用于描述结果，绝不能用来设定删除目标。只有在清单中的每一项都经过审查后，才能声称已完成整个子系统的审计。