本卡為 FR-132 母案。把公司層權限補成 Azure 式「誰 × 角色 × 範圍 × 時效」，5 個子需求、31 張子卡（A.1 盤點只讀、A.2～A.5 實作）。子卡清單在末段。

這系列在做什麼（白話）

Guidant AI 今天的權限是「管理員建角色、在角色上勾能力點（系統裡「可以做某件事」的最小單位）、再把角色派給人」。骨架都在，但有幾件事只做了一半：派角色時可以選部門、選起訖日，系統卻不看；有 33 支 API 只要登入就能用；角色只能一格一格勾，沒有「整個模組」「全部唯讀」的寫法，也不能搬到別的環境。

這系列把它補成像 Azure 那樣的四段模型：誰（使用者）×角色（一組能力點，支援萬用字元如 grc.*.*、*.*.read）×範圍（整個租戶或某個部門）×時效（每筆指派的起訖日）。另外新做一個「存取管理」模組四頁（角色、指派、檢查存取、使用者），加一個預設關閉的「部門資料隔離」開關給需要部門互不相見的客戶。

專案內成員角色（manager／reviewer／auditor／viewer）的合併是另一個需求 FR-B，本案不做，只預留欄位。

為什麼要做

• 部門範圍只存不判：user_roles 有部門欄，判定只比租戶——指到某部門的角色在整個租戶都有效，且無錯誤訊息（jedi-iam infra/repository/user_role_repo_impl.py:81-101）。
• 起訖日判了但設不了：判定有看每筆指派的起訖（active_role_conditions.py:19-39），畫面只開了帳號層的生效／到期日（FE UserMTRBACForm.vue:489,501）。
• 33 支 API 只驗登入：公司沒辦法說「稽核部的人不准碰 SSP 匯出」（盤點 ① 第 3 節 J 組）。
• 命名三套、角色只能逐筆勾：123 個能力點、37 種資源，底線／連字號／單字三套寫法混用；角色沒有萬用字元、不能匯出匯入。
• 兩個資安漏洞：選單明細與 JWT 的 is_admin 欄位不過濾已到期、已停用的指派（app/service/user_service.py:522-529,547、middleware/jwt_mw.py:79），過期管理員仍看得到管理頁入口。

關鍵設計決策（D1–D12，2026-10-06 定案）

• D1 模組命名：一個「存取管理」模組四頁（角色、指派、檢查存取、使用者），取代 /auth/role-manage、/auth/user-manage 等四條路由。
• D2 pattern 怎麼存：新表 role_capability_patterns(role_id, pattern) 為判定來源；舊表 role_capabilities 並存一版後退役，回滾不必動資料。
• D3 快取失效：展開結果放 Redis，鍵含「能力點清單版本號」；角色改動時主動清該租戶快取。Redis 壞掉退回查 DB，不放行也不全擋。
• D4 部門繼承：上層部門的指派涵蓋所有子部門。
• D5 只記錄觀察期：33 支新守門先出一版「不放行時記 log 但仍放行」，DEV＋STG 跑滿一週無「非管理員會被擋」紀錄才真擋。旗標是每個能力點一個，不是全域開關（全域一開會把既有守門也放寬）。
• D6 出貨角色：系統管理員 *.*.* 內建、不可刪改、每租戶必有；稽核主管／稽核員／唯讀（*.*.read）是出貨範例，可改可刪可複製。
• D7 is_admin 旗標保留：判斷管理員只看旗標，不看是否持有 *.*.*（用能力點反推管理員已實際踩過坑）。
• D8 選單同源：選單可見性、選單明細、JWT is_admin claim、判定四者吃同一份「有效指派＋展開結果」，順便修掉兩個資安漏洞。