存取管理：補完 RBAC

現況是什麼

Guidant AI 的權限今天分兩層，各管各的：

• 公司層（租戶 RBAC，Role-Based Access Control，以角色為單位授權）：管理員建「角色」、在角色上勾「能力點」（例如 project.read），再把角色指派給使用者。API 用 require_capability("project.read") 這類守門擋人。這層由 jedi-iam 套件（帳號與權限套件）判定。
• 專案層（成員角色）：每個專案有自己的成員名單，每人是 manager／reviewer／auditor／viewer 四選一，決定專案內哪些按鈕能按、誰收待辦通知。這層散在主專案與六個 jedi 套件裡，約 70 處硬寫判斷（見盤點 ② 第 2 節）。

另有一層是資料隔離：資料庫用 RLS（Row-Level Security，資料庫列層級隔離）擋住「別的租戶的資料」。這層只到租戶，不到部門——見 4.2。

公司層這一套有骨架，但三個地方沒接上：

1. 「範圍」只存不判，「時效」判了但設不了。user_roles 表有 org_unit_id（部門）與 scope 欄（jedi-iam infra/models/user_role.py:20-84），判定時卻只比租戶（user_role_repo_impl.py:81-101）——前端存部門指派時同時帶租戶 id，所以指派到某部門的角色，實際上在整個租戶都有效。指派的起訖日（starts_at／ends_at）判定有算，但前端只開了使用者帳號層的生效／到期日，每筆指派設不了。
2. 守門不完整。api/ 下 61 支要登入的 route 檔裡，33 支沒掛任何能力點（盤點 ① 第 3 節）。
3. 角色只能逐筆勾。123 個能力點、三套命名寫法，角色只能一個一個勾，沒有「這個模組的全部」「所有東西的唯讀」這種寫法，也沒辦法把角色帶到另一個環境。

Azure 的模型是什麼

Azure 把一次授權拆成四個問題：誰（使用者）× 什麼角色（一組動作，可用 * 萬用字元）× 在哪個範圍（訂用帳戶／資源群組／單一資源，上層涵蓋下層）× 到什麼時候（指派可設起訖）。角色定義可以匯出成 JSON 帶走，「檢查存取」頁可以列出某人實際拿到哪些權限、從哪個指派來。

本案要補的三件事

一句話：先把能力點清單理乾淨定規則（A.1），再改資料表（A.2）與判定邏輯（A.3），最後同時補守門（A.4）和做新畫面（A.5）。

A.1→A.2→A.3 必須照順序；A.4 和 A.5 可以平行做。

事實全部來自本資料夾三份盤點：盤點 ①（BE＋jedi-iam）、盤點 ②（專案角色與流程）、盤點 ③（FE），資料隔離與部門指派的數字另查 DEV DB。jedi-iam 路徑以 jedi-iam/jedi_iam/ 為根，FE 路徑以 compliance-manager-fe/src/ 為根。

4.1 可以直接沿用的

4.2 缺口（每條附座標）

命名三套寫法（DEV 共 123 個能力點、37 種 resource_type，其中 16 個是平台層）：

另有 9 個孤兒能力點（沒掛任何 route）：cloud_integration.update、feedback.export、system_config.create/delete/update、workflow.create/delete/read/update；system_config 缺 read，而 system_config_route 剛好沒有任何守門（盤點 ① 第 4 節）。

33 支只驗登入的 route（盤點 ① 第 3 節 J 組）：

SSP、flow_engine、grc 這幾組多數在 service 層已有專案成員角色守門（盤點 ② 第 2 節），「沒掛能力點」不等於「誰登入都能用」——缺的是租戶 RBAC 這一層：公司沒辦法說「稽核部門的人不准碰 SSP 匯出」。這 61 支只算 BE api/；jedi-iam 的 /roles、jedi-survey 等外部套件自帶的 route 不在其中，A.1 要一併列入。

其他缺口：

• 指派起訖日畫面設不了：前端只有使用者帳號層的 effective_date／expire_date（FE UserMTRBACForm.vue:489,501），每筆角色指派本身沒有；資料表有 starts_at／ends_at、判定也會看，只是畫面沒開。
• 路由守衛不判能力點：FE 只有 requiresAdmin 與 requiresPlatformAdmin（config/router/index.js:1057-1100），註解明寫不依選單擋直接輸入網址（:464、:873）。
• 前端沒有通用元件：沒有部門樹、日期區間、矩陣、轉移清單的封裝；矩陣唯一範本是 RoleForm 內嵌 TreeTable，未抽元件（盤點 ③ 第 6 節）。
• 角色沒有匯出匯入：角色端點只有 5 個 CRUD／狀態切換（api/routing.py:107-111）。
• 出貨預設角色只有一個：Administrator（id=2、is_admin = 1，scripts/init/04-seed-core.sql:62），從 :272 起配全部 123 個能力點；新租戶另建 System Manager（app/service/tenant_provisioning_service.py:49,149）。DEV 9 個租戶各至少有一個 is_admin 角色，其中租戶 102 有兩個；轉換規則見第 6 節。

5.1 三段式

<模組>.<資源>.<動詞>，三段都小寫，資源名內部用連字號：

• grc.project.read、grc.project.approve、grc.audit-round.close
• oscal.ssp.export、oscal.framework-version.update
• system.ldap-config.update、system.security-policy.read

前兩段就是矩陣的兩層分組，所以「群組」不是另一張表，而是名字的前綴。新增一個能力點，矩陣自動長出它該在的位置。

5.2 粒度規則

5.3 矩陣怎麼畫

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
flowchart LR
  ROOT["全部 *.*.*"] --> GRC["grc 專案稽核"]
  ROOT --> OSCAL["oscal 合規框架"]
  ROOT --> SYS["system 系統設定"]
  GRC --> P["project 專案<br/>read create update delete<br/>approve assign export"]
  GRC --> AR["audit-round 稽核輪次<br/>read create update delete close"]
  OSCAL --> SSP["ssp 系統安全計畫<br/>read create update delete<br/>import export"]
  SYS --> LDAP["ldap-config LDAP 設定<br/>read create update delete"]

矩陣上，勾「grc」這一列＝存 grc.*.*；勾「grc / project」的 read 欄＝存 grc.project.read；勾整欄 read＝存 *.*.read。畫面上看到的永遠是展開後的結果，存起來的是最短的 pattern。

5.4 模組怎麼定

模組不是 UI 選單。 選單會隨改版重排，能力點名卻是對外契約——授權照、角色 JSON、客戶已勾好的角色都綁著它，改一次就是一次全客戶升級。兩者各自獨立：矩陣用模組分組、顯示 display_name；選單照自己的結構走，透過 route_capabilities 對到能力點。

判準：客戶會不會把這群功能當一組來授權。 不照程式住在哪個套件分——外部套件（jedi-*）只是實作位置，一個模組可以橫跨主專案與數個套件，一個套件也可以分屬兩個模組。

硬規則：模組邊界與授權照的加值包邊界對齊。 授權照把功能分成基礎包與四個加值包（docs/features/FR-062-2608-license-management/design.md 第 6 節）：

另有不受授權照管制的基礎設施七項 INFRASTRUCTURE_MODULES（smtp-config、ldap-config、log-forwarding、security-policy、ai-call-log、ai-quota、scan-zone，common/authz/license.py:107-121）。一個加值包必須整包落在單一模組內，不可橫跨兩個模組——否則「買了檢測工具包」在矩陣上會散成兩區，客戶勾一半就以為勾完了。模組可以比加值包大（一個模組含一個加值包加其他基礎功能），不可以把一個加值包切開。

現況：沒有正式的模組盤點。手上有的是三份半成品——DEV 的 37 個 resource_type（＝三段名的第二段，沿用不重定義）、授權照的基礎包／加值包分層、core/plugins/ 下約 30 支 plugin 註冊檔。

草案（A.1 的起點，不是定稿）：

盤點時預期會有爭議、要回來請決策者裁的歸屬：

• information-system 歸 grc 還是 oscal（它是 SSP 受評範圍的支撐資料，也是專案的設定項）
• storage-config 歸 evidence 還是 system（存的是證據檔，但屬機房設定性質）
• ai-quota 歸 platform 還是 system
• ai-dashboard 是賣給租戶的加值包，放在「平台（原廠）」模組名稱上會誤導；要不要獨立成一個模組

A.1 每棒產出表欄位固定：route × method → 新三段名 → 現有能力點 → UI 頁。外部套件自帶的 route 一併列入（jedi-iam 的 /roles、jedi-survey 的端點等）——第 4.2 節的 61 支只算 BE api/，只照那份盤會漏掉整個 iam 與 survey 模組。

升級相容：全部是加欄、加表、改資料，沒有刪欄、沒有改型別。帶舊資料升級不會因 schema 失敗；會出事的只會是「資料改得不對」，所以靠下面的自檢擋。

migration 要點

1. 行為零變化是硬條件：每筆既有 role_capabilities 轉成一筆「完整名 pattern」，角色實際能做的事一個都不能多、不能少。migration 結尾自檢：轉換前後每個角色展開出來的能力點集合逐角色比對一致，有任何一個角色不一致就整支 rollback。
2. *.*.* 展開的範圍：非 root 租戶展開時扣掉 is_platform 能力點與不販售清單 TENANT_ADMIN_EXCLUDED_RESOURCE_TYPES（core/plugins/identity.py:89-95），與今天新租戶 System Manager 拿到的集合一致（DEV：123 − 16 個平台層 − 4 個 workflow ＝ 103）。授權照另由軸⑥判，不在展開時扣。
3. 改名要同時處理三種消費者：BE 寫死的 require_capability(...)／viewer_has_capability(...) 約 116 處、jedi 套件 11 支檔（jedi_iam 4、jedi_issue 3、jedi_ai_dashboard 2、jedi_detection 1、jedi_system_core 1）、FE hasCap 約 14 支檔——一版內新舊名並存（D11）。
4. license 判定讀的是 resource_type：授權照裡的模組鍵就是能力點的 resource_type（common/authz/license.py:79-80、:283-297），照已簽出在客戶手上不能重簽。改名後 license 改讀 license_module（D10）。
5. 新租戶與既有租戶回補：tenant_provisioning_service.py 建角色的邏輯改成建系統管理員 *.*.* 加三個範例；scripts/init/migrate-capability-grants.sql 模板改寫 pattern。
6. 出貨基線待重產：scripts/init/02-schema.sql 與 seed 要同步，否則新裝客戶缺這幾支 migration 且不報錯。所有 migration 落地後回報「出貨基線待重產」，重產屬決策者裁示。
7. 升級排練用真實舊庫：見第 14 節。

判定還是在 jedi-iam 的 CapabilityGuard，對外介面不變（require_capability("grc.project.read") 照用），裡面換三件事：

1. 找有效指派：沿用 active_user_role_conditions（起訖、啟用、未刪除、租戶），加上部門條件（7.1）。
2. 展開 pattern：把這些角色的 pattern 展開成具體能力點集合。展開只跟「角色有哪些 pattern」與「能力點清單有哪些名字」有關，跟使用者無關，所以可以跨請求快取。
3. 比對：要求的能力點在不在集合裡。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
sequenceDiagram
    participant R as API 請求
    participant G as CapabilityGuard
    participant DB as 資料庫
    participant C as 展開快取
    R->>G: require_capability("grc.project.read")
    G->>G: super_admin？是就直接放行
    G->>DB: 查有效指派（起訖、啟用、租戶；部門指派連同其部門 path 一起取回）
    DB-->>G: 角色清單
    G->>C: 取這些角色的展開結果（鍵：租戶＋能力點清單版本＋角色）
    alt 快取有
        C-->>G: 具體能力點集合
    else 快取沒有
        G->>DB: 讀角色 pattern 與能力點清單
        G->>G: 展開 pattern（grc.project.* → read/create/…）
        G->>C: 存入
    end
    G->>G: 比對；同一請求內再存 flask.g
    G-->>R: 放行，或回 403

7.1 部門範圍怎麼算（方式乙：範圍套在資料上）

角色不分部門，指派才分部門。 角色定義（一組 pattern）全租戶共用；user_roles.org_unit_id 是這筆指派的範圍。既有欄位設計正確，缺的是判定去讀它，以及資料有可比的部門歸屬。

先分清兩個不同的「部門」：

判法：一筆掛在部門 X 的指派，在使用者碰的資料列 org_unit_id 落在 X 子樹內時啟用（資料列部門的 path 以 X 的 path 開頭）。使用者本人隸屬哪個部門不影響結果——一個人可以隸屬稽核部，卻被指派去管財務部的專案。這就是 Azure「上層涵蓋下層」的原意：比的是被操作的對象落不落在指派範圍內。

• 租戶指派（org_unit_id 為空）：在該租戶內一律啟用，與資料部門無關。
• D12 開關關著：部門不拿來分資料，部門指派等同整租戶有效，行為與今天完全一致。
• D12 開關打開：部門指派只對掛在 X 子樹內的資料有效；org_unit_id 為空的資料列不受部門限制。

落到程式上分兩層：

第三層存在的原因：一個人在 A 部門是編輯、在 B 部門是唯讀，RLS 讓他看得到 A、B 兩邊，route 層也會因為 A 那筆指派放行 update——只有比對「哪一筆指派給的」才擋得住他改 B 的資料。第三層只需掛在 D12 挑選的業務表的寫入路徑（第 8.2 節），由 A.3 提供、守門補齊（A.4）一併掛上。

7.2 選單與判定同源

今天選單可見性（infra/repository/ui_route_repo_impl.py:70-141）、判定（user_role_repo_impl.py:73-101）、選單明細（user_service.py:522-529）、JWT is_admin claim（middleware/jwt_mw.py:79）是四條各自的查法，後兩條不看有效指派。pattern 與部門範圍上線後若四條各自實作，必然有一條漏改，症狀是「選單看得到、點進去 403」或反過來，且不報錯。四條全部改吃同一個「有效指派＋展開後能力點集合」（D8）。

D12 定案：做機制，租戶自己開，預設關。 關著時行為與今天完全一樣；需要「A 部門看不到 B 部門的專案」的客戶，在存取管理裡打開。

8.1 機制

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
flowchart TB
  Q["讀一筆業務資料"] --> T{"租戶允許？<br/>app_tenant_allowed_for_session"}
  T -- 否 --> NO["看不到"]
  T -- 是 --> S{"本租戶開了部門隔離？"}
  S -- 否 --> YES["看得到（與今天相同）"]
  S -- 是 --> N{"該列 org_unit_id 為空？"}
  N -- 是 --> YES
  N -- 否 --> P{"該列部門 path 落在<br/>允許的部門清單子樹內？"}
  P -- 是 --> YES
  P -- 否 --> NO

• session 多注入一個變數 app.allowed_org_unit_paths，照 jedi-common session/database/db.py:205-209 注入 app.allowed_tenant_paths 的做法。值＝使用者有效部門指派的部門 path 清單；有任何有效租戶指派、是 super_admin 或系統管理員時，等同全部門可見。
• 與既有 app.allowed_org_paths 不是同一件事：那個是所屬部門（context.py:129），今天只給 INSERT 檢查用；新的是指派部門。名字刻意不同，A.3 落地時兩個變數旁都要寫明差別，否則下一個人會拿錯的那個。
• policy 形狀：挑選的表 SELECT／UPDATE／DELETE policy 改成「租戶允許 且（該列 org_unit_id 為空 或 其 path 在允許清單子樹內 或 本租戶未開隔離 或 app.can_read_all_orgs 為真）」。can_read_all_orgs 是背景流程已在用的系統放行旗標（app/flow_engine/service/workflow_execution_service.py:581,706），policy 必須尊重它，否則背景工作會在開隔離的租戶裡讀不到資料。
• 開關怎麼讓 policy 讀到：開 session 時從租戶設定讀出、注入成 session 變數，policy 只比變數，不在每一列去查設定表。

8.2 挑哪些表

只挑客戶會說「這是 A 部門的」業務表，初估 8～12 張，A.1 盤點定案：

不挑的：工作紀錄、解析任務、子表（如 evidence_batch_files）、設定表。子表靠父表入口間接隔離，A.1 要確認沒有直接列出子表的 API 繞過父表。

8.3 開啟流程

1. 管理員在存取管理裡按「開啟部門隔離」。
2. 系統先產預覽清單：開啟後，每位使用者在每張表會少看到幾筆、哪些人會整張表看不到任何資料。
3. 客戶確認後才寫入開關，並記一筆稽核事件。
4. 關閉不需預覽，直接回到只看租戶。

預覽是這個功能的安全網：部門指派下錯一層，開了之後主管看不到自己部門的專案，而 RLS 擋掉的資料畫面上只是少了幾筆，不會報錯。

8.4 前置

• org_units.path migration 掃一次回填，保證每列有值且格式一致。DEV 目前沒有空值，但客戶舊庫未驗過；path 有誤，子樹比對就會靜默算錯。

8.5 不做

• 不把 43 張帶 org_unit_id 的表全改 policy——只挑業務表。
• 不提供「依角色決定看不看得到別部門」這類細規則；部門可見性只跟有效部門指派走。

9.1 範圍

第 4.2 節那 33 支 route，由 A.1 盤點逐支定出要掛的能力點。setup_route（設定精靈）在安裝當下還沒有任何帳號，A.1 要確認是否刻意不設守門，是的話登記成豁免清單而非漏網。

9.2 兩階段上線

新掛上去的能力點會自動進 *.*.*（系統管理員角色），管理員不受影響；一般角色要客戶自己勾。這條要寫進兩版的 release note：第一版預告「下一版會開始擋，請到存取管理頁補勾」，並附「只記錄」期間的統計讓客戶知道會擋到誰。觀察期長度與放行判準見 D5。

一個模組（D1）、四頁，取代今天的 /auth/role-manage、/auth/role-form、/auth/user-manage、/auth/user-form-mtrbac（FE config/router/index.js:93-122）。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
flowchart TB
  subgraph FE["存取管理模組（前端）"]
    ROLE["角色<br/>矩陣、pattern、JSON 匯出入"]
    ASSIGN["指派<br/>誰 × 角色 × 範圍 × 起訖"]
    CHECK["檢查存取<br/>有效能力點與來源"]
    USER["使用者<br/>帳號本身"]
  end
  subgraph BE["後端"]
    CAP["能力點清單<br/>（含顯示名、排序）"]
    RP["角色 pattern"]
    UR["user_roles 指派"]
    EXP["展開服務<br/>（與判定同源）"]
  end
  ROLE --> CAP
  ROLE --> RP
  ASSIGN --> UR
  CHECK --> EXP
  EXP --> RP
  EXP --> UR
  USER -.->|從使用者跳到指派| ASSIGN

10.1 角色

• 矩陣：列是「模組 → 資源」兩層樹（就是能力點名字的前兩段），欄是動詞。以 RoleForm 現有 TreeTable 三態矩陣為底（FE RoleForm.vue:456-516），抽成可重用元件。
• 每個勾選背後存的是 pattern，畫面另有一區列出「這個角色存了哪幾條 pattern」，讓人看得懂 grc.*.* 與一個個勾的差別。
• 系統管理員（*.*.*，is_system）：內建、不可刪、不可改內容、每租戶必有一個；畫面上整列鎖住，只能看、只能複製。
• 稽核主管／稽核員／唯讀（is_template）：出貨範例，客戶可以直接改、刪、複製。刪了或改壞了，用角色 JSON 匯入出貨預設那份即可還原（第 11 節）。範例內容在 A.1 定出能力點樹後才填。
• JSON 匯出、匯入（第 11 節）。
• 既有的 license 旗標與平台層過濾照搬（FE RoleForm.vue:236-240、:41-54、:171-220）。

10.2 指派

• 一筆指派＝誰 × 角色 × 範圍 × 起訖。本案範圍只開 tenant 與 org_unit；project 留給 FR-B。
• 範圍選部門時，畫面要寫清楚「這筆指派只對掛在該部門與子部門的資料有效；本租戶未開部門隔離時，等同全租戶有效」；若本租戶已開部門隔離，改寫成「他只看得到、只能操作該部門與子部門的資料」。
• 起訖日每筆指派各自設定，空白＝立即生效、永不到期。
• 三個入口：從「人」看（他有哪些指派）、從「角色」看（誰拿了這個角色）、從「範圍」看（這個部門有哪些指派）。
• 需要新元件：部門樹選擇器、日期區間選擇器——專案內目前都沒有（盤點 ③ 第 6 節）。

10.3 檢查存取

選一個人，列出他目前的有效能力點，每一列寫出：來自哪個角色、哪條 pattern、在哪個範圍、何時到期。另外標出三種「不必看矩陣」的豁免：帳號層 super_admin、角色 is_admin、平台管理員。這頁吃的就是判定層的展開服務，所以畫面上看到的＝API 實際放行的。本租戶開了部門隔離時，另列一區「他看得到哪些部門的資料」，同樣來自判定層的有效部門指派。

10.4 部門隔離設定

租戶層一個開關（D12，第 8 節），放在存取管理模組內。按下開啟先出預覽清單（每人每張表少看到幾筆、誰會整張表空掉），確認後才生效並記稽核事件。只有系統管理員能動。

10.5 使用者

只管帳號本身（基本資料、啟用停用、帳號層生效到期、匯入）。今天表單裡的角色指派欄（FE UserMTRBACForm.vue:548-578）移到「指派」頁，這頁只留一個連結跳過去。

{
  "name": "稽核員",
  "description": "執行稽核、可讀全部專案",
  "is_admin": 0,
  "capabilities": ["grc.*.read", "grc.audit-round.update", "oscal.ssp.read"]
}

• 用途：跨環境搬角色（DEV 調好搬到客戶機）、出貨角色（取代 SQL seed）、出貨範例被刪或改壞時匯入還原、給稽核當「這個角色當時被授予什麼」的證據。
• 匯入規則：每條 pattern 必須在目標環境的能力點清單裡至少命中一個，命中零個就整份報錯並列出哪幾條，不靜默跳過——靜默跳過會讓匯入後的角色比來源環境少權限，而且沒人發現。
• 不帶 id：以名字對應，同名角色由使用者決定覆蓋或另存。
• 系統管理員不可被匯入覆蓋：匯入檔內若有與內建系統管理員同名的角色，一律另存，不改內建那個。
• license 不在 JSON 管：匯入後若含未授權模組的能力點，沿用既有寫入端 license 守門（app/auth/service/role_app_service.py:54-91）。

其他：

• 快取一致性：多台 api／worker 行程時，快取放在各行程記憶體內會不同步，D3 的「清除」要能通知所有行程（或快取放 Redis）。
• jedi-iam 發版：判定層改在套件，開發期走 poetry path dependency，發版等決策者明示。
• 出貨基線：所有 migration 落地後要回報「出貨基線待重產」。

本節只寫範圍與風險，不展開設計。FR-B 另開時間由決策者與 PM 討論後定；FR-132 只替它預留一件事：capabilities.assignable_scopes 的值域含 project。

要做什麼：把專案成員角色（manager／reviewer／auditor／viewer）收進同一套「誰 × 角色 × 範圍 × 時效」，範圍多一層 project；專案內的按鈕改由能力點判定，成員角色變成「一組 pattern 的預設角色」。

為什麼至少要等 A.1：專案內每個按鈕要對到哪個能力點，取決於 A.1 定出來的能力點樹；樹沒定，FR-B 的對照表無從寫起。

已知的難處（盤點 ②）：

最後一條決定了 FR-B 的關鍵取捨：翻譯 main_role 必須連實例那份 XML 一起改，或在 _resolve_main_roles（app/flow_engine/service/stage_advance_service.py:584-591）做讀取時轉換。

• 盤點：inventory/01-authz-capabilities.md、inventory/02-project-roles-and-flow.md、inventory/03-frontend.md
• 授權守門決策表：common/authz/__init__.py
• 統一授權守門設計（FR-048）：docs/analysis/2026-07-07-unified-auth-guard-design.md
• 權限與選單系統設計說明書：docs/system-design/permission/Permission-System-權限與選單系統設計說明書.md
• license 第六軸與基礎設施豁免：common/authz/license.py
• 授權照基礎包／加值包分層：docs/features/FR-062-2608-license-management/design.md 第 6 節
• 新租戶排除清單：core/plugins/identity.py:89-95