把重要邊界交給程式檢查

從基準版本與程式碼審查證據開始。需要設計判斷的 expectation 留在指引並附正反例；套件責任歸屬、路由資產清單、schema 狀態與公開匯出交給產生器；只有審查者穩定拒絕、檢查器低歧義的狀態才升成規則。

每條規則記 ID、目的、負責人、範圍、嚴重程度、本機指令、CI 階段、修復提示與例外條件。本機和 CI 顯示相同 ID，使用同版檢查器。若判定不同，先查輸入及環境差異，避免本機通過後在推送時才發現問題。

資料遷移偶爾需要暫時跨依賴或修改受保護的清單。例外要指明精確規則、精確路徑、負責人、原因、問題、createdAt 與 expiresAt。檢查器驗所有欄位，已到期或路徑放寬一律拒絕；一律通用的停用不在任務契約。

規則健康狀態也要量：違規、修復成功、誤判、例外存續時間、執行環境、CI 偏移與繞過嘗試。失去真實邊界的規則應刪除。少而可信的規則，比一長串人人忽略的紅字更有用。

差異預算同時檢查範圍與內容。契約先列允許根目錄、受保護檔案、自動產生範圍、資料遷移規則與交付要求，再檢查新增、刪除、改名、二進位檔、lockfile 和依賴變更。十個小檔案可能合理，一個 lockfile 大改也可能增加供應鏈風險。超出預算就回差異摘要並轉人工審查，不讓 Agent 拆成多次提交來繞過門檻。

機密規則要掃的不只有來源。測試資料 canary 可能進終止紀錄、JSON 驗收憑證、瀏覽器截圖中繼資料、執行軌跡、涵蓋程度輸出、修補差異說明與自動產生的說明文件。每個範圍都設保留的 fail 案例，並確認檢查器自己不把命中的完整值印到報告。真正事故還要有撤銷、輪替、歷史紀錄審查與通知流程；課程 canary 通過只能證明已列範圍沒有洩漏，不能宣稱整體沒有秘密風險。

架構規則需要跟責任歸屬地圖對齊。DEP-001 讀套件工作圖與公開匯出，而不是靠字串搜尋匯入路徑。允許依賴變更時先更新架構決策、負責人與保留的測試資料，再改規則清單。若 agent 直接編輯自動產生的工作圖，GEN-002 應先擋；正確流程是改正式可信的設定或來源，再執行產生器。這能維持規則、地圖與實際程式碼同一套真相。

例外審查要看使用紀錄。某條例外在七天內被三個無關任務匹配，即使尚未到期也可能範圍過寬；健康狀態報告應列已匹配的提交版本、路徑與 actors。負責人可選縮小、提早撤銷或正式修改必須成立的條件。期限到了不能自動續期，更不能因 CI 壓力改成警告；新例外必須重新說明原因與風險，並重跑受影響的關鍵測試資料。

保護路徑規則要區分禁止修改與需額外核准。測試資料的憑證設定、部署清單與資料刪除程序可以完全禁止 agent 觸碰；核心狀態機或資料遷移登錄清單可能允許修改，但必須有對應合約、負責人審查與完整回歸。檢查器回傳規則類型、需要的證據與申請位置，不建議 agent 移動檔案或改名來避開 glob。重新命名、symlink 與自動產生的輸出也要解析到實際目標，避免表面路徑不同便穿過保護。

規則失敗的修復文字本身要受測。若依賴方向錯誤，提示應指向公開服務或領域邊界，不要只說禁止匯入；自動產生的檔案被改，提示要指出正式可信的來源與生成指令；機密命中則只顯示檔案、類型與遮蔽片段，不能重印完整值。全新 agent 依提示修復後，除了原規則通過，也要跑相關功能，避免為了消掉紅字而刪除必要行為。

發布前抽查規則是否真的阻擋實際執行路徑。某些檢查只掃 Git 差異，卻漏掉執行環境產生的紀錄或截圖；另一些只在 CI 跑，agent 本機無法取得及時回饋。將必須成立的條件對到產生、提交、建置、執行與歸檔各階段，選最早且可靠的位置攔截，較晚階段再做整體防線。多層檢查可以共用規則 ID，但各自證明的表面要在驗收憑證寫清楚。

規則變更也要像功能變更一樣經過之前／之後測試資料。新增規則先在歷史乾淨變更上跑，估誤判與修復時間；放寬規則則重播曾被它擋下的違規修補差異，確認仍有其他控制或已由正式架構決策接受。負責人簽的是具體差異與殘餘風險，不是一個規則檔案已被修改的事實。若新規則讓本機執行前檢查超過團隊可接受時間，拆成快速阻擋執行的與較慢建議項目／CI 層，不能直接鼓勵跳過整包檢查。規則發佈後觀察一個週期，再決定保留、調整或撤回。

每次規則發佈都附一個最小壞修補差異與一個合法邊界修補差異。前者證明它真的攔住風險，後者防止維護者只測失敗路徑，卻讓正常工作全被誤傷。