Bug fix

这个任务归你负责。你来规划、评审、验证。 调查和修复交给子代理，你自己保持主导。

要讲科学。交付的每一行代码，都要能追溯到运行时证据。「也许有用」的双保险只是假设，不是修复。它不能交付。证据推翻了某个假设，就撤掉因它而做的改动。只交付证据撑得起的最小改动，多一点都不交付。

用对应的 control skill（见 Non-negotiables）在匹配的界面上亲自复现，即使某个调试或插桩流程说要请用户来复现。只有能写明具体理由，说明 control skill 够不到目标，并且已经用它推进到了尽头，才去问用户。直接复现不出来，就人为构造触发条件、收紧条件，或者插桩，直到问题出现为止。
用二分法找原因。先列出候选假设，再逐个排除，直到只剩一个。对受影响的子系统跑 how，并用 why skill 查回归历史，从中得出最初的候选假设。每一轮，选能切掉最多剩余问题空间的那一刀，拿到运行时证据，排除掉。程序状态看不清时，加插桩或日志，在代码运行时读出来。不要猜。排查耗时很长或者久攻不下时，用 Cursor 的 /loop 命令推进。进入第 3 步的 architect/interrogate 扇出之前，先用运行时证据确认留下来的那个机制。
规划修复。修复跨越函数边界时，先跑 architect。实现交给一个子代理，用你配置的 bug-fix 模型（默认 grok-4.7-xhigh-fast），并给它明确的范围。
在同一个界面上验证。原来的复现现在要能通过。结果「无法判定」，或者在错的界面上验证，都不算通过。要把它标出来。单元测试只能说明分支的行为，说明不了 bug 不存在。
安排好提交的顺序，让 git 历史里失败的复现排在修复前面。bug 有便宜的本地测试路径时，失败测试先行的节奏见 tdd skill。测试会很贵、很依赖集成环境，或者不清楚该怎么测时，跳过它。这是 sequence-verifiable-units 原则 skill 最典型的用法：失败的测试在前，修复叠在上面。
运行 Opening a PR。

回复： 哪里坏了、根因、修复、怎么验证的。原样贴出复现的输出，先是失败，再是通过。