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

這張卡做什麼（白話）

授權照上的「模組」鍵今天就是能力點的 resource_type。T-2.1 把 resource_type 改成新資源名後，若 license 判定繼續讀它，已出貨客戶手上的照對不上，整個模組會被判「沒買」。這張卡把 license 判定、寫入端守門、基礎設施豁免清單全部改讀 license_module（存的是舊 resource_type 原值）。

在哪裡

~/Projects/Billows/Audit-Manager/compliance-manager-be/common/authz/license.py:79-80      能力點 → license 模組鍵
~/Projects/Billows/Audit-Manager/compliance-manager-be/common/authz/license.py:107-121      INFRASTRUCTURE_MODULES 基礎設施豁免七項
~/Projects/Billows/Audit-Manager/compliance-manager-be/common/authz/license.py:283-297      判定讀 resource_type
~/Projects/Billows/Audit-Manager/compliance-manager-be/app/auth/service/role_app_service.py:54-91      角色寫入端 license 守門（未授權模組的能力點不能勾進角色）

怎麼做

• 上面三處凡是拿 resource_type 當 license 鍵的，改讀 license_module。先 grep -rn resource_type common/authz/ app/auth/ 找全，不要只改這幾行。
• INFRASTRUCTURE_MODULES 的值保持舊 resource_type 原值（smtp-config、ldap-config、log-forwarding、security-policy、ai-call-log、ai-quota、scan-zone）——它比對的就是 license_module。在常數旁一行註解寫明「比對 license_module，不是新資源名」。
• jedi-iam 的 capability entity／repo 若沒有帶出 license_module，補上（path dependency）。
• common/authz/ 屬授權核心：本卡當次跑 ddd-compliance-reviewer。

要寫測試

• test/ 下找既有 license 測試（grep -rln license test/），補：能力點 name 改新名、license_module 為舊值時判定結果不變。
• 突變：把判定改回讀 resource_type，測試要紅。

驗收條件

• 舊授權照在改名後 DEV 開同樣的模組；未授權模組的能力點仍不能勾進角色。

手測

• DEV：授權狀態頁看已授權模組清單與改前相同。
• DEV：拿一張不含問卷包的照（或 DEV 模擬），在角色頁勾問卷能力點 → 被擋。

紀律

• 只動 DEV：migration、資料修改、部署一律只碰本機 DEV，絕不碰 STG／POC（POC 等同 production）。唯讀查詢任何環境都可以。