investigue

在开始之前，请确认你具备以下两项信息：

• 症状：具体发生了什么（错误消息、观察到的行为、返回值……）
• 预期行为：应该发生什么

如果缺少其中任何一项，请先明确询问，再继续。

---

进行任何修复之前，请按顺序完成以下 4 个阶段。每个阶段结束后都要停下来，等待我的确认。

阶段 1：定位并复现。

根据症状探索代码（必要时使用 Explore 子 Agent），找出最可能存在问题原因的 2～3 个位置。逐一列出，并各用一句话说明理由。然后用 3 行描述能稳定复现此错误的最简场景。如果无法可靠复现，请说明这一点，并提出实现可靠复现的计划。

阶段 2：按可能性排序的 3 个根因假设。

提出 3 个关于根本原因（而非症状）的假设，并按可能性从高到低排序。每个假设先用 1 句话说明，然后给出可证伪的预测——“如果此假设成立，我们会观察到 <具体观察结果>；如果观察到相反情况，就排除该假设”。

阶段 3：测试假设 #1。

添加有针对性的日志，以验证假设 #1。每条日志都以标签 [DEBUG-a4f2]（4 个随机字符）作为前缀，以便之后批量删除。此阶段不要提出修复方案。告诉我需要观察什么才能确认或否定该假设。

3 次失败规则：如果 3 个假设都不成立，就停止。这不再是代码错误，而是架构问题。我们换个角度。

阶段 4：最小修复。

确认假设后，提出能够解决根因的最小改动。不做无关优化，也不趁机重构。撰写提交说明，解释根因，而不是症状。