用途：为难以定位的 bug 和性能回归提供一套有纪律的诊断循环，避免直接跳到猜测或让用户手动点击排查。
主要能力与流程：
- 建立反馈回路：优先构造失败测试、curl/HTTP 脚本、CLI 夹具对比、无头浏览器脚本、回放抓取轨迹、一次性最小 harness、属性/模糊测试、二分 harness、差分对比等；并持续优化回路的速度、信号锐度与确定性。对非确定性 bug，目标是提高复现率而非追求干净复现。
- 复现：运行回路，确认失败模式与用户描述一致，可多次复现并捕获确切症状。
- 假设：先给出 3–5 个可证伪的排序假设，每条须说明预测，展示给用户后再测试。
- 插桩：每个探针映射到具体预测，一次只改一个变量；优先调试器/REPL，日志须带唯一前缀如 [DEBUG-a4f2] 便于清理；性能问题先建立基线再二分。
- 修复与回归测试：在正确接缝处先写失败测试，再修复并验证；若无正确接缝，需记录该架构问题。
- 清理与复盘：确认原复现不再出现、回归测试通过、移除全部调试插桩、删除临时原型，并在提交信息中写明最终正确的假设。
必要用法与检查点：进入第 2 阶段前须向用户说明所选回路、信号及未选更快方案的原因并等待确认；进入第 5 阶段前须说明根因、被确认的假设、拟议修复及修复类型（根因修复或防御性修复）并等待确认。用户不在时可继续选项 1–9，但不得无人值守使用 HITL 选项 10。
限制：资料未提供安装命令、平台支持、收费方式或具体代码示例；无法建立回路时应明确说明并请求环境访问、抓取产物或临时生产插桩许可，不得在无回路情况下进入假设阶段。