本卡屬 FR-132（母卡 CM-2510），A.2 資料地基第 1 張。依賴：T-1.6。建議 model：opus。

這張卡做什麼（白話）

capabilities 表今天只有 name／resource_type／action／is_platform。這張卡加六個欄位，並照 T-1.6 定出的全表把 123 個能力點改成三段式新名（例 project.approve → grc.project.approve）。舊名存進 legacy_name，舊的 resource_type 原值存進 license_module——授權照已簽出在客戶手上，license 判定之後要讀這欄才不會把客戶整個模組判成「沒買」。

這張只改資料表與資料，不改判定邏輯；改完之後判定仍讀舊名會壞，所以新舊名並存（D11）由後續 T-3.3 讓判定兩邊都認。本卡結束時 DEV 上程式仍照舊名判定——套用後要確認 BE 沒有立刻 403，若會壞就在同一卡內先只加欄與回填、改名延後到 T-3.3 同步套，回寫說明。

在哪裡

~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/<日期>-fr132-capabilities-rename.sql      新 migration
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/models/capability.py:15-27      ORM 同步加欄
~/Projects/Billows/Audit-Manager/compliance-manager-be/core/host_capabilities.py      主專案自有能力點宣告（name/resource/action）
各 jedi-* 套件 plugin/contract.py 的 CAPABILITIES      套件能力點宣告（改名來源）
~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/build/flatten_pkg_migrations.sh:169-250      宣告攤平成 _capabilities.sql（upsert ON CONFLICT (name)）
~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/2026-09-25-fr114-module-frame-read-capability-backfill.sql      既有「補能力點」migration 寫法參考

怎麼做

• 加欄：module varchar(50) NOT NULL（三段名第一段，CHECK name LIKE module || '.%'）、display_name varchar(200)（i18n key，矩陣顯示用）、sort int、assignable_scopes text[]（值域 tenant／org_unit／project，project 為 FR-B 預留）、license_module varchar(100)、legacy_name varchar(100)。resource_type 改存新資源名（三段名第二段），action 存動詞，is_platform 不變。
• 改名順序：先 UPDATE ... SET license_module = resource_type, legacy_name = name，再依 docs/features/FR-132-2610-access-management/inventory/a1-capability-tree.md（T-1.6 產出的能力點全表） 逐列改 name／module／resource_type。不要用名字推導，照表一對一寫 VALUES 對照。
• 補 system.system-config.read；9 個孤兒（cloud_integration.update、feedback.export、system_config.create/delete/update、workflow.* 四個）依 T-1.6 結論刪或改名。刪之前確認 role_capabilities、route_capabilities 沒有引用（有就一併處理）。
• 🔴 能力點宣告也要改：每次升級 migrate.sh 第三輪會重跑 _capabilities.sql（由 core/host_capabilities.py 與各套件 plugin.CAPABILITIES 產生，ON CONFLICT (name) upsert）。只改 DB 不改宣告，下次升級舊名會被 upsert 回來變成重複列。宣告改名涉及多個 jedi 套件——先回寫本卡問決策者：宣告是本卡一起改，還是 upsert 改成以 legacy_name 對應、宣告延後到 T-3.3。
• jedi-iam ORM infra/models/capability.py 同步加欄（套件改動走 path dependency）。
• 收尾 INSERT public.schema_migrations，只套 DEV。

要寫測試

• migration 自檢段（SQL 內 DO block）：每列 name 符合 ^[a-z0-9-]+\.[a-z0-9-]+\.[a-z0-9-]+$、module = split_part(name,'.',1)、license_module 非空——任一不符 RAISE 讓整支 rollback。
• 突變：把某列 license_module 故意改成 NULL，確認自檢會擋。

驗收條件

• DEV 套用後每列 name 符合三段式、module 與 name 前綴一致、license_module 等於舊 resource_type。
• 能力點總數與 T-1.6 全表一致。

手測