用途：在动手修 bug 前，按方法论先定位根因。开始前需明确两件事：症状（具体错误信息、观测行为或返回值）与预期行为；缺少任一项应先向用户确认。
主要能力：分四阶段推进，每阶段结束后停下等待用户确认。
阶段一：定位与复现。从症状出发浏览代码（必要时用 Explore 子代理），列出 2-3 个最可能包含根因的区域，每个附一句理由；再用三行描述可稳定复现该 bug 的最小场景；若无法可靠复现，需说明并提出复现计划。
阶段二：给出 3 个按可能性排序的根因假设（针对根因而非症状）。每条含一句话假设与可证伪预测：若假设成立会观察到什么具体现象，若观察到相反结果则排除。
阶段三：验证假设一。添加定向日志，每条日志以随机 4 字符标签 [DEBUG-a4f2] 作前缀，便于日后批量删除；此阶段不提出修复，只说明应观察什么来确认或否定。设有“三振规则”：若 3 个假设均被否定则停止，视为架构问题而非代码 bug，需换角度。
阶段四：最小修复。假设确认后，只给出处理根因的最短改动，不做附带优化或顺手重构；提交信息应说明根因而非症状。
适用场景：调试代码库中的具体缺陷，需要可复现、可验证、避免猜测式修补的排查流程。
限制：资料未提供具体运行命令、依赖或平台要求；类别归属依据其调试用途判断。