用途：为诊断疑难 bug 与性能回退提供一套分阶段执行的纪律流程，强调先建立可复现的反馈循环再定位根因。
主要能力：流程包含六个阶段。阶段1建立能变红的紧凑反馈循环，可尝试失败测试、Curl/HTTP 脚本、CLI 调用、无头浏览器脚本（Playwright/Puppeteer）、回放捕获的 trace、一次性测试工具、属性/模糊循环、git bisect、差异循环，最后一手段为 scripts/hitl-loop.template.sh 驱动人工操作。阶段2复现并最小化。阶段3生成3到5个可证伪的排序假设。阶段4插桩，探针须对应具体预测，调试日志使用如 [DEBUG-a4f2] 的唯一前缀。阶段5修复并加回归测试。阶段6清理临时插桩与一次性制品。
使用方式：开始前加载项目上下文，使用已加载的 CONTEXT 术语与 RULE；知识不可用时继续并如实说明。没有能变红的命令不得进入阶段2。只要求诊断时，移除临时插桩后停止；用户明确要求修复、解决或实现改动时才进入阶段5；意图不明时在写入前询问。性能回退应建立基线测量后二分，先测量后修复。
适用场景：诊断或调试请求，功能损坏、报错、失败或变慢的报告；非确定性 bug 目标是提高复现率至可调试水平。
限制：无法建立反馈循环时应停下并说明，列出已尝试方法，请求环境访问、捕获制品或临时生产插桩，不得继续假设。阶段1完成要求命令能变红、确定、快速且可无人值守运行。回归测试需要正确接缝，接缝太浅只产生虚假信心，缺失接缝应作为架构发现记录。修复需符合已加载 RULE，偏离时交由用户决定。