本卡屬 FR-114 資安修正（母卡 CM-2019），第 6 批「資料結構補強」卡 6-0b，是 SUMMARY #109（M10-10）的前置。中。由 CM-2023 退回：那六個寫入點的 uid→id 解析函式是空殼恆回 0，功能本身已斷半年，補守門沒有意義。

問題是什麼（白話）

場景：專案管理者在「專案規劃」或「稽核總覽」點某個群組／控制項的「成員」加一個人。前端只送文字編號（project_uid／group_uid／control_uid），後端要換成數字 id 才能查、才能寫——負責換的那支函式是空殼，永遠回 0。結果管理者按儲存 → 後端拿 0 去查「你是不是專案 0 的管理者」→ 查無 → 一律被擋。DEV 兩張表最後一筆寫入 2026-03-23，半年沒新資料。

首腦核對：

• jedi-task-platform/jedi_task_platform/participant/app/service/control_group_participant_service.py:188-190 與 project_control_participant_service.py:197 附近：_resolve_ids_from_uids 註解「🔴 stub：舊 OSCAL 評估計畫模型停用後未重建，恆回 0」。
• group_id／control_id 兩欄沒有外鍵；CM-2023 拿 DEV 實際值去 oscal.catalog_groups／catalog_controls 查全部查不到——「群組屬於哪個專案」目前資料庫沒有一條路回答得出來。

工作區

套件側：在 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-task-platform（branch fix/security-b1）改，只動這支套件的子目錄、只 git add 該子目錄。BE 工作區 pyproject.toml 把 jedi-task-platform 的 pin 改成 path 指向套件工作區，poetry update jedi-task-platform，path 改動不 commit。

在哪裡

jedi-task-platform/jedi_task_platform/participant/app/service/control_group_participant_service.py:188   _resolve_ids_from_uids 空殼（三個呼叫點 :77/:116/:146）
jedi-task-platform/jedi_task_platform/participant/app/service/project_control_participant_service.py:197   同名空殼（呼叫點 :59/:103/:136）
前端呼叫點：compliance-manager-fe 的群組／控制項成員畫面                      ⚠️ runner 開工先 grep FE src/ 找送 group_uid／control_uid 的兩個呼叫點，確認送的欄位

怎麼修

• ① 先盤點（唯讀，結果先回寫本卡）：現行 FE 送的 group_uid／control_uid 對應到哪張表的 uid？候選：SSP 控制項實作那組表（oscal 的 control_implementation／module_frame 的 group）、或 jedi-task-platform 自己的表。用 DEV 現有的 group_id 259/309/399、control_id 1560/1877 反查是哪張表的 id。
• ② 盤點清楚後，把 _resolve_ids_from_uids 改成真的查（走該表的 domain service，不在 app service 直接 query），兩支檔各一份或抽共用——先查再寫，看 participant 模組有沒有現成的 uid→id 查法。
• ③ 解析成功後，#109 的反查（填進來的群組／控制項屬不屬於這個專案）順手在同一處補上——這是本卡的收尾，不另開卡。
• ④ 若盤點發現那兩張表的 group_id／control_id 指向的東西已不存在（舊 OSCAL 模型），本卡改為回寫「功能無法重建、建議整組退役」並停，交決策者裁。

手測

• DEV：專案管理者在群組成員畫面加一個人 → 成功寫入、清單看得到。
• DEV：填一個不屬於該專案的群組編號 → 被擋。
• DEV：非管理者操作 → 被擋（既有守門沒被弄壞）。

做完要回寫報告