用途：面向难缠的 Bug 和性能回归，强调先构建反馈循环，再假设、插桩、修复。仅在有明确理由时才跳过阶段。探索代码库时读取 CONTEXT.md（若存在），并查看相关区域的 ADR。展示命令、输出和捕获物前必须先脱敏，用 <REDACTED> 替换秘密；循环基于环境变量，凭证留在环境里。若脱敏后信息不足以定位，应说明并向用户求助。
阶段一：构建反馈循环。这是核心，其余都是机械操作。想尽办法做出针对该 Bug 的通过/失败信号，途径可包括失败测试、对开发服务器的 curl/HTTP 脚本、带 fixture 的 CLI 调用、Playwright/Puppeteer 无头浏览器、回放捕获的 trace、一次性最小 harness、属性/模糊测试、二分 harness、新旧版本差分循环，最后才用 HITL 脚本（scripts/hitl-loop.template.sh）。随后收紧循环：更快、信号更锐利、更确定。非确定性 Bug 的目标不是干净复现，而是提高复现率。若确实无法构建循环，应停下并明确说明，列出尝试，向用户索取环境访问、脱敏捕获物或临时生产插桩许可。完成标准：一条已运行过且能变红的紧凑循环，确定性、快速、可无人值守运行。
阶段二：复现与最小化。确认失败模式与用户描述一致且可重复，捕获确切症状，再逐步削减输入、调用方、配置和步骤，只保留承重部分。
阶段三：假设。先列出 3–5 个排序假设，每个可证伪并写明预测，展示给用户后再测试。
阶段四：插桩。每个探针对应一个具体预测，一次只改一个变量；优先调试器/REPL，日志加唯一前缀如 [DEBUG-a4f2]，性能问题先建基线再二分。
阶段五：修复与回归测试。先写回归测试（仅当存在正确接缝），看它失败、修复、看它通过，再用阶段一循环验证原始场景；若无正确接缝，这本身就是发现。
阶段六：清理。确认原始问题不再复现、回归测试通过或记录接缝缺失、移除所有 [DEBUG-...] 插桩、删除一次性原型，并在提交信息中写明最终正确的假设。