investigate

调查

修复 Bug 前先确立因果证据。对于仅要求诊断的请求，报告原因和修正方案，不要编辑源代码。

从症状入手

阅读错误、失败的测试、问题描述或观察到的行为。明确预期行为与实际行为，并在相关环境中复现故障。检查相关代码、调用方和数据。若已提供经过验证的根本原因，则直接复用，不必重复调查。

直接原因可验证时使用快速模式。如果第一个假设不成立，就扩大调查范围。遇到性能、环境或回归问题时，只阅读 specialized.md 中对应的部分。

调查

简要记录证据：观察结果、假设、反证检查、结果和下一步行动。对于明显的 Bug，记下几条即可；对于耗时较长的调查，将记录保存为临时材料。避免反复通读完整日志。

沿着数据流追踪故障边界。只有证据表明相关时，才检查部分更新、过时状态、权限、编码、时间/区域设置、依赖项、并发和外部约定。确认已安装的 API 后，再判断框架行为。对外部资料进行研究时，使用经过脱敏的通用错误信息和一手资料；不要上传私有日志或客户数据。

通过复现、断言、跟踪记录或受控实验，检验具体的因果假设。寻找能够推翻假设的证据。多个假设失败，说明应该重新评估模型和证据，而不代表架构有误。继续进行有效检查；如果缺少的信息或重要的范围决策阻碍了进展，则应提出询问。

修复与验证

获得修复授权且原因有证据支持后，只修改责任代码，不顺带清理相邻代码。保留冻结的约定和无关的未提交改动。对于逻辑或约定类 Bug，如果项目支持，应添加有意义的回归测试，并证明不修复时测试失败、修复后测试通过；明确要求保留的 RED 流程时间顺序也应照做。

使用最终文件复现原始场景，然后运行一次适当的测试和 lint。如果受影响的调用方或故障证据有此需要，则扩大覆盖范围；修改后重新运行受影响的检查。保存原始日志并总结结果，不要重复粘贴完整的测试套件结果。文件数量本身不构成重新申请批准的理由。

如果修复无法得到完整验证，应标记为未经验证，不要将其作为已证实的修复交付。不要通过削弱或删除测试来制造通过结果。如果相同原因可能影响相关路径，则检查这些路径；更广泛的架构工作应另行提出。

结果

报告症状、有证据支持的原因、已修改的文件、复现/测试证据、剩余的不确定性以及交付状态。只有完成请求的修复并通过所需验证，才能标记为 DONE；DONE_WITH_CONCERNS 表示仍有未完成但不阻塞交付的覆盖；BLOCKED 则应说明缺少的信息或授权。仅在现有任务授权范围内提交、推送或合并。