本卡屬 FR-114（母卡 CM-2019），合回前整理稿 8.3 另開卡候選，決策者 2026-09-24 裁開。兩段式：先提案、首腦裁後再做。改出貨 seed，會動 scripts/sql 與 scripts/init 產生器。

問題是什麼（白話）

出貨公版只內建一個 Administrator 角色，客戶自建的角色要從零勾選權限。這批資安修正讓設備、資訊系統、掃描設定檔等下拉選單都改成要有對應的讀取權限（device.read、information-system.read、detection-profile.read），補權限 migration 只補給「升級當下已存在」的角色。之後客戶新建角色若沒勾到，就會看到「沒有權限」鎖住欄位；以後每加一道讀取守門都會再踩一次。長期正解是公版內建幾個常用角色範本，預先勾好讀取類權限，客戶複製或直接用。

在哪裡

scripts/init/gen_seed_sql.sh:19、:294、:326   出貨 seed 只帶 roles(Administrator)，且預期持有全部能力點
scripts/init/gen_capability_seed.sql           權限四表以 name 反查產生 INSERT（CM-1757）
scripts/init/README.md「出貨 seed 的去向」段   哪些 seed 在 04、哪些歸套件
scripts/sql/2026-09-22-fr114-asset-read-capability-backfill.sql、2026-09-23-fr114-detection-profile-read-capability-backfill.sql   本批補權限 migration（範本的寫法參考）

第一段：提案（做完停下）

• 盤點：DEV 全部能力點（capabilities）依「讀取類／寫入類／管理類」分群；列出目前所有 *.read 與前端下拉選單會打的讀取端點對應的能力點。
• 提案 2～4 個角色範本（例：一般成員、稽核人員、唯讀檢視者），每個列出預勾的能力點與理由；說明新裝（04 seed）與既有客戶升級（seed 類 migration，冪等、只在角色不存在時建）各怎麼帶；說明範本角色是否允許客戶修改、升級時會不會覆蓋客戶的修改（原則：不覆蓋）。
• 回寫本卡後停，狀態留 Not started，等首腦裁定段。

第二段：實作（首腦裁後）

• 照裁定寫 seed 類 migration（phase=seed、envs=*、冪等），更新 gen 產生器讓新裝也帶到；只套 DEV。

紀律

• 工作區 BE /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security（branch fix/security-b1），主 checkout 不動；不碰 pyproject／lock。
• 不重產 02／04 產物、不動 188 基線庫（基線重產由首腦另排）。DEV 資料庫第一段只准 SELECT。
• 註解只寫為什麼與陷阱；顯式 git add；commit message 結尾 Co-Authored-By；不 push、不切 branch。回寫不得含憑證。
• 做完（第二段）：commit → 本卡 append 白話補充 → 狀態改「修正待驗證」。

第一段回報：盤點＋提案（2026-09-24，runner；DEV 只做了 SELECT，沒改任何檔、沒 commit）

先講一個會改變做法的發現：新客戶的角色不是從 04 seed 來的

• 出貨 04 seed 裡的 Administrator 掛在 tenant 1（root，原廠殼）。客戶實際上班用的是設定精靈建的業務租戶，那個租戶的「System Manager」角色是 jedi-iam 的建租戶服務（jedi_iam/app/service/tenant_provisioning_service.py:_add_tenant_with_defaults）當場建的；之後在畫面上新增子租戶也走同一支。
• 角色是每個租戶各自一份（roles.tenant_id 必填，DEV 14 個角色沒有一個是 NULL；RLS 只讓租戶看到自己路徑下的角色）。沒有「全系統共用角色」這回事。