diagnoselisted

# 构建与失败诊断 `diagnose` 把失败转化为 **reproduce -> minimize -> hypothesize -> instrument -> fix -> regression-test**，而不是盲改循环。 ## 路由快照 - **Use when**: 失败存在且 root cause 不能由单一证据解释。 - **Do not use when**: 这是实现中的预期 RED、根因已知、或问题其实是需求/范围不清。 - **Route to**: 根因明确且修复直接转 `implement`；修复稳定转 `review` 或 `verify`；命令链路缺口转 `harness-builder`。 ## 目的 - 没有可复现失败，不提修复结论。 - 没有 root cause 证据，不算诊断完成。 - 不在 build/test/lint 已红的状态下推进 implementation。 - 修复必须最小、单一、可验证。 - 三轮 hypothesis 仍找不到根因，升级为 blocker。 ## 何时使用 ### 触发信号 - `implement` 中一个明确假设循环仍无法解释失败，或同一命令两次返回不同错误。 - `npm test` / build / lint / typecheck 等命令红，且错误不能直接对应刚改的几行。 - 本地和 CI 结果不一致。 - 构建突然慢、卡住、内存爆。 - 用户说「为什么报这个错」「再试一下还是不行」「flaky 了」「CI 红了」。 ### 不要使用 - 这是 RED->GREEN 流程里刚写的测试在红：回 `implement`。 - 这是已知 Spec 变化导致旧测试失效：先回 `plan`。 - 失败根因已经清楚，只差最小修改：回 `implement`。 - 用户在问方案而不是失败原因：转 `brainstorm`。 ### 路由规则 | 状态 | 下一步 | | --- | --- | | 根因已找到、修复直接 | `implement` | | 根因影响多文件或范围 | `plan` | | 根因揭示需求边界错 | `brainstorm` | | 修复稳定 | `review` 或 `verify` | | 根因是已提交里程碑的回归 | 记录到 recovery surface + `implement` 修复 + 重新 verify | | 三轮诊断未果 | 记录 blocker 并向用户升级 | | 命令链路本身坏 | `harness-builder` | ## 先读取这些输入 1. 失败命令的真实输出：完整 stderr、stack trace、退出码。 2. selected recovery surface：最近成功状态、风险、dead ends、capability gaps。 3. `git status --short` 和相关 diff：确认变化面。 4. 与失败直接相关的源文件、测试、配置。 5. README / `AGENTS.md`：确认命令入口是否真实。 ## 执行流程 ### 第 1 步 — 捕获事实 记录命令、cwd、退出码、失败输出、时间戳、git HEAD 和最近相关命令序列。 ### 第 2 步 — 稳定复现 跑同样命令两次，确认结果一致。若 flaky，先把 flaky 当根因方向诊断。 ### 第 3 步 — 定位变化面 查看最近提交、本地 diff、相关配置和已知能跑通