用途：稳定一个已存在的非确定性（flaky）测试。它不用于修复 100% 失败的普通缺陷（那属于写修复），也不用于编写新测试。
主要能力与规则：
一、先复现再声称理解。循环运行该测试直到触发失败，通常 100 次，低频 flake 常需 500–1000 次；再循环足够次数以信任观察到的失败率。若无法复现，应扩大条件（CI 负载、并行跑同组测试、固定或变换 seed、推进时钟），而不是断定它从未真实存在。需粘贴显示通过与失败的循环输出作为复现证据。如何循环单个测试应查 AGENTS.md 或项目机制，不得猜测。
二、命名非确定性类别以缩小修复范围：timing/ordering、shared state、network/external service、randomness、time/clock、resource exhaustion、environment。混合类别的 flake 需拆成独立修复。
三、在生产代码或测试设置中找根因，绝不在断言中找。断言只是信使；根因位于非确定性生产代码（未播种随机、未 mock 的时间、竞态）、未隔离的 setup/teardown、并行运行器框架或环境。
四、修复根因，绝不掩盖。例如注入时钟或 seed 而非读取真实值；隔离共享状态（新鲜 fixture、限定作用域的 teardown）；等待真实契约（稳定状态、发出的事件）而非 sleep；正确保留和释放争用资源。
五、用同一测试循环证明修复：在 flake 复现的条件下循环足够次数，每一次都通过，并粘贴输出。一次通过只证明失败率低于 100%。
六、在根因处留一行注释命名失败模式。
七、若根因是真实生产 bug（竞态、未处理拒绝、泄漏），本技能交付诊断与作为回归护栏的稳定测试，生产修复是独立工作，应记录而非捆绑。自我批准不构成独立证据。
使用方式：打开 references/notes.md 并复制到本次运行的工作笔记文件，随做随填，内含 flake 类别、复现协议与证据、假设追踪、修复证据与自审。此纪律在任何仓库和测试运行器中适用，但无编辑时强制。
限制：不包含具体命令示例；项目如何循环单测暂未提供。需避免的诱惑包括：重跑变绿即称修复、加 sleep、无法复现就放弃、放宽断言、try/catch 包裹、跳过测试保 CI 绿、仅凭 diff 断定修复。