為什麼需要衝突自愈合併？

當我們啟動並行開發（Team Mode），多個 Worker 同時在各自的分支（Git Worktree）中修改程式碼。在最後合併回主分支（main）時，常會因為行號不同或修改同一個檔案而觸發嚴重的 Git Merge Conflict。傳統做法需要人手動去打開 IDE，找出 <<<<<<< HEAD 標籤手動剔除，這破壞了全自動化開發的體驗。

並行開發衝突自愈合併工作流 (Concurrency-Safe Merge Flow) 利用 OMO 的雜湊錨定編輯協定，實現了衝突的 100% 自動辨識與自愈合併。

步驟詳解與實戰指令

    ┌──────────────────────┐
    │ 1. 觸發一鍵合併      │  <-- 觸發 Hash-Anchored 合併
    └──────────┬───────────┘
               │ 
               ▼
    ┌──────────────────────┐
    │ 2. 雜湊錨點比對定位   │  <-- 識別衝突區間的特徵 Hash
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │ 3. 語意三方合併      │  <-- 自動將修改安全織入
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │ 4. 編譯自愈驗證      │  <-- 跑 Sisyphus Loop 解決懸空引用
    └──────────────────────┘

步驟 1：觸發一鍵合併

當所有的背景 Worker 完成代碼編修後，開發者或 Master 代理下達合併指令。

• 實戰動作：透過 Team Mode 觸發 Hash-Anchored 合併，將各 Worktree 分支織回主分支（合併引擎會在下一步讀取 Context Hash Anchor 進行比對）。

步驟 2：雜湊錨點比對定位

當 Git 提示衝突時，OMO 的合併引擎不依賴 Git 簡單的文本對比，而是讀取兩端分支在修改前記錄的 Context Hash Anchor，在 AST 語法樹中精確鎖定衝突點的物理位置。

步驟 3：三方安全合併與 Patch 織入

利用 3-way Merge 語意引擎，自動將兩端的修改進行融合。例如：

• Worker A 往方法新增了一個參數。
• Worker B 修改了方法的內部實現。 引擎會自動將兩者融合成一個同時包含新參數與新實現的完整方法。

步驟 4：編譯自愈驗證 (Post-merge Build)

合併完成後，系統會自動在主分支啟動 Sisyphus 引擎，執行全域建置與測試。若合併引發了懸空的類型引用或命名空間錯誤，Sisyphus 會在背景自動修復，直到專案再次 100% healthy，完成安全合併。