為什麼需要防退化校驗？

在大型強型別專案（如 C# 或 TS）的重構中，最讓人沮喪的是：「修好了當前的 Bug，卻無意間導致之前已經編譯成功的其他檔案再次報錯」。這種修復過程中的「前進一步、後退兩步」被稱為代碼退化 (Regression)。

嚴格防退化編譯校驗工作流 (Strict Regression Prevention Flow) 結合了 $plan 與本地編譯器，建立了一套「一次只修一個錯，每步皆進行全域防退化檢驗」的嚴格重構體制。

步驟詳解與實戰指令

    ┌──────────────────────┐
    │  1. 捕獲全域編譯錯誤  │  <-- 執行編譯，拉取所有 Error List
    └──────────┬───────────┘
               │ 
               ▼
    ┌──────────────────────┐
    │  2. 精確定位首個錯誤 │  <-- Plan 鎖定特定 AST 行號
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │  3. 應用單行修正     │  <-- 嚴格限制最小 Patch 範圍
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │  4. 防退化增量建置   │  <-- 重新編譯，確認未引入新錯誤
    └──────────────────────┘

步驟 1：全域編譯與錯誤列表生成

在專案中執行建置，生成完整的錯誤報告。

• 實戰指令：

  dotnet build /clp:ErrorsOnly

步驟 2：精確定位首個關鍵錯誤 (Pinpointing)

$plan 會解析錯誤日誌，鎖定首個阻礙建置的編譯錯誤（例如 CS0246），並提取其所屬類別與精確行號。

步驟 3：限制範圍的單行 Patch 應用

AI 助手被限制在僅修改出錯的程式碼行。嚴禁改動其他無關程式碼，以防止修改範圍擴散（Scope Creep）。

步驟 4：防退化增量建置驗證

應用修改後，立即重新啟動增量編譯。

• 實戰指令：

  omx $plan "重新編譯並驗證首個錯誤已清除"

• 判定標準：若該錯誤消失，且全域錯誤總數減少，則判定成功，推進至下一個錯誤；若錯誤總數增加或引入了新錯誤，則立即 Rollback（還原）該 Patch，重新生成方案，從根本上杜絕代碼退化。