本卡屬 FR-132（母卡 CM-2510），A.4 守門補齊第 1 張。依賴：T-3.3。建議 model：opus。

這張卡做什麼（白話）

33 支新守門如果直接上線，客戶自己勾的一般角色會突然被擋。所以先出一版「只記錄」：判定照跑，結果是「不放行」時寫 log 但仍放行，累積一週統計看會擋到誰，再決定真擋。

🔴 旗標是每個能力點一個，不是全域開關——全域開關一開，既有守門也會被放寬，等於把整個系統的權限打開。

在哪裡

~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/authz/capability.py      CapabilityGuard（require_capability 的實作）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/models/capability.py      capabilities（旗標可加在這，或放常數清單）
~/Projects/Billows/Audit-Manager/compliance-manager-be/common/authz/__init__.py      主專案 re-export

怎麼做

• 旗標放哪：二選一並回寫理由——(a) capabilities 加 enforce_mode varchar（log_only／enforce，預設 enforce）由 migration 設；(b) 套件內常數集合由宿主注入。判準：真擋切換（T-4.5）要不要靠 migration、客戶端能不能各自調。若選 (a)，套用主線 migration 規則與出貨基線回報。
• 不放行時：只記錄的能力點 → 寫結構化 log（JSON 一行：時間、tenant_id、user_id、login_name、使用者角色清單、能力點、route、method）並放行；非只記錄 → 照舊 403。log 有固定標記字串方便 grep。log 不得含 request body（BE log 已有印憑證明文的 follow-up）。
• 統計：一支腳本或 SQL（看 log 落在哪：檔案用腳本、若有 DB log 表用 SQL）輸出「能力點 × 使用者 × 次數」，排除管理員（is_admin）。
• super_admin 判斷不變。

要寫測試

• 只記錄能力點 × 無權帳號 → 放行且有 log。
• 非只記錄能力點 × 無權帳號 → 403。
• 突變：把旗標判斷改成全域放行，第二個測試紅。

驗收條件

• 標成只記錄的能力點在無權帳號下放行且有 log；未標的既有守門照擋。

手測

• DEV：把某個新能力點標只記錄，用一般帳號打對應 API，200 且 log 有一行；把某個既有能力點（例專案刪除）用同帳號打，照舊 403。

紀律