用途：为难以定位的缺陷和性能回归提供一套有纪律的诊断流程，适用于用户要求“诊断/调试”或报告某处损坏、抛错、失败、变慢的场景。资料称除有明确理由外不应跳过阶段。
主要能力与流程：探索代码库时先读 CONTEXT.md（若存在）并查看相关 ADR。阶段1构建反馈回路，这是核心，可用失败测试、curl/HTTP 脚本、CLI 夹具对比、无头浏览器（Playwright/Puppeteer）、回放捕获的 trace、一次性最小 harness、属性/模糊测试、二分 harness、差分对比，最后才用人工脚本 scripts/hitl-loop.template.sh。回路需可红、确定、快速、可无人运行；非确定性缺陷目标是提高复现率而非干净复现。若确实无法构建回路，应停下说明并索取环境、捕获产物或临时生产插桩许可。阶段2复现并最小化，确认失败模式与用户描述一致。阶段3提出3至5个可证伪的排序假设，并先给用户看。阶段4插桩，每个探针对应一个预测，一次只改一个变量，调试日志加唯一前缀如 [DEBUG-a4f2]；性能问题先建立基线再二分。阶段5先写回归测试再修复，但仅在存在正确接缝时；无正确接缝本身即为发现。阶段6清理与复盘，包括重跑原回路、移除插桩、删除原型、在提交信息中写明正确假设，并考虑是否移交 /improve-codebase-architecture。
限制：资料未提供安装命令、收费、平台支持或具体效果数据；流程要求严格，缺少可红回路时不应进入假设阶段。