A.1 盤點：grc 專案稽核模組端點 × 三段式能力點

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

• 範圍：專案（project）、稽核輪次與其下的 AP／AR／POA&M、任務（job，含成員、指派、留言、佐證）、流程執行（api/flow_engine/ 的任務提交與稽核階段推進）、專案摘要報告、資訊系統（information-system）、workflow 能力點。
• 主專案 route 檔 16 支、92 個 method：api/flow_control/routes/ 4 支、api/project/routes/ 4 支、api/project_summary_report/routes/ 2 支、api/flow_engine/routes/ 6 支（30 個）。另有 1 個已註解停用的 Resource（ProjectMenuResource，/projects/menu），不計入。
• 外部套件 route 檔 10 支、33 個 method：jedi-compliance-audit 2 支（5）、jedi-task-platform task 5 支（12）、jedi-task-platform participant 2 支（10）、jedi-asset 1 支（6）。讀的是 .venv/lib/python3.11/site-packages/ 內實際執行的版本。
• 合計 26 支檔、125 個 method。其中流程範本管理 11 個屬 T-1.2 範圍，只列不定名。jedi-flow-engine 套件本身沒有 route。
• DEV 查詢時間：2026-10-06 16:18（本機 localhost:5432/guidant_ai_dev）。範圍內舊能力點 23 個。

1. 125 個 method 裡，只有 25 個掛了能力點守門。 主專案 8 個（專案列表／明細／改／刪／批次刪、建專案）、流程範本 11 個（flow_template.*），jedi-asset 資訊系統 6 個。其餘 100 個只有 jwt_required（多數加授權模組軸 require_license），專案內的權限全靠 service 層的專案成員角色檢查。
2. audit.* 四個能力點一支 route 都沒守。 它們只出現在三處：稽核管理頁的選單綁定（/project/audit-manage）、出貨角色範本、FE 儀表板的 hasCap('audit.read')。整個稽核輪次／AP／AR／POA&M 共 36 個 method 都沒有公司層守門。
3. project.approve／project.assign／project.export 三個獨立動詞一支 route 都沒守。 只綁在專案列表頁選單與角色範本，FE ProjectListView 只讀 CREATE／UPDATE／DELETE。下面主表把「指派」接到專案成員端點、「匯出」接到任務匯出；approve 沒有任何對應功能（任務提交與審核關卡走 /flow-engine/task/complete 與 .../stage/advance，都不是它），名字移給 grc.audit.approve（審閱標記）。
4. 兩層守門要分開看：主表「現有守門」欄先寫公司層（能力點），再寫「成員角色：」後的專案層檢查。成員角色守門是「你在這個專案裡是什麼身分」，能力點是「公司准不准你碰這類功能」，有前者不等於有後者。
5. 個人視角端點（我的任務、我的稽核、儀表板摘要、我被指派的專案下拉）只回「自己參與的」資料，service 層不做角色檢查。新名照主資源 read 填，定案要掛守門；上線前要確認出貨角色範本都帶了對應 read。

grc 模組 7 個資源，資訊系統歸 asset 模組：

• grc.audit 一組涵蓋稽核輪次、評估計畫（AP）、評估結果（AR，含風險）、矯正計畫（POA&M）。這四塊誰能寫，由專案層的成員角色分（AP／AR 給 auditor／manager，POA&M 給 manager），公司層只分「能不能看、能不能改」。
• workflow.* 四個刪除，不給新名。
• 「每個資源固定四個」照規則全開；某資源今天沒有 delete 或 create 端點的，仍要建出來。

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

守門縮寫：J＝jwt_required；L(x)＝require_license("x")；C(x)＝require_capability("x")。專案層守門寫「成員：」＋放行角色（參與者＝任何成員）。路徑前綴：主專案 grc 段＝/api/1.0/grc，其餘＝/api/1.0。

專案（grc.project）

稽核：輪次（grc.audit）

稽核：評估計畫 AP（grc.audit）

稽核：評估結果 AR，含風險（grc.audit）

稽核：矯正計畫 POA&M（grc.audit）

任務（grc.job）

任務留言（grc.job-comment）

流程執行（api/flow_engine，歸 grc）

任務提交、審核關卡的通過／退回、稽核階段推進都在這一段，project.approve 跟它們無關。流程執行的 19 個 method 全部只有 jwt_required，沒有 license 軸。

佐證開獨立資源 grc.job-evidence 的理由跟留言相同：「只能看任務、但要上傳佐證」的執行人，不必拿到改任務本身的權限。

流程範本管理（T-1.2 範圍，只列不定名）

api/flow_engine/routes/flow_template_route.py，11 個 method 已掛 flow_template.*（:37-147），綁 /flow/template-manage 頁。讀取用 require_capability("flow_template.read", "project.create", mode="any")（:23-25），因為建專案第一步要選流程範本。改 project.create 名字時這一處要跟著改。

專案摘要報告（grc.summary-report）

project-summary-report.* 四個舊名在 DEV 有綁 /project-summary-report 頁選單，但後端沒有任何 route 守它們。

資訊系統（asset.information-system）

能力點名不是寫死的：route 讀 rt.config.information_system_*_capability，預設值在套件 jedi_asset/plugin/contract.py:81-84。改名時改這四個預設值（或宿主注入），route 不用動。

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

project.approve、project.assign、project.export、audit.*（4）、project-summary-report.*（4）、workflow.*（4），共 15 個。前 11 個有綁選單、出貨角色範本也有給，孤兒不等於沒用：它們目前決定「選單看不看得到」，只是端點沒跟著守。改名後由主表對應的 route 掛上守門。workflow.* 才是真正什麼都沒用到。

1. 資訊系統歸 asset 模組，名字 asset.information-system.*。它跟設備同屬資產：程式同一支套件（jedi-asset）、各自有獨立管理頁，專案與 SSP 只是挑選它來用，只需要 read。設備那份盤點要採用同一個模組名 asset。能力點名由套件 jedi_asset/plugin/contract.py:81-84 的預設值決定，改那四個值即可，route 不用動。
2. workflow.* 刪除。 AO 流程執行走專案成員角色，流程範本走 flow_template.*，兩者都沒用到它。要動三處：套件 jedi_flow_engine/plugin/contract.py 的 CAPABILITIES 清空；core/plugins/identity.py 排除清單的 "workflow" 拿掉；migration 刪除四個能力點與 Administrator 角色的綁定。
3. 稽核保留一組 grc.audit.*，不拆成輪次／AP／AR／POA&M 四組。
   • 誰能寫哪一塊，專案層成員角色已經分好（AP／AR：auditor、manager；POA&M：manager），公司層再拆一次是同一件事管兩遍，且兩層可能互相矛盾。
   • 拆開後，「專案裡是稽核員、但公司角色少勾一格」會變成按鈕 403 且沒有錯誤訊息，正是本 FR 要避免的失敗形狀。
   • 公司層真正要分的是「能看／能改」，read 與 update 已足夠。
   • 反悔條件：客戶要求「矯正計畫交給被稽核單位的人寫、但不能碰稽核結果」時，把 POA&M 拆成 grc.poam.*，其他三塊不受影響。
4. project.approve 沒有對應功能。 任務提交與審核關卡走 /flow-engine/task/complete，稽核階段審核走 .../stage/advance，問卷審核屬問卷模組，都不是它。名字移給第 5 項。
5. 審閱標記用 grc.audit.approve，控制項層與 AO 層打勾、取消共用一個。用 approve 不另創 review，是為了守住獨立動詞只有四類的規則；跟 update 分開，客戶才能做到「外部顧問可寫判定，最後審閱確認留給內部人員」。
6. 風險不另開資源，跟評估結果一起，屬 grc.audit。
7. 啟動任務執行、強制開始任務都歸 grc.job.assign。 兩者本質是派工，有權指派任務的人就要能派發。
8. 任務留言獨立成 grc.job-comment；佐證比照獨立成 grc.job-evidence。
9. 個人視角端點掛 read 守門（我的任務、我的稽核、儀表板摘要、我被指派的專案下拉、待辦數字）。上線前要確認出貨角色範本都帶了 grc.project.read、grc.job.read、grc.audit.read，否則只有成員身分的使用者會突然 403。

決策者已裁「要補」。本卡只讀，修正另開卡（由首腦排入 A.2 或獨立一棒）。

1. 任務留言列表不驗專案成員：GET /grc/job-executions/<je>/comments 的 service（jedi_task_platform/task/app/service/job_comment_service.py:27）直接查，知道 job_execution uid 的登入者就能讀。要補成員檢查，比照同檔 add_comment 的 assert_project_participant。
2. 專案摘要報告整組沒有授權模組檢查：api/project_summary_report/routes/ 9 個 method 都沒有 require_license。成員檢查有（列表以參與專案過濾，單筆走 _require_participant）。
3. 刪除專案有管理員旁路：app/flow_control/service/project_service.py:547 起，is_admin 可刪任意專案，跟「明細讀取一律不給 admin 旁路」不一致。
4. 流程圖定義端點沒有任何檢查：GET /flow-engine/process-definition/<uid>（api/flow_engine/routes/flow_engine_route.py:27），任何登入者給 uid 就能讀流程範本 XML。呼叫它的 WorkflowSetupForm 是舊入口，先確認還有沒有在用，沒用就退役，有用就補守門。歸屬由 T-1.2 一併處理。

• core/host_capabilities.py（PROJECT、PROJECT_SUMMARY_REPORT）
• core/role_templates.py（:13、:15、:25、:33-41、:46-47）
• 套件 contract：jedi_compliance_audit/plugin/contract.py（audit.*）、jedi_asset/plugin/contract.py:81-84（information-system 預設名）、jedi_flow_engine/plugin/contract.py:29-32（workflow 刪除）
• 範圍外放行條件：api/module_frame/routes/module_frame_route.py:26、api/flow_engine/routes/flow_template_route.py:24
• DEV route_capabilities：/project/projects、/project/audit-manage、/project-summary-report、/information-system/manage 四頁的綁定
• FE：DashboardView.vue 的 hasCap('project.read')／hasCap('audit.read')、userUtil.js；ProjectListView 讀的是頁面動作字（CREATE／UPDATE／DELETE），三段式動詞不變就不用改

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