diagnose-issue

诊断问题

在更改行为之前，先找到原因并提供证据。除非用户明确要求修复或实现，否则诊断过程仅进行只读操作。

当外部文档或工具行为与问题相关时，使用 research-ladder.md。如果仓库中有 Glossary 和 ADR，也请参考。

流程

1. 建立最快且有用的反馈闭环：针对性测试、构建、CLI 调用、请求、浏览器检查、跟踪重放、基准测试，或小型临时测试程序。
2. 尽可能复现所报告的症状并捕获确切故障。对于不稳定的行为，记录基线复现率，并将其提高到足以比较更改的程度。如果无法复现，请区分结论与假设，并仅请求缺少且重要的证据。
3. 根据实际情况，完整阅读错误、日志、堆栈跟踪、近期差异、依赖项或配置更改、环境差异、调用方以及附近可正常工作的示例。
4. 只有在仍存在不确定性时，才保留按可能性排序且可证伪的假设。直接证据解释原因后，应转而验证，而不是凭空制造其他可能性。
5. 对区分合理原因的边界进行插桩。逐一移除输入、步骤、配置或调用方，精简可复现的症状，直到只剩下关键要素。追踪异常值的来源，测量性能，并根据真实异步条件等待，而不是任意休眠。
6. 说明证据最充分的原因，以及能够支持或排除重要替代解释的证据。

授权修复时

• 如果存在有用的切入点，修复前应优先添加会失败的回归测试。
• 应用能够解决原因的最小更改。
• 如果公共契约、迁移、持久化、身份验证或安全行为、生产状态或性能权衡需要由负责人判断，应停止修改并提供选项。
• 如果多次更改仍未解决问题，不要继续叠加补丁。应根据新证据重新评估思维模型、反馈闭环和架构。
• 重新运行原有反馈闭环和相关回归检查；阅读结果后再声称成功。
• 交付前，通过 review-work 将完整工作范围（而非仅最新补丁）交给一位具有独立全新上下文的审查者；根据一手证据核实已接受的结论，修复已授权的阻塞问题，并重新运行受影响的检查。
• 仅移除本任务创建的临时插桩和临时产物。保留已有草稿、测试夹具和无关工作。

如果正确的修复缺少安全的测试切入点或架构切入点，请说明这一限制，并将未解决的设计问题交由 improve-architecture 或 plan-work 处理。对于已明确且不改变行为的清理工作，应交由 simplify-work，而不是将其混入错误修复。

输出

报告应简洁：

• 原因和证据
• 修复（仅在获得授权时）
• 已执行的验证
• 局限性、剩余风险或建议的后续操作

不要把诊断写成实验记录，也不要声称证据无法支持的确定性。