本卡屬 FR-132（母卡 CM-2510），A.4 守門補齊第 6 張，來源是 T-1.1（CM-2511）盤點發現。依賴：A.3 判定層完成後才做。決策者 2026-10-06 已裁「要補」。建議 model：opus。

這張卡做什麼（白話）

T-1.1 盤點 grc 模組時發現四個地方「該擋沒擋」：有人只要知道某個編號就能讀到不該讀的資料，或管理員能繞過一般規則。本卡把這四個缺口補上守門。

缺口一：任務留言列表不驗專案成員

• 現況：GET /grc/job-executions/<je>/comments 的 service 直接查資料，沒檢查呼叫者是不是專案成員。位置：jedi_task_platform/task/app/service/job_comment_service.py:27。
• 風險（白話）：任何登入的人只要拿到任務執行的編號，就能讀到別的專案的留言。
• 修法：補專案成員檢查，比照同檔 add_comment 用的 assert_project_participant。這是套件檔案，走 jedi 套件異動規範（先提醒、path dependency、不發版）。

缺口二：專案摘要報告整組沒有授權模組檢查

• 現況：api/project_summary_report/routes/ 9 個 method 都沒有 require_license。成員檢查有（列表依參與專案過濾，單筆走 _require_participant）。
• 風險（白話）：沒買這個加值模組的客戶，仍然能打這組端點。資料範圍有被成員身分限制，所以風險是授權沒管到，不是資料外洩。
• 修法：9 個 method 補授權軸守門；動手前先看 common/authz/ 決策表與 FR-062 設計第 6 節，確認這組歸基礎包還是加值包。

缺口三：刪除專案有管理員旁路

• 現況：app/flow_control/service/project_service.py:547 起，is_admin 可以刪任意專案。
• 風險（白話）：專案明細的讀取原則是「一律不給管理員旁路」，刪除卻給了，兩邊規則不一致；管理員帳號被盜時可以直接刪別人的專案。
• 修法：拿掉 is_admin 旁路，改走專案成員角色（manager）加能力點判定；先查有沒有現有流程靠這個旁路（grep 呼叫端與 FE），有的話先回寫問決策者再動手。

缺口四：流程圖定義端點沒有任何檢查

• 現況：GET /flow-engine/process-definition/<uid>（api/flow_engine/routes/flow_engine_route.py:27）沒有任何檢查。
• 風險（白話）：任何登入者給 uid 就能讀到流程範本的 XML。
• 修法：先查呼叫它的 WorkflowSetupForm（舊入口）還有沒有在用。沒在用就退役該端點；有在用就補守門。歸屬（歸 grc 還是 flow 模組）由 T-1.2 一併定。

手測