一句话

针对难缠 bug 和性能回退的六阶段纪律：先造一条能对「这个 bug」变红的紧密反馈环，再最小化、排假设、插桩、修复加回归测试、清理。

何时用

• 适合：一眼看不出的 bug、间歇 flake、两个已知好版本之间引入的回归、有前后对照的性能回退。
• 不适合：一句话能答的快问（它又慢又彻底是故意设计的）；别人刚报来的原始 bug 先过 matt-triage；问「瓶颈在哪」不算，它只诊断一个明确失败。

怎么用

这个接口偶发 500，帮我诊断到底哪错了

1. 先脱敏：命令、输出、抓包件里的 secret 一律写 <REDACTED> 再给。
2. Phase 1 造反馈环：按序优先失败测试、curl/HTTP 脚本、CLI diff、headless 浏览器、trace 回放、throwaway harness、property/fuzz、bisect，最后一招才是 HITL 脚本带人点。验收：能对症状变红、确定、秒级、agent 可跑。
3. Phase 2 跑红并最小化：每次砍一项输入/调用方/配置，砍完重跑。
4. Phase 3 先列 3-5 个可证伪的假设再测，排序给用户看；Phase 4 插桩一次只改一个变量。
5. Phase 5 只在 seam 正确时先写回归测试再修；Phase 6 清理 DEBUG 插桩和临时件，正确假设写进 commit。

产出

• 修复 + 回归测试 + commit/PR 里的假设记录。

要点与坑

• 没有 red-capable 的命令就没有 Phase 2，这道门就是技能本体；读代码猜理论正是它要拦的。
• 非确定性 bug 的目标是把复现率抬到可调试（循环 100 次、加压、缩时间窗）。
• 性能回退走另一条分支：先测基线再 bisect，不打日志。

本机版本差异

本机旧版读 CONTEXT.md，仓库版读 GLOSSARY.md；仓库版新增：人为制造红后要 diff 纯净副本证明 mutation 落地才信。

关联

• 下游：matt-retro、matt-improve-codebase-architecture · 同类：addy-debugging-and-error-recovery
• 所属：00-matt-概览 · 工作流：W1-快修