debug-firstlisted

# debug-first > 触发：`/debug-first` 或诊断信号词 > 输出：按 4 步节拍走，每步给"硬约束 + 跳出条件" > 不修改业务代码——只**约束诊断流程**，结论给用户拍板后再动手 ## 为什么有这个 skill 排查 bug 时模型会习惯性"读两眼代码直接猜原因 → 给方案 → 让用户监工验证"。三个常见失败模式： 1. **静态推理 vs 真复现**：代码逻辑能列可能性，但只有真数据告诉你**实际**走的是哪条路径。曾经第一轮我推 "前端 inflight race 是真因"，跑端到端真后端后发现根本是后端 SFTP channel 死掉了 — 推理全错。 2. **环境假设**：以为"复现需要 X 我没有"就停手让用户跑，常被反问"之前不是配过吗"。十次有八次现成 docker / fixture / e2e 脚本就在 `scripts/` 里。 3. **诊断浮于表面**：单次复现就下结论 / 不标置信度 / 把不相关 bug 顺手修扩大 scope，让 reviewer 反复抓 critical race。 ## 4 步主流程（按顺序执行） | Step | 关键动作 | 跳出条件 | |---|---|---| | 1 | 复现 + 调高 log + 多时间点 trial | 无外部状态依赖（无 IPC / 文件 I/O / 并发 / 网络 / SSH）的本地纯函数 bug | | 2 | 跨端数据不一致先 `ps`/`lsof` 排进程残留 | 单进程 / 单 runtime 的 bug | | 3 | 假设环境缺失前先 `grep` 基础设施 | 已确认环境齐 | | 4 | 诊断报告标置信度 + 方案分级 | 单 bug 100% 确认 + 一行 fix | ### Step 1: 复现 + 调 log + 多时间点 trial 涉及"多端交互 / 状态机 / 时间窗口 / 并发 / 网络 / SSH"的 bug，**SHALL 真复现 + 看真数据**再猜原因。三件事一起做： **真复现**： - 优先用 `e2e-http-verify` skill（已配 `cdt-cli` HTTP server + 浏览器 `?http=1` 端到端真后端） - SSH 类走 `just verify-ssh-docker` / docker `cdt-ssh-test` 容器 - 浏览器交互类用 chrome-devtools mcp + `evaluate_script` 看真 store 状态 **调高 log level 比读代码快 10×**：怀疑哪个 module 就 `RUST_LOG="<module>=debug"`： ```bash RUST_LOG="cdt_api=info,cdt_ssh=debug,cdt_watch=info" cargo run -q -p cdt-cli --bin cdt > /tmp/cdt-debug.log 2>&1 & ``` 加一次 debug log 后 log 直接打出真因（如 "session closed / projects root does not exist"）—— 比追代码追半天快。前端调试同理（`?debug=1` query / `localStorage.debug = '*'`）。 **多时间点 trial**：状态/时间相关 bug **不要**信单次复现。三种 trial 时机： - 立即