fixing-flakes 是 stripe-android 项目中的一项技能，目标是对不稳定的 stripe-android 测试进行复现、诊断和修复，采用聚焦、重复验证以及证据驱动的同步或确定性修复方式。
用途 该技能用于处理测试中的 flaky（不稳定）问题，即同一测试在不同执行中结果不一致的情况。它强调基于证据进行修复，要求先获取失败证据，再实施永久性修改。
主要能力
- 确定测试范围：使用 rg 定位测试及其规则，并将测试分类为单元、协程、Robolectric/Compose、截图、插桩、托管设备或外部表面 E2E 测试。明确禁止对非插桩测试使用模拟器。
- 要求失败证据：在实施或提交永久修复之前，必须获得符合条件的证据，例如带有原始异常和相关堆栈帧的聚焦本地复现，或可操作的原始 CI 失败追踪加上确定性回归测试。
- 选择重复机制：对插桩测试使用仅诊断用途的 ShampooRule 工作流；对单元、协程、Robolectric/Compose 和截图测试，保持常规规则链并无缓存地重复聚焦的 Gradle 任务。先执行 2 次，再要求最终候选通过 50 次干净执行。
- 应用 ShampooRule：替换 flaky 测试实际使用的共享规则链中的 RetryRule。不能将 ShampooRule 与 RetryRule 并存，因为重试会隐藏第一次失败迭代。
- 运行聚焦模拟器测试：对浏览器重定向使用启用了 Chrome 的 Pixel 2/API 33 托管设备。文档提供了具体的 Gradle 命令示例。
- 升级 Shampoo 迭代次数：从 ShampooRule(2) 开始，通过后改为 50，全部通过后才算修复得到验证。
- 读取证据：Gradle 报告一个 JUnit 测试，因为 ShampooRule 在单个测试方法内重复。需要从托管设备 logcat 确认实际迭代次数，并查找相关产物。
- 修复根本原因而非症状：要求给定测试设置有确定的单一结果。优先使用有界、基于状态的同步，而非重试或任意睡眠。涵盖时间、采样异步工作、执行顺序、重复进程状态、Compose、事件驱动稳定化、顺序、Espresso、UiAutomator 与 Chrome、WebView 与服务器驱动 UI、异步 UI 资源、外部活动、测试生命周期等方面。
- 最小化并隔离修复：将通过 soak 测试视为候选修复的验证，而非证明候选中每个更改都必要。需要审查永久差异，尝试逐个移除、缩小或整合推测性和不相关的更改，并在每次实质性简化后重新验证。
- 确保 Shampoo 不出现在提交和 PR 中：在任何 git add、git commit、gh stack push、gh stack submit 或 PR 创建之前，必须使用 apply_patch 将规则文件恢复为 soak 前的 RetryRule 配置，并检查未暂存和已暂存的规则文件差异。
使用方式 该技能通过调用方式使用，在执行任何 Gradle 命令前先调用 delegate-low-reasoning-work，并在可用执行器时委托精确命令。使用 rg 定位测试和规则，根据测试类型选择相应的重复机制，对插桩测试应用 ShampooRule，运行聚焦模拟器测试，按需升级迭代次数，读取证据并修复根本原因。
适用场景 适用于 stripe-android 项目中处理单元测试、协程测试、Robolectric/Compose 测试、截图测试、插桩测试、托管设备测试以及外部表面 E2E 测试中的 flaky 问题。特别适用于使用 PaymentSheet 示例 E2E 测试、Chrome 重定向流程、IME 测试等场景。
限制
- ShampooRule 交换和迭代次数修改只能用于本地工作区，绝不能在 pull request 中暂存、提交、推送或提交。
- 在实施永久修复前必须获得符合条件的失败证据。
- 如果初始两次执行复现通过，需在更改永久代码前运行聚焦的 50 次执行基线。如果全部 50 次通过且没有符合条件的外部证据，则恢复所有诊断性修改并停止，报告任务无法复现。
- 不能通过接受竞态中任意结果让 flaky 测试通过。
- 不要捕获并抑制失败、增加 RetryRule 尝试次数、添加广泛延迟、仅仅延长不精确的等待或削弱断言。
- 如果失败仅来自基础设施，应单独报告该证据，而不是更改产品或测试行为。
- 修复完成前必须完成简化尝试，且最终 PR 差异应包含隔离的因果修复，而不是更大的诊断候选。
该技能未提供官方收费、价格、平台或效果信息。