核心判斷：先停下 V5，再驗證 V6

這份 BMRalph 架構檢視的結論並不是「V6 已經可以上線」，而是：V5 的執行層不宜再靠增加中介程式補洞；V6 可以朝更精簡的方向設計，但仍有幾個關鍵接縫必須實測。

建議的架構組合是：上游編排器負責流程，一套 Cline 執行框架負責開發與審核，外部驗證負責守住提交門檻，再以有界的文字經驗協助後續任務。這是目標設計，不代表各元件已經接通。

檢視過程也有清楚的證據界線：本次沒有修改計畫、ADR、程式碼或測試，也沒有啟動模型、安裝套件、提交或封存任何內容。歷史測試結果是既有紀錄，不是本次重跑的驗證。

V5 的問題不只是「程式太多」

記錄完整，不代表任務完成

目前檢視的 bmad_control_store.py 為 315 行，是追加式檔案記錄存放區，不是 SQL 資料庫；所謂歷史上曾有 1,728 行版本及其對應提交，這次沒有足夠證據確認。

這個模組會處理目錄身分、檔案權限、鎖、版本、歷史連續性、容量預算，以及寫入後回讀與內容指紋。不過，它的回傳結果也明確劃出界線：不驗證人工身分、不授予執行權、不啟動任務，也不保存任務進度。

問題因此不在於安全檢查本身，而在於投入大量工程維護決策紀錄，卻尚未證明「人的決定如何接到實際執行」這條產品閉環。檢視也提醒，不能只因儲存程式碼較長，就斷言它造成模型上下文膨脹；必須先證明這些內容真的反覆被放進模型輸入。

同樣地，程式使用非阻塞獨占鎖，遇到衝突會拒絕操作，而非無限等待。多層鎖可能阻礙流程，但目前不能直接稱為已發生死鎖，仍需要等待鏈或執行紀錄佐證。

執行器不認技能，外围就得補更多膠水

V5 的 Agent 後端設定同時停用技能、擴充功能、MCP、提示模板與上下文檔案，並限制可用工具。這表示執行器無法原生探索 BMAD 技能；若仍要使用 BMAD 工作流程，就得由外围重新展開內容、補足依賴，並管理版本對應。

這不等於 Agent 完全不能使用 BMAD，但會把原本可由技能載入處理的工作，轉移到額外的適配層。BMAD 的自動建置入口也不只是可任意複製的一段提示詞：它要求專案具備渲染入口、技能根目錄與明確的失敗處理。

因此，V6 的建議是不要搬移舊執行器驅動、預算適配或相容層，也不要讓分析端成為第二個背景調度器。工具的自動核准不等於任務授權，模型也不能自行擴大工作範圍。

單元測試通過，不代表遠端工作流程已跑通

現有計畫記錄了使用者確認的 231 項專屬單元測試通過；同一份計畫也指出，真實後端、獨立身分驗證、用戶端關閉後的新任務，以及遠端閉環仍未驗證。本次沒有重新執行這些測試。

單元測試可以證明鎖、版本、預算與路徑檢查符合程式實作；模擬後端也能驗證某些失敗回饋與狀態寫回。但這些結果不能直接證明目標 CLI 能正確執行技能、真實模型工具呼叫與完成事件可靠，或本機 IDE 關閉後 VPS 能開始下一個任務。

換句話說，問題不是「測試都沒用」，而是測試涵蓋的範圍，不能被誤當成產品閉環驗收。舊測試可以保留為歷史資產，不應自動成為 V6 的綠燈。

V6 各元件要各做各的事

元件	建議的單一職責	不應越界的事
bmad-loop	選擇 Story、管理工作階段、驗證、重試與提交	不改變人的目標，也不再外包一套循環控制器
Cline CLI	在指定工作區執行單次開發或審核任務	不另開第二套排程、背景 Hub 或團隊循環
BMAD-METHOD	提供規劃、建置與審查工作流程	不複製成私有技能分支，也不把所有角色一次載入
solo-jev-gate	評估候選 Diff 是否符合範圍，分類失敗	不改程式、不挑下一張 Story，也不覆蓋真實測試結果
Harness²-inspired 經驗	將有證據、適用範圍有限的教訓留給後續任務	不更改硬性門禁，也不增加訓練或最佳化循環

bmad-loop：讓程式控制流程，別再造一個控制器

「No LLM in the control loop」的意思，是 Story 選擇、重試預算、門禁與完成檢查由程式決定；不是整套系統都不用模型。產生程式碼和審查工作，仍可由新的 Agent 工作階段執行。

文件列出的流程大致是開發、驗證、獨立審查、再次驗證，再提交。Worktree 隔離需要明確啟用；上游也已有 TUI 看板，不必再自製另一套看板。

不過，預設行為仍須留意：獨立審核可能只在開發者建議時觸發，不一定每張 Story 都必審；某些審核預算收斂情境仍允許提交；Story 的 Token 上限則是提醒性預算，不等於硬性停止。V6 若要求強制審核，就必須在上游提供的接縫補上門檻，而不是誤把預設行為當成已達標。

Cline：兩個任務設定，不是兩套自治系統

架構建議為開發與審核設兩個設定身分：開發設定可寫入獲准的 Story 工作區，審核設定則使用不同的設定與工作階段目錄，只接觸驗收條件、凍結候選內容、相關程式碼和測試證據。檢視文本列出的模型目標分別是 Sonnet 5.5 與 GPT-6-Sol，但實際模型 ID、提供者協定、憑證與費用預算仍須從非機密設定及真實呼叫回執核對。

目前明確的阻礙是：bmad-loop 列出的內建 CLI 尚不包含 Cline，而通用適配器需要生命週期 Hooks；相關文件列出的 Hook 方言也沒有 Cline。也就是說，不能只寫出一張事件對照表，就宣稱已完成整合。

要解除這個阻礙，至少要實際證明：工作階段能啟動並在完成後退出；開始與完成事件可綁定到正確的工作階段；一般訊息不會被誤認為任務完成；取消後工作階段和工具程序確實終止；用量讀取失敗時會清楚標示未知，而不是宣稱費用限制有效。

BMAD-METHOD：原生按需載入，不要技能套娃

建議由 BMAD 提供規劃、實作與票據管理等既有工作流程，技能來源保持唯讀並按任務需要載入。檢視資料列出 31 個技能目錄，其中 3 個是模組紀錄，因此不能直接說成 31 個都可呼叫的敏捷技能。

建立技能連結也不等於完成安裝：專案初始化、渲染依賴、Worktree 中的技能可見性與實際載入，都還需要驗證。更不應把整個技能目錄一次塞進每個模型任務。

Jev：可做結構化評估，但不能取代確定性門檻

Jev 接收狀態與具型別的問題，回傳結構化答案；官方文件也列出 API、SDK 等使用方式。它不是負責寫程式或聊天的編碼 Agent。12

建議門禁分成兩層：程式先檢查所有候選檔案是否位於核准範圍，新增檔案也要納入；路徑越界就直接失敗。接著才讓 Jev 根據有限的 Diff、驗收條件與失敗證據，評估語意是否越界，以及失敗較像實作問題、環境問題或未知。

對外部服務不可用、認證失敗或傳輸錯誤，建議採用獨立的環境故障結果，讓編排器暫停，而不是把它算成程式修復失敗。Jev 的請求格式、回應驗證與資料出站範圍仍需工程核驗；語意評估也不能取代確定性路徑檢查。

這種外部門禁是在程式已寫入之後才評估，因此無法撤銷先前發生的外部操作。Worktree、帳號權限及禁止使用生產憑證，仍是控制副作用的必要邊界。

Harness²-inspired：只借用有證據的經驗

建議 V6 MVP 只採用跨任務的文字經驗機制，不安裝完整 Harness² 執行器，也不引進候選探測循環。因此，準確說法是「受 Harness² 啟發的文字經驗機制」，而非完整重現其雙層遞迴。

每條經驗只保留觸發條件、適用範圍、一項可執行教訓，以及 Story 和證據位置；也要記下反例或不適用情況。失敗任務的觀察先留在原生失敗回饋中，不能急著包裝成已驗證規律。經驗只能協助任務，不得變更授權或驗收標準。

一張 Story 的理想流程，以及不能忽略的失敗情境

以「避免重複提交訂單」為例，前提是產品已明確定義重複提交的預期行為，並核准改動相關實作與測試：

1. bmad-loop 選出已核准的 Story，確認依賴與初始化門檻，再建立 Story 專用 Worktree。
2. 開啟新的 Cline 開發工作階段，載入 Story、驗收條件、相關經驗與必要程式碼；不接續舊聊天，也不載入 V5 驅動。
3. Agent 修改實作並補上重複提交的反例。工作階段停止，只能說明 Agent 已停止，不代表任務通過。
4. 執行檔案範圍檢查、相關測試與 Jev 語意評估；必需項目未通過，就不能提交。
5. 凍結候選內容與證據，包含新增檔案、驗收條件、測試命令及實際退出結果。
6. 由新的 Cline 審核工作階段進行獨立盲審，不提供開發對話或自我辯護。審核只能回覆通過、拒絕或未知，不能修改業務程式碼。
7. 審核後再從真實反例提煉經驗；沒有新教訓就不必硬寫一條「進化成果」。
8. 提交前重新核對候選內容、測試、Jev 結果和盲審結果。若業務內容在審核後改變，原審核就失效。
9. 只有上游編排器負責最終提交與合併。經驗檔案跟著通過的候選一起提交，避免程式碼尚未落地，經驗卻先影響下一個任務。
10. 下一張 Story 從已合併的目標分支建立新工作階段，再讀取相關經驗；提交或票據回寫中斷時，依照原生狀態停下，不另造補丁式恢復機制。

盲審也有一個容易誤判的地方：一般審核流程可能再次執行建置技能，甚至修改成果，這不等於真正唯讀的獨立審查。建議透過上游提交前的工作流程接縫執行唯一一輪盲審，再由確定性檢查驗證其結果。但「工作階段完成」不等於「審核通過」；門禁必須失敗關閉，候選內容一旦變更，舊批准不得沿用。

V5 凍結與 V6 啟動：先設邊界，再談上線

對 V5 的建議是保留原計畫、未完成事項與歷史回執，以既有狀態標記為暫停，並明確註明執行層不再推進。不要把未完成項目改勾為完成，也不要把舊測試重新命名為 V6 驗證。V6 應建立新的計畫與 ADR，記錄哪些舊決策不再沿用。

這只代表文件上的凍結，不代表 V5 的宿主程序已經停止；停用舊入口、確認在途程序結束與實際封存，仍需要另行核准並執行。

V6 最小軟體範圍可包括 Python 3.11 以上、Git 2.34 以上、tmux 3.2 以上、固定版本的 bmad-loop 與 Cline、上游 BMAD 技能及專案渲染依賴，以及專案測試所需套件。不需要再裝另一套 Agent、看板、資料庫或完整 Harness² 執行器。

不過，安裝與設定本身也不是完成證明。初期應先檢查 Cline 適配、BMAD 初始化、技能發現和必要門禁是否就緒；未確認前，不應直接啟動會呼叫模型、修改工作區或可能提交的 Story。

真正的 MVP 驗收至少要證明：一張獲准 Story 走完開發、必需測試、Jev 評估、獨立盲審與原生提交；用戶端斷開後，VPS 仍能產生新的真實執行階段與回執；越界、拒絕、未知、服務不可用與測試失敗都不能進入提交；停止後會話與工具程序確實結束，失敗現場也能保留。

「用戶端離線自治」和「VPS 完全沒有網路」是兩種不同驗收情境。V6 的目標可以是前者；若遠端模型或 Jev 無法連線，系統應在有限時間內正確暫停，而不是假裝能離線呼叫遠端服務。

最後裁決

這份檢視支持 V5 執行層停止擴建、保留分析方法與歷史證據；也支持以 bmad-loop、單一 Cline 框架、BMAD 原生技能、外部門禁和有限文字經驗作為 V6 方向。

但「方向精簡」不等於「產品已準備好」。最優先的工程工作不是再寫一套控制器，而是證明 Cline 確實符合上游工作階段契約，並跑通失敗關閉的獨立審核與提交鏈。若適配不成立，就應停在接縫上處理，而不是把缺口重新包裝成 V5 式中介層。

核心判斷：先停下 V5，再驗證 V6

這份 BMRalph 架構檢視的結論並不是「V6 已經可以上線」，而是：V5 的執行層不宜再靠增加中介程式補洞；V6 可以朝更精簡的方向設計，但仍有幾個關鍵接縫必須實測。

建議的架構組合是：上游編排器負責流程，一套 Cline 執行框架負責開發與審核，外部驗證負責守住提交門檻，再以有界的文字經驗協助後續任務。這是目標設計，不代表各元件已經接通。

檢視過程也有清楚的證據界線：本次沒有修改計畫、ADR、程式碼或測試，也沒有啟動模型、安裝套件、提交或封存任何內容。歷史測試結果是既有紀錄，不是本次重跑的驗證。

V5 的問題不只是「程式太多」

記錄完整，不代表任務完成

目前檢視的 bmad_control_store.py 為 315 行，是追加式檔案記錄存放區，不是 SQL 資料庫；所謂歷史上曾有 1,728 行版本及其對應提交，這次沒有足夠證據確認。

這個模組會處理目錄身分、檔案權限、鎖、版本、歷史連續性、容量預算，以及寫入後回讀與內容指紋。不過，它的回傳結果也明確劃出界線：不驗證人工身分、不授予執行權、不啟動任務，也不保存任務進度。

問題因此不在於安全檢查本身，而在於投入大量工程維護決策紀錄，卻尚未證明「人的決定如何接到實際執行」這條產品閉環。檢視也提醒，不能只因儲存程式碼較長，就斷言它造成模型上下文膨脹；必須先證明這些內容真的反覆被放進模型輸入。

同樣地，程式使用非阻塞獨占鎖，遇到衝突會拒絕操作，而非無限等待。多層鎖可能阻礙流程，但目前不能直接稱為已發生死鎖，仍需要等待鏈或執行紀錄佐證。

執行器不認技能，外围就得補更多膠水

V5 的 Agent 後端設定同時停用技能、擴充功能、MCP、提示模板與上下文檔案，並限制可用工具。這表示執行器無法原生探索 BMAD 技能；若仍要使用 BMAD 工作流程，就得由外围重新展開內容、補足依賴，並管理版本對應。

這不等於 Agent 完全不能使用 BMAD，但會把原本可由技能載入處理的工作，轉移到額外的適配層。BMAD 的自動建置入口也不只是可任意複製的一段提示詞：它要求專案具備渲染入口、技能根目錄與明確的失敗處理。

因此，V6 的建議是不要搬移舊執行器驅動、預算適配或相容層，也不要讓分析端成為第二個背景調度器。工具的自動核准不等於任務授權，模型也不能自行擴大工作範圍。

單元測試通過，不代表遠端工作流程已跑通

現有計畫記錄了使用者確認的 231 項專屬單元測試通過；同一份計畫也指出，真實後端、獨立身分驗證、用戶端關閉後的新任務，以及遠端閉環仍未驗證。本次沒有重新執行這些測試。

單元測試可以證明鎖、版本、預算與路徑檢查符合程式實作；模擬後端也能驗證某些失敗回饋與狀態寫回。但這些結果不能直接證明目標 CLI 能正確執行技能、真實模型工具呼叫與完成事件可靠，或本機 IDE 關閉後 VPS 能開始下一個任務。

換句話說，問題不是「測試都沒用」，而是測試涵蓋的範圍，不能被誤當成產品閉環驗收。舊測試可以保留為歷史資產，不應自動成為 V6 的綠燈。

V6 各元件要各做各的事

元件	建議的單一職責	不應越界的事
bmad-loop	選擇 Story、管理工作階段、驗證、重試與提交	不改變人的目標，也不再外包一套循環控制器
Cline CLI	在指定工作區執行單次開發或審核任務	不另開第二套排程、背景 Hub 或團隊循環
BMAD-METHOD	提供規劃、建置與審查工作流程	不複製成私有技能分支，也不把所有角色一次載入
solo-jev-gate	評估候選 Diff 是否符合範圍，分類失敗	不改程式、不挑下一張 Story，也不覆蓋真實測試結果
Harness²-inspired 經驗	將有證據、適用範圍有限的教訓留給後續任務	不更改硬性門禁，也不增加訓練或最佳化循環

bmad-loop：讓程式控制流程，別再造一個控制器

「No LLM in the control loop」的意思，是 Story 選擇、重試預算、門禁與完成檢查由程式決定；不是整套系統都不用模型。產生程式碼和審查工作，仍可由新的 Agent 工作階段執行。

文件列出的流程大致是開發、驗證、獨立審查、再次驗證，再提交。Worktree 隔離需要明確啟用；上游也已有 TUI 看板，不必再自製另一套看板。

不過，預設行為仍須留意：獨立審核可能只在開發者建議時觸發，不一定每張 Story 都必審；某些審核預算收斂情境仍允許提交；Story 的 Token 上限則是提醒性預算，不等於硬性停止。V6 若要求強制審核，就必須在上游提供的接縫補上門檻，而不是誤把預設行為當成已達標。

Cline：兩個任務設定，不是兩套自治系統

架構建議為開發與審核設兩個設定身分：開發設定可寫入獲准的 Story 工作區，審核設定則使用不同的設定與工作階段目錄，只接觸驗收條件、凍結候選內容、相關程式碼和測試證據。檢視文本列出的模型目標分別是 Sonnet 5.5 與 GPT-6-Sol，但實際模型 ID、提供者協定、憑證與費用預算仍須從非機密設定及真實呼叫回執核對。

目前明確的阻礙是：bmad-loop 列出的內建 CLI 尚不包含 Cline，而通用適配器需要生命週期 Hooks；相關文件列出的 Hook 方言也沒有 Cline。也就是說，不能只寫出一張事件對照表，就宣稱已完成整合。

要解除這個阻礙，至少要實際證明：工作階段能啟動並在完成後退出；開始與完成事件可綁定到正確的工作階段；一般訊息不會被誤認為任務完成；取消後工作階段和工具程序確實終止；用量讀取失敗時會清楚標示未知，而不是宣稱費用限制有效。

BMAD-METHOD：原生按需載入，不要技能套娃

建議由 BMAD 提供規劃、實作與票據管理等既有工作流程，技能來源保持唯讀並按任務需要載入。檢視資料列出 31 個技能目錄，其中 3 個是模組紀錄，因此不能直接說成 31 個都可呼叫的敏捷技能。

建立技能連結也不等於完成安裝：專案初始化、渲染依賴、Worktree 中的技能可見性與實際載入，都還需要驗證。更不應把整個技能目錄一次塞進每個模型任務。

Jev：可做結構化評估，但不能取代確定性門檻

Jev 接收狀態與具型別的問題，回傳結構化答案；官方文件也列出 API、SDK 等使用方式。它不是負責寫程式或聊天的編碼 Agent。12

建議門禁分成兩層：程式先檢查所有候選檔案是否位於核准範圍，新增檔案也要納入；路徑越界就直接失敗。接著才讓 Jev 根據有限的 Diff、驗收條件與失敗證據，評估語意是否越界，以及失敗較像實作問題、環境問題或未知。

對外部服務不可用、認證失敗或傳輸錯誤，建議採用獨立的環境故障結果，讓編排器暫停，而不是把它算成程式修復失敗。Jev 的請求格式、回應驗證與資料出站範圍仍需工程核驗；語意評估也不能取代確定性路徑檢查。

這種外部門禁是在程式已寫入之後才評估，因此無法撤銷先前發生的外部操作。Worktree、帳號權限及禁止使用生產憑證，仍是控制副作用的必要邊界。

Harness²-inspired：只借用有證據的經驗

建議 V6 MVP 只採用跨任務的文字經驗機制，不安裝完整 Harness² 執行器，也不引進候選探測循環。因此，準確說法是「受 Harness² 啟發的文字經驗機制」，而非完整重現其雙層遞迴。

每條經驗只保留觸發條件、適用範圍、一項可執行教訓，以及 Story 和證據位置；也要記下反例或不適用情況。失敗任務的觀察先留在原生失敗回饋中，不能急著包裝成已驗證規律。經驗只能協助任務，不得變更授權或驗收標準。

一張 Story 的理想流程，以及不能忽略的失敗情境

以「避免重複提交訂單」為例，前提是產品已明確定義重複提交的預期行為，並核准改動相關實作與測試：

1. bmad-loop 選出已核准的 Story，確認依賴與初始化門檻，再建立 Story 專用 Worktree。
2. 開啟新的 Cline 開發工作階段，載入 Story、驗收條件、相關經驗與必要程式碼；不接續舊聊天，也不載入 V5 驅動。
3. Agent 修改實作並補上重複提交的反例。工作階段停止，只能說明 Agent 已停止，不代表任務通過。
4. 執行檔案範圍檢查、相關測試與 Jev 語意評估；必需項目未通過，就不能提交。
5. 凍結候選內容與證據，包含新增檔案、驗收條件、測試命令及實際退出結果。
6. 由新的 Cline 審核工作階段進行獨立盲審，不提供開發對話或自我辯護。審核只能回覆通過、拒絕或未知，不能修改業務程式碼。
7. 審核後再從真實反例提煉經驗；沒有新教訓就不必硬寫一條「進化成果」。
8. 提交前重新核對候選內容、測試、Jev 結果和盲審結果。若業務內容在審核後改變，原審核就失效。
9. 只有上游編排器負責最終提交與合併。經驗檔案跟著通過的候選一起提交，避免程式碼尚未落地，經驗卻先影響下一個任務。
10. 下一張 Story 從已合併的目標分支建立新工作階段，再讀取相關經驗；提交或票據回寫中斷時，依照原生狀態停下，不另造補丁式恢復機制。

盲審也有一個容易誤判的地方：一般審核流程可能再次執行建置技能，甚至修改成果，這不等於真正唯讀的獨立審查。建議透過上游提交前的工作流程接縫執行唯一一輪盲審，再由確定性檢查驗證其結果。但「工作階段完成」不等於「審核通過」；門禁必須失敗關閉，候選內容一旦變更，舊批准不得沿用。

V5 凍結與 V6 啟動：先設邊界，再談上線

對 V5 的建議是保留原計畫、未完成事項與歷史回執，以既有狀態標記為暫停，並明確註明執行層不再推進。不要把未完成項目改勾為完成，也不要把舊測試重新命名為 V6 驗證。V6 應建立新的計畫與 ADR，記錄哪些舊決策不再沿用。

這只代表文件上的凍結，不代表 V5 的宿主程序已經停止；停用舊入口、確認在途程序結束與實際封存，仍需要另行核准並執行。

V6 最小軟體範圍可包括 Python 3.11 以上、Git 2.34 以上、tmux 3.2 以上、固定版本的 bmad-loop 與 Cline、上游 BMAD 技能及專案渲染依賴，以及專案測試所需套件。不需要再裝另一套 Agent、看板、資料庫或完整 Harness² 執行器。

不過，安裝與設定本身也不是完成證明。初期應先檢查 Cline 適配、BMAD 初始化、技能發現和必要門禁是否就緒；未確認前，不應直接啟動會呼叫模型、修改工作區或可能提交的 Story。

真正的 MVP 驗收至少要證明：一張獲准 Story 走完開發、必需測試、Jev 評估、獨立盲審與原生提交；用戶端斷開後，VPS 仍能產生新的真實執行階段與回執；越界、拒絕、未知、服務不可用與測試失敗都不能進入提交；停止後會話與工具程序確實結束，失敗現場也能保留。

「用戶端離線自治」和「VPS 完全沒有網路」是兩種不同驗收情境。V6 的目標可以是前者；若遠端模型或 Jev 無法連線，系統應在有限時間內正確暫停，而不是假裝能離線呼叫遠端服務。

最後裁決

這份檢視支持 V5 執行層停止擴建、保留分析方法與歷史證據；也支持以 bmad-loop、單一 Cline 框架、BMAD 原生技能、外部門禁和有限文字經驗作為 V6 方向。

但「方向精簡」不等於「產品已準備好」。最優先的工程工作不是再寫一套控制器，而是證明 Cline 確實符合上游工作階段契約，並跑通失敗關閉的獨立審核與提交鏈。若適配不成立，就應停在接縫上處理，而不是把缺口重新包裝成 V5 式中介層。