本卡屬 FR-132（母卡 CM-2510），A.3 判定層第 3 張。依賴：T-3.1。建議 model：opus。

這張卡做什麼（白話）

require_capability("grc.project.read") 對外介面不變，內部改成：取有效指派 → 展開角色 pattern → 比對（新舊名皆認）。完成後 DEV 所有既有角色的判定結果要與改前一模一樣。另加一支守衛測試掃程式裡還寫死的舊名，供下一版移除舊名用。

在哪裡

~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/repository/user_role_repo_impl.py:73-101      get_active_capability_names（今天只比 tenant_id）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/repository/active_role_conditions.py:19-39      active_user_role_conditions（起訖、啟用、未刪除、租戶）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/authz/capability.py:115,135      CapabilityGuard 讀集合處
~/Projects/Billows/Audit-Manager/compliance-manager-be/test/test_authz_capability.py      既有判定測試
~/Projects/Billows/Audit-Manager/compliance-manager-be/test/test_module_boundaries.py      守衛測試範例

怎麼做

• get_active_capability_names 改為：沿用 active_user_role_conditions 取有效指派的 role_id → 讀 role_capability_patterns → 經 T-3.1／T-3.2 展開（含快取）→ 合併集合。本卡先不處理部門（T-3.5 做），部門指派此時仍等同租戶有效（與今天相同）。
• super_admin 放行邏輯不動。
• 守衛測試：新增一支測試掃 BE（api/ app/ common/ core/）、jedi 套件源碼、FE src/ 裡 require_capability(、viewer_has_capability(、hasCap( 的字串引數，比對 capabilities.legacy_name（從 core/host_capabilities.py＋套件 CAPABILITIES 宣告取，不連 DB），列出剩餘舊名但先不 fail（標 xfail 或只印清單），下一版再改成 fail。盤點已知：BE 約 116 處、jedi 套件 11 支檔、FE 約 14 支檔。
• 舊表 role_capabilities 不再被判定讀取，但不要刪。

要寫測試

• 既有 test/test_authz_capability.py 全綠。
• 新增：角色只有 grc.*.* pattern 時，要求 grc.project.read 放行、oscal.ssp.read 擋。
• 要求舊名 project.read 也放行（D11）。
• 突變：拿掉舊名支援，對應測試紅。

驗收條件

• DEV 全部既有角色判定結果與改前相同（寫腳本對每個角色、每個能力點，比對舊表與新邏輯）；守衛測試列出剩餘舊名清單。

手測

• DEV：一般帳號與管理員登入，點過專案、SSP、系統設定各頁，行為與改前一樣、log/app.log 無新的 403。

紀律