把重要邊界改成機械式規則

從 baseline 與 code review evidence 開始。需要設計判斷的 expectation 留在 instructions 並附正反例；package ownership、route inventory、schema status 與 public export 交給 generator；只有 reviewer 穩定拒絕、checker 低歧義的狀態才升成 rule。

每條規則記 id、目的、owner、scope、severity、local command、CI stage、repair hint 與 exception policy。Local 與 CI 顯示相同 id；兩邊 implementation 不一致會造成 local 假信心與 push 後 surprise。

Migration 偶爾需要暫時跨 dependency 或修改 protected manifest。Exception 要指明 exact rule、exact paths、owner、reason、issue、createdAt 與 expiresAt。Checker 驗所有欄位，expired 或 path widening 一律拒絕；blanket disable 不在 task contract。

Rule health 也要量：violation、repair success、false positive、exception age、runtime、CI drift 與 bypass attempt。失去真實邊界的 rule 應刪除。少而可信的規則，比一長串人人忽略的紅字更有用。

Diff budget 不應只限制檔案數。先由 contract 列 allowed roots、protected files、generated surfaces、migration policy 與預期 artifact，再由 checker 比新增、刪除、rename、binary、lockfile 與 dependency change。十個小檔案可能完全合理，一個 package lock 大改卻可能擴張 supply-chain surface。超出 budget 時回需要 review 與差異摘要，不讓 agent 為了過門檻把大改拆成多次 commit。

Secret rule 要掃的不只有 source。Fixture canary 可能進 terminal log、JSON receipt、browser screenshot metadata、trace、coverage output、patch description 與 generated docs。每個 surface 都設 retained fail case，並確認 checker 自己不把命中的完整值印到報告。真正 incident 還要有 revoke、rotate、history review 與通知流程；課程 canary 通過只能證明已列 surface 沒有洩漏，不能宣稱整體沒有秘密風險。

Architecture rule 需要跟 ownership map 對齊。DEP-001 讀 package graph 與 public export，而不是靠字串搜尋 import path。允許 dependency 變更時先更新 architecture decision、owner 與 retained fixtures，再改 rule manifest。若 agent 直接編輯 generated graph，GEN-002 應先擋；正確流程是改 authoritative config 或 source，再執行 generator。這能維持 rule、map 與實際 code 同一套真相。

Exception review 要看使用紀錄。某條 exception 在七天內被三個無關 task match，即使尚未到期也可能 scope 過寬；health report 應列 matched commits、paths 與 actors。Owner 可選縮小、提早撤銷或正式修改 invariant。期限到了不能自動續期，更不能因 CI 壓力改成 warning；新 exception 必須重新說明原因與風險，並重跑 affected critical fixtures。

保護路徑規則要區分禁止修改與需額外核准。Fixture 的憑證設定、部署清單與資料刪除程序可以完全禁止 agent 觸碰；核心狀態機或 migration registry 可能允許修改，但必須有對應合約、owner review 與完整回歸。Checker 回傳 policy class、需要的證據與申請位置，不建議 agent 移動檔案或改名來避開 glob。Rename、symlink 與 generated output 也要解析到實際目標，避免表面路徑不同便穿過保護。

規則失敗的修復文字本身要受測。若依賴方向錯誤，提示應指向 public service 或 domain boundary，不要只說禁止 import；generated file 被改，提示要指出 authoritative source 與 generation command；secret 命中則只顯示檔案、類型與遮蔽片段，不能重印完整值。Fresh agent 依提示修復後，除了原規則通過，也要跑相關功能，避免為了消掉紅字而刪除必要行為。

Release 前抽查規則是否真的阻擋實際執行路徑。某些檢查只掃 Git diff，卻漏掉 runtime 產生的 log 或 screenshot；另一些只在 CI 跑，agent 本機無法取得及時回饋。將 invariant 對到產生、提交、建置、執行與歸檔各階段，選最早且可靠的位置攔截，較晚階段再做整體防線。多層檢查可以共用 rule ID，但各自證明的表面要在 receipt 寫清楚。

Policy change 也要像功能 change 一樣經過 before／after fixture。新增規則先在歷史乾淨變更上跑，估 false positive 與修復時間；放寬規則則重播曾被它擋下的違規 patch，確認仍有其他 control 或已由正式架構決策接受。Owner 簽的是具體差異與殘餘風險，不是一個規則檔案已被修改的事實。若新規則讓 local preflight 超過團隊可接受時間，拆成快速 blocking 與較慢 advisory／CI 層，不能直接鼓勵跳過整包檢查。規則發佈後觀察一個週期，再決定保留、調整或撤回。

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