先講結論：方向成立，V6 未算 ready

建議將 V5 執行層凍結，唔好再靠加測試、加鎖或加狀態檔延長佢嘅壽命。分析層則可以保留，包括三遍閱讀方法、ADR 決策方式、授權界線同歷史證據。

V6 可以朝住「上游編排器＋單一 Cline 執行框架＋外部驗證＋文字經驗」簡化。不過，呢個只係目標架構，唔代表各部分已經接通。本次資料未證明 Cline 符合 bmad-loop 所需嘅工作階段契約，亦未實測獨立盲審、Jev 門禁或本地 IDE 斷線後 VPS 繼續完成新工作階段。

所以，第一個工程目標唔應該係再寫一個控制器，而係先證明現有編排器真係可以安全地啟動、驗證、審查同提交一個 Story。

V5 問題：記錄周全，唔等於任務閉環

控制儲存層做得多，但未接通執行

目前讀到嘅 bmad_control_store.py 有 315 行，係追加式檔案記錄存放，唔係 SQL 資料庫。所謂歷史版本有 1728 行，本次未有證據核實。

程式處理目錄身份、檔案權限、鎖、請求版本、歷史連續性、容量預算、寫入後回讀同內容指紋；但其回傳結果亦清楚列明，唔會認證人手身份、啟動任務、消耗執行權，亦唔會保存任務進度。

問題唔係安全檢查本身無用，而係系統未證明「人作決定」到「任務真係完成」嘅閉環，就先投放大量工程去建置通用儲存協議。完整記錄唔等於完成工作。

亦唔應該單憑程式碼長，就斷言佢造成上下文爆炸；要證明上下文負擔，仲需要知道相關檔案有冇反覆放入模型輸入。本次資料不足以建立呢個因果關係。程式使用非阻塞獨占鎖，撞鎖會拒絕操作；「可能阻礙推進」同「已造成死鎖」亦係兩回事，後者需要等待鏈或實際日誌證明。

執行器限制技能載入，但事故指控要有證據

V5 執行器設定明確關閉技能、擴充、MCP、提示模板同上下文檔案。咁做會令佢無法原生發現 BMAD 技能；如果仍要求執行 BMAD 流程，就要由外围補回技能內容、執行依賴同版本對應。

BMAD 嘅自動建構入口亦唔只係一段提示詞，仲依賴專案內嘅渲染入口、技能目錄同明確失敗處理。將幾段內容複製入提示詞，唔足以證明上游技能契約已經滿足。

不過，舊 ADR 提過雙執行器、審批偷換等風險，只能證明呢啲風險曾被識別，唔能夠當成「雙 Agent 嵌套事故已發生」嘅證據。

231 項舊測試通過，唔代表遠端產品閉環通過

現有計劃記錄咗用戶確認嘅 231 項歷史專屬單元測試通過；同一份計劃亦指出，真實後端、獨立認證、客戶端關閉後開始新步驟，以及遠端閉環仍未驗證。本次亦無重新執行測試。

單元測試可以驗證鎖、版本、預算同路徑處理；模擬後端可以測試失敗回饋。呢啲結果唔能夠直接證明目標 CLI 可以正確執行技能、模型工具呼叫可靠、客戶端離線後 VPS 會繼續開新步驟，或者審核、停止、提交及恢復已經完整運作。

**沉沒成本處理建議：**保留方法同歷史證據，凍結 V5 執行層。舊測試可以留作歷史資產，但唔應該自動列入 V6 預設回歸，更唔可以當作 V6 綠燈。

V6 建議：五個元件，各自只做一件事

元件	建議只負責	唔應該兼做
bmad-loop	選 Story、管理會話、驗證、重試、提交同執行狀態	另外再建一套外層循環或調度器
Cline CLI	喺指定工作區執行一次開發或審核工作	第二套計劃調度、後台 Hub 或團隊循環
BMAD-METHOD	提供角色、規劃、建構及審查工作流	複製成私有技能分支，或每次載入全部角色
Jev 門禁	評估候選變更是否符合語義範圍，分類失敗	改程式、選下一個 Story，或蓋過測試結果
文字經驗	保存有證據支持、適用範圍清楚嘅教訓	改變授權、驗收標準或硬性門禁

bmad-loop：重用上游循環，唔好再造一個

「控制循環入面冇 LLM」唔代表系統唔用模型；意思係由程式決定選邊個 Story、重試幾多次、過唔過門禁同幾時完成，模型則喺新會話入面負責編碼或審查。

有幾個上游預設行為要特別留意：獨立審核未必每個 Story 都強制觸發；部分審核預算用盡嘅路徑仍可能容許提交；Story Token 上限亦屬告警性預算，唔等於硬停機。V6 如要強制盲審或失敗即停，應透過上游門禁接縫處理，唔係複製另一份狀態機。

Cline：兩個 Profile，唔係兩個總控

建議設 DEV 同 REVIEW 兩個設定身份，各自使用隔離設定及會話目錄：DEV 有權喺獲批 Story 工作區寫入；REVIEW 只讀驗收要求、凍結候選變更同相關測試證據。

Sonnet 5.5 同 GPT-6-Sol 可以先作為目標模型角色；但實際模型 ID、供應商協定、認證同費用預算，必須以非秘密設定及真實呼叫回執核實，唔好將角色名稱當成已驗證嘅服務型號。

目前最大阻塞係：bmad-loop 列出嘅內置 CLI 未包括 Cline；通用適配器又需要生命週期 Hooks，而已知 Hook 方言未列出 Cline。現有安裝說明有工作目錄、隔離狀態同模型選項，仍不足以證明佢符合編排器所需嘅事件契約。

正式接線前，至少要證明新會話可以啟動並退出、開始及完成事件有可核對身份、普通訊息唔會被誤認為任務完成、取消後工具程序會停止，以及用量讀唔到時會明確顯示未知。若適配唔到，就應停喺呢個邊界，唔好另包一個自製調度器。

BMAD、Jev 同 Harness²：用其所長，唔好過度承諾

BMAD 技能應按 Story 需要原生載入；上游來源保持唯讀，並先完成專案初始化及渲染依賴設定。目錄數量唔等於可直接呼叫嘅技能數量，亦唔應該將所有角色內容一次過塞入每個任務。

Jev 嘅定位係接收狀態同類型化問題，再回傳結構化答案；佢唔係寫程式或聊天嘅編碼 Agent。12 因此可以考慮將佢用作外部語義評估，但呢個定位本身唔能夠證明佢一定判得準每一種越界或測試根因。

門禁建議分兩層：程式先確定性檢查所有候選檔案，包括新增檔案，核對批准路徑；再由 Jev 評估語義範圍同「實作問題／環境問題／未知」。路徑越界直接失敗，語義結果未知亦唔放行。可將退出碼定為 0＝通過、1＝違規、75＝服務或環境不可用；實際請求格式同資料傳送範圍仍要工程核實。

外部門禁喺程式已經寫入之後先執行，唔可以撤銷先前副作用。Worktree 只隔離程式碼變更，唔會自動隔離同一帳戶下嘅其他程序或生產憑證，所以權限同憑證管理仍然重要。

Harness² 談及任務層及跨任務兩層改進，研究資料亦將佢描述為遞歸式 harness 改進方法。10 V6 MVP 可以只借用「將有證據嘅教訓寫入文字檔，供下一個任務參考」呢個想法；唔應該聲稱完整重現 Harness²，亦唔需要安裝另一套執行框架。

每條經驗只記觸發條件、適用範圍、一條可執行教訓、來源 Story 同反例。冇新教訓就唔使硬寫；未驗證嘅觀察亦唔好包裝成規律。

一個 Story 應該點樣行

以「避免重複提交訂單」為例，前提係產品已明確行為要求，並批准修改相關實作及測試：

1. bmad-loop 揀出已獲批准嘅 Story，檢查依賴，建立 Story 專屬 Worktree。
2. 開一個全新 Cline DEV 會話，提供 Story、驗收標準、相關經驗同必要源碼；唔接續舊聊天。
3. Agent 完成後產生候選變更；會話停止只代表 Agent 停咗，唔代表 Story 已通過驗收。
4. 外部檢查所有變更檔案、執行相關測試，再做 Jev 語義檢查；任何必需門禁失敗都唔提交。
5. 凍結候選內容身份、驗收標準、測試命令同真實退出結果，並將新增檔案一併納入審核。
6. 開一個獨立 Cline REVIEW 會話，只提供候選同證據，唔提供開發聊天或自我辯解。審核結果要清楚係通過、拒絕定未知，並綁定同一個候選版本。
7. 從實際反例提煉經驗；如果業務內容其後有改動，舊審核即失效。
8. 最終重驗候選身份、測試、Jev 結果同盲審，再由上游編排器提交及合併。
9. 下一個 Story 用新會話同新 Worktree，讀取已提交、適用範圍清楚嘅經驗。

審核會話「完成」唔等於審核通過。提交門禁要檢查真實裁決及候選綁定，而且必須失敗關閉；亦唔應將「審核超時」當成通過。

由凍結到 MVP：建議分階段驗收

**第一步：凍結 V5。**保留未完成事項同歷史回執，清楚標記執行層停止推進；唔好將未完成項目勾成完成，亦唔好把舊測試改名為 V6 驗證。另開 V6 新計劃同新 ADR，唔用覆寫舊文件嚟營造已完成升級嘅印象。文件凍結亦唔等於宿主程序已經停止；停止舊入口同清理在途工作，需要另外授權及確認。

**第二步：先做 Cline 適配探測。**核實實際啟動方式、會話身份、完成事件、取消行為同用量讀取。適配未過，唔好啟動真實 Story。

**第三步：接上失敗關閉門禁。**配置必需嘅路徑檢查、測試、Jev 同獨立盲審；逐項測試違規、未知、服務不可用、審核超時及候選變更後會唔會阻止提交。插件預設可能容許錯誤時放行，必需門禁要明確設為失敗即停。

**第四步：先做一個獲批 Story 嘅冒煙測試。**另外驗證本地 IDE 或 SSH 斷線之後，VPS 有冇產生新嘅開發、驗證或審核事件。單係 tmux 仲存在，唔算完成斷線測試。

**第五步：再做第二個 Story。**一個 Story 可以測執行鏈，但唔足以證明「第一個任務嘅經驗會喺下一個新會話生效」。完整經驗閉環至少要驗證下一個任務有冇讀到已提交嘅相關教訓。

MVP 通過條件

• 一個獲批 Story 真正完成開發、必要測試、Jev、獨立盲審及上游提交。
• 本地客戶端斷線後，VPS 有新工作階段及可核對回執；唔係只剩下一個 tmux 視窗。
• 越界、測試失敗、審核拒絕或未知、Jev 不可用，都唔會進入提交。
• 候選在審核後改動，原有批准即失效。
• 停止操作後，確認會話及工具程序已結束，失敗現場亦有保留。
• 無額外自製調度器、資料庫、舊執行器依賴或第二份運行進度帳本。

最終判斷：V5 執行層應停止加碼；V6 精簡方向合理，但目前仍係有條件嘅架構方案，唔係已可上線嘅系統。下一個最有價值嘅動作，係證明 Cline 工作階段契約同失敗關閉嘅盲審提交鏈，而唔係再寫一層中介程式。

先講結論：方向成立，V6 未算 ready

建議將 V5 執行層凍結，唔好再靠加測試、加鎖或加狀態檔延長佢嘅壽命。分析層則可以保留，包括三遍閱讀方法、ADR 決策方式、授權界線同歷史證據。

V6 可以朝住「上游編排器＋單一 Cline 執行框架＋外部驗證＋文字經驗」簡化。不過，呢個只係目標架構，唔代表各部分已經接通。本次資料未證明 Cline 符合 bmad-loop 所需嘅工作階段契約，亦未實測獨立盲審、Jev 門禁或本地 IDE 斷線後 VPS 繼續完成新工作階段。

所以，第一個工程目標唔應該係再寫一個控制器，而係先證明現有編排器真係可以安全地啟動、驗證、審查同提交一個 Story。

V5 問題：記錄周全，唔等於任務閉環

控制儲存層做得多，但未接通執行

目前讀到嘅 bmad_control_store.py 有 315 行，係追加式檔案記錄存放，唔係 SQL 資料庫。所謂歷史版本有 1728 行，本次未有證據核實。

程式處理目錄身份、檔案權限、鎖、請求版本、歷史連續性、容量預算、寫入後回讀同內容指紋；但其回傳結果亦清楚列明，唔會認證人手身份、啟動任務、消耗執行權，亦唔會保存任務進度。

問題唔係安全檢查本身無用，而係系統未證明「人作決定」到「任務真係完成」嘅閉環，就先投放大量工程去建置通用儲存協議。完整記錄唔等於完成工作。

亦唔應該單憑程式碼長，就斷言佢造成上下文爆炸；要證明上下文負擔，仲需要知道相關檔案有冇反覆放入模型輸入。本次資料不足以建立呢個因果關係。程式使用非阻塞獨占鎖，撞鎖會拒絕操作；「可能阻礙推進」同「已造成死鎖」亦係兩回事，後者需要等待鏈或實際日誌證明。

執行器限制技能載入，但事故指控要有證據

V5 執行器設定明確關閉技能、擴充、MCP、提示模板同上下文檔案。咁做會令佢無法原生發現 BMAD 技能；如果仍要求執行 BMAD 流程，就要由外围補回技能內容、執行依賴同版本對應。

BMAD 嘅自動建構入口亦唔只係一段提示詞，仲依賴專案內嘅渲染入口、技能目錄同明確失敗處理。將幾段內容複製入提示詞，唔足以證明上游技能契約已經滿足。

不過，舊 ADR 提過雙執行器、審批偷換等風險，只能證明呢啲風險曾被識別，唔能夠當成「雙 Agent 嵌套事故已發生」嘅證據。

231 項舊測試通過，唔代表遠端產品閉環通過

現有計劃記錄咗用戶確認嘅 231 項歷史專屬單元測試通過；同一份計劃亦指出，真實後端、獨立認證、客戶端關閉後開始新步驟，以及遠端閉環仍未驗證。本次亦無重新執行測試。

單元測試可以驗證鎖、版本、預算同路徑處理；模擬後端可以測試失敗回饋。呢啲結果唔能夠直接證明目標 CLI 可以正確執行技能、模型工具呼叫可靠、客戶端離線後 VPS 會繼續開新步驟，或者審核、停止、提交及恢復已經完整運作。

**沉沒成本處理建議：**保留方法同歷史證據，凍結 V5 執行層。舊測試可以留作歷史資產，但唔應該自動列入 V6 預設回歸，更唔可以當作 V6 綠燈。

V6 建議：五個元件，各自只做一件事

元件	建議只負責	唔應該兼做
bmad-loop	選 Story、管理會話、驗證、重試、提交同執行狀態	另外再建一套外層循環或調度器
Cline CLI	喺指定工作區執行一次開發或審核工作	第二套計劃調度、後台 Hub 或團隊循環
BMAD-METHOD	提供角色、規劃、建構及審查工作流	複製成私有技能分支，或每次載入全部角色
Jev 門禁	評估候選變更是否符合語義範圍，分類失敗	改程式、選下一個 Story，或蓋過測試結果
文字經驗	保存有證據支持、適用範圍清楚嘅教訓	改變授權、驗收標準或硬性門禁

bmad-loop：重用上游循環，唔好再造一個

「控制循環入面冇 LLM」唔代表系統唔用模型；意思係由程式決定選邊個 Story、重試幾多次、過唔過門禁同幾時完成，模型則喺新會話入面負責編碼或審查。

有幾個上游預設行為要特別留意：獨立審核未必每個 Story 都強制觸發；部分審核預算用盡嘅路徑仍可能容許提交；Story Token 上限亦屬告警性預算，唔等於硬停機。V6 如要強制盲審或失敗即停，應透過上游門禁接縫處理，唔係複製另一份狀態機。

Cline：兩個 Profile，唔係兩個總控

建議設 DEV 同 REVIEW 兩個設定身份，各自使用隔離設定及會話目錄：DEV 有權喺獲批 Story 工作區寫入；REVIEW 只讀驗收要求、凍結候選變更同相關測試證據。

Sonnet 5.5 同 GPT-6-Sol 可以先作為目標模型角色；但實際模型 ID、供應商協定、認證同費用預算，必須以非秘密設定及真實呼叫回執核實，唔好將角色名稱當成已驗證嘅服務型號。

目前最大阻塞係：bmad-loop 列出嘅內置 CLI 未包括 Cline；通用適配器又需要生命週期 Hooks，而已知 Hook 方言未列出 Cline。現有安裝說明有工作目錄、隔離狀態同模型選項，仍不足以證明佢符合編排器所需嘅事件契約。

正式接線前，至少要證明新會話可以啟動並退出、開始及完成事件有可核對身份、普通訊息唔會被誤認為任務完成、取消後工具程序會停止，以及用量讀唔到時會明確顯示未知。若適配唔到，就應停喺呢個邊界，唔好另包一個自製調度器。

BMAD、Jev 同 Harness²：用其所長，唔好過度承諾

BMAD 技能應按 Story 需要原生載入；上游來源保持唯讀，並先完成專案初始化及渲染依賴設定。目錄數量唔等於可直接呼叫嘅技能數量，亦唔應該將所有角色內容一次過塞入每個任務。

Jev 嘅定位係接收狀態同類型化問題，再回傳結構化答案；佢唔係寫程式或聊天嘅編碼 Agent。12 因此可以考慮將佢用作外部語義評估，但呢個定位本身唔能夠證明佢一定判得準每一種越界或測試根因。

門禁建議分兩層：程式先確定性檢查所有候選檔案，包括新增檔案，核對批准路徑；再由 Jev 評估語義範圍同「實作問題／環境問題／未知」。路徑越界直接失敗，語義結果未知亦唔放行。可將退出碼定為 0＝通過、1＝違規、75＝服務或環境不可用；實際請求格式同資料傳送範圍仍要工程核實。

外部門禁喺程式已經寫入之後先執行，唔可以撤銷先前副作用。Worktree 只隔離程式碼變更，唔會自動隔離同一帳戶下嘅其他程序或生產憑證，所以權限同憑證管理仍然重要。

Harness² 談及任務層及跨任務兩層改進，研究資料亦將佢描述為遞歸式 harness 改進方法。10 V6 MVP 可以只借用「將有證據嘅教訓寫入文字檔，供下一個任務參考」呢個想法；唔應該聲稱完整重現 Harness²，亦唔需要安裝另一套執行框架。

每條經驗只記觸發條件、適用範圍、一條可執行教訓、來源 Story 同反例。冇新教訓就唔使硬寫；未驗證嘅觀察亦唔好包裝成規律。

一個 Story 應該點樣行

以「避免重複提交訂單」為例，前提係產品已明確行為要求，並批准修改相關實作及測試：

1. bmad-loop 揀出已獲批准嘅 Story，檢查依賴，建立 Story 專屬 Worktree。
2. 開一個全新 Cline DEV 會話，提供 Story、驗收標準、相關經驗同必要源碼；唔接續舊聊天。
3. Agent 完成後產生候選變更；會話停止只代表 Agent 停咗，唔代表 Story 已通過驗收。
4. 外部檢查所有變更檔案、執行相關測試，再做 Jev 語義檢查；任何必需門禁失敗都唔提交。
5. 凍結候選內容身份、驗收標準、測試命令同真實退出結果，並將新增檔案一併納入審核。
6. 開一個獨立 Cline REVIEW 會話，只提供候選同證據，唔提供開發聊天或自我辯解。審核結果要清楚係通過、拒絕定未知，並綁定同一個候選版本。
7. 從實際反例提煉經驗；如果業務內容其後有改動，舊審核即失效。
8. 最終重驗候選身份、測試、Jev 結果同盲審，再由上游編排器提交及合併。
9. 下一個 Story 用新會話同新 Worktree，讀取已提交、適用範圍清楚嘅經驗。

審核會話「完成」唔等於審核通過。提交門禁要檢查真實裁決及候選綁定，而且必須失敗關閉；亦唔應將「審核超時」當成通過。

由凍結到 MVP：建議分階段驗收

**第一步：凍結 V5。**保留未完成事項同歷史回執，清楚標記執行層停止推進；唔好將未完成項目勾成完成，亦唔好把舊測試改名為 V6 驗證。另開 V6 新計劃同新 ADR，唔用覆寫舊文件嚟營造已完成升級嘅印象。文件凍結亦唔等於宿主程序已經停止；停止舊入口同清理在途工作，需要另外授權及確認。

**第二步：先做 Cline 適配探測。**核實實際啟動方式、會話身份、完成事件、取消行為同用量讀取。適配未過，唔好啟動真實 Story。

**第三步：接上失敗關閉門禁。**配置必需嘅路徑檢查、測試、Jev 同獨立盲審；逐項測試違規、未知、服務不可用、審核超時及候選變更後會唔會阻止提交。插件預設可能容許錯誤時放行，必需門禁要明確設為失敗即停。

**第四步：先做一個獲批 Story 嘅冒煙測試。**另外驗證本地 IDE 或 SSH 斷線之後，VPS 有冇產生新嘅開發、驗證或審核事件。單係 tmux 仲存在，唔算完成斷線測試。

**第五步：再做第二個 Story。**一個 Story 可以測執行鏈，但唔足以證明「第一個任務嘅經驗會喺下一個新會話生效」。完整經驗閉環至少要驗證下一個任務有冇讀到已提交嘅相關教訓。

MVP 通過條件

• 一個獲批 Story 真正完成開發、必要測試、Jev、獨立盲審及上游提交。
• 本地客戶端斷線後，VPS 有新工作階段及可核對回執；唔係只剩下一個 tmux 視窗。
• 越界、測試失敗、審核拒絕或未知、Jev 不可用，都唔會進入提交。
• 候選在審核後改動，原有批准即失效。
• 停止操作後，確認會話及工具程序已結束，失敗現場亦有保留。
• 無額外自製調度器、資料庫、舊執行器依賴或第二份運行進度帳本。

最終判斷：V5 執行層應停止加碼；V6 精簡方向合理，但目前仍係有條件嘅架構方案，唔係已可上線嘅系統。下一個最有價值嘅動作，係證明 Cline 工作階段契約同失敗關閉嘅盲審提交鏈，而唔係再寫一層中介程式。