為什麼需要多工作區並行重構？

在大型專案中，核心模組的 API 簽章修改（例如重構 IConnection.cs）會立刻導致多個獨立的子模組（如 Billing, Admin, Jobs）同時編譯失敗。如果只有一個 AI 進程，你必須手動修改一個檔案、編譯、看錯誤、再修改下一個，這是一條極為漫長的循序道路。

並行多工作區重構工作流 (Parallel Worktree Refactor Flow) 透過 omc team，讓 AI 助手能同時在多個獨立的 git worktree 中並行修復各個子模組的編譯錯誤，省去 70% 以上的等待時間。

步驟詳解與實戰指令

    ┌──────────────────────┐
    │  1. 修改核心 API     │  <-- 修改底層介面，引發全域編譯中斷
    └──────────┬───────────┘
               │ 
               ▼
    ┌──────────────────────┐
    │  2. 建立並行 Worker   │  <-- 執行 omc team init --workers=N
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │  3. 背景 Sisyphus 自修│  <-- 啟動 omc sisyphus 循環
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │  4. 合併並安全清理   │  <-- 執行 omc team merge && cleanup
    └──────────────────────┘

步驟 1：修改核心 API 與定義

修改底層核心類別或介面。此時全域編譯會中斷，並在多個子專案中產生連鎖編譯錯誤。

步驟 2：初始化並行 Workers 與隔離工作樹

呼叫 omc team，為每個相依的子應用建立一個隔離的 git worktree 與對應的 tmux Pane。

• 實戰指令：

  omc team init --workers=3 --names=billing,subscription,admin

步驟 3：在背景啟動 Sisyphus 自主修復

在所有背景 Pane 中並行啟動 Sisyphus 代理，要求它們在各自的局部目錄下，自動反覆編譯並修復由於底層 API 修改帶來的編譯報錯。

• 實戰指令：在各 Worker 工作樹中分別啟動 omc sisyphus 自主修復循環。

  omc sisyphus --build-cmd="dotnet build" --max-loops=10

步驟 4：代碼安全合併與 Worktree 清理

當所有背景 Worker 在 HUD 中都顯示「Build Succeeded」後，執行一鍵合併指令，將所有分支程式碼統一合併回主線，並自動刪除臨時建立的 Worktree 以釋放空間。

• 實戰指令：

  omc team merge
  omc team cleanup

v5.1～v5.3：並行工作流的新版邊界

升到 v5.1+ 後，Team scale-up 應保留你已明確設定的 Cursor / provider model defaults；框架預設不應覆蓋 explicit choice。v5.2 也把 per-tool hook state 與 worker spawns 改為 bounded，長時間平行重構時資源更可預期。

如果工作包含需要人工核准的高風險步驟，v5.3 建議不要只靠「所有 worker 都綠」作為唯一完成條件；可把 remote approval gate 與 workspace checkpoint 加在 merge / release 前，失敗時能 rollback 到已知狀態。