先看結論：現在缺的是接線，不是另一套工具

建議保留現有 V5 Python 控制器與 Pi 執行適配，將架構收斂為「使用者明確啟動一次、控制器統一裁決、四種角色分權、IDE 只讀觀察」。目前沒有充分理由把全面遷移到 Cline 當成解除阻塞的前提。

現有證據指向執行鏈還沒接完整、關鍵門禁尚未具體化；不足以判定 Pi 的底層選型已失敗，也不能證明系統已發生實際腦裂。

進度盤點：已有原語，尚未串成閉環

• 目前計畫仍標示為 BLOCKED，相關 ADR仍為 PROPOSED。唯一的結構化清單記錄七項歷史 COMPLETED、一項 SUSPENDED；不能用這些數字推算整個工程的完成率。
• 真實執行裁決任務仍暫停，回執為空。最近讀取的歷史執行紀錄顯示曾有一次呼叫遇到網路錯誤，任務未完成。這支持網路路徑受阻的判斷，但無法確定故障是在 Pi、閘道或上游服務。
• 最近工程目錄中的舊日誌記錄了檢查點接線 10 項、監督器 25 項，以及事故接線 6 項通過。本次只讀取舊紀錄，沒有重新確認它們是否仍適用於目前原始碼。
• 實際執行迴圈會在候選結果驗收後主動阻擋：Git 交易尚未接通，就不允許寫回完成狀態或開始下一項任務。Git 交易模組已經存在；更準確的說法是「模組尚未接入主流程」，而不是「模組不存在」。
• 模型註冊表只有兩個候選，編碼模型預設為空；路由模組沒有獨立審核動作。Pi 啟動參數則明確停用了擴充套件，因此目前不能同時宣稱 pi-jev 已載入。

目前最值得補上的，是人工啟動契約、閘道真實協定、Git 交易接線、獨立審核，以及能表達新增執行驗收的機制。繼續增加通用原語或改換外掛，不會自動補上這些缺口。

重新看探索文件：參考構想可以，不能當成選型證據

可保留文件中的四槽位分權、外層狀態機與盲審三個核心構想；但應刪除「徹底消滅幻覺」或「新視窗無損接力」等絕對承諾。

Cline 官方文件確認 CLI 可用於自動化，也有規劃模式；但目前證據不足以確認文件所描述的整套背景 Hub、工作階段共享與生命週期保證，因此不能據此宣布 Cline 已通過所有門檻。123 文件中的主觀總分與效益數字也沒有可複核的測量依據，不宜拿來決策。

Jev 擴充套件並非單一產品，不能把不同專案的能力混為一談。與探索文件描述較接近的專案，提供工具執行前與輸出後的判斷；缺少金鑰時則會保持不介入。9101112 至於單一無介面阻擋開關能否同時涵蓋逾時、額度不足與介面異常，目前證據不足。

異質模型不等於腦裂，共用同一個核心也不等於只有一個權威。真正需要明確規範的是：誰能啟動任務、誰能寫入程式碼、誰負責裁決、誰更新任務狀態，以及誰能重新啟動流程。

因此，不採用「自動切換輕量模型，就能提供同等 Jev 安全門禁」的回退設計，也不採用低風險時自動免除獨立審核的切換條件。

底層選型：Pi 優先，Cline 暫列非關鍵候選

方案	本次判斷	主要理由
現有控制器搭配 Pi 四角色執行個體	有條件優先	可沿用既有協定、預算、清理、記憶與交易資產，新增接線較少。
Cline 負責規劃或研究，Pi 負責編碼與審核	有條件備選	可以分工，但應先證明規劃體驗確有收益，且不能因此多出第二個排程權威。
全面遷移到 Cline	暫不採用	會增加協定、設定、權限與回歸成本，目前尚未證明能解決實際阻塞。
Roo 持續調度背景模型	不作為目標架構	前台應退出執行責任，而不是持續代管後端狀態。

目標不是讓四個大型模型常駐，而是讓一套執行適配承載四種不同權限。模型負責提供不同判斷，程式負責確定性的狀態轉換；兩者不能互相取代。

目標架構：四種角色，一個執行權威

1. 規劃角色：Opus／Astra。 使用者提供方向後，可自動探索、研究並整理方案；只有獲准將成果定稿時，才能修改同一份計畫與提案，沒有啟動編碼的權限。
2. 研究角色：Astra academic。 依需求整理來源與證據，不寫業務程式碼，也不更改驗收條件。
3. 編碼角色：Pi＋Sonnet。 每項 Task 或外層修復都使用新工作階段。可以調查、修改與診斷，但不能自行批准、變更驗收，或直接登記完成。
4. 審核角色：獨立 GPT-6-Sol。 以新工作階段檢視凍結的候選版本、相關原始碼、任務驗收條件與外層驗證回執；不讀取編碼對話，也不能修改業務程式碼。

上述名稱先視為使用者指定的角色；實際模型 ID 仍須核對。目前設定記錄的是 GPT-6.1-Sol，不能直接假定它與 GPT-6-Sol 相同。

• **唯一排程者：**沿用現有 Python 控制器。四個 tmux 槽位只是執行與觀察的位置，不各自擁有任務佇列，也不要求四個模型持續在線。
• **唯一進度來源：**綁定計畫的任務清單。狀態卡只是呈現方式；Git 保存成果、回執記錄事實，不應再建立另一套能獨立推進的進度帳本。
• **人工啟動門檻：**計畫就緒、審核通過、入口切換或 IDE 重新載入，都不能啟動編碼。只有使用者明確指定任務集合、範圍與預算，才建立綁定本次執行的啟動授權。重複提交應回傳既有執行位置，而非產生第二個寫入者。
• **啟動後自動執行：**在獲准的任務集合內，可自動研究、編碼、驗證、盲審、建立檢查點並執行下一項任務。若範圍擴大、驗收條件變更、授權到期或關鍵假設失效，才交還使用者處理。
• **IDE 的界線：**本機只需 Antigravity IDE，透過 SSH 查看差異與結果，不承載背景執行生命週期。若執行中要由人修改同一工作區，應先暫停並確認清理完成；修改後再重新接手。

正常流程應為：使用者啟動 → 程式確定性選取任務 → 建立新的編碼工作階段 → 確認工作階段退出並完成清理 → 凍結候選版本 → 執行相關外層驗證 → 獨立盲審 → 確認候選版本未變 → Git 交易 → 寫回完成狀態 → 更新狀態呈現 → 執行下一項任務。

這套安排可以避免編碼者成為最終裁判，但不能保證不同模型不會有共同盲點；真實測試與可核驗的回執仍不可少。

Jev 的位置：輔助判斷，不掌握授權

• 優先固定四種角色對應，不讓 Jev 任意切換規劃、編碼與審核身分；單一工作階段內的模型應保持固定。
• 將「模型路由建議」與「工具安全門禁」分成兩種契約。前者失效時可改用預先授權的固定模型；若工具安全門禁被列為必要防線，失效時就應阻擋，而非默默降級放行。
• Jev 可協助判斷任務範圍、風險與故障類別；路徑權限、帳號隔離、禁止操作、逾時與預算則應由程式硬性限制。提示詞和語意判斷不能取代這些邊界。
• 導入擴充套件前，須確認具體儲存庫、版本、與固定 Pi 的相容性、資料傳出範圍及失效時的行為。目前啟動契約會停用所有擴充套件，應改成經稽核的單一擴充白名單，而不是開放所有擴充套件。

Jev 不應成為第一階段固定模型閉環的阻塞條件；但若最終交付目標包含 Jev，就必須另外驗收整合後的組合鏈，不能以固定模型測試代替。

修改計畫與 ADR：按順序補齊，不要重建工程

1. 先修訂邊界，不重建工程。 在同一份 ADR 的決策 9後新增明確的替代條款：人工啟動、四角色分權、獨立審核與控制器單一權威。這將取代由 Roo 前台負責一次性模型啟動交接的預設設計，同時保留唯讀觀察與可選的人工作業入口。
2. 把可執行契約具體化。 現有結構化清單主要呈現 Python 單元測試，不能把真實斷線、模型審核或 Git 交易包裝成單元測試通過。先說清楚這些驗收如何連結真實回執，再納入同一份清單，不另開一份計畫。
3. 先接通最短真實鏈。 使用固定編碼模型與獨立審核，選兩項彼此依賴的小型 Task，證明流程能走過真實失敗、新工作階段修復、外層驗證通過、審核、檢查點與下一項任務；同時蒐集客戶端斷線後的新事件。不要先投入四窗格介面美化或動態路由。
4. 針對交易缺口補強。 現有 Git 模組只支援一般儲存庫，且禁止不同任務管理的路徑重疊。前後相依的 Task 往往會再次修改同一個檔案；應補上逐 Task、逐檢查點的接手機制，而非強迫每項任務只能碰互不重疊的檔案。
5. 最後再接入研究、Jev 與四槽位呈現。 只針對實際變更的介面與證據進行定向回歸；保存狀態、無關文件變更與查詢狀態，不應觸發業務流程重測。完整流程及中斷點驗收通過後，再申請接受 ADR。

現階段不建議立刻改採 worktree。這會同時改動已約定的共享工作區與一般儲存庫交易介面。先在與正式服務隔離的編碼工作區建立單一寫入流程；是否改採 worktree，另作明確的拓樸決策，不要把它夾帶進這次解阻工作。

本次交付是唯讀架構審查與修訂方案：沒有修改計畫、ADR 或正式環境檔案，沒有執行終端、測試、真實模型或背景任務，也沒有恢復暫停中的任務。最務實的方向不是推倒 Pi 改用 Cline，而是把既有資產收斂成一條最短、可驗證的流程：使用者握有唯一啟動權，控制器握有唯一狀態權，編碼與審核彼此分權。

先看結論：現在缺的是接線，不是另一套工具

建議保留現有 V5 Python 控制器與 Pi 執行適配，將架構收斂為「使用者明確啟動一次、控制器統一裁決、四種角色分權、IDE 只讀觀察」。目前沒有充分理由把全面遷移到 Cline 當成解除阻塞的前提。

現有證據指向執行鏈還沒接完整、關鍵門禁尚未具體化；不足以判定 Pi 的底層選型已失敗，也不能證明系統已發生實際腦裂。

進度盤點：已有原語，尚未串成閉環

• 目前計畫仍標示為 BLOCKED，相關 ADR仍為 PROPOSED。唯一的結構化清單記錄七項歷史 COMPLETED、一項 SUSPENDED；不能用這些數字推算整個工程的完成率。
• 真實執行裁決任務仍暫停，回執為空。最近讀取的歷史執行紀錄顯示曾有一次呼叫遇到網路錯誤，任務未完成。這支持網路路徑受阻的判斷，但無法確定故障是在 Pi、閘道或上游服務。
• 最近工程目錄中的舊日誌記錄了檢查點接線 10 項、監督器 25 項，以及事故接線 6 項通過。本次只讀取舊紀錄，沒有重新確認它們是否仍適用於目前原始碼。
• 實際執行迴圈會在候選結果驗收後主動阻擋：Git 交易尚未接通，就不允許寫回完成狀態或開始下一項任務。Git 交易模組已經存在；更準確的說法是「模組尚未接入主流程」，而不是「模組不存在」。
• 模型註冊表只有兩個候選，編碼模型預設為空；路由模組沒有獨立審核動作。Pi 啟動參數則明確停用了擴充套件，因此目前不能同時宣稱 pi-jev 已載入。

目前最值得補上的，是人工啟動契約、閘道真實協定、Git 交易接線、獨立審核，以及能表達新增執行驗收的機制。繼續增加通用原語或改換外掛，不會自動補上這些缺口。

重新看探索文件：參考構想可以，不能當成選型證據

可保留文件中的四槽位分權、外層狀態機與盲審三個核心構想；但應刪除「徹底消滅幻覺」或「新視窗無損接力」等絕對承諾。

Cline 官方文件確認 CLI 可用於自動化，也有規劃模式；但目前證據不足以確認文件所描述的整套背景 Hub、工作階段共享與生命週期保證，因此不能據此宣布 Cline 已通過所有門檻。123 文件中的主觀總分與效益數字也沒有可複核的測量依據，不宜拿來決策。

Jev 擴充套件並非單一產品，不能把不同專案的能力混為一談。與探索文件描述較接近的專案，提供工具執行前與輸出後的判斷；缺少金鑰時則會保持不介入。9101112 至於單一無介面阻擋開關能否同時涵蓋逾時、額度不足與介面異常，目前證據不足。

異質模型不等於腦裂，共用同一個核心也不等於只有一個權威。真正需要明確規範的是：誰能啟動任務、誰能寫入程式碼、誰負責裁決、誰更新任務狀態，以及誰能重新啟動流程。

因此，不採用「自動切換輕量模型，就能提供同等 Jev 安全門禁」的回退設計，也不採用低風險時自動免除獨立審核的切換條件。

底層選型：Pi 優先，Cline 暫列非關鍵候選

方案	本次判斷	主要理由
現有控制器搭配 Pi 四角色執行個體	有條件優先	可沿用既有協定、預算、清理、記憶與交易資產，新增接線較少。
Cline 負責規劃或研究，Pi 負責編碼與審核	有條件備選	可以分工，但應先證明規劃體驗確有收益，且不能因此多出第二個排程權威。
全面遷移到 Cline	暫不採用	會增加協定、設定、權限與回歸成本，目前尚未證明能解決實際阻塞。
Roo 持續調度背景模型	不作為目標架構	前台應退出執行責任，而不是持續代管後端狀態。

目標不是讓四個大型模型常駐，而是讓一套執行適配承載四種不同權限。模型負責提供不同判斷，程式負責確定性的狀態轉換；兩者不能互相取代。

目標架構：四種角色，一個執行權威

1. 規劃角色：Opus／Astra。 使用者提供方向後，可自動探索、研究並整理方案；只有獲准將成果定稿時，才能修改同一份計畫與提案，沒有啟動編碼的權限。
2. 研究角色：Astra academic。 依需求整理來源與證據，不寫業務程式碼，也不更改驗收條件。
3. 編碼角色：Pi＋Sonnet。 每項 Task 或外層修復都使用新工作階段。可以調查、修改與診斷，但不能自行批准、變更驗收，或直接登記完成。
4. 審核角色：獨立 GPT-6-Sol。 以新工作階段檢視凍結的候選版本、相關原始碼、任務驗收條件與外層驗證回執；不讀取編碼對話，也不能修改業務程式碼。

上述名稱先視為使用者指定的角色；實際模型 ID 仍須核對。目前設定記錄的是 GPT-6.1-Sol，不能直接假定它與 GPT-6-Sol 相同。

• **唯一排程者：**沿用現有 Python 控制器。四個 tmux 槽位只是執行與觀察的位置，不各自擁有任務佇列，也不要求四個模型持續在線。
• **唯一進度來源：**綁定計畫的任務清單。狀態卡只是呈現方式；Git 保存成果、回執記錄事實，不應再建立另一套能獨立推進的進度帳本。
• **人工啟動門檻：**計畫就緒、審核通過、入口切換或 IDE 重新載入，都不能啟動編碼。只有使用者明確指定任務集合、範圍與預算，才建立綁定本次執行的啟動授權。重複提交應回傳既有執行位置，而非產生第二個寫入者。
• **啟動後自動執行：**在獲准的任務集合內，可自動研究、編碼、驗證、盲審、建立檢查點並執行下一項任務。若範圍擴大、驗收條件變更、授權到期或關鍵假設失效，才交還使用者處理。
• **IDE 的界線：**本機只需 Antigravity IDE，透過 SSH 查看差異與結果，不承載背景執行生命週期。若執行中要由人修改同一工作區，應先暫停並確認清理完成；修改後再重新接手。

正常流程應為：使用者啟動 → 程式確定性選取任務 → 建立新的編碼工作階段 → 確認工作階段退出並完成清理 → 凍結候選版本 → 執行相關外層驗證 → 獨立盲審 → 確認候選版本未變 → Git 交易 → 寫回完成狀態 → 更新狀態呈現 → 執行下一項任務。

這套安排可以避免編碼者成為最終裁判，但不能保證不同模型不會有共同盲點；真實測試與可核驗的回執仍不可少。

Jev 的位置：輔助判斷，不掌握授權

• 優先固定四種角色對應，不讓 Jev 任意切換規劃、編碼與審核身分；單一工作階段內的模型應保持固定。
• 將「模型路由建議」與「工具安全門禁」分成兩種契約。前者失效時可改用預先授權的固定模型；若工具安全門禁被列為必要防線，失效時就應阻擋，而非默默降級放行。
• Jev 可協助判斷任務範圍、風險與故障類別；路徑權限、帳號隔離、禁止操作、逾時與預算則應由程式硬性限制。提示詞和語意判斷不能取代這些邊界。
• 導入擴充套件前，須確認具體儲存庫、版本、與固定 Pi 的相容性、資料傳出範圍及失效時的行為。目前啟動契約會停用所有擴充套件，應改成經稽核的單一擴充白名單，而不是開放所有擴充套件。

Jev 不應成為第一階段固定模型閉環的阻塞條件；但若最終交付目標包含 Jev，就必須另外驗收整合後的組合鏈，不能以固定模型測試代替。

修改計畫與 ADR：按順序補齊，不要重建工程

1. 先修訂邊界，不重建工程。 在同一份 ADR 的決策 9後新增明確的替代條款：人工啟動、四角色分權、獨立審核與控制器單一權威。這將取代由 Roo 前台負責一次性模型啟動交接的預設設計，同時保留唯讀觀察與可選的人工作業入口。
2. 把可執行契約具體化。 現有結構化清單主要呈現 Python 單元測試，不能把真實斷線、模型審核或 Git 交易包裝成單元測試通過。先說清楚這些驗收如何連結真實回執，再納入同一份清單，不另開一份計畫。
3. 先接通最短真實鏈。 使用固定編碼模型與獨立審核，選兩項彼此依賴的小型 Task，證明流程能走過真實失敗、新工作階段修復、外層驗證通過、審核、檢查點與下一項任務；同時蒐集客戶端斷線後的新事件。不要先投入四窗格介面美化或動態路由。
4. 針對交易缺口補強。 現有 Git 模組只支援一般儲存庫，且禁止不同任務管理的路徑重疊。前後相依的 Task 往往會再次修改同一個檔案；應補上逐 Task、逐檢查點的接手機制，而非強迫每項任務只能碰互不重疊的檔案。
5. 最後再接入研究、Jev 與四槽位呈現。 只針對實際變更的介面與證據進行定向回歸；保存狀態、無關文件變更與查詢狀態，不應觸發業務流程重測。完整流程及中斷點驗收通過後，再申請接受 ADR。

現階段不建議立刻改採 worktree。這會同時改動已約定的共享工作區與一般儲存庫交易介面。先在與正式服務隔離的編碼工作區建立單一寫入流程；是否改採 worktree，另作明確的拓樸決策，不要把它夾帶進這次解阻工作。

本次交付是唯讀架構審查與修訂方案：沒有修改計畫、ADR 或正式環境檔案，沒有執行終端、測試、真實模型或背景任務，也沒有恢復暫停中的任務。最務實的方向不是推倒 Pi 改用 Cline，而是把既有資產收斂成一條最短、可驗證的流程：使用者握有唯一啟動權，控制器握有唯一狀態權，編碼與審核彼此分權。