Flaky Test Fixer 是一个用于处理不稳定测试（flaky test）的技能，来源于 Datadog 的 dd-trace-js 项目。其核心目标是帮助开发者分类、调查并修复间歇性测试失败、非确定性的 CI 失败、时序竞态、挂起等问题。
用途
该技能主要用于在 CI 或本地测试中出现非确定性失败时，提供系统化的调查和修复流程。它强调“flaky”、“pre-existing”和“unrelated”等结论需要证据支持，不能随意下结论。默认将当前更改导致的失败视为由该更改引起，直到有证据表明其他机制。
主要能力
- 分类失败：首先对失败进行分类，分为基础设施问题、确定性缺陷、真正的偶发失败和未知。分类基于一次证据收集，包括确切的失败命令、测试名称、断言或错误、环境、第一个可操作的错误、最后有意义的日志行、测试进程是否启动以及当前 diff。
- 调查与修复：在分类后，重新阅读当前 diff，提出一行候选机制（“X 失败是因为 Y 导致 Z”），通过最小的真实测试入口点复现，保留相关环境变量和服务。仅在测试具体的非确定性假设时，对可疑边界进行压力测试或聚焦重复运行。在安全且可行的情况下，在隔离的工作树或等效的干净环境中与未更改的目标分支进行比较。
- 编写机制句子：在编辑之前，写一个机制句子，命名生产者、消费者、状态或事件，以及无效的顺序或生命周期，必须能解释偶发失败的通过和失败两种情况。
- 搜索相同不变量的测试：在编辑之前，搜索所有具有相同违反不变量和生命周期所有者的测试，列出每个成员和排除项，说明共享的失败机制和生命周期或完成所有者。
- 设计证明并修复：设计证明，然后跟踪成功、错误、重试、清理和并发路径。修复最窄的规范所有者，恢复整个队列的不变量，不添加新的公共或仅测试表面，也不为测试添加生产工作。
- 应用修复：将修复应用于完整队列。停止杂散请求，关闭泄漏资源，恢复钩子，移除共享可变状态。使用假定时器而不是实时等待，使用适当的资源分配而不是任意延迟，使用生命周期所有权而不是强制排序。不要用重试、跳过、睡眠、超时或容差增加、过滤断言或更广泛的模拟来替代原因。
- 验证：在没有修复或使用确定性回归的情况下验证原始失败（如果可行）。在验证计划中单独列出每个更改的兄弟项，然后运行它们、针对性重复或压力运行、完整规格以及 AGENTS.md 要求的覆盖率和 lint。报告命令、迭代次数和未证明的声明。
- 处理挂起：将挂起视为可能被掩盖的失败。在考虑增加超时之前，检查最后有意义的错误和泄漏的句柄，如跟踪器或远程配置定时器、套接字、子进程、服务器和未完成的钩子。
- 并行调查：在分类门之后，当另一个任务中出现疑似无关的偶发失败时，如果子代理可用且调查具有不相交的写入范围，立即委托其调查。继续主任务同时运行。给子代理提供确切的命令和失败输出、当前更改摘要及失败可能无关的原因、相关路径、服务、运行时版本和环境变量、分类优先然后阅读和复现的授权、以及请求复现率、机制、证据和最小建议修复。不要在主线程中重复子代理的调查，也不要让它修改主线程也在更改的文件。
使用方式
该技能以文档形式提供指导，用户在实际遇到测试失败时按照上述流程操作。具体使用步骤包括：首先进行一次证据收集并分类；根据分类结果决定下一步；对于真正的偶发失败，进行复现和机制分析；搜索相同不变量的测试队列；设计并应用修复；验证并报告。
适用场景
适用于 CI 中出现的非确定性测试失败、间歇性失败的测试、疑似时序竞态或挂起的测试。也适用于在开发过程中遇到测试失败但不确定是否由当前更改引起的情况。
限制
该技能强调不能通过削弱或删除断言、过滤意外输入、增加超时或添加无解释的重试来使 CI 变绿。对于基础设施问题，应停止并忽略，除非被要求作为单独的 CI 任务处理。对于未知分类，只能进行一次针对性复现或历史比较，不得将不确定性提升为“flaky”、“infrastructure”或“unrelated”。另外，单独的通过重跑只是非确定性的证据，并不能证明当前更改无关。任何临时跳过都需要在单独的授权更改中记录原因，不能静默削弱断言。