本卡屬 FR-132（母卡 CM-2510），A.1 第 3 份盤點：detection 檢測（device、remote-agent-manage、detection-profile、plugin、scan-zone）＋ evidence 證據（cloud_integration、storage-config）＋ survey 問卷。只讀不寫。
把「detection 檢測（device、remote-agent-manage、detection-profile、plugin、scan-zone）＋ evidence 證據（cloud_integration、storage-config）＋ survey 問卷」底下每一支需要登入的 API，逐支對到一個新的三段式能力點名字（例 grc.project.approve），並記下它現在掛了什麼守門、對應哪個畫面。外部套件（jedi-*）自帶的 route 一併列入——只看主專案 api/ 會漏掉整個模組。這張表是下一階段改名 migration 與補守門的唯一依據，漏一支就是上線後某個按鈕永遠 403 且沒有錯誤訊息。
這三塊幾乎全住在外部套件裡、又各含一個授權照加值包（檢測三合一、雲端整合、問卷），模組邊界切錯會讓客戶「買了某包」在矩陣上散成兩區；需要一份專門確認加值包整包落在同一模組。
首腦讀過盤點後認為最容易出錯的地方，是思考起點不是檢查清單：
remote-agent-manage、detection-profile、plugin 必須同一模組；cloud_integration 一個模組；survey 一個模組。產出表末尾附一張「加值包 → 模組」對照驗證。plugin.* 能力點宣告在 jedi_detection/plugin/contract.py，查它守哪支 route。scan-zone 是基礎設施豁免（common/authz/license.py:107-121 的 INFRASTRUCTURE_MODULES），不受授權照管制但仍要歸模組。api/cloud_integration/routes/ 4 支（含 google_drive_webhook_route.py——webhook 是外部呼入，確認是否刻意不設守門，是就標豁免）；api/remote_agent/routes/agent_file_route.py。storage-config 歸屬爭議：存證據檔但屬機房設定，evidence 或 system 待首腦裁；宣告在 jedi_file_upload/plugin/contract.py，也盤 jedi-file-upload 的 upload_file_route.py。cloud_integration.update：查是否真的沒人用。survey.response.* 之類獨立資源。cloud_integration/ 三支已守。public.devices、compliance.evidence_batches、compliance.detection_executions、survey.surveys——順手記下每張表有沒有 API 直接列它的子表（例 evidence_batch_files）而繞過父表，寫在產出檔「D12 觀察」小節。<模組>.<資源>.<動詞>，三段小寫，資源名內部用連字號（ldap-config，不是 ldap_config）。前兩段就是角色矩陣的兩層分組，不另建群組表。