用途：面向棘手 bug 和性能回归的诊断流程，强调先建立能对该 bug 变红的反馈循环，再进入假设与修复。触发场景包括用户说“诊断”“调试这个”，或报告崩溃、报错、不正常、缓慢。
主要能力与流程：探索代码库时读取 GLOSSARY.md（若存在）并查看相关 ADR；展示命令、输出和产物前先脱敏，用 <REDACTED> 替换秘密，凭证留在环境变量中，捕获产物只引用携带信号的若干行。Phase 1 构建反馈循环，方式包括失败测试、curl/HTTP 脚本、CLI 调用、无头浏览器脚本（Playwright/Puppeteer）、重放已捕获 trace、一次性 harness、属性/fuzz 循环、二分 harness、差分循环，最后手段是 scripts/hitl-loop.template.sh 驱动人工。随后收紧循环：更快、信号更尖锐、更确定。非确定性 bug 目标是提高复现率而非干净复现。完成判据是一条紧凑、能变红、确定性、秒级、Agent 可跑的循环。Phase 2 复现并最小化，确认失败模式与用户描述一致。Phase 3 生成 3–5 个可证伪的排序假设，测试前展示给用户。Phase 4 插桩，每次探测对应具体预测，一次只改一个变量，调试日志加唯一前缀如 [DEBUG-a4f2]；性能回归先建立基线测量再二分。Phase 5 在正确 seam 上先写回归测试再修复，若无正确 seam 则记录为发现。Phase 6 清理：重跑原始复现、回归测试通过、grep 移除 [DEBUG-...] 插桩、删除一次性原型、把成立的假设写进 commit/PR。
限制：只有显式说明正当理由时才能跳过某个阶段；没有能变红的命令就不进入 Phase 2；脱敏后输出不足以诊断时需明确说明并请用户提供更多材料；建不出循环时停下并列出尝试，请用户提供环境访问、脱敏捕获产物或临时插桩授权。资料未提供具体安装命令、收费与平台信息。