onedragon-anything Deciding a Fix
核心原则
修复的难点不是"找到 bug"，而是"在因果链的哪一环介入"。根因是一条链，不是点；选在哪一环介入 = 选方案。 本 skill 把"决定怎么修"拆成 5 步，每步锚定一个业界方法论，产出一份可被 review 的修复决策。
When to use / 不适用
- 用：bug 已定位失败机制，要在多个修法里选
- 不用：还没定位失败机制 →
systematic-debugging；新功能设计 →brainstorming
流程
0. 确认故障机制（入口） — 能复述"失败怎么发生"？不能 → systematic-debugging 先定位。
1. 画因果链 (RCA / 5 Whys / Fault Tree) — 症状→直接原因→机制→包级→系统级→上游代码→流程→修复状态。每节点 = 候选介入点。挖到 actionable 层（你有权且能修的那层），不更深。
2. 影响面 + 可行动性 (Impact Analysis / Blast Radius) — 在链上标"我能修"的节点。影响面决定方案形态：全量用户 / 主依赖链 → 必须零用户操作；个别环境 → 文档可接受。
3. 候选方案 — 在 actionable 节点生成：补系统依赖 / 锁版本或换实现 / 改代码移除问题调用 / 文档绕过 / 提上游 PR。
4. 前提验证 + 权衡 (Trade-off Matrix / Pugh) — 每个候选必填：
- 前提验证：前提是事实还是假设？最小成本证伪（下 artifact 看、跑解析、grep 全库）。
- 权衡：[代价 / 风险 / 可逆性 / 临时-永久] 横评。
- 必填：根因链的"上游修复状态"（已修？待发版？有意设计？）→ 决定方案是"有终点的临时止损"还是"永久拖延"。
5. 假设驱动验证 (Hypothesis-driven Verify) — 精确化"失败的可观察判据"，确认介入后该判据不再成立。不是"能跑就行"——开发机有系统资源时成功可能是假绿，把判据收紧到具体路径 / 行为。
Quick Reference
| 步 | 方法论 | 核心提问 |
|---|---|---|
| 0 | — | 能复述失败机制吗？ |
| 1 | RCA / 5 Whys | 链上有哪些介入点？哪个 actionable？ |
| 2 | Impact Analysis | 影响谁？谁有权修？ |
| 3 | Intervention Selection | 每个 actionable 节点对应什么方案？ |
| 4 | Trade-off Matrix | 前提验证了吗？上游修了吗？ |
| 5 | Hypothesis-driven Verify | 失败的判据是什么？还成立吗？ |
Common Mistakes
- 直接采纳 issue 里用户的方案，不验证前提
- 根因停在"缺某文件"，不查"上游是否已修" → 误判方案临时 / 永久
- 验证停在"能跑"，不收紧到失败机制
- 介入点前提（如"只有这一处用"）不验证就下结论