## Error Fix

從錯誤訊息中識別根本原因，預測解決時間並提出經過驗證的解決方案。學習類似錯誤的模式，立即提供適當的處理方法。

### 使用方法

```bash
/fix-error [選項]
```

### 選項

- 無 : 標準錯誤分析
- `--deep` : 深度分析模式 (包括依賴關係・環境因素)
- `--preventive` : 重視預防措施的分析
- `--quick` : 僅提供立即可用的修復方案

### 基本示例

```bash
# 標準錯誤分析
npm run build 2>&1
/fix-error
"分析建置錯誤並提出修復方法"

# 深度分析模式
python app.py 2>&1
/fix-error --deep
"包括環境因素在內分析錯誤的根本原因"

# 即時修復重視
cargo test 2>&1
/fix-error --quick
"提供可立即應用的修復方法"

# 預防措施重視
./app 2>&1 | tail -50
/fix-error --preventive
"提出錯誤修復和未來的預防措施"
```

### 與 Claude 的協作

```bash
# 錯誤日誌分析
cat error.log
/fix-error
"識別錯誤的根本原因，提出修復方法"

# 測試失敗的解決
npm test 2>&1
/fix-error --quick
"分析失敗的測試，提出可立即應用的修復方案"

# 堆疊追蹤的解析
python script.py 2>&1
/fix-error --deep
"從這個堆疊追蹤中定位問題，包括環境因素一起分析"

# 批次解決多個錯誤
grep -E "ERROR|WARN" app.log | tail -20
/fix-error
"按優先順序分類這些錯誤和警告，分別提出解決方法"
```

### 錯誤解決時間預測

```text
🚀 即時修復 (5 分鐘以內)
├─ 拼字錯誤、import 遺漏
├─ 環境變數未設定
├─ 未定義變數的參照
└─ 預測時間: 2-5 分鐘

⚡ 快速修復 (30 分鐘以內)
├─ 依賴關係不一致
├─ 設定檔錯誤
├─ 型別不匹配
└─ 預測時間: 10-30 分鐘

🔧 需要調查 (2 小時以內)
├─ 複雜的邏輯錯誤
├─ 非同步處理競爭
├─ API 整合問題
└─ 預測時間: 30 分鐘-2 小時

🔬 深度分析 (半天以上)
├─ 架構起因
├─ 多系統連接
├─ 效能劣化
└─ 預測時間: 4 小時-數天
```

### 類似錯誤模式資料庫

```text
頻發錯誤與即時解決方案
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 "Cannot read property 'X' of undefined/null" (頻度: 極高)
├─ 主要原因: 物件的 null 檢查不足
├─ 解決時間: 5-10 分鐘
└─ 處理方法: 添加 Optional chaining (?.) 或 null 檢查

📊 "ECONNREFUSED" / "ENOTFOUND" (頻度: 高)
├─ 主要原因: 服務未啟動或 URL 設定錯誤
├─ 解決時間: 5-15 分鐘
└─ 處理方法: 確認服務啟動，檢查環境變數

📊 "Module not found" / "Cannot resolve" (頻度: 高)
├─ 主要原因: 套件未安裝，路徑指定錯誤
├─ 解決時間: 2-5 分鐘
└─ 處理方法: 執行 npm install，確認相對路徑

📊 "Unexpected token" / "SyntaxError" (頻度: 中)
├─ 主要原因: 括號・引號不一致，使用保留字
├─ 解決時間: 2-10 分鐘
└─ 處理方法: 確認語法高亮，執行 Linter

📊 "CORS policy" / "Access-Control-Allow-Origin" (頻度: 中)
├─ 主要原因: 伺服器端 CORS 設定不足
├─ 解決時間: 15-30 分鐘
└─ 處理方法: 伺服器 CORS 設定，代理設定

📊 "Maximum call stack size exceeded" (頻度: 低)
├─ 主要原因: 無限迴圈・遞迴，循環參照
├─ 解決時間: 30 分鐘-2 小時
└─ 處理方法: 確認遞迴結束條件，解除循環參照
```

### 錯誤分析的優先順序矩陣

| 優先順序          | 圖示        | 影響範圍 | 解決難度 | 回應期限      | 說明                         |
| ----------------- | ----------- | -------- | -------- | ------------- | ---------------------------- |
| **Critical**      | 🔴 緊急回應 | 廣       | 低       | 15 分鐘內著手 | 系統全面停止，資料遺失風險   |
| **High Priority** | 🟠 早期回應 | 廣       | 高       | 1 小時內著手  | 主要功能停止，多數使用者影響 |
| **Medium**        | 🟡 計畫回應 | 窄       | 高       | 當日回應      | 部分功能限制，有迴避方案     |
| **Low**           | 🟢 過程觀察 | 窄       | 低       | 下次修改時    | 輕微不良，對 UX 影響小       |

### 分析流程

#### 階段 1: 錯誤資訊收集

```bash
🔴 必須執行:
- 完整取得錯誤訊息
- 確認堆疊追蹤
- 確定發生條件 (可重現性)

🟡 早期執行:
- 收集環境資訊 (OS，版本，依賴關係)
- 直接變更歷程 (git log，最近提交)
- 確認相關日誌

🟢 額外執行:
- 系統資源狀況
- 網路狀態
- 外部服務狀態
```

#### 階段 2: 根本原因分析

1. **整理表面症狀**
   - 錯誤訊息的正確內容
   - 發生時間和模式
   - 確定影響範圍

2. **確定深層原因**
   - 應用 5 Whys 分析
   - 追蹤依賴關係
   - 確認環境差異

3. **驗證假設**
   - 建立最小重現程式碼
   - 執行隔離測試
   - 縮小原因範圍

#### 階段 3: 解決方案實作

```bash
🔴 即時處理 (熱修復):
- 抑制症狀的最小修復
- 應用暫時迴避方案
- 準備緊急部署

🟡 根本解決:
- 針對原因的本質修復
- 新增測試案例
- 更新文件

🟢 預防措施實作:
- 強化錯誤處理
- 設定監控・警報
- 改善 CI/CD 管線
```

### 輸出範例

```text
🚨 錯誤分析報告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📍 錯誤概要
├─ 類型: [編譯/執行時/邏輯/環境]
├─ 緊急度: 🔴 高 / 🟡 中 / 🟢 低
├─ 影響範圍: [功能名/元件]
└─ 重現性: [100% / 間歇性 / 特定條件]

🔍 根本原因
├─ 直接原因: [具體原因]
├─ 背景因素: [環境/設定/依賴關係]
└─ 觸發器: [發生條件]

💡 解決方案
🔴 即時處理:
1. [具體修復指令/程式碼]
2. [暫時迴避方案]

🟡 根本解決:
1. [本質修復方法]
2. [必要的重構]

🟢 預防措施:
1. [錯誤處理改善]
2. [測試新增]
3. [監控設定]

📝 驗證程序
1. [修復套用後確認方法]
2. [測試執行指令]
3. [動作確認項目]
```

### 錯誤類型別分析技法

#### 編譯/建置錯誤

```bash
# TypeScript 型別錯誤
必須確認 (高):
- tsconfig.json 設定
- 型別定義檔 (.d.ts) 的存在
- import 陳述句的正確性

# Rust 生命週期錯誤
必須確認 (高):
- 所有權移動
- 參照的有效期間
- 可變性衝突
```

#### 執行時錯誤

```bash
# Null/Undefined 參照
必須確認 (高):
- 可選鏈結不足
- 初始化時機
- 非同步處理的完成等待

# 記憶體相關錯誤
必須確認 (高):
- 取得堆積傾印
- 分析 GC 日誌
- 偵測循環參照
```

#### 依賴關係錯誤

```bash
# 版本衝突
必須確認 (高):
- lock 檔案的一致性
- peer dependencies 要求
- 傳遞性依賴關係

# 模組解析錯誤
必須確認 (高):
- NODE_PATH 設定
- 路徑別名設定
- 符號連結
```

### 注意事項

- **絕對禁止**: 僅憑錯誤訊息的一部分判斷，未驗證就套用 Stack Overflow 解決方案
- **例外條件**: 暫時迴避方案僅在以下 3 個條件下允許
  1. 生產環境緊急回應 (24 小時內根本解決必須)
  2. 外部服務故障 (復原等待中的替代手段)
  3. 已知框架錯誤 (等待修正版本發布)
- **建議事項**: 以根本原因確定為最優先，避免表面修復

### 最佳實務

1. **完整資訊收集**: 從頭到尾確認錯誤訊息
2. **確認重現性**: 最優先建立最小重現程式碼
3. **階段性方法**: 從小修復開始驗證
4. **文件化**: 記錄解決過程進行知識分享

#### 常犯錯誤

- **處理症狀**: 遺漏根本原因的表面修復
- **過度一般化**: 廣泛套用特定案例的解決方案
- **省略驗證**: 不確認修復後的副作用
- **知識個人化**: 不將解決方法文件化

### 相關指令

- `/design-patterns` : 分析程式碼結構問題並提出模式建議
- `/tech-debt` : 從技術債務觀點分析錯誤的根本原因
- `/analyzer` : 需要更深入根本原因分析的情況