本卡屬 FR-132(母卡 CM-2510),A.1 第 4 份盤點:system 系統設定(smtp-config、ldap-config、notify_config、security-policy、log-forwarding、system_config、system-menu、issue-integrate-config、license)+ iam 身分與存取(user、role、department、tenant)。只讀不寫。

這一棒在做什麼(白話)

把「system 系統設定(smtp-config、ldap-config、notify_config、security-policy、log-forwarding、system_config、system-menu、issue-integrate-config、license)+ iam 身分與存取(user、role、department、tenant)」底下每一支需要登入的 API,逐支對到一個新的三段式能力點名字(例 grc.project.approve),並記下它現在掛了什麼守門、對應哪個畫面。外部套件(jedi-*)自帶的 route 一併列入——只看主專案 api/ 會漏掉整個模組。這張表是下一階段改名 migration 與補守門的唯一依據,漏一支就是上線後某個按鈕永遠 403 且沒有錯誤訊息。

為什麼切這一塊

iam 是本案自己要改的那塊(角色、指派的端點都在 jedi-iam),主專案 api/ 完全看不到;system 則有 system_config 缺 read、setup_route 疑似刻意不守等特例,需要一份專門把它們釐清。

重點看什麼

首腦讀過盤點後認為最容易出錯的地方,是思考起點不是檢查清單:

已知背景

粒度與命名規則(照這個定新名)