一個 AI 助手話「已完成」，到底代表咩？可能只係模型自稱做完；亦可能真係跑過檢查、由另一位審查者批准，再將同一份候選交畀下游。兩者差好遠。

一份 BMAD-Solo 治理草案提出，與其為每個角色建立一套獨立文件和流程，不如按端到端業務流程組織工作，再用機器回執、獨立審查和受控發布把關。要留意，今次交付只係設計草案：不代表程式已經寫好、規則已經載入，亦不代表測試或遷移已完成。

角色可以切換，權限唔會跟住升級

草案把工作分成兩個基本動作：Plan 和 Act。Plan 階段先由 Analyst 梳理目標、業務要求和驗收條件，再由 Architect 確認介面、依賴、寫入範圍及驗證方法；Act 階段則由 Coder 實施候選，最後由 Supervisor 作獨立審查及核對交付。

四個名稱代表同一條業務流程中的職責視角，並唔係四個互相獨立的 Agent。模型由 Coder 轉為 Supervisor，只係換咗工作角度，唔會因此變成真正獨立的審查者。草案建議由獨立的人類審查者，或經核實身份、權限確實隔離的審查實例批准；如果做唔到，就唔應聲稱已完成獨立審查。

分析亦分三步：先釐清業務要求，再核對資料來源和證據，最後反向推演邊界情況、失敗路徑同副作用。推演可以協助找風險，但唔可以冒充實際測試結果。

任務正本做主，其他紀錄各有分工

草案建議將任務契約放喺單一任務正本，列明目標、輸入、階段、授權、交付項目、驗收條件和所需檢查。另設焦點指針，只用來指向目前唯一的執行任務；它不應再複製一份任務進度。

其他資料亦要分清楚：機器檢查結果由真實執行器產生，獨立審查結論由受信任審批入口記錄，已發布的長期規則則寫入領域規範。測試回執、審查簽章和發布紀錄都唔可以靠任務文件入面一個「通過」字眼代替。

任務契約必須精確列出會建立或修改哪些檔案、每項驗收對應哪些檢查，以及哪些路徑禁止寫入。缺少欄位、依賴、授權或驗證證據時，應該停止相關流程，而唔係自行估一個答案。

放行要過兩道門，而且要驗同一份候選

草案將放行條件寫成：機器檢查通過，並且獨立審查批准。兩者必須同時成立，而且要指向同一個任務契約、候選版本和適用環境。缺證據或無法判斷時，都唔可以當作通過。

機器回執唔只係一個成功狀態。它應記錄實際執行的命令、退出結果、測試收集數目、必要案例有否出現、是否有必需測試被跳過，以及日誌和清理狀況。零個測試、超時、來源無法核實，或者執行程序未能確認已退出，都唔應放行。

審查批准亦要綁定候選內容、任務契約、機器回執和審查報告。候選之後一有改動，舊簽章就唔應自動套用。模型自行填寫「approved」、同一位實施者自我簽核，或者用純文字寫個審查者姓名，都不足以證明審查獨立。

因此，提示詞本身唔足以構成物理門禁。真正發布的入口需要重新核對授權、焦點、候選身份、檢查回執和審查簽章，確保交付的正正係獲批版本。若同一個人或程序可以同時改寫候選、回執和簽章，檔案摘要最多證明內容一致，唔能夠證明資料可信或審查獨立。

失敗要保留現場，唔好為咗變綠而降低標準

檢查失敗或審查拒絕時，任務應停止放行，但要保留差異、失敗回執和審查發現。草案不建議用重設整個目錄、刪除測試或覆蓋用戶改動的方式清理現場。

如果只是修正原有範圍內的問題，可以按原授權返工，再為新候選重新驗證和審查；如果改動涉及介面、驗收或寫入範圍，就要返回設計階段，修訂契約並重新批准。相反，永遠拒絕所有任務亦唔算合格：失敗後能否安全修復、重新驗證並完成合法交付，同樣要測試。

宿主設定唔等於隔離證明

草案提供 Cline 和 Roo Code 的設定方向，並建議 Plan 模式預設只讀、Act 模式只處理已獲批的候選。不過，設定檔已經保存，不代表宿主確實載入規則；模式名稱寫得清楚，也不代表其他工具入口已被阻截。

因此，還要實際核實規則載入、模式切換、未授權寫入的拒絕行為、審查身份，以及發布入口能否擋住缺證據或候選已改動的情況。未驗證的宿主功能應保留為未知，不可以當作已通過。

證據未齊，草案就唔應扮成實證

草案指出，雖然找到 AutoSwarm 的論文條目，但現有摘錄不足以獨立核對其中與任務單元及驗收公式相關的全文段落；徐直軍文章原始版本和目標宿主的實際運作方式，亦未取得足夠一手證據。因此，相關設計應視為本草案採用的規範要求，而唔係已經由上述資料全面證實的結論。1

整體而言，呢份設計最重要的提醒係：角色分工唔等於職責隔離，提示詞亦唔等於執行控制。只有任務契約、真實檢查、獨立審查和受控發布都能互相核對，AI Agent 的「完成」先有清楚、可追溯的意思。至於系統有冇真正做到，仍要等相關程式、宿主整合和實際驗收完成後先可以下結論。

一個 AI 助手話「已完成」，到底代表咩？可能只係模型自稱做完；亦可能真係跑過檢查、由另一位審查者批准，再將同一份候選交畀下游。兩者差好遠。

一份 BMAD-Solo 治理草案提出，與其為每個角色建立一套獨立文件和流程，不如按端到端業務流程組織工作，再用機器回執、獨立審查和受控發布把關。要留意，今次交付只係設計草案：不代表程式已經寫好、規則已經載入，亦不代表測試或遷移已完成。

角色可以切換，權限唔會跟住升級

草案把工作分成兩個基本動作：Plan 和 Act。Plan 階段先由 Analyst 梳理目標、業務要求和驗收條件，再由 Architect 確認介面、依賴、寫入範圍及驗證方法；Act 階段則由 Coder 實施候選，最後由 Supervisor 作獨立審查及核對交付。

四個名稱代表同一條業務流程中的職責視角，並唔係四個互相獨立的 Agent。模型由 Coder 轉為 Supervisor，只係換咗工作角度，唔會因此變成真正獨立的審查者。草案建議由獨立的人類審查者，或經核實身份、權限確實隔離的審查實例批准；如果做唔到，就唔應聲稱已完成獨立審查。

分析亦分三步：先釐清業務要求，再核對資料來源和證據，最後反向推演邊界情況、失敗路徑同副作用。推演可以協助找風險，但唔可以冒充實際測試結果。

任務正本做主，其他紀錄各有分工

草案建議將任務契約放喺單一任務正本，列明目標、輸入、階段、授權、交付項目、驗收條件和所需檢查。另設焦點指針，只用來指向目前唯一的執行任務；它不應再複製一份任務進度。

其他資料亦要分清楚：機器檢查結果由真實執行器產生，獨立審查結論由受信任審批入口記錄，已發布的長期規則則寫入領域規範。測試回執、審查簽章和發布紀錄都唔可以靠任務文件入面一個「通過」字眼代替。

任務契約必須精確列出會建立或修改哪些檔案、每項驗收對應哪些檢查，以及哪些路徑禁止寫入。缺少欄位、依賴、授權或驗證證據時，應該停止相關流程，而唔係自行估一個答案。

放行要過兩道門，而且要驗同一份候選

草案將放行條件寫成：機器檢查通過，並且獨立審查批准。兩者必須同時成立，而且要指向同一個任務契約、候選版本和適用環境。缺證據或無法判斷時，都唔可以當作通過。

機器回執唔只係一個成功狀態。它應記錄實際執行的命令、退出結果、測試收集數目、必要案例有否出現、是否有必需測試被跳過，以及日誌和清理狀況。零個測試、超時、來源無法核實，或者執行程序未能確認已退出，都唔應放行。

審查批准亦要綁定候選內容、任務契約、機器回執和審查報告。候選之後一有改動，舊簽章就唔應自動套用。模型自行填寫「approved」、同一位實施者自我簽核，或者用純文字寫個審查者姓名，都不足以證明審查獨立。

因此，提示詞本身唔足以構成物理門禁。真正發布的入口需要重新核對授權、焦點、候選身份、檢查回執和審查簽章，確保交付的正正係獲批版本。若同一個人或程序可以同時改寫候選、回執和簽章，檔案摘要最多證明內容一致，唔能夠證明資料可信或審查獨立。

失敗要保留現場，唔好為咗變綠而降低標準

檢查失敗或審查拒絕時，任務應停止放行，但要保留差異、失敗回執和審查發現。草案不建議用重設整個目錄、刪除測試或覆蓋用戶改動的方式清理現場。

如果只是修正原有範圍內的問題，可以按原授權返工，再為新候選重新驗證和審查；如果改動涉及介面、驗收或寫入範圍，就要返回設計階段，修訂契約並重新批准。相反，永遠拒絕所有任務亦唔算合格：失敗後能否安全修復、重新驗證並完成合法交付，同樣要測試。

宿主設定唔等於隔離證明

草案提供 Cline 和 Roo Code 的設定方向，並建議 Plan 模式預設只讀、Act 模式只處理已獲批的候選。不過，設定檔已經保存，不代表宿主確實載入規則；模式名稱寫得清楚，也不代表其他工具入口已被阻截。

因此，還要實際核實規則載入、模式切換、未授權寫入的拒絕行為、審查身份，以及發布入口能否擋住缺證據或候選已改動的情況。未驗證的宿主功能應保留為未知，不可以當作已通過。

證據未齊，草案就唔應扮成實證

草案指出，雖然找到 AutoSwarm 的論文條目，但現有摘錄不足以獨立核對其中與任務單元及驗收公式相關的全文段落；徐直軍文章原始版本和目標宿主的實際運作方式，亦未取得足夠一手證據。因此，相關設計應視為本草案採用的規範要求，而唔係已經由上述資料全面證實的結論。1

整體而言，呢份設計最重要的提醒係：角色分工唔等於職責隔離，提示詞亦唔等於執行控制。只有任務契約、真實檢查、獨立審查和受控發布都能互相核對，AI Agent 的「完成」先有清楚、可追溯的意思。至於系統有冇真正做到，仍要等相關程式、宿主整合和實際驗收完成後先可以下結論。