diagnoselisted

# Evidence-based diagnosis 将用户描述的故障与真实环境对应，区分现象、假设、已证实原因和修复证据。不要用隐藏错误、跳过测试或扩大容错来冒充修复。 ## 流程 1. 捕获相关命令、cwd、环境、退出码、日志、输入和最近改动；避免输出凭据。 2. 能安全且合理成本复现时复现；只有需要判断稳定性时重复。昂贵 GPU、线上或破坏性任务不为满足固定次数重复运行。 3. 难以复现时可先用既有日志、回放、源码和配置提出假设，并标明不确定性。无复现不禁止调查，但不能据此声称修复已验证。 4. 对有证据支持的候选排序，用最小检查区分原因。单个因果实验保持变量可归因，独立只读检查可以并行；不强制固定假设数量。 5. 证据充分后做授权范围内的最小修复，验证原始症状及受影响路径。不要把相邻无关失败混成同一个根因。 6. 持续有信息增益且在预算内时继续。无新证据、需要外部访问或成本超出授权时说明具体缺口；不以固定三轮自动宣布阻塞。 ## 完成与输出 给出故障、支持/排除的关键假设、根因或未定项、修改及验证。只读诊断可交付有边界的结论，无需强制修代码。调查中途即把关键 dead ends、排除的假设和恢复命令写入本轨道 state 的 Evidence 行（不写其他轨道文件；无本轨道行时不暗示新建，随本次报告交付），不等收尾；长调查后重读任务入口防漂移。值得复用的根因按 lessons 格式提升到项目恢复面的 lessons；项目为 harness backend 而 lessons 文件不存在时，随首次落笔创建。 工作台级问题可参考 `references/harness-layer-patterns.md`；不要因一条命令失败就安装新工具或重建 harness。 ## Recommended next skill - 原因已明但需修改：`implement`；修复复杂或用户要求评审：`review`。 - 简单修复已验证或只读诊断已交付：结束。 - 仅在实际缺口需改工作台时：`harness-builder`；目标改变才回 `plan`。