BMAD-METHOD、Harness² 和 Cline CLI 看起來像一套現成的 AI 開發組合，但把幾個專案放在一起，並不等於已經建立可靠的遠端執行系統。

真正需要確認的是：關掉本機 IDE 後，遠端流程能否繼續呼叫模型和工具；任務能否依相依關係推進；失敗後能否有界修復；完成後又能否由獨立驗收確認成果，並安全停止。

從這個角度看，V5 的方向不必推倒重來，但架構應從「打造一套通用平台」收斂為「方法資產、小型任務狀態機、獨立 Agent 執行，以及有界的回饋與經驗」。

先分清楚：這些工具並非同一層的替代品

層次	要解決的問題	在系統中的定位
BMAD-METHOD	如何整理需求、規劃工作與提供上下文	提供方法與任務材料
任務圖或狀態機	任務依賴什麼、誰先執行、失敗後往哪走	小型、確定性的編排器
Agent 執行框架	如何呼叫模型、操作工具及管理工作階段	例如由 Pi 負責編碼，Cline 可選擇負責規劃
循環（Loop）	驗證未通過時如何修復、何時停止	當前任務的有界回饋機制
Harness² 思路	如何改進圍繞模型的提示、工具、記憶與編排	以證據支持的方式改善執行環境
Tmux	如何承載遠端工作程序	可在連線中斷後維持程序的載體，不是任務調度器

BMAD 官方將技能描述為預先建好的提示，可用來載入 Agent、執行工作流程或處理任務；其文件也涵蓋單次小改動與較完整的規劃路徑。因此，BMAD 並非只能用於企業級大型專案。256

Harness² 官方倉庫則將 harness 描述為模型周邊、使其能以 Agent 方式行動的系統，包括提示、工具、記憶、技能與編排；相關論文提出遞迴式 harness 改進框架。113 這代表它與任務圖或修復循環有概念上的交集，卻不表示三者都要各自部署成獨立平台。

此處提到的做法，較適合稱為「受 Harness² 啟發的簡化經驗機制」，而不是完整採用了 Harness²。相關評估僅取得論文摘要與倉庫資訊，並未完成全文及原始碼審查。

工具組合不等於執行能力

遠端 AI 開發至少要分辨三個層次：

1. 能載入方法提示並完成一次任務。
2. 遠端程序不依賴本機 IDE；即使中斷連線，仍能呼叫模型與工具。
3. 能依序選擇、驗證並寫回任務狀態；中斷後也能避免重複提交等副作用。

若目標是長時間、可恢復的遠端執行，後兩項才是重點。即使某個 CLI 支援背景工作，也仍要確認它是否涵蓋任務相依、審核隔離、預算限制與檢查點語義。

目前沒有足夠證據確認 Cline 與 pi-jev 的最新介面，以及兩者組合後是否已涵蓋上述能力。換句話說，不能因為安裝了幾個成熟專案，就推定系統自然具備斷線續跑或安全恢復能力。較務實的做法是先採用上游工具，再補上經確認仍缺少的最小功能。

過度設計不只看程式碼行數

這套方案的核心需求其實很集中：由人審查並啟動，讓 VPS 獨立執行獲准任務；每一步經真實驗證後才推進；失敗時只允許有限次修復，之後停止。

但 V5 同時保留了版本分發相容、閘道續接、精細計量、檢查點交易、事故恢復、四槽位、看板與經驗機制等承諾。這使「先證明一條最短、可獨立執行的流程」背負了太大的交付範圍。

較清楚的做法，是把首個可用閉環與後續強化分開。歷史承諾不應被悄悄刪除，但也不必全都成為第一版上線的前置條件；應由系統負責人明確決定哪些列為首輪門檻，哪些延後處理。

還有一項重要的診斷需要修正：先前的架構說明將儲存膨脹歸因於把經驗沉澱做成資料庫，但實際檢視到的儲存模組保存的是人工版本決定，不是任務經驗；模組本身也沒有執行核准或維護任務進度的功能。真正該精簡的，是不需要的通用審批控制層，而不是把授權、執行狀態與檢查點一律塞進一份經驗筆記。

這幾類資訊雖可用簡單檔案保存，責任仍應分清：

• 經驗：下次怎樣做得更好。
• 任務狀態：哪些工作已完成、下一步是什麼。
• 執行證據：實際發生了哪些操作與結果。
• 啟動範圍：這次允許執行哪些任務與寫入。

目前更像是「接線不足」，不是完全沒有原語

現有程式碼檢視呈現幾個具體缺口：

• **已有任務圖雛形：**具備檢查相依、偵測循環，以及在依賴滿足後選取就緒任務的能力。問題不是完全沒有 Graph，而是目前的執行契約只支援 Python 單元測試，尚不能完整描述預期流程。
• **擴充入口未開啟：**現有 Pi 參數禁止載入擴充、技能與上下文檔案。因此，不能假設 pi-jev 已掛載，或 BMAD 技能會自動生效；方法材料仍需明確裝配。
• **檢查點尚未接通整條流程：**循環在候選成果與驗收建立關聯後，仍會阻止完成寫回及推進下一個任務。模組存在，並不等同檢查點交易已完整整合。
• **凍結範圍過大：**執行循環綁定了腳本目錄內幾乎所有 Python 檔案，而不是僅綁定實際執行依賴。已退出新路線的資產，仍可能透過檔案身分檢查影響目前流程。

這些問題指向同一個優先事項：縮小必需依賴，接通已有原語，而不是繼續增加控制層。

建議保留的最小架構

「四槽位」可以理解成四種權限與職責，不代表必須常駐四個模型，更不代表要把四個工作視窗做成四個後台服務。

1. **規劃與研究：**按需要使用 BMAD 整理目標、任務與驗收條件；研究結果作為證據，不直接變成執行授權。
2. **人工啟動：**一次確認計畫版本、任務集合、寫入範圍、預算與停止方式。
3. **單一寫入執行鏈：**選出獲准且已就緒的任務，開新工作階段進行編碼，再做相關的真實驗證、獨立審核、同一候選成果的複核、檢查點保存與任務狀態寫回，之後才進入下一項。
4. **有界修復：**真實驗證失敗後，將回饋交給新的工作階段處理；達到核准的輪次或預算上限，就停止。
5. **經驗與觀察：**依需要、有上限地提供經驗；看板只呈現狀態，不負責授權或判定任務完成。

這條流程已經包含任務圖、修復循環與模型周邊環境等不同職責，無須為每個概念再造一套平台。相應地，可暫緩維護 Cline 私有分支，也避免 Cline 與 Pi 同時取得編碼調度權；一般工程修復不必每次重跑完整三遍分析，也不需要建立通用審批資料庫、經驗資料庫或永久協調 Agent。

同樣地，單純限制檔案行數並不是可靠性的替代指標；真正需要管理的是職責、依賴與可驗證的執行邊界。JeV 的模型路由建議也應與安全門禁分開：可選路由失效時，可以採用事先授權的固定策略；必要護欄失效時，則必須停止。這些是架構建議，不代表已修改原有驗收條件或 JeV 的必要地位。

瘦身也不能拿掉的三道防線

• **確認斷線後仍有實際執行：**驗收時要觀察斷開連線後是否仍發生新的模型與工具操作，以及後續任務是否推進。只看到 Tmux 程序存活或狀態更新，還不夠。
• **確認測試、審核與提交的是同一份成果：**三者必須指向同一候選版本。若提交成功但任務狀態寫回失敗，應停止並對帳，不能重新啟動後再次提交。
• **不把經驗筆記當成真理：**去重不代表內容正確。經驗應附上證據與適用範圍；彼此衝突的規則不能自動覆蓋驗收條件或權限，也不應承諾能徹底避免重犯。

另有一項與實際開發相關的限制：目前的 Git 檢查點策略會拒絕不同任務共用受管理檔案。若相依任務需要先後修改同一檔案，這項策略可能阻擋流程。解法是按任務邊界重新界定檔案所有權，而非假設真實專案永遠不會有跨任務共用檔案。

結論：先證明一條短鏈，再擴充平台

V5 的方向並非錯誤，但曾把個人使用的任務執行器推向通用控制平台。四組件的收斂方向較合理，首輪必需範圍還可以再縮小。

較準確的定位是：BMAD 提供方法，Pi 或 Cline 提供執行入口，小型狀態機落實任務圖與修復循環，經驗機制則可借鏡 Harness²。專案組合不是已驗證系統；個人使用，也不代表可以省略真實驗證、停止條件與成果保護。

第一個價值證明可以只有一條短鏈：關閉本機 IDE 後，遠端完成兩項相依任務，經歷一次真實失敗修復，通過獨立驗收，保存檢查點，最後可靠停止。在這條流程獲得證明之前，其他強化功能都不應成為擴張架構的理由。

靜態檢視範圍

上述工作區觀察來自提供的文件與程式碼檢視，屬於靜態分析，並未證明系統當前的實際執行能力，也未驗證過往的執行回執。檢視位置包括 architecture-v5.md、pending_implementation_plan.md、bmad_agent_backend.py、bmad_loop.py、bmad_state.py、bmad_control_store.py 與 bmad_git_checkpoint.py。

BMAD-METHOD、Harness² 和 Cline CLI 看起來像一套現成的 AI 開發組合，但把幾個專案放在一起，並不等於已經建立可靠的遠端執行系統。

真正需要確認的是：關掉本機 IDE 後，遠端流程能否繼續呼叫模型和工具；任務能否依相依關係推進；失敗後能否有界修復；完成後又能否由獨立驗收確認成果，並安全停止。

從這個角度看，V5 的方向不必推倒重來，但架構應從「打造一套通用平台」收斂為「方法資產、小型任務狀態機、獨立 Agent 執行，以及有界的回饋與經驗」。

先分清楚：這些工具並非同一層的替代品

層次	要解決的問題	在系統中的定位
BMAD-METHOD	如何整理需求、規劃工作與提供上下文	提供方法與任務材料
任務圖或狀態機	任務依賴什麼、誰先執行、失敗後往哪走	小型、確定性的編排器
Agent 執行框架	如何呼叫模型、操作工具及管理工作階段	例如由 Pi 負責編碼，Cline 可選擇負責規劃
循環（Loop）	驗證未通過時如何修復、何時停止	當前任務的有界回饋機制
Harness² 思路	如何改進圍繞模型的提示、工具、記憶與編排	以證據支持的方式改善執行環境
Tmux	如何承載遠端工作程序	可在連線中斷後維持程序的載體，不是任務調度器

BMAD 官方將技能描述為預先建好的提示，可用來載入 Agent、執行工作流程或處理任務；其文件也涵蓋單次小改動與較完整的規劃路徑。因此，BMAD 並非只能用於企業級大型專案。256

Harness² 官方倉庫則將 harness 描述為模型周邊、使其能以 Agent 方式行動的系統，包括提示、工具、記憶、技能與編排；相關論文提出遞迴式 harness 改進框架。113 這代表它與任務圖或修復循環有概念上的交集，卻不表示三者都要各自部署成獨立平台。

此處提到的做法，較適合稱為「受 Harness² 啟發的簡化經驗機制」，而不是完整採用了 Harness²。相關評估僅取得論文摘要與倉庫資訊，並未完成全文及原始碼審查。

工具組合不等於執行能力

遠端 AI 開發至少要分辨三個層次：

1. 能載入方法提示並完成一次任務。
2. 遠端程序不依賴本機 IDE；即使中斷連線，仍能呼叫模型與工具。
3. 能依序選擇、驗證並寫回任務狀態；中斷後也能避免重複提交等副作用。

若目標是長時間、可恢復的遠端執行，後兩項才是重點。即使某個 CLI 支援背景工作，也仍要確認它是否涵蓋任務相依、審核隔離、預算限制與檢查點語義。

目前沒有足夠證據確認 Cline 與 pi-jev 的最新介面，以及兩者組合後是否已涵蓋上述能力。換句話說，不能因為安裝了幾個成熟專案，就推定系統自然具備斷線續跑或安全恢復能力。較務實的做法是先採用上游工具，再補上經確認仍缺少的最小功能。

過度設計不只看程式碼行數

這套方案的核心需求其實很集中：由人審查並啟動，讓 VPS 獨立執行獲准任務；每一步經真實驗證後才推進；失敗時只允許有限次修復，之後停止。

但 V5 同時保留了版本分發相容、閘道續接、精細計量、檢查點交易、事故恢復、四槽位、看板與經驗機制等承諾。這使「先證明一條最短、可獨立執行的流程」背負了太大的交付範圍。

較清楚的做法，是把首個可用閉環與後續強化分開。歷史承諾不應被悄悄刪除，但也不必全都成為第一版上線的前置條件；應由系統負責人明確決定哪些列為首輪門檻，哪些延後處理。

還有一項重要的診斷需要修正：先前的架構說明將儲存膨脹歸因於把經驗沉澱做成資料庫，但實際檢視到的儲存模組保存的是人工版本決定，不是任務經驗；模組本身也沒有執行核准或維護任務進度的功能。真正該精簡的，是不需要的通用審批控制層，而不是把授權、執行狀態與檢查點一律塞進一份經驗筆記。

這幾類資訊雖可用簡單檔案保存，責任仍應分清：

• 經驗：下次怎樣做得更好。
• 任務狀態：哪些工作已完成、下一步是什麼。
• 執行證據：實際發生了哪些操作與結果。
• 啟動範圍：這次允許執行哪些任務與寫入。

目前更像是「接線不足」，不是完全沒有原語

現有程式碼檢視呈現幾個具體缺口：

• **已有任務圖雛形：**具備檢查相依、偵測循環，以及在依賴滿足後選取就緒任務的能力。問題不是完全沒有 Graph，而是目前的執行契約只支援 Python 單元測試，尚不能完整描述預期流程。
• **擴充入口未開啟：**現有 Pi 參數禁止載入擴充、技能與上下文檔案。因此，不能假設 pi-jev 已掛載，或 BMAD 技能會自動生效；方法材料仍需明確裝配。
• **檢查點尚未接通整條流程：**循環在候選成果與驗收建立關聯後，仍會阻止完成寫回及推進下一個任務。模組存在，並不等同檢查點交易已完整整合。
• **凍結範圍過大：**執行循環綁定了腳本目錄內幾乎所有 Python 檔案，而不是僅綁定實際執行依賴。已退出新路線的資產，仍可能透過檔案身分檢查影響目前流程。

這些問題指向同一個優先事項：縮小必需依賴，接通已有原語，而不是繼續增加控制層。

建議保留的最小架構

「四槽位」可以理解成四種權限與職責，不代表必須常駐四個模型，更不代表要把四個工作視窗做成四個後台服務。

1. **規劃與研究：**按需要使用 BMAD 整理目標、任務與驗收條件；研究結果作為證據，不直接變成執行授權。
2. **人工啟動：**一次確認計畫版本、任務集合、寫入範圍、預算與停止方式。
3. **單一寫入執行鏈：**選出獲准且已就緒的任務，開新工作階段進行編碼，再做相關的真實驗證、獨立審核、同一候選成果的複核、檢查點保存與任務狀態寫回，之後才進入下一項。
4. **有界修復：**真實驗證失敗後，將回饋交給新的工作階段處理；達到核准的輪次或預算上限，就停止。
5. **經驗與觀察：**依需要、有上限地提供經驗；看板只呈現狀態，不負責授權或判定任務完成。

這條流程已經包含任務圖、修復循環與模型周邊環境等不同職責，無須為每個概念再造一套平台。相應地，可暫緩維護 Cline 私有分支，也避免 Cline 與 Pi 同時取得編碼調度權；一般工程修復不必每次重跑完整三遍分析，也不需要建立通用審批資料庫、經驗資料庫或永久協調 Agent。

同樣地，單純限制檔案行數並不是可靠性的替代指標；真正需要管理的是職責、依賴與可驗證的執行邊界。JeV 的模型路由建議也應與安全門禁分開：可選路由失效時，可以採用事先授權的固定策略；必要護欄失效時，則必須停止。這些是架構建議，不代表已修改原有驗收條件或 JeV 的必要地位。

瘦身也不能拿掉的三道防線

• **確認斷線後仍有實際執行：**驗收時要觀察斷開連線後是否仍發生新的模型與工具操作，以及後續任務是否推進。只看到 Tmux 程序存活或狀態更新，還不夠。
• **確認測試、審核與提交的是同一份成果：**三者必須指向同一候選版本。若提交成功但任務狀態寫回失敗，應停止並對帳，不能重新啟動後再次提交。
• **不把經驗筆記當成真理：**去重不代表內容正確。經驗應附上證據與適用範圍；彼此衝突的規則不能自動覆蓋驗收條件或權限，也不應承諾能徹底避免重犯。

另有一項與實際開發相關的限制：目前的 Git 檢查點策略會拒絕不同任務共用受管理檔案。若相依任務需要先後修改同一檔案，這項策略可能阻擋流程。解法是按任務邊界重新界定檔案所有權，而非假設真實專案永遠不會有跨任務共用檔案。

結論：先證明一條短鏈，再擴充平台

V5 的方向並非錯誤，但曾把個人使用的任務執行器推向通用控制平台。四組件的收斂方向較合理，首輪必需範圍還可以再縮小。

較準確的定位是：BMAD 提供方法，Pi 或 Cline 提供執行入口，小型狀態機落實任務圖與修復循環，經驗機制則可借鏡 Harness²。專案組合不是已驗證系統；個人使用，也不代表可以省略真實驗證、停止條件與成果保護。

第一個價值證明可以只有一條短鏈：關閉本機 IDE 後，遠端完成兩項相依任務，經歷一次真實失敗修復，通過獨立驗收，保存檢查點，最後可靠停止。在這條流程獲得證明之前，其他強化功能都不應成為擴張架構的理由。

靜態檢視範圍

上述工作區觀察來自提供的文件與程式碼檢視，屬於靜態分析，並未證明系統當前的實際執行能力，也未驗證過往的執行回執。檢視位置包括 architecture-v5.md、pending_implementation_plan.md、bmad_agent_backend.py、bmad_loop.py、bmad_state.py、bmad_control_store.py 與 bmad_git_checkpoint.py。