用途：write-fix 是叠加在基础 implement-task 规则之上的修复纪律，用于把一份缺陷报告转化为一次可审查的修复。它强调修复容易以两种方式失败：只压制症状而根因仍在，或回归测试并未真正触发该缺陷。
主要能力与要求：
- 打补丁前必须在工作区复现缺陷，重跑报告中的复现步骤并粘贴失败输出；无法复现时不应打补丁，环境差异本身应作为发现或阻塞项上报。
- 修复根因而非症状。打补丁前用自己的话说明为何该位置是原因，而非失败显现之处；吞掉错误、钳制数值或对触发输入特判都会让根因以其他触发方式存活。
- 回归测试必须在修复前失败、修复后通过。把修复移除（回退或注释掉相关路径）后测试必须失败，恢复后必须通过，并粘贴两次转变。断言应针对缺陷破坏的行为（输出、返回值、发出的事件），而非内部状态。
- 运行完整测试套件而非只跑回归测试，并粘贴输出。
- 保持修复最小化，不捆绑其他改动；相关缺陷只作为摘要中的发现候选。
- 在摘要中用一两句话说明补丁为何解决根因。
- 粘贴所有证据；命令从 AGENTS.md 解析，命令未定义时应询问；不得对自己的工作出具审查结论。
根因排查：对第一个看似合理的解释保持怀疑；从可观察失败回溯到产生它的状态加输入；把原因锚定到 file:line 并给出触发状态与输入；说明 Expected 与 Actual 以及 Expected 的依据来源；无法复现时变化负载、并行、种子、时钟、数据状态等条件，仍无法触发则上报阻塞问题。
使用方式：开始前打开 references/task-template.md 并复制到任务文件中，随做随填，用于搭建复现块、假设轨迹、粘贴证据与自审。
适用场景：已有缺陷报告、需要产出修复并接受审查的工程任务。
限制：这些是审查包检查的约定，编辑时并无强制机制；编写缺陷报告属于另一指南 write-bug-report；偶发失败的测试应使用 fix-flaky-test 而非本指南。