用途：面向疑难 bug 与性能回退的六阶段诊断纪律，强调先建立可靠的复现反馈循环，再进入假设与修复；除明确说明理由外不跳过阶段。探索代码库时使用项目领域术语表，并遵守 docs/rules/ 下的项目规则（所有假设、插桩、修复不得与规则冲突）。
主要流程：阶段1 建立反馈循环，按顺序尝试失败测试、Curl/HTTP 脚本、CLI 调用、无头浏览器脚本（Playwright/Puppeteer）、回放捕获的 trace、一次性测试工具、属性/模糊循环、二分工具、差异循环，最后才用 HITL bash 脚本（scripts/hitl-loop.template.sh）；并持续优化循环速度、信号清晰度与确定性。对非确定性 bug，目标是提高复现率至可调试水平；确实无法建立循环时应停下说明并请求环境、制品或临时插桩许可。阶段2 复现，确认失败模式与用户描述一致且可复现。阶段3 生成 3-5 个可证伪的排序假设，并展示给用户参考。阶段4 插桩，每个探针映射到具体预测，一次只改一个变量，优先调试器/REPL，日志使用 [DEBUG-xxxx] 唯一前缀；性能问题先建立基线测量再二分。阶段5 修复与回归测试，前提是存在正确接缝，观察测试失败→应用修复→观察通过，并校验符合全部 RULES，必要时显式标出冲突交用户裁决。阶段6 清理与事后分析：确认原复现不再出现、回归测试通过、移除全部 [DEBUG-...] 插桩、删除一次性原型、在 commit/PR 中陈述最终正确的假设；随后思考预防方案，并在适当时提议把约束固化为 docs/rules/ 下的规则。
适用场景：难以定位的 bug、报错/失败排查、性能回退。限制：资料未提供具体支持的平台、安装方式、收费与价格信息，暂未提供。