重點唔係放寬測試，而係分清楚每一步要做乜

一份針對 BMAD V4.2 流程嘅只讀審計，提出嘅方向係：保留隔離強度，但將驗證範圍分級、環境準備獨立處理，亦只將必要證據放入對話上下文。

審計並無修改規則檔、執行測試或部署，亦無將任何計劃轉正或歸檔。佢嘅核心判斷係：目前成本可能由幾件事一齊放大，包括階段切得太細、測試入口夾帶環境安裝、詳細輸出大量回灌，以及執行記錄反覆對賬。

先講清楚：現有證據證明到乜？

唔能夠話係全局規則要求每個補丁跑完整矩陣

全局核心規則要求每個階段做相關驗證；工程模式規則亦容許按改動範圍選擇驗證方式，使用當前主機或獲批容器。較強嘅「每步修改後物理驗證」要求，出現喺歷史項目計劃，而唔係已確認嘅全局硬性要求。

所以，較準確嘅解讀係：規則未有講清楚階段粒度同準備成本邊界，項目計劃再將要求加強；當工具鏈準備同測試都由同一入口處理，成本就更容易反覆出現。

有安裝記錄，但未證明每次都下載 198.1 MiB

一份測試日誌顯示，測試事件開始前曾安裝 14 個套件；安裝結尾列出 31 個套件、合共 198.1 MiB。不過，呢個數字唔足以證明當次實際下載量或新增解壓量就係 198.1 MiB。

記錄時間顯示，操作約於 14:04:04 開始，測試事件於 14:04:09.330 開始，即前置階段約 5.3 秒；包級測試約 2.72 秒，整個操作約 8 秒。現有時間點未能再拆出安裝、容器啟動、編譯或快取檢查各自佔幾多。

因此，資料支持「測試入口有明顯準備開銷」，但未足以量化安裝本身嘅成本，更未證明每次呼叫都重新下載相同容量。

減少安裝輸出，唔等於解決日誌洪水

安裝部分約 16 行；測試部分則重複輸出開始事件、文字開始行、通過行同通過事件。提供嘅日誌仲有約 76,000 個字元嘅省略標記。

換句話講，單單收起套件安裝訊息，未必可以解決測試事件過量輸出嘅問題。另一方面，亦唔可以單靠聊天匯出或介面畫面，就斷定所有文字都曾進入模型請求，或者推算實際收費 token。

審計記錄到多組分開編譯同測試嘅呼叫，但實際測試入口仍使用可能涉及建構準備嘅 Go 測試命令。由於未有隔離腳本正文，暫時無法確定安裝發生喺腳本、鏡像入口，抑或其他包裝層；亦唔應推斷所有歷史呼叫都重新安裝。

把四種生命周期拆開處理

審計指出，現行做法容易將以下幾件事混為一談：

1. 隔離生命周期：測試唔應污染源碼、主機或下一次測試。
2. 工具鏈生命周期：編譯器、系統函式庫同依賴，應隨環境版本管理，而唔係每次業務斷言改動就重裝。
3. 驗證生命周期：要判斷今次改動令邊啲既有證據失效，哪些需要重跑。
4. 記錄生命周期：保存結果、更新狀態，唔應自動令剛完成嘅功能驗證全部失效。

例如，計劃可能要求驗證更新後嘅文件綁定，又要求將歷史摘要寫入執行記錄。若唔分清「契約輸入」同「執行結果」，就有機會形成記錄結果、文件變更、再驗證、再記錄嘅循環。審計視之為結構風險，並無證明已經出現無限循環。

關鍵分別係：重用不可變工具鏈，唔等於重用受污染嘅測試現場；重建臨時測試現場，亦唔代表要重新安裝工具鏈。

建議三層驗證：L0、L1、L2

以下係建議契約，唔代表相關能力已經實施。

層級	做乜	幾時觸發
L0：不可變執行環境	預備工具鏈、系統函式庫同獲批依賴，記錄鏡像身份、工具鏈版本同安全設定	環境輸入改變時先準備新版本；改業務源碼唔應觸發系統套件安裝
L1：開發回環	對一個語義完整嘅改動，跑相關單元、模組測試及必要嘅競態回歸	每個語義批次一次，維持同等隔離，但按改動縮窄測試範圍
L2：階段交付驗收	對凍結候選執行階段所需矩陣、獨立未插樁 RSS 測量同證據核對	階段完成或獲授權交付前執行；普通狀態記錄唔應令佢重跑

L0：環境可重用，測試現場仍要乾淨

建議固定鏡像內容身份；測試入口禁止安裝系統套件、拉取鏡像或在線解析依賴。若環境缺少必要工具或依賴，就應停止並報告環境未就緒，而唔係自動連網補齊。環境準備亦應獨立授權、獨立計時，唔好藏喺驗證命令入面。

測試仍應保留源碼唯讀、外網關閉、最小權限同有上限嘅臨時空間；快取亦要按項目、工具鏈、平台同信任邊界隔離。快取命中只代表可以重用計算產物，唔代表測試已經通過。

L1：快速回歸唔代表離開沙盒

歷史授權明確限定離線隔離容器驗證。因此，唔應為咗慳時間，就默默將快速回歸搬到主機執行。建議預設用同一安全限制下嘅輕量隔離環境；要喺主機跑，就必須另外取得清晰授權同列明適用條件。

一個「語義批次」係指一項行為改動連同其測試，當中可以有多次精準編輯。相關 L1 必須喺開始依賴該行為嘅下一批工作前通過；但亦唔應按工具呼叫次數機械式切批，或者無限累積改動。

L2：驗收綁定候選版本，而唔係反覆重裝環境

階段驗收應綁定源碼同測試快照、依賴、執行環境、執行設定同驗證集合。RSS 應用獨立、未插樁嘅程序測量，並同競態結果分開登記。若門禁後相關輸入改變，舊結果唔可以直接套用到新候選；可以只重跑受影響部分，但要證明其他證據仍然適用，否則就要擴大驗證範圍。

觸發條件要跟改動走，唔好跟檔案數目走

改動或事件	建議動作	唔應自動觸發
同一行為嘅實作同斷言改好	做一次相關 L1 驗證	重建 L0 或跑完整 L2
鎖、並行存取、取消或資源釋放方式改變	加做針對性競態及生命周期驗證	等到最終交付先檢查競態
跨模組介面或共享依賴改變	擴大到受影響嘅呼叫鏈	無理由只測修改過嘅檔案
工具鏈、系統依賴或隔離設定改變	重新確認 L0，並重新評估相關證據	喺測試入口臨時安裝
階段候選凍結	執行一套階段所需 L2 矩陣	每個中間補丁都重跑完整矩陣
只更新進度或執行記錄	檢查完整性及文件契約	重跑業務測試或 RSS

如果用 race detector，結果只代表實際執行過嘅路徑受到檢查，唔能夠證明程式絕對冇資料競態。9

規則同執行器可以點改

審計建議喺全局核心規則清楚定義：物理驗證係喺獲批環境真實執行並產生可核驗結果，唔等於每次改動都重建基礎環境；每個語義批次做 L1，階段驗收做 L2；環境準備、編譯、斷言執行同清理則分開定義輸入、預算同結果。

工程模式亦應要求每次驗證交代改動範圍、選擇咗邊啲測試，以及點解要升級驗證範圍。若編譯同測試要求嚴格分開，測試階段就要使用可識別嘅建構產物，而唔係重新進入隱式建構流程。編譯、測試同清理可以各自設限時，但外層總預算要覆蓋實際包含嘅階段同終止寬限。

另建議為輸出訂立契約：原始診斷日誌同模型可見摘要分開；成功摘要可先以不多於 2 KiB、失敗摘要不多於 8 KiB 作起始預算。摘要保留首個根因、必要堆疊、退出狀態、失敗或跳過項目、耗時、清理結果同原始產物位置；超出上限要清楚標示，唔好扮成完整輸出。呢兩個容量只係建議起點，唔係行業標準，亦唔係已測得嘅最佳值。

重點係裁剪要喺工具結果進入模型對話紀錄之前完成；叫模型「忽略日誌」或者只喺介面收起內容，都唔等於達成要求。結構化測試事件亦要解析同歸併，唔好單靠刪走含有錯誤字眼嘅行。若缺少終結事件、解析失敗、零命中、有未解釋跳過，或者產物不可用，就唔應只憑退出碼為零判定通過。

計劃模板亦應列明每項驗證嘅層級、觸發事件、覆蓋與不覆蓋範圍、獲批環境、各階段預算、輸入指紋、證據失效條件、摘要上限同產物保留方式。執行結果要同契約輸入分開保存；保存結果本身唔應遞迴觸發同一項功能驗證。

實施次序：先減少重複準備，再談驗證頻率

審計建議先更新規則同計劃模板，並一併檢查唔同入口有冇採用一致解讀；之後再改執行器，分清環境準備、測試同結構化摘要。最後用小規模對照驗收：連續跑多個改動批次，確認測試階段唔會安裝系統套件、普通記錄更新唔會觸發 L2，摘要亦受限；同時刻意測試斷言失敗、零命中、超時同清理失敗，確保仍然可以阻止推進。

總結而言，唔好先取消隔離、削減關鍵競態覆蓋，再用安全退讓去補執行器同規則契約嘅缺口。較穩陣嘅次序係先分清環境準備同測試生命周期，減少重複安裝及不必要輸出，然後先按改動影響範圍調整驗證頻率。

重點唔係放寬測試，而係分清楚每一步要做乜

一份針對 BMAD V4.2 流程嘅只讀審計，提出嘅方向係：保留隔離強度，但將驗證範圍分級、環境準備獨立處理，亦只將必要證據放入對話上下文。

審計並無修改規則檔、執行測試或部署，亦無將任何計劃轉正或歸檔。佢嘅核心判斷係：目前成本可能由幾件事一齊放大，包括階段切得太細、測試入口夾帶環境安裝、詳細輸出大量回灌，以及執行記錄反覆對賬。

先講清楚：現有證據證明到乜？

唔能夠話係全局規則要求每個補丁跑完整矩陣

全局核心規則要求每個階段做相關驗證；工程模式規則亦容許按改動範圍選擇驗證方式，使用當前主機或獲批容器。較強嘅「每步修改後物理驗證」要求，出現喺歷史項目計劃，而唔係已確認嘅全局硬性要求。

所以，較準確嘅解讀係：規則未有講清楚階段粒度同準備成本邊界，項目計劃再將要求加強；當工具鏈準備同測試都由同一入口處理，成本就更容易反覆出現。

有安裝記錄，但未證明每次都下載 198.1 MiB

一份測試日誌顯示，測試事件開始前曾安裝 14 個套件；安裝結尾列出 31 個套件、合共 198.1 MiB。不過，呢個數字唔足以證明當次實際下載量或新增解壓量就係 198.1 MiB。

記錄時間顯示，操作約於 14:04:04 開始，測試事件於 14:04:09.330 開始，即前置階段約 5.3 秒；包級測試約 2.72 秒，整個操作約 8 秒。現有時間點未能再拆出安裝、容器啟動、編譯或快取檢查各自佔幾多。

因此，資料支持「測試入口有明顯準備開銷」，但未足以量化安裝本身嘅成本，更未證明每次呼叫都重新下載相同容量。

減少安裝輸出，唔等於解決日誌洪水

安裝部分約 16 行；測試部分則重複輸出開始事件、文字開始行、通過行同通過事件。提供嘅日誌仲有約 76,000 個字元嘅省略標記。

換句話講，單單收起套件安裝訊息，未必可以解決測試事件過量輸出嘅問題。另一方面，亦唔可以單靠聊天匯出或介面畫面，就斷定所有文字都曾進入模型請求，或者推算實際收費 token。

審計記錄到多組分開編譯同測試嘅呼叫，但實際測試入口仍使用可能涉及建構準備嘅 Go 測試命令。由於未有隔離腳本正文，暫時無法確定安裝發生喺腳本、鏡像入口，抑或其他包裝層；亦唔應推斷所有歷史呼叫都重新安裝。

把四種生命周期拆開處理

審計指出，現行做法容易將以下幾件事混為一談：

1. 隔離生命周期：測試唔應污染源碼、主機或下一次測試。
2. 工具鏈生命周期：編譯器、系統函式庫同依賴，應隨環境版本管理，而唔係每次業務斷言改動就重裝。
3. 驗證生命周期：要判斷今次改動令邊啲既有證據失效，哪些需要重跑。
4. 記錄生命周期：保存結果、更新狀態，唔應自動令剛完成嘅功能驗證全部失效。

例如，計劃可能要求驗證更新後嘅文件綁定，又要求將歷史摘要寫入執行記錄。若唔分清「契約輸入」同「執行結果」，就有機會形成記錄結果、文件變更、再驗證、再記錄嘅循環。審計視之為結構風險，並無證明已經出現無限循環。

關鍵分別係：重用不可變工具鏈，唔等於重用受污染嘅測試現場；重建臨時測試現場，亦唔代表要重新安裝工具鏈。

建議三層驗證：L0、L1、L2

以下係建議契約，唔代表相關能力已經實施。

層級	做乜	幾時觸發
L0：不可變執行環境	預備工具鏈、系統函式庫同獲批依賴，記錄鏡像身份、工具鏈版本同安全設定	環境輸入改變時先準備新版本；改業務源碼唔應觸發系統套件安裝
L1：開發回環	對一個語義完整嘅改動，跑相關單元、模組測試及必要嘅競態回歸	每個語義批次一次，維持同等隔離，但按改動縮窄測試範圍
L2：階段交付驗收	對凍結候選執行階段所需矩陣、獨立未插樁 RSS 測量同證據核對	階段完成或獲授權交付前執行；普通狀態記錄唔應令佢重跑

L0：環境可重用，測試現場仍要乾淨

建議固定鏡像內容身份；測試入口禁止安裝系統套件、拉取鏡像或在線解析依賴。若環境缺少必要工具或依賴，就應停止並報告環境未就緒，而唔係自動連網補齊。環境準備亦應獨立授權、獨立計時，唔好藏喺驗證命令入面。

測試仍應保留源碼唯讀、外網關閉、最小權限同有上限嘅臨時空間；快取亦要按項目、工具鏈、平台同信任邊界隔離。快取命中只代表可以重用計算產物，唔代表測試已經通過。

L1：快速回歸唔代表離開沙盒

歷史授權明確限定離線隔離容器驗證。因此，唔應為咗慳時間，就默默將快速回歸搬到主機執行。建議預設用同一安全限制下嘅輕量隔離環境；要喺主機跑，就必須另外取得清晰授權同列明適用條件。

一個「語義批次」係指一項行為改動連同其測試，當中可以有多次精準編輯。相關 L1 必須喺開始依賴該行為嘅下一批工作前通過；但亦唔應按工具呼叫次數機械式切批，或者無限累積改動。

L2：驗收綁定候選版本，而唔係反覆重裝環境

階段驗收應綁定源碼同測試快照、依賴、執行環境、執行設定同驗證集合。RSS 應用獨立、未插樁嘅程序測量，並同競態結果分開登記。若門禁後相關輸入改變，舊結果唔可以直接套用到新候選；可以只重跑受影響部分，但要證明其他證據仍然適用，否則就要擴大驗證範圍。

觸發條件要跟改動走，唔好跟檔案數目走

改動或事件	建議動作	唔應自動觸發
同一行為嘅實作同斷言改好	做一次相關 L1 驗證	重建 L0 或跑完整 L2
鎖、並行存取、取消或資源釋放方式改變	加做針對性競態及生命周期驗證	等到最終交付先檢查競態
跨模組介面或共享依賴改變	擴大到受影響嘅呼叫鏈	無理由只測修改過嘅檔案
工具鏈、系統依賴或隔離設定改變	重新確認 L0，並重新評估相關證據	喺測試入口臨時安裝
階段候選凍結	執行一套階段所需 L2 矩陣	每個中間補丁都重跑完整矩陣
只更新進度或執行記錄	檢查完整性及文件契約	重跑業務測試或 RSS

如果用 race detector，結果只代表實際執行過嘅路徑受到檢查，唔能夠證明程式絕對冇資料競態。9

規則同執行器可以點改

審計建議喺全局核心規則清楚定義：物理驗證係喺獲批環境真實執行並產生可核驗結果，唔等於每次改動都重建基礎環境；每個語義批次做 L1，階段驗收做 L2；環境準備、編譯、斷言執行同清理則分開定義輸入、預算同結果。

工程模式亦應要求每次驗證交代改動範圍、選擇咗邊啲測試，以及點解要升級驗證範圍。若編譯同測試要求嚴格分開，測試階段就要使用可識別嘅建構產物，而唔係重新進入隱式建構流程。編譯、測試同清理可以各自設限時，但外層總預算要覆蓋實際包含嘅階段同終止寬限。

另建議為輸出訂立契約：原始診斷日誌同模型可見摘要分開；成功摘要可先以不多於 2 KiB、失敗摘要不多於 8 KiB 作起始預算。摘要保留首個根因、必要堆疊、退出狀態、失敗或跳過項目、耗時、清理結果同原始產物位置；超出上限要清楚標示，唔好扮成完整輸出。呢兩個容量只係建議起點，唔係行業標準，亦唔係已測得嘅最佳值。

重點係裁剪要喺工具結果進入模型對話紀錄之前完成；叫模型「忽略日誌」或者只喺介面收起內容，都唔等於達成要求。結構化測試事件亦要解析同歸併，唔好單靠刪走含有錯誤字眼嘅行。若缺少終結事件、解析失敗、零命中、有未解釋跳過，或者產物不可用，就唔應只憑退出碼為零判定通過。

計劃模板亦應列明每項驗證嘅層級、觸發事件、覆蓋與不覆蓋範圍、獲批環境、各階段預算、輸入指紋、證據失效條件、摘要上限同產物保留方式。執行結果要同契約輸入分開保存；保存結果本身唔應遞迴觸發同一項功能驗證。

實施次序：先減少重複準備，再談驗證頻率

審計建議先更新規則同計劃模板，並一併檢查唔同入口有冇採用一致解讀；之後再改執行器，分清環境準備、測試同結構化摘要。最後用小規模對照驗收：連續跑多個改動批次，確認測試階段唔會安裝系統套件、普通記錄更新唔會觸發 L2，摘要亦受限；同時刻意測試斷言失敗、零命中、超時同清理失敗，確保仍然可以阻止推進。

總結而言，唔好先取消隔離、削減關鍵競態覆蓋，再用安全退讓去補執行器同規則契約嘅缺口。較穩陣嘅次序係先分清環境準備同測試生命周期，減少重複安裝及不必要輸出，然後先按改動影響範圍調整驗證頻率。