本卡為 FR-095 母案。用 claude-security plugin 掃「任務平台」這支套件（jedi-task-platform）與它在主專案的宿主接線，七棒共 216 檔，只掃不修。子卡清單在末段。

這系列在做什麼（白話）

產品裡「誰是這個稽核專案的成員、他是什麼角色、哪個任務指派給誰、任務怎麼啟動與留言」這一整套，都由「任務平台」這支套件管。它是所有「你在這個專案能做什麼」判定的資料來源——系統每次要問「這個人是不是這個專案的管理者」，最後都是去查它管的那幾張表。

套件分三個子模組：participant（專案成員與角色、任務指派，10 條對外 API）、task（任務留言／匯入匯出／批次完成／執行啟動／儀表板，10 條 API）、project（專案資料存取，沒有 API）。

這個 arc 要回答三個問題：① 有沒有辦法讀到或改掉別家客戶（或別的專案）的成員名冊與任務指派？② 守門是不是「有接線才檢查、沒接線就放行」——接漏一條就整段開放？③ 這 11 張表在資料庫層有沒有隔離兜底？

為什麼要做

• 從未掃過，而且是前面每一輪掃描都會回頭指到的地方：FR-086（檔案）、FR-088（流程引擎）找到的「只驗身分不驗歸屬」問題，修法都是「補一行去問任務平台：這個人是不是這個專案的人」。如果任務平台自己這一層有洞，前面所有修法都是建在沙上。
• 決策者 2026-09-14 裁定：四支合併套件（task-platform／log／asset／system-core）解除暫緩，第一支掃 jedi-task-platform（detection／remote-agent 維持暫緩）。
• 規模（attack-surface 口徑，2026-09-14 git ls-files 實數）：套件 195 檔（含 tests 外全部；0 行的 __init__.py 不入棒）／8,551 行；宿主接線 59 檔／13,850 行（另 1 檔 di_containers/dashboard_apis/participant.py 走 DI 字串不 import 套件，grep 抓不到，手動帶入）。
• 資料庫實況最刺眼：這支套件管的 11 張表沒有一張隔離是開的，9 張連租戶欄都沒有。套件自己的 migration 檔頭寫「沒有 RLS 是刻意的，租戶隔離由專案層擋」——但 projects 表的隔離也是關的，這個前提已被總表第 43 條推翻。與 FR-086 檔案存取「四層全空」同一形狀。

首腦讀完後的重點（各子卡有完整行號與核對註記）

• 🔴 五支「讀」端點只驗登入、專案編號由呼叫端自填（POST /project-participants、GET /project-participants/menu、POST /task-assignees、POST /project-control-participants、GET /project-control-participants/menu）：project_participant_service.py:43-45 直接 get_all(**kwargs)，不問「你是不是這個專案的人」。讀端點漏守門第五次出現（前四：CM-1585／1589、FR-079、FR-081、FR-088 第 58）。門檻：登入＋知道任一專案編號。（P1／P2）
• 🔴 六支成員服務都是「有注入角色服務才守門」，DI 漏注入＝靜默全開：宿主 di_containers/flow_engine/project_participant_containers.py:113-117 建 ProjectGroupParticipantService 時就沒傳 participant_role_service，該檔 grep 零守門。目前 route 表沒掛它，但 AI 儀表板讀得到。（P1＋H1）
• 🔴 更新／刪除時「撈不到既有紀錄就 return」，守門寫在 return 之後：process_participant_service.py:55-56、task_assignee_service.py:213-214。撈不到就跳過檢查，等於用一個不存在的編號就繞過 manager 檢查。（P1／P2）
• 🔴 批次完成任務預設把呼叫者當 manager：app/flow_control/service/job_batch_complete_service.py:50-56 is_manager = True，註解自陳「沿用舊守門『context 不齊就跳過檢查』」。這正是總表第 59 條「未核對」的那個點。（H2）
• 四處 enforce_role=False 繞過套件守門（project_service.py:460/467/474、module_frame_service.py:242），而它們依賴的上游守門 update_project :373-375 又是同款「有注入才檢查」條件式。（H1）
• 7 支成員查詢直接曝給 AI 儀表板（di_containers/dashboard_apis/participant.py:19-64），只有 project_id／user_id 這類參數、沒有歸屬檢查——與總表第 8／10 條（AI 儀表板列全公司帳號／專案後門）同型、位置不同。（H1）

怎麼拆（七棒，按「可利用門檻」排序，不按嚴重度）

• 第 1 棒 P1 專案成員新增／移除／角色指派＋守門入口＋掛載契約（39 檔，套件）— 門檻最低：登入＋自填 project_id 就能讀成員名冊；common/guard.py 是所有守門的單一入口，要與六支 service 同棒才看得出誰有接誰沒接。
• 第 2 棒 H1 專案 CRUD＋成員同步＋接線（plugin／DI）（34 檔，宿主 BE）— 「套件拿到什麼守門、什麼身分」的唯一答案在 core/plugins/；AI 儀表板繞守門；四處 enforce_role=False。