诊断（Diagnose）是一套针对疑难缺陷和性能回归的纪律化排查流程，适合智能体按阶段执行，帮助开发者在复杂系统中定位根因。其核心主张是：先为缺陷构建一个快速、确定、可自动运行的通过/失败信号，后续的二分、假设检验和插桩都依赖这个信号。
流程分为六个阶段。阶段一建立反馈回路，可选方式包括失败的单元/集成/端到端测试、针对开发服务器的 curl 或 HTTP 脚本、带固定输入的 CLI 调用并与已知良好快照对比、Playwright/Puppeteer 无头浏览器脚本、回放已捕获的请求或事件日志、最小化一次性测试支架、属性/模糊循环、可运行 git bisect 的二分支架、新旧版本或两套配置的差分对比，以及最后手段的人工参与脚本（scripts/hitl-loop.template.sh）。获得回路后还需优化其速度、信号锐度和确定性。对于非确定性缺陷，目标是提高复现率而非追求干净的复现。
阶段二运行回路并确认复现的是用户所述症状，且可多次复现或达到可调试的复现率。阶段三生成 3 到 5 个可证伪的排序假设，每个假设须给出预测，并可在测试前先展示给用户。阶段四按假设进行插桩，一次只改一个变量，优先使用调试器或 REPL，日志须带唯一前缀（如 [DEBUG-a4f2]）便于清理；性能回归应先建立基线测量再二分排查。阶段五在修复前编写回归测试，前提是存在正确的测试接缝；若接缝过浅或不存在，应记录并说明架构限制。阶段六要求确认原始复现不再出现、回归测试通过、所有调试日志清理、临时原型删除，并在提交或 PR 中写明最终正确的假设。
限制方面，文中明确：若确实无法建立回路，应停止并说明尝试过的方法，向用户请求可复现环境、捕获的工件（HAR、日志转储、核心转储、带时间戳录屏）或增加临时生产插桩的许可；在拥有可信回路之前不应进入假设阶段，在成功复现之前不应继续推进。