先講結論：唔使二揀一，但要避免兩套流程互相踩界

Plan／Act 同 ana-solo、bmad-solo 可以一齊用，前提係採用「原生宿主能力＋方法論技能＋單一項目契約＋程式門禁」呢種分層方式，而唔係將兩套完整提示詞原封不動疊埋。

建議次序係：先定好最基本嘅治理契約，再做 Cline 薄適配，之後分批遷移文件同測試，最後喺真實部署環境驗收。唔需要等到所有目錄整理好晒先開始。

文件治理重要，但單靠佢未夠

設計取捨應該跟住一個目標：令正確做法更容易執行；對於可以明確判斷嘅錯誤，就喺產生副作用或推進階段之前，由程式攔截。

而家仍有兩個程序化缺口：

• 現有 hooks 只係停用嘅佔位設定，未有實際攔截邏輯。
• 計劃驗證器會檢查中繼資料同命令格式，但說明中亦列明限制：佢唔會執行命令，亦唔係 Shell 安全解析器。即係話，靜態檢查本身阻止唔到執行時越權，亦未必識別到虛報完成。

所以，統一文件命名同規則可以減少歧義，但唔足以確保錯誤會被程式擋住。要做到呢點，仲需要喺實際工具執行同階段推進嘅入口加上可驗證門禁。

各層分工：一層做一件事

層次	建議負責	唔應該重複負責
Cline 原生宿主	模式互動、工具執行、審批，以及可用嘅上下文機制	重新定義項目驗收標準同方法論
ana-solo	三遍閱讀、DM 候選比較、DR 反向審查同收斂裁決	再造一套 Plan 模式
bmad-solo	判斷任務場景、拆分工作、揀相關驗證方式，以及處理失敗背壓	再造一套 Act 模式，或者第二本進度帳
項目契約	訂明當前規範、計劃、驗收、測試同證據責任	複製整套全局方法論或所有歷史紀錄
程式門禁	檢查授權範圍、受控操作同階段證據	扮到可以自動判斷所有架構決策啱唔啱

Cline 官方將 Plan／Act 定位為探索規劃同執行兩個模式；工具文件亦列出技能呼叫能力，不過明確指出由模型決定呼叫邊個工具。63 換句話講，支援呼叫技能，唔代表一轉模式就必定會叫指定技能。

實際配合可以咁做：

• Plan 預設負責分析；按任務風險使用三遍閱讀、DM 同 DR。簡單查詢唔使硬性做完整研究或者留下正式產物。
• Act 預設負責工程執行；按明確需求或已獲批准嘅方案做事。複雜工作拆成 Epic／Task；範圍清楚嘅小修正就保留輕量流程。
• 如果目標版本支援原生上下文壓縮或檢查清單，可以用佢哋承載同展示資訊；但唔好因此多建一份事實來源、驗收清單或進度帳。
• 技能路由係幫模型搵到合適流程；執行門禁就獨立決定操作准唔准做。漏咗叫技能，唔可以變成越權執行嘅後門。
• 場景標記只係用嚟揀驗證方式，唔係權限令牌；唔可以靠改標記，將必要回歸測試降級做配置檢查。

Plan 模式下寫好嘅內容亦要分清界線：Cline 官方對 Plan 嘅定位係唔會改動檔案。6 建議獲用戶批准後，先由 Act 按指定範圍保存文件；保存分析文件唔應該順手變成程式實作。

要先修嘅係規則衝突，唔止係目錄

而家已經搵到幾個上下層規則互相唔一致嘅位置：

• DM 參考文件仍要求固定權重同候選數量，再按最高分裁決，見裁決要求。呢個做法同「證據不足時唔好虛構評分、硬性門檻優先」唔一致。
• 能力對照文件要求所有中大型編碼任務預檢，部分產物亦列作必需；開發角色文件再要求預檢通過先可以實施。但構建流程已講明，唔應該將重型規劃機械套用喺缺陷修復同運維工作上。

如果自動路由會載入呢啲文件，就可能重新帶返核心規則已經取消嘅限制。因此 F1 唔可以只檢查頂層技能，仲要睇埋相關嘅下層文件同路徑消費者；至於超出現有批准範圍嘅改動，仍然要先確認。

另外要分清楚：Cline 喺單次會話入面嘅規劃，唔應該自動變成另一份項目執行計劃。項目只綁定一份已獲批准嘅契約；原生清單可以記錄當前進度，但文件計劃唔需要逐輪複製嗰份狀態。

DM：比較三種推行次序

今次冇可靠嘅成本量度，所以唔用虛構分數作比較。

做法	主要好處	主要風險	判斷
搬晒所有文件，之後先適配 Cline	最後目錄較一致	宿主介面未驗證就大規模搬遷，容易返工	不建議
先完整部署 Cline，再做治理	較早有實際使用體驗	將現有規則衝突帶入新宿主，之後可能要重做適配	不建議作正式次序
最小治理 → 薄適配 → 分批遷移 → 真實驗收	先處理語義衝突，再驗證各路徑消費者，遷移範圍較易控制	要清楚訂出每階段嘅出口條件	有條件建議

第三種做法同現有獨立計劃嘅 F1 至 F4 次序一致，唔需要靜靜雞改寫計劃：

1. **F1：**先統一職責、產物同狀態由邊度管理；修正已發現嘅規則衝突，並檢查路徑消費者。暫時唔搬目錄。
2. **F2：**核實 Cline 版本後，做技能同規則嘅薄適配、項目內隔離測試，並講清楚實際可以接入邊啲程序門禁。
3. **F3：**等消費者確認相容，再按已批准清單分批遷移文件、測試同證據；唔係一次過搬晒，亦唔可以削弱白盒測試。
4. **F4：**喺真實 Antigravity／Cline 宿主驗收規則載入、模式切換、審批、拒絕行為同復原流程。

Cline 介面嘅一手資料，只讀研究可以同 F1 並行；但安裝插件、寫入真實配置同啟動宿主，就唔係只讀研究。如果想提早做真實宿主試點，就要明確調整階段依賴同授權，唔好當咗 F2 自動包括呢啲工作。

DR：由反例推返必要門禁

• **壓縮上下文後漏咗未完成工作：**要由綁定契約同唯一進度入口恢復必要資訊；摘要唔可以取代原始驗收證據。
• **Act 保存分析文件時順手改程式：**文件保存同工程實施要有唔同授權範圍；執行入口應檢查實際目標，唔可以只睇模式名稱。
• **模型將失敗 Task 標記為完成：**推進階段前要檢查對應範圍嘅實際結果。非零退出、逾時、零項目被收集、必需項目被跳過，或者缺少證據，都唔應該當通過。
• **檔案工具受限，但命令、外部工具或子任務仍可寫入：**逐一確認所有已啟用嘅副作用入口有冇受到控制；未覆蓋嘅入口要限制或停用。只攔截一個編輯工具，唔足以聲稱已經隔離。
• **搬目錄後測試唔再被發現：**驗收要檢查測試發現入口、必要斷言、引用同語言封裝；成功搬到檔案，唔等於驗收完成。

Cline 官方文件有介紹透過工具執行前嘅 hook 加強存取限制。4 不過，目標 IDE 版本嘅模式資訊、實際攔截範圍同失敗處理方式，仍然需要查證；唔可以單憑 hook 嘅名稱或者設定存在，就當作執行時保證。

程式門禁應該優先處理可以可靠判斷嘅事項，例如目標路徑、授權範圍、契約格式、依賴關係同實際退出結果。測試夠唔夠、架構啱唔啱，以及 DR／DM 判斷得好唔好，仍需要模型同人一齊審查；唔好將所有判斷都扮成可以自動完成。

最終建議

• **能力共存：**有條件可行；採用分層分工同單一事實來源，唔好堆疊兩套完整提示詞。
• **推行次序：**先治理最小契約，唔使先搬晒所有文件；之後按既有 F2 至 F4 次序做適配、遷移同驗收。
• **下一步界線：**現有計劃嘅 F1 係第一個等待授權嘅階段，見審批狀態。今次發現應納入之後確認嘅工作範圍；唔好另開平行計劃，亦唔好覆蓋舊任務。

今次只完成咗唯讀裁決；冇修改 ADR、計劃、技能或生產文件，亦冇執行終端命令、測試、hook 或部署。

先講結論：唔使二揀一，但要避免兩套流程互相踩界

Plan／Act 同 ana-solo、bmad-solo 可以一齊用，前提係採用「原生宿主能力＋方法論技能＋單一項目契約＋程式門禁」呢種分層方式，而唔係將兩套完整提示詞原封不動疊埋。

建議次序係：先定好最基本嘅治理契約，再做 Cline 薄適配，之後分批遷移文件同測試，最後喺真實部署環境驗收。唔需要等到所有目錄整理好晒先開始。

文件治理重要，但單靠佢未夠

設計取捨應該跟住一個目標：令正確做法更容易執行；對於可以明確判斷嘅錯誤，就喺產生副作用或推進階段之前，由程式攔截。

而家仍有兩個程序化缺口：

• 現有 hooks 只係停用嘅佔位設定，未有實際攔截邏輯。
• 計劃驗證器會檢查中繼資料同命令格式，但說明中亦列明限制：佢唔會執行命令，亦唔係 Shell 安全解析器。即係話，靜態檢查本身阻止唔到執行時越權，亦未必識別到虛報完成。

所以，統一文件命名同規則可以減少歧義，但唔足以確保錯誤會被程式擋住。要做到呢點，仲需要喺實際工具執行同階段推進嘅入口加上可驗證門禁。

各層分工：一層做一件事

層次	建議負責	唔應該重複負責
Cline 原生宿主	模式互動、工具執行、審批，以及可用嘅上下文機制	重新定義項目驗收標準同方法論
ana-solo	三遍閱讀、DM 候選比較、DR 反向審查同收斂裁決	再造一套 Plan 模式
bmad-solo	判斷任務場景、拆分工作、揀相關驗證方式，以及處理失敗背壓	再造一套 Act 模式，或者第二本進度帳
項目契約	訂明當前規範、計劃、驗收、測試同證據責任	複製整套全局方法論或所有歷史紀錄
程式門禁	檢查授權範圍、受控操作同階段證據	扮到可以自動判斷所有架構決策啱唔啱

Cline 官方將 Plan／Act 定位為探索規劃同執行兩個模式；工具文件亦列出技能呼叫能力，不過明確指出由模型決定呼叫邊個工具。63 換句話講，支援呼叫技能，唔代表一轉模式就必定會叫指定技能。

實際配合可以咁做：

• Plan 預設負責分析；按任務風險使用三遍閱讀、DM 同 DR。簡單查詢唔使硬性做完整研究或者留下正式產物。
• Act 預設負責工程執行；按明確需求或已獲批准嘅方案做事。複雜工作拆成 Epic／Task；範圍清楚嘅小修正就保留輕量流程。
• 如果目標版本支援原生上下文壓縮或檢查清單，可以用佢哋承載同展示資訊；但唔好因此多建一份事實來源、驗收清單或進度帳。
• 技能路由係幫模型搵到合適流程；執行門禁就獨立決定操作准唔准做。漏咗叫技能，唔可以變成越權執行嘅後門。
• 場景標記只係用嚟揀驗證方式，唔係權限令牌；唔可以靠改標記，將必要回歸測試降級做配置檢查。

Plan 模式下寫好嘅內容亦要分清界線：Cline 官方對 Plan 嘅定位係唔會改動檔案。6 建議獲用戶批准後，先由 Act 按指定範圍保存文件；保存分析文件唔應該順手變成程式實作。

要先修嘅係規則衝突，唔止係目錄

而家已經搵到幾個上下層規則互相唔一致嘅位置：

• DM 參考文件仍要求固定權重同候選數量，再按最高分裁決，見裁決要求。呢個做法同「證據不足時唔好虛構評分、硬性門檻優先」唔一致。
• 能力對照文件要求所有中大型編碼任務預檢，部分產物亦列作必需；開發角色文件再要求預檢通過先可以實施。但構建流程已講明，唔應該將重型規劃機械套用喺缺陷修復同運維工作上。

如果自動路由會載入呢啲文件，就可能重新帶返核心規則已經取消嘅限制。因此 F1 唔可以只檢查頂層技能，仲要睇埋相關嘅下層文件同路徑消費者；至於超出現有批准範圍嘅改動，仍然要先確認。

另外要分清楚：Cline 喺單次會話入面嘅規劃，唔應該自動變成另一份項目執行計劃。項目只綁定一份已獲批准嘅契約；原生清單可以記錄當前進度，但文件計劃唔需要逐輪複製嗰份狀態。

DM：比較三種推行次序

今次冇可靠嘅成本量度，所以唔用虛構分數作比較。

做法	主要好處	主要風險	判斷
搬晒所有文件，之後先適配 Cline	最後目錄較一致	宿主介面未驗證就大規模搬遷，容易返工	不建議
先完整部署 Cline，再做治理	較早有實際使用體驗	將現有規則衝突帶入新宿主，之後可能要重做適配	不建議作正式次序
最小治理 → 薄適配 → 分批遷移 → 真實驗收	先處理語義衝突，再驗證各路徑消費者，遷移範圍較易控制	要清楚訂出每階段嘅出口條件	有條件建議

第三種做法同現有獨立計劃嘅 F1 至 F4 次序一致，唔需要靜靜雞改寫計劃：

1. **F1：**先統一職責、產物同狀態由邊度管理；修正已發現嘅規則衝突，並檢查路徑消費者。暫時唔搬目錄。
2. **F2：**核實 Cline 版本後，做技能同規則嘅薄適配、項目內隔離測試，並講清楚實際可以接入邊啲程序門禁。
3. **F3：**等消費者確認相容，再按已批准清單分批遷移文件、測試同證據；唔係一次過搬晒，亦唔可以削弱白盒測試。
4. **F4：**喺真實 Antigravity／Cline 宿主驗收規則載入、模式切換、審批、拒絕行為同復原流程。

Cline 介面嘅一手資料，只讀研究可以同 F1 並行；但安裝插件、寫入真實配置同啟動宿主，就唔係只讀研究。如果想提早做真實宿主試點，就要明確調整階段依賴同授權，唔好當咗 F2 自動包括呢啲工作。

DR：由反例推返必要門禁

• **壓縮上下文後漏咗未完成工作：**要由綁定契約同唯一進度入口恢復必要資訊；摘要唔可以取代原始驗收證據。
• **Act 保存分析文件時順手改程式：**文件保存同工程實施要有唔同授權範圍；執行入口應檢查實際目標，唔可以只睇模式名稱。
• **模型將失敗 Task 標記為完成：**推進階段前要檢查對應範圍嘅實際結果。非零退出、逾時、零項目被收集、必需項目被跳過，或者缺少證據，都唔應該當通過。
• **檔案工具受限，但命令、外部工具或子任務仍可寫入：**逐一確認所有已啟用嘅副作用入口有冇受到控制；未覆蓋嘅入口要限制或停用。只攔截一個編輯工具，唔足以聲稱已經隔離。
• **搬目錄後測試唔再被發現：**驗收要檢查測試發現入口、必要斷言、引用同語言封裝；成功搬到檔案，唔等於驗收完成。

Cline 官方文件有介紹透過工具執行前嘅 hook 加強存取限制。4 不過，目標 IDE 版本嘅模式資訊、實際攔截範圍同失敗處理方式，仍然需要查證；唔可以單憑 hook 嘅名稱或者設定存在，就當作執行時保證。

程式門禁應該優先處理可以可靠判斷嘅事項，例如目標路徑、授權範圍、契約格式、依賴關係同實際退出結果。測試夠唔夠、架構啱唔啱，以及 DR／DM 判斷得好唔好，仍需要模型同人一齊審查；唔好將所有判斷都扮成可以自動完成。

最終建議

• **能力共存：**有條件可行；採用分層分工同單一事實來源，唔好堆疊兩套完整提示詞。
• **推行次序：**先治理最小契約，唔使先搬晒所有文件；之後按既有 F2 至 F4 次序做適配、遷移同驗收。
• **下一步界線：**現有計劃嘅 F1 係第一個等待授權嘅階段，見審批狀態。今次發現應納入之後確認嘅工作範圍；唔好另開平行計劃，亦唔好覆蓋舊任務。

今次只完成咗唯讀裁決；冇修改 ADR、計劃、技能或生產文件，亦冇執行終端命令、測試、hook 或部署。