用途：在调试错误、修复 bug、排查失败测试、处理异常行为，或代码行为与预期不符时使用。
主要能力与规范：
- 编码前禁止未经根因分析直接修复，必须先建立可运行、可重复、可判断的反馈循环。
- 用 Git 作为记忆：调试前先读取相关历史，如 git log --oneline -20 查看最近变更，git log --all --grep="revert" 查看过去的失败回滚；若发现类似修复已被回滚，不要重复同样方向。
- 反馈循环优先：优先写失败测试；不适合时可用 HTTP 脚本、CLI 样例输入、浏览器脚本、请求/事件回放、最小验证脚本、差异对比或压力循环复现。循环要快、稳定、断言具体症状，不用“没有崩溃”代替正确性。非确定性问题先提高复现率，记录触发次数、失败比例和关键条件。无法建立循环时应停止并说明已尝试方式，向用户请求日志、录屏、请求记录、环境访问或授权加临时观测点。
- 四阶段调试法：定位（完整读取错误信息、稳定复现、反向追踪数据流）；分析（对比正常代码、检查最近变更、识别隐含假设）；假设（形成 3-5 个按可能性排序且可证伪的假设，单变量测试并记录）；修复（先写失败测试复现 bug，实现针对根因的最小修复，验证有效且无回归）。
- 临时观测点须带唯一前缀如 [DEBUG-a4f2]，每个观测点对应一个假设，禁止到处打印再搜索；收尾前搜索前缀并清理临时日志、验证脚本和实验文件。
- 卡住升级机制：第 1-2 次失败正常反思；第 3 次停止并重新从根因分析；第 4 次扩大范围重读相关文件、审查 git 历史、检查隐藏依赖或副作用；第 5 次必须与用户讨论，提出组合接近成功的尝试、尝试相反方向、重构架构或重新定义问题等选项；超过 5 次停止自主尝试，转为用户决策。
- 交付检查：根因已识别并记录；已建立能证明问题出现/消失的反馈循环；有失败测试复现 bug 或说明替代验证；单一修复针对根因；临时观测点和实验文件已清理；无回归引入。
限制：资料未提供具体安装命令、平台支持、收费方式或代码示例，相关事实暂未提供。