复杂故障排查
目标不是快速制造看似有效的补丁，而是形成可重复证据、定位根因并验证修复。
与已有调试框架配合
如果其他插件、Skill 或项目规则已经指定通用调试流程，以该流程作为根因调查主流程。本 Skill 只补充间歇性、并发、性能、资源泄漏、失败恢复和反复复发场景的专项检查。
复用已有故障描述、复现步骤、假设记录、测试和日志证据，不重新创建第二套调查流程。两个流程要求真正冲突时，遵循用户当前指令和项目规则；仍无法解决时先报告差异，不默默选择。
1. 定义故障
开始复杂故障调查时，读取 assets/incident-investigation.md，根据当前项目情况创建调查记录，并在排查过程中持续更新。
记录：
- 预期行为；
- 实际行为；
- 首次出现时间和变化；
- 稳定复现还是间歇出现；
- 影响范围；
- 当前已有证据；
- 已尝试方案及结果。
区分事实、推断和未知。
2. 建立最小复现
优先获得：
- 最小输入；
- 最小环境；
- 稳定命令；
- 失败日志、错误码或指标；
- 修改前必然失败的测试。
不能稳定复现时，先增加必要的可观测性，不盲目修改核心逻辑。
3. 缩小范围
按证据逐层排除：
- 输入与配置；
- 调用链与数据流；
- 边界条件；
- 外部依赖；
- 并发与事务；
- 超时、重试和部分失败；
- 缓存和状态；
- 资源释放；
- 环境和版本差异。
每次只验证一个主要假设，并记录结果。
4. 选择验证工具
按问题使用：
- 单元或集成测试；
- 日志和结构化事件；
- Trace；
- 指标和性能剖析；
- 数据库执行计划、锁和事务视图；
- 网络抓包或请求录制；
- 线程、进程、内存和文件句柄分析；
- 二分定位；
- 故障注入；
- 并发或压力测试。
没有基准时不声称性能提升。
5. 修复原则
- 修复根因，不只屏蔽症状；
- 保持改动最小；
- 不删除测试或放宽断言；
- 证据不足时不进行大规模重构；
- 多次修补仍反复出现时，重新检查领域模型、数据流和设计边界。
6. 验证修复
确认：
- 原始复现不再失败；
- 修改前失败、修改后通过；
- 相邻正常场景未受影响；
- 必要回归测试已增加；
- 并发、重复、失败恢复或资源释放得到与风险匹配的验证；
- 未验证内容和剩余风险明确记录。
7. 沉淀
记录根因、关键证据、修复、回归测试和长期改进。临时调试流水不全部写入长期项目文档。
长期项目中，将依据 assets/incident-investigation.md 完成的调查记录保存到项目 docs/ 下，并在 project-status.md 中引用，不在状态文件中复制完整调查内容。