本卡屬 FR-132（母卡 CM-2510），A.1 第 1 份盤點：grc 專案稽核模組（project、audit、workflow、project-summary-report、information-system）。只讀不寫。

這一棒在做什麼（白話）

把「grc 專案稽核模組（project、audit、workflow、project-summary-report、information-system）」底下每一支需要登入的 API，逐支對到一個新的三段式能力點名字（例 grc.project.approve），並記下它現在掛了什麼守門、對應哪個畫面。外部套件（jedi-*）自帶的 route 一併列入——只看主專案 api/ 會漏掉整個模組。這張表是下一階段改名 migration 與補守門的唯一依據，漏一支就是上線後某個按鈕永遠 403 且沒有錯誤訊息。

為什麼切這一塊

grc 是客戶天天用的主線，現有能力點最多（project 一個資源就有 7 個動詞），也是 33 支漏網 route 裡 grc 佔 8 支的地方；專案內按鈕另有成員角色守門，兩層容易混淆，需要獨立一份把公司層這層理清楚。

重點看什麼

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

• J 組 8 支只驗登入：api/flow_control/routes/assessment_plan_route.py、job_force_start_route.py、job_route.py；api/project/routes/ap_docx_import_route.py、ar_import_route.py、audit_round_route.py；api/project_summary_report/routes/project_summary_report_route.py、project_summary_report_history_route.py。每支都要給新名。
• service 層成員角色守門 ≠ 能力點守門：J 組多數在 service 層已有專案成員角色檢查（manager/auditor…）。「現有守門」欄要分開寫兩層，不要因為有成員角色守門就填「已守」。
• 外部套件：jedi-task-platform 7 支（task_assignee、project_participant、job_batch_complete、dashboard、job_comment、task_execution、job_import）、jedi-compliance-audit 2 支（auditor_dashboard、review）。
• 跨資源動作：AP 匯入、AR 匯入、從 SSP 產 AP——照「歸被產出的資源」規則給 grc.assessment-plan.*／grc.assessment-result.* 之類新資源，不要塞進 project。
• workflow 資源：4 個能力點（create/delete/read/update）全是孤兒、且在新租戶排除清單 TENANT_ADMIN_EXCLUDED_RESOURCE_TYPES（core/plugins/identity.py:89-95）。標「建議刪除或併入」並寫理由。
• information-system 歸屬爭議：它是 SSP 受評範圍的支撐資料也是專案設定項，grc 或 oscal 待首腦裁。程式在 jedi-asset（information_system_route.py），也請一併盤。
• 現有獨立動詞：project.approve、project.assign、project.export 是全系統僅有的幾個非 CRUD 動詞，確認它們實際守哪些 route。

已知背景

• 盤點 ① 第 3 節：api/ 下 61 支有 jwt_required 的檔，G 組 28 支有守門、J 組 33 支只驗登入（僅供對照，以你實查為準）。
• 現有能力點宣告：主專案自有的在 core/host_capabilities.py（PROJECT 等 tuple），套件的在各套件 plugin/contract.py 的 CAPABILITIES。
• 出貨範本角色引用的能力點：core/role_templates.py（project.read、audit.*、project-summary-report.read…），改名後這裡也要跟著改，表內備註標出。

粒度與命名規則（照這個定新名）

• 格式 <模組>.<資源>.<動詞>，三段小寫，資源名內部用連字號（ldap-config，不是 ldap_config）。前兩段就是角色矩陣的兩層分組，不另建群組表。