A.1 盤點：system 系統設定＋iam 身分與存取 端點 × 三段式能力點

卡片 CM-2514（FR-132 T-1.4）。唯讀盤點，不改程式、不改 DB。

• 範圍：system 系統設定（smtp-config、ldap-config、notify_config、security-policy、log-forwarding、system_config、system-menu、issue-integrate-config、license，以及走同一組設定端點的 storage-config／AI 服務／Drive 應用程式設定、支援頁）＋ iam 身分與存取（user、role、department、tenant，含登入／MFA／改密碼／第三方登入綁定）。
• 主專案 route 檔 8 支、15 個 method：api/system_config/routes/ 2 支（8）、api/notify_config/routes/ 1 支（1）、api/setup/routes/ 1 支（2）、api/support/routes/ 2 支（2）、api/version/routes/ 2 支（2）。api/user_auth_provider/ 只剩 __pycache__，route 已上移 jedi-iam。
• 外部套件 route 檔 19 支、81 個 method：jedi-iam 12 支（51；卡上寫 13 支，實際 12 支，routing.py 凍結 URL 43 條）、jedi-system-core 2 支（11）、jedi-notification 1 支（1）、jedi-issue 1 支（1，label_route；同套件的 feedback_route 屬 T-1.5）、jedi-log（jedi_api_log.forwarding）1 支（3）、jedi-license-runtime 2 支（14）。讀的是 .venv/lib/python3.11/site-packages/ 內實際執行的版本。
• 合計 27 支檔、96 個 method。
• DEV 查詢時間：2026-10-06 17:28（本機 localhost:5432/guidant_ai_dev）。範圍內舊能力點 45 個（另 storage-config 4 個屬 T-1.3，本表只列被本範圍 route 用到的部分）。

1. 設定類的「讀」幾乎都沒有能力點守門。 GET /system/config/<group>/<key>、GET /system/configs/<group>、GET /system/config/<uid> 三支只驗登入；service 層只多兩道（AI／Drive 鎖平台管理員、SMTP／LDAP／登入政策鎖總部），沒有任何 *.read。登入的一般使用者可以讀通知設定、議題整合設定、儲存設定（機密欄已遮罩）。寫入那側有按 GROUP 分流守門，讀這側沒有。
2. system_config.* 不是純孤兒。 它是 GROUP 分流的 fallback（core/plugins/system_core.py:88-93）：對照表沒登記的 group（DEV 有 GOOGLE_DRIVE_APP_CONFIG、WEB_IDEL_CONFIG；AI_QUOTA 另被專門擋掉）寫入時就要 system_config.update。Drive 應用程式設定頁（/system/drive-app-config）的儲存走的正是這條，選單卻綁 storage-config.*。只有 Administrator 角色持有 system_config.*，實務上靠平台管理員那道把關才沒出事。
3. 授權照管理端整組沒用能力點。 /license/tenants*、/license/upload、/license/lc/plans 9 支只疊平台管理員守門；license.read 只綁 /license/manage 選單。租戶自救 5 支只驗登入是刻意的防死鎖設計。
4. 幾個動作的守門動詞與語意不符：停用／啟用使用者守 user.create、LDAP 連線測試守 ldap-config.create、改租戶只守平台管理員（tenant.update 沒有 route 用）。
5. 第三方登入綁定的查詢沒有本人檢查：GET /auth-providers/user/<user_uid> 只驗登入，service（jedi_iam/app/service/user_auth_provider_service.py:87）不呼叫同檔的 _assert_caller_can_manage，任何登入者帶別人 uid 就能看到對方綁了哪個 LDAP／AD 帳號。新增與刪除兩支有本人或 user.update 檢查。
6. 安裝精靈是刻意豁免，證據完整，結論見〈setup_route 結論〉。

system 模組（基礎設施，皆不受授權照管制或屬原廠）：

iam 模組：

• 設定類的「測試送出」（測試信、通知測試、log 轉發測試、LDAP 連線測試）建議一律歸該資源的 update，不開 send：沒有客戶會要「能改設定但不能測」。見定案 3。
• storage-config 歸 system；AI 服務設定與 AI 證據分類設定改 ai.ai-provider-config.*（新開，歸 ai 模組）、Drive 應用程式憑證歸 platform 層、支援頁歸 platform.support.*（見定案 2）。

欄位：route 路徑 ｜ HTTP ｜ 程式位置 ｜ 現有守門 ｜ 新三段名 ｜ 現有能力點 ｜ 對應 UI ｜ 可指派範圍層 ｜ 備註。

守門縮寫：J＝jwt_required／套件 auth_required；C(x)＝require_capability("x")／套件 capability_required("x")；G(action)＝按 GROUP 分流的 assert_config_capability(group, action)（對照表 core/plugins/system_core.py:63-79：STORAGE_CONFIG→storage-config、SMTP→smtp-config、THIRD_PARTY_LOGIN→ldap-config、NOTIFY_CONFIG→notify_config〔create／delete 改判 update〕、ISSUE_INTEGRATE_CONFIG→issue-integrate-config、RUNTIME_CONFIG→security-policy、AI_PROVIDER_CONFIG→storage-config；其餘 group fallback system_config.*）；PA＝平台管理員（require_platform_admin）；HQ＝總部層級（SMTP／LDAP／登入政策的讀寫、log 轉發的寫）。路徑前綴一律 /api/1.0。

泛用設定端點（system-config，依 group 落到各設定頁）

system_config_route 只驗登入是指 handler 外層；寫入三支在 handler 內呼叫 G(...)，讀取三支什麼都沒呼叫。套件與宿主兩支 system_config_route 的分工：套件管純 CRUD（新增、by-uid 讀改刪、by-group 列表），宿主管吃產品規則的（by-group/key 讀改刪、出廠快照還原、AI 模型下拉）；兩邊都注入同一支宿主包過的 GuardedSystemConfigService（app/system_config/service/guarded_system_config_service.py）。

設定頁專屬端點

系統選單字典（system-menu）

授權照（license）

套件 jedi_license_runtime/api/routing.py:43-57 的 ROUTE_TABLE 宣告兩級：admin＝J＋PA（宿主 core/plugins/license.py:325-327），login＝只有 J（license.py:332，刻意）。

支援頁、版本、安裝精靈

使用者（iam.user）

角色（iam.role）

部門（iam.org-unit）

租戶（iam.tenant）

免登入與本人端點（豁免）

登記為豁免，不是漏網。 依據：

1. 檔頭明文宣告未登入可達的理由（api/setup/routes/setup_route.py:1-50）：首次啟動時一個帳號都沒有，JWT 不可用；改以 install.sh 印在終端的一次性設定碼（X-Setup-Token）當身分證據；端點刻意只留兩支。
2. 有「已安裝就拒絕」的閘門，且 fail-closed：POST /setup/provision 先過 _require_setup_token()（setup_route.py:62-76），service 第一步 _assert_not_initialized()（app/setup/service/setup_wizard_service.py:167、:302-313）——已開通回 409，DB 查不出狀態時也當已開通擋下。判據是 DB 內是否已有業務租戶使用者，不是記憶體旗標，重啟不失效。
3. token 驗證 fail-closed：common/setup/setup_token.py:81-97，磁碟上沒有 token 檔一律 False，timing-safe 比對。
4. GET /setup/status 分級：無 token 只回 is_initialized 與 deployment_mode（開站看畫面就知道的資訊），機器指紋要有效 token 才給（setup_route.py:100-104）。
5. 授權照豁免是有意的：不掛 @require_license，並在 common/middleware/license_readonly_mw.py 的 _EXEMPT_PREFIXES 補了 /setup/（裝機當下必然無照）。

新名：不開能力點，在能力點登記表記為「豁免：安裝精靈（setup token＋已開通即封）」。

沒有任何 route 用到的能力點（孤兒）

smtp-config.read、ldap-config.read、notify_config.read、issue-integrate-config.read、system-menu.read、license.read、tenant.update，共 7 個。全部有綁選單、決定「選單看不看得到」，只是端點沒跟著守——前四個正是〈先看這幾點〉第 1 條的讀取缺口。卡上說的「system_config.* 三個都是孤兒」不成立：它們沒有綁選單，但寫入守門會 fallback 到它們。

不販售資源（TENANT_ADMIN_EXCLUDED_RESOURCE_TYPES）

core/plugins/identity.py:89-95 列的五個裡，DEV 只有 workflow 還有能力點（workflow.create/read/update/delete，T-1.1 已定刪除）；cruise-project、dashboard、resource、report 在 DEV 都沒有任何能力點。workflow 刪掉後這份清單可以清空。

• POST /role、PUT /role/<uid> 的 request：capabilities: List[int]——能力點 id 陣列（jedi_iam/api/serializers/role.py:13）。改成三段式名或 pattern 時這裡的型別要變。
• 角色 response：capabilities: List[CapabilityResponse]，每筆 id／name／description／resource_type／action／is_platform（role.py:43、capability.py）。
• GET /capabilities/menu：同 CapabilityResponse 陣列，角色矩陣的欄。
• GET /ui-routes：route 樹，每個節點帶 route_capabilities、capabilities_count（serializers/ui_route.py:23-26），角色矩陣的列。
• GET /user/web-menu：每個選單項帶 operations: List[str] 與 capabilities: List[Dict]（serializers/user.py:136-142）。
• POST /user、PUT /user/<uid> 的 request：user_roles: List[{role_uid, tenant_id, org_unit_id, scope, is_default, start_at, end_at}]（serializers/user_role.py:4-11）——這就是指派。UserProfileRequest 刻意不收它。

第 1～4 條併入 T-4.6（CM-2542），在該卡編為第 6～8 條（第 3、4 兩條守錯動詞合成一條）；第 5 條屬改名時順手修，由 A.2／A.4 帶走，不併。

1. 設定讀取三支沒有 read 守門：GET /system/config/<group>/<key>（system_config_route.py:149）、套件 GET /system/configs/<group>、GET /system/config/<uid>。修法對稱寫入側：route 呼叫 assert_config_capability(group, "read")（by-uid 用 resolve_group_for_uid）。注意 /system/configs/<group> 是套件 route，要動 jedi-system-core。上線前確認出貨角色範本都帶了各設定頁的 read。
2. 第三方登入綁定的查詢無本人檢查：get_user_auth_providers 補呼叫 _assert_caller_can_manage(user_uid)（jedi-iam 套件內）。
3. 改狀態守錯動詞：/user/change-status/<uid> 從 user.create 改為 iam.user.update。
4. LDAP 連線測試守錯動詞：/ldap/connect-test 從 ldap-config.create 改為 system.ldap-config.update。
5. 管理端讀取只守平台管理員、沒守 read：/system/menus、/system/category-menu 補 system.system-menu.read；license 管理端照定案 4 補 platform.license.*（平台管理員那道保留）。

決策者 2026-10-06 逐條裁決。

1. system.system-config 保留並補 read；GOOGLE_DRIVE_APP_CONFIG 正式登記進 GROUP 對照表，Drive 設定頁不再靠 fallback。fallback 只當「未登記 group 的兜底」。理由：fallback 不能拿掉（未登記 group 要有最嚴的門），但原本 Drive 頁「選單綁 storage-config、儲存要 system_config」是兩套門鎖，靠平台管理員那道才沒出事。
2. storage-config 一顆開五門，全拆。 儲存設定頁 → system.storage-config.*；AI 服務設定頁＋AI 證據分類設定 → ai.ai-provider-config.*（新開，歸 T-1.5 定案的 ai 模組）；Google Drive 應用程式憑證 → platform 層（原廠，具體資源名由 T-1.6 定）；支援頁 → platform.support.*（T-1.5 已裁）。storage-config 歸屬爭議結論：system。理由：五頁鎖的層級不同（AI、Drive 鎖平台管理員，儲存不鎖），共用一顆能力點無法分別授權。
3. 設定頁「測試送出」四支（測試信、通知測試、log 轉發測試、LDAP 連線測試）一律歸該資源 update，不開 send。 理由：沒有客戶要「能改設定但不能測」；log 轉發套件也已刻意把測試掛在寫入欄。
4. 授權照原廠管理端 9 支移到 platform.license.*，不留 system。 動詞：read、assign（指派、向 LC 請新照）、update（停權、解除、展延）、import（上傳照檔），is_platform = true；後端平台管理員判定保留再加能力點，兩道都過。租戶自救 5 支維持只驗登入（防死鎖，不變）。理由：這是原廠對租戶的操作，放 system 會讓客戶以為自己能管授權。
5. 支援頁已隨 T-1.5 第 5 條裁定 platform.support.read／.export，本卡只引用不重裁。
6. /users/menu、/org-units/menu 豁免（跨模組挑人挑部門，只驗登入）；/capabilities/menu、/ui-routes → iam.role.read；/tenants/menu → iam.tenant.read。/roles/menu 守 role.read 的副作用（只有 user.create 的人在使用者表單拿不到角色下拉）留 A.3 處理。
7. 改租戶 PUT 改守 iam.tenant.update，平台管理員那道保留（兩道都過）；A.3 實作時先查清 service 是否會動 parent_id，再決定能否拿掉。
8. 部門資源名用 iam.org-unit，不用 department。 決策者原話：「跟程式統一才不會亂掉，以前已經改版過」。連帶：舊名 department.* → iam.org-unit.*；畫面顯示名由前端 i18n 處理，A.5 帶走。

沿革見 FR-132-LOG.md 與 git log。