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

這張卡做什麼（白話）

展開只跟「角色有哪些 pattern」與「清單有哪些能力點」有關、跟使用者無關，可以跨請求快取。多台 api／worker 行程時只有共用的 Redis 能一致清除，所以放 Redis。權限的錯誤方向是「拔了還有效」，不能只靠時間到期。

在哪裡

~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/authz/capability.py:48,51-66,99-106      現有單一請求快取（flask.g `_authz_capability_names`）
core/extensions.py      主專案 Redis 單例（先 grep 既有 redis client 取得方式）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/      角色寫入、停用、刪除的 service（清快取的掛點）

怎麼做

• 鍵：authz:exp:{tenant_id}:{catalog_version}:{role_id} → 該角色展開後的能力點名集合。catalog_version 是 T-2.3 加的版本號。
• 失效：角色 pattern 改動、角色停用／刪除 → 刪 authz:exp:{tenant_id}:*（用 SCAN，不要 KEYS）。能力點新增或改名 → 版本號加一，舊鍵自然不命中；找出能力點 upsert 的地方（_capabilities.sql 是 SQL，加一行 UPDATE 版本號），回寫說明怎麼保證版本號會加。
• 🔴 Redis 讀不到時直接查 DB 展開，不可放行也不可回 403——包 try/except 只針對 Redis 連線錯誤，log warning。
• 指派的起訖、啟用每次都查 DB，不進 Redis——到期當下就失效。
• flask.g 單一請求快取保留。
• Redis client 由宿主注入（套件不直接讀環境變數）；先查既有 jedi-iam 有無 Redis 依賴與注入方式，沒有就加 port，新 env var 前先查 config.py。

要寫測試

• 改角色 pattern 後下一次展開拿到新結果（模擬兩個 guard 實例共用 fake redis）。
• Redis 丟連線錯誤時判定結果與有 Redis 時相同。
• 突變：拿掉清快取那行，第一個測試要紅。

驗收條件

• 改角色後下一個請求即生效（多行程）；停掉 Redis 判定結果不變、不放行不全擋。

手測

• DEV：起兩個 BE 行程（不同 port），在 A 改某角色、用 B 打該角色守的 API，立即生效。