先說結論：可以接入，但不能把兩者當成同一件事

BMAD 的動態背壓，不能簡化成「Act 模式裡測試失敗就停止」。它的核心是：先辨識任務情境與影響範圍，再選擇必要流程和驗證方式；接著依據實際回饋修復或重驗，只有符合門檻後才推進下一階段。相關規則可參考 bmad-suite-v4/skills/bmad/SKILL.md:40、bmad-suite-v4/skills/bmad/SKILL.md:96 與 bmad-suite-v4/rules/bmad-core.md:118。

因此，動態背壓不只決定驗證要多嚴謹，也決定工作能以多快的節奏前進。不是每個任務都要走完整流程；測試失敗也不代表禁止修復；同樣地，也不能只因模型表示「完成了」，就一路自動推進。

Plan／Act 各自負責什麼？

以下是將背壓原則映射到 Cline Plan／Act 的建議分工，並非已確認存在的插件功能：

背壓環節	Plan 可負責	Act 可負責	程式門禁可負責
情境與影響辨識	說明任務性質、風險和驗收條件	根據實際改動檢查原先判斷是否仍適用	檢查契約是否合法；標籤本身不增加授權
流程與技能選擇	選擇必要的分析、架構或演算法資料	按需要載入實作、驗證與審查流程	即使漏調技能，也不能跳過必要門禁
驗證方式	定義所需證據及影響範圍	執行相關驗證，不盲目跑完整個專案	阻止缺少必要項目、未蒐集證據或跳過驗證的情況
一般失敗	必要時釐清問題或設計缺口	在授權範圍和預算內修復、重驗	容許修復，但不可拿失敗結果當作推進依據
風險升級	對重大取捨進行 DR／DM	發現介面漂移或反覆失敗時重新檢視	阻止未經批准擴大範圍或降低驗收標準
階段完成	定義依賴關係與階段出口	根據實際結果提出完成	核對適用證據後，才允許進入下一階段

換句話說，Plan／Act 是承載工作的模式；動態背壓則是貫穿兩者的決策與執行約束，不是某個模式額外加上的提示詞。

遇到需要重檢的情況，也不代表一定要自動切回 Plan。Act 可以先在授權範圍內做定向診斷；只有當問題涉及新的重大取捨或需要額外授權時，才交由使用者確認方向。

保留「動態」：不同任務，不同驗證

BMAD 的情境策略並非一律套用同一套重型流程，四類任務各有側重，詳見 bmad-suite-v4/skills/bmad/SKILL.md:64：

• 演算法任務：檢查演算法是否適用，以及必要的效能限制。
• 結構調整：檢查介面、所有權和跨層依賴，不必附加無關的演算法檢查。
• 缺陷修復：採取足以確認修復有效的回歸測試，不機械式地建立 ADR 或重跑完整架構分析。
• 維運工作：驗證設定、差異及必要的發佈流程，不盲目執行業務單元測試。

分類只是起始判斷，不是永久豁免。例如，看似小型的修復若改變了資料所有權，就應加強相應審查；但也不該只因改動跨越多個檔案，就強迫套用所有重型流程。

幾個容易混淆的界線尤其重要：失敗可以修復，但不能用失敗證據推進；單純儲存進度不會觸發重新測試，只有相關實作、契約或環境發生變化，對應證據才需要重驗。這與 bmad-suite-v4/rules/bmad-core.md:19 的規則一致。

Cline 原生機制能做什麼、不能替代什麼

操作審批不等於品質門禁

Cline 的自動核准設定，控制哪些工具操作可以不必每次都詢問使用者，並依工具呼叫逐項評估。8

這和 BMAD 的背壓回答的是不同問題：前者問「這次操作是否需要人工確認？」；後者問「操作是否在任務授權內、依賴是否滿足、驗證證據是否有效？」因此，自動核准不能視為品質放行；測試失敗也不應阻止已獲授權的正常修復。

忽略檔案不等於隔離執行

Cline 文件區分了自動脈絡過濾與執行前攔截，也說明可以透過工具執行前 hook 阻止特定檔案操作。7 這提供了程式化接入的方向，但不能據此推定你的 Antigravity／Cline 版本已涵蓋所有檔案工具、命令和其他副作用入口。只保護單一編輯入口，不足以宣稱已完成完整隔離。

SDK 有擴充點，不代表 IDE 插件已具備同樣能力

Cline SDK 提供生命週期與策略檢查的擴充點。6 不過，SDK 的能力不能直接當成目標 IDE 插件的實際行為證明。目標插件能否取得必要工具結果、阻止階段推進，以及 hook 故障時是否會安全停止，目前仍須核驗實際版本；不宜直接套用 SDK、CLI 或其他工具的介面假設。

程式化背壓的最小落點

與其另建一套通用控制平台，不如先打通三個關鍵邊界：

1. 執行前：檢查授權、目標範圍與依賴，阻止明確越權的操作。
2. 驗證後：取得真實結果，區分通過、可修復失敗與阻塞，並記錄證據適用的改動範圍。
3. 推進前：核對所有必要證據，確認後才允許依賴階段開始或登記完成。

只做執行前檢查，無法得知驗證結果；只在最後檢查，則可能已經執行錯誤的下一階段。因此，門禁必須涵蓋實際的推進路徑，而不只是攔截「宣布完成」的動作。

程式適合檢查路徑、依賴、預算和驗證結果；架構判斷、情境辨識及測試是否充分，仍需要技能流程與人工審查。不能把比對命令關鍵字，說成已完成完整的語意判斷。

目前 bmad-suite-v4/hooks.json:2 只是停用中的佔位設定；scripts/validate-roo-contracts.py:199 也明確只檢查命令格式，不會實際執行命令。因此，現階段能確認的是相關策略資產存在，還不能確認執行階段的強制背壓已經落地。

對實施計畫的修正重點

既有階段順序可以保留，但應把動態背壓列為 Cline 適配的核心驗收條件，而不只是文件整理工作：

• F1：統一背壓契約，明確定義情境選擇、一般修復、風險升級、證據失效與推進規則。
• F2：依實際 Cline 介面完成最小接入，並同時驗證「正確路徑能執行」及「錯誤推進會被阻止」。
• F3：待消費端相容後，再按需要遷移文件與測試；目錄整理本身不代表背壓已生效。
• F4：在實際宿主環境驗證攔截範圍、結果處理與復原行為。

這些建議對應既有計畫 PLAN-20261022-document-test-governance-01.md:87；本輪分析沒有修改該計畫，也沒有開始實作。

總結來說，動態背壓是 bmad-solo 應保留的核心策略；Cline 原生機制可提供承載與接入點，但不能取代它。兩者在原則上可相容，然而若只有載入技能與規則，沒有實際執行和推進門禁，就只能稱為方法上的適配，不能說錯誤操作已被程式阻止。本輪僅進行唯讀分析，未安裝或修改檔案，也未執行驗證。

先說結論：可以接入，但不能把兩者當成同一件事

BMAD 的動態背壓，不能簡化成「Act 模式裡測試失敗就停止」。它的核心是：先辨識任務情境與影響範圍，再選擇必要流程和驗證方式；接著依據實際回饋修復或重驗，只有符合門檻後才推進下一階段。相關規則可參考 bmad-suite-v4/skills/bmad/SKILL.md:40、bmad-suite-v4/skills/bmad/SKILL.md:96 與 bmad-suite-v4/rules/bmad-core.md:118。

因此，動態背壓不只決定驗證要多嚴謹，也決定工作能以多快的節奏前進。不是每個任務都要走完整流程；測試失敗也不代表禁止修復；同樣地，也不能只因模型表示「完成了」，就一路自動推進。

Plan／Act 各自負責什麼？

以下是將背壓原則映射到 Cline Plan／Act 的建議分工，並非已確認存在的插件功能：

背壓環節	Plan 可負責	Act 可負責	程式門禁可負責
情境與影響辨識	說明任務性質、風險和驗收條件	根據實際改動檢查原先判斷是否仍適用	檢查契約是否合法；標籤本身不增加授權
流程與技能選擇	選擇必要的分析、架構或演算法資料	按需要載入實作、驗證與審查流程	即使漏調技能，也不能跳過必要門禁
驗證方式	定義所需證據及影響範圍	執行相關驗證，不盲目跑完整個專案	阻止缺少必要項目、未蒐集證據或跳過驗證的情況
一般失敗	必要時釐清問題或設計缺口	在授權範圍和預算內修復、重驗	容許修復，但不可拿失敗結果當作推進依據
風險升級	對重大取捨進行 DR／DM	發現介面漂移或反覆失敗時重新檢視	阻止未經批准擴大範圍或降低驗收標準
階段完成	定義依賴關係與階段出口	根據實際結果提出完成	核對適用證據後，才允許進入下一階段

換句話說，Plan／Act 是承載工作的模式；動態背壓則是貫穿兩者的決策與執行約束，不是某個模式額外加上的提示詞。

遇到需要重檢的情況，也不代表一定要自動切回 Plan。Act 可以先在授權範圍內做定向診斷；只有當問題涉及新的重大取捨或需要額外授權時，才交由使用者確認方向。

保留「動態」：不同任務，不同驗證

BMAD 的情境策略並非一律套用同一套重型流程，四類任務各有側重，詳見 bmad-suite-v4/skills/bmad/SKILL.md:64：

• 演算法任務：檢查演算法是否適用，以及必要的效能限制。
• 結構調整：檢查介面、所有權和跨層依賴，不必附加無關的演算法檢查。
• 缺陷修復：採取足以確認修復有效的回歸測試，不機械式地建立 ADR 或重跑完整架構分析。
• 維運工作：驗證設定、差異及必要的發佈流程，不盲目執行業務單元測試。

分類只是起始判斷，不是永久豁免。例如，看似小型的修復若改變了資料所有權，就應加強相應審查；但也不該只因改動跨越多個檔案，就強迫套用所有重型流程。

幾個容易混淆的界線尤其重要：失敗可以修復，但不能用失敗證據推進；單純儲存進度不會觸發重新測試，只有相關實作、契約或環境發生變化，對應證據才需要重驗。這與 bmad-suite-v4/rules/bmad-core.md:19 的規則一致。

Cline 原生機制能做什麼、不能替代什麼

操作審批不等於品質門禁

Cline 的自動核准設定，控制哪些工具操作可以不必每次都詢問使用者，並依工具呼叫逐項評估。8

這和 BMAD 的背壓回答的是不同問題：前者問「這次操作是否需要人工確認？」；後者問「操作是否在任務授權內、依賴是否滿足、驗證證據是否有效？」因此，自動核准不能視為品質放行；測試失敗也不應阻止已獲授權的正常修復。

忽略檔案不等於隔離執行

Cline 文件區分了自動脈絡過濾與執行前攔截，也說明可以透過工具執行前 hook 阻止特定檔案操作。7 這提供了程式化接入的方向，但不能據此推定你的 Antigravity／Cline 版本已涵蓋所有檔案工具、命令和其他副作用入口。只保護單一編輯入口，不足以宣稱已完成完整隔離。

SDK 有擴充點，不代表 IDE 插件已具備同樣能力

Cline SDK 提供生命週期與策略檢查的擴充點。6 不過，SDK 的能力不能直接當成目標 IDE 插件的實際行為證明。目標插件能否取得必要工具結果、阻止階段推進，以及 hook 故障時是否會安全停止，目前仍須核驗實際版本；不宜直接套用 SDK、CLI 或其他工具的介面假設。

程式化背壓的最小落點

與其另建一套通用控制平台，不如先打通三個關鍵邊界：

1. 執行前：檢查授權、目標範圍與依賴，阻止明確越權的操作。
2. 驗證後：取得真實結果，區分通過、可修復失敗與阻塞，並記錄證據適用的改動範圍。
3. 推進前：核對所有必要證據，確認後才允許依賴階段開始或登記完成。

只做執行前檢查，無法得知驗證結果；只在最後檢查，則可能已經執行錯誤的下一階段。因此，門禁必須涵蓋實際的推進路徑，而不只是攔截「宣布完成」的動作。

程式適合檢查路徑、依賴、預算和驗證結果；架構判斷、情境辨識及測試是否充分，仍需要技能流程與人工審查。不能把比對命令關鍵字，說成已完成完整的語意判斷。

目前 bmad-suite-v4/hooks.json:2 只是停用中的佔位設定；scripts/validate-roo-contracts.py:199 也明確只檢查命令格式，不會實際執行命令。因此，現階段能確認的是相關策略資產存在，還不能確認執行階段的強制背壓已經落地。

對實施計畫的修正重點

既有階段順序可以保留，但應把動態背壓列為 Cline 適配的核心驗收條件，而不只是文件整理工作：

• F1：統一背壓契約，明確定義情境選擇、一般修復、風險升級、證據失效與推進規則。
• F2：依實際 Cline 介面完成最小接入，並同時驗證「正確路徑能執行」及「錯誤推進會被阻止」。
• F3：待消費端相容後，再按需要遷移文件與測試；目錄整理本身不代表背壓已生效。
• F4：在實際宿主環境驗證攔截範圍、結果處理與復原行為。

這些建議對應既有計畫 PLAN-20261022-document-test-governance-01.md:87；本輪分析沒有修改該計畫，也沒有開始實作。

總結來說，動態背壓是 bmad-solo 應保留的核心策略；Cline 原生機制可提供承載與接入點，但不能取代它。兩者在原則上可相容，然而若只有載入技能與規則，沒有實際執行和推進門禁，就只能稱為方法上的適配，不能說錯誤操作已被程式阻止。本輪僅進行唯讀分析，未安裝或修改檔案，也未執行驗證。