用途：为难以定位的缺陷和性能回归提供一套分阶段的诊断纪律，非必要不得跳过阶段。开始前如存在 GLOSSARY.md 应阅读以建立模块心智模型，并查看相关区域的 ADR。
展示命令、输出和抓取物前必须先脱敏，用 <REDACTED> 替换密钥；回路应基于环境变量，凭证留在环境中而非展示内容里；抓取物含认证头时只引用有信号的行。若脱敏后信息不足以诊断，应说明并询问用户。
阶段1：建立反馈回路。这是核心，其余是机械操作。需要一条针对该缺陷的紧致通过/失败信号。构建方式大致按序：能触达缺陷的失败测试（单元/集成/端到端）、对运行中开发服务器的 curl/HTTP 脚本、带固定输入的 CLI 调用并与已知良好快照对比、驱动 UI 并对 DOM/控制台/网络断言的 Playwright/Puppeteer 无头浏览器脚本、回放捕获的轨迹、一次性最小化实验台、属性/模糊循环、二分定位装置、新旧版本或两种配置的差分循环、最后手段的人工 bash 脚本 scripts/hitl-loop.template.sh。
收紧回路：更快（缓存初始化、缩小测试范围）、信号更尖锐（断言具体症状而非未崩溃）、更确定（固定时间、随机种子、隔离文件系统、冻结网络）。非确定性缺陷追求更高复现率而非干净复现，可循环触发100次、并行、加压、缩窄时间窗、注入睡眠，直到可调试。确实无法建回路时应停止并明确说明，列出尝试，向用户索取可复现环境访问、脱敏抓取物（HAR、日志转储、核心转储、带时间戳录屏）或加临时生产插桩的许可；无回路不要进入假设。
阶段1完成标准：一条已至少运行过一次、能走红、确定性、快速（秒级）、可无人值守运行的命令。若在命令存在前就开始读代码建理论，应停止。
阶段2：复现与最小化。运行回路看其走红，确认失败模式与用户描述一致、可多次复现，并捕获确切症状。随后逐步删减输入、调用方、配置、数据与步骤，每次删减后重跑，保留承担失败的部分；直到删掉任一元素回路就转绿。
阶段3：提出3–5个排序假设，每个可证伪并写出预测（“若X是原因，则Y会使缺陷消失/加剧”），测试前先展示给用户，用户可能凭领域知识重新排序。
阶段4：插桩。每个探针映射到具体预测，一次只改一个变量。优先调试器/REPL，其次在能区分假设的边界打定向日志，禁止“全量打日志再 grep”。每条调试日志加唯一前缀如 [DEBUG-a4f2] 便于清理。性能回归通常不用日志，应先建立基线测量（计时装置、performance.now()、分析器、查询计划）再二分。
阶段5：修复与回归测试。仅在存在正确接缝时先写回归测试：该接缝需在调用现场复现真实缺陷模式；若只有过浅接缝，写出的测试会造成虚假信心，应将“无正确接缝”本身作为发现记录并留待下一阶段。有正确接缝则把最小复现变为失败测试、看其失败、修复、看其通过，再跑阶段1原场景。
阶段6：收尾。原复现不再出现、回归测试通过（或记录接缝缺失）、所有 [DEBUG-...] 插桩已清除、一次性原型已删除或移至明确标记的调试位置，并在提交/PR 信息中写明最终正确的假设，供后来者参考。