用途：面向疑难 Bug 和性能回归的诊断流程，适用于用户要求“diagnose”“debug this”，或报告功能损坏、抛错、失败、变慢的场景。
主要能力：把诊断拆成六个阶段。阶段1建立反馈循环，这是核心，其余步骤相对机械；可用失败测试、curl/HTTP 脚本、CLI 夹具对比、无头浏览器脚本、回放抓取轨迹、临时最小 harness、属性/模糊测试、二分 harness、差分循环或人工脚本等方式构造。循环要能对该 Bug 变红、确定、快速、可无人值守运行。阶段2复现并最小化，确认失败模式与用户描述一致，并逐步裁剪到最小可复现场景。阶段3提出3至5个可证伪的排序假设，并先展示给用户。阶段4按假设做定向插桩，一次只改一个变量，调试日志加唯一前缀如 [DEBUG-a4f2]；性能问题先建立基线再二分。阶段5先写回归测试再修复，需存在正确接缝，否则记录该发现。阶段6清理，确认原复现不再出现、回归测试通过、移除所有调试插桩、删除临时原型，并在提交信息中写明最终正确的假设。
使用方式：探索代码库时读取 GLOSSARY.md（若存在），并查看相关区域的 ADR。展示命令、输出和抓取物前必须脱敏，用 <REDACTED> 替换密钥，凭据通过环境变量传入，抓取物只引用含信号的片段。若脱敏后不足以诊断，应说明并询问用户。
限制：没有可复现的反馈循环时不应进入假设阶段；无法建立循环时应明确说明并请求环境访问、脱敏抓取物或临时生产插桩许可。非确定性 Bug 的目标是提高复现率而非干净复现。若不存在正确测试接缝，应记录为架构问题。资料未提供具体安装命令、收费或平台信息。