FR-114 資安修正派工計畫

這份文件是什麼：docs/security-report/SUMMARY.md 的問題總表是按嚴重度排的檢視結果，不是派工單。這份計畫把 145 件翻成「一個工作區一張卡、一個工程師一次做完哪些事」。決策者看過、裁完第 6 節後，才照它建 Notion 卡。

狀態：🟡 計畫待審（尚未開卡）｜母卡 CM-2019｜每批的逐卡細節在 batches/plan-b*.md，本頁是總覽。

整案一句話：145 件裡 121 件要動手（24 件已修或裁定不修），拆成 46 張卡，分六批；第 1、3、4、5 批今天就能開，第 2 批要等第 1 批合回主線＋套件發版，第 6 批等程式面修完測過一版。

工作區怎麼開（決策者 2026-09-21 裁定：依序做、不平行；開 worktree 是為了不碰掃描線正在讀的主 checkout）：只開兩個常駐工作區——BE 一個、套件 monorepo 一個——所有卡依序在裡面做，一張卡一個 commit，做完驗過再派下一張。第 3、5 批 FE／agent 那兩張卡到時各自在 FE／agent repo 開一個。

2.1 為什麼開 worktree、開幾個

• 目的是隔離，不是平行：FR-113 掃描線正在讀 BE 主 checkout（feature/review），修正不能在那裡動。套件 monorepo 沒有掃描在跑，但 BE 工作區的 path dependency 要指向一個固定路徑，開一個 worktree 讓它指過去比較乾淨。
• 常駐兩個：

• BE 工作區的 pyproject.toml：把本卡動到的套件 pin 改成 path dependency 指向套件工作區（例：jedi-task-platform = { path = "/Users/chouraymond/Projects/Jedicogy/module/jedi-wt-fix-security/jedi-task-platform", develop = true }），poetry update jedi-task-platform。這個改動不 commit；一張卡做完不用還原（下一張卡接著用），整批合回前才還原 pin。BE 工作區跑服務用另一個 port（例 PORT=8001），不跟主 checkout 的 8000 撞。
• FE 卡（3-5、1-5 若拆出 FE 半、5A-5 的下拉）到時在 FE repo 開 wt-fix-security；agent 卡（5A-1）到時在 agent repo 開。
• 同一張 branch 累積多張卡的 commit：branch 名不帶卡號，因為卡是依序做的；commit message 帶卡號。

2.2 依序做的順序（一次一張，做完驗過再派下一張）

1. 第 1 批：1-1 → 1-3 → 1-4 → 1-5 → 1-7 → 1-8 → 1-9 → 1-6（等 1-9 的 migration 套 DEV）→ 1-2（等 1-1）
2. 第 3 批（可插在第 1 批任何位置，互不相干）：3-1 → 3-2 → 3-3 → 3-4 → 3-5（FE）
3. 第 4 批（同上可插）：4-3 → 4-1 → 4-2 → 4-4
4. 第 5 批：先派方向已定的（5A-3、5A-4＋5C-7 合併、5A-5、5B-1～5B-4、5C-1～5C-5、5C-8），5A-1／5A-2 裁完方向再派，5C-6 排最後（動所有 pyproject）
5. 合回＋套件發版（決策者下令）→ 第 2 批：2-1 → 2-2 → 2-3 → 2-4 → 2-5 → 2-6 → 2-7 → 2-8 → 2-9 → 2-10
6. 測過一版 → 第 6 批開卡

2.3 合回與發版順序（誰下令）

2.4 先後有相依的卡（依序做時要守的順序）

第 1 批 權限地基（13 件 → 9 張）→ batches/plan-b1.md

第 2 批 只驗登入不檢查歸屬（29 件 → 10 張，等第 1 批）→ batches/plan-b2.md

第 3 批 刪除沒人用的（11 件＋M13-10 → 5 張）→ batches/plan-b3.md

⚠️ 這批材料檔沒有程式座標，11 個入口全部要在開卡前補查（首腦派 opus 一支補，不佔 runner）。

第 4 批 憑證殘留（10 件 → 4 張＋沿用 CM-1998）→ batches/plan-b4.md

⚠️ 249 檔與 15 檔清單要在開卡前盤點附卡（唯讀 grep，首腦做；不把憑證印進卡，只列檔案路徑）。

第 5 批 設定與信任鏈（54 件 → 18 張）

A 子集 → batches/plan-b5A.md | 卡 | 做什麼 | repo | # | model | |---|---|---|---|---| | 5A-1 | 代理程式每次打進來都要證明身分，「撤銷」真的斷乾淨 | evidence-agent＋jedi-remote-agent | 1 | fable／high（先裁方向） | | 5A-2 | 驗簽工具與鎖定紀錄變成拔不掉的 | jedi-integrity＋BE | 17、18、90、91、133 | fable／high（先裁方向） | | 5A-3 | 「改全公司共用設定」收到客戶總部那一層，儲存設定密鑰遮蓋 | jedi-system-core＋jedi-log＋BE | 19、22、134 | opus／high | | 5A-4 | 交出去統一編碼：匯出試算表不被當公式、日誌不被讀成兩筆（共用函式放 jedi-common） | jedi-common＋jedi-log＋jedi-issue | 20、93 | opus／high | | 5A-5 | 停權當下通行證立刻失效；日誌轉送加密選項 | jedi-iam＋jedi-log＋FE | M13-17、92 | opus／medium |

B 子集 → batches/plan-b5B.md | 卡 | 做什麼 | repo | # | model | |---|---|---|---|---| | 5B-1 | 規則包解析前先看內容；三道防炸彈上限搬到所有來源都經過的那層 | jedi-detection | 15、76、77、78 | opus／high | | 5B-2 | 弱點檢測三處資源上限：測試連線收斂、重新解析去重、換工具用生效值重查 | jedi-detection | 79、80、81 | opus／high | | 5B-3 | 流程圖走訪記路＋補上限；範本新增修改與起輪次一定過檢查 | jedi-flow-engine＋BE | 16、87、88、128 | opus／high | | 5B-4 | 問卷資料夾與即時填答：身分改用登入身分、送進來的欄位逐一收掉 | jedi-survey | 85、86、126、127 | opus／high | | 5B-5 | 驗證卡：確認 M07 五件是否已隨舊線退役消失（第 3 批之後） | jedi-evidence-classification | 89、129～132 | opus／medium |

C 子集 → batches/plan-b5C.md | 卡 | 做什麼 | repo | # | model | |---|---|---|---|---| | 5C-1 | 別人點預覽時跑不起攻擊者的程式；存檔前先洗檔名 | jedi-file-upload＋jedi-detection | 13、123 | opus／high | | 5C-2 | 儲存空間帳密不再回傳前端，連線改加密（M22-2 那側在 5A-3） | BE＋FE | 14、124 | opus／high | | 5C-3 | AI 助手與儀表板補逾時、次數上限，停止整包送出密碼材料 | jedi-ai-dashboard＋jedi-ai-bot＋jedi-common | 21、94、95 | opus／high | | 5C-4 | 共用底層五處小修：密碼遮乾淨、清單筆數上限、設定打錯字往嚴的倒、寫日誌失敗不連累請求、紀錄等級 | jedi-common | 82、83＝136、84、103、125 | opus／high | | 5C-5 | 意見回饋：連 GitHub 恢復身分驗證；刪附件用上算好的過濾結果 | jedi-issue | 100、135 | sonnet／medium | | 5C-6 | 內部套件倉庫全面改走加密連線，版本鎖定檔納版控（先查 Nexus 有沒有 TLS） | monorepo 28 支＋BE＋FE | 101 | sonnet／medium | | 5C-7 | 匯出 Word／Excel 把使用者填的字當資料處理（與 5A-4 合併見 D-X2） | BE | 102 | opus／high | | 5C-8 | 自動產生密碼補回少的那個字元；清兩支零引用複製品 | jedi-survey＋jedi-log | 137 | sonnet／medium | | 不開 | #98 安裝程式同一組最高權限帳密（裁定暫不調整）、#99 三環境共用公鑰（等正式簽發站） | — | 98、99 | — |

七份批次計畫共列了 42 項待裁（各批檔末段），大多數是 runner 動手時才要選的細節、且每項都附了建議。這裡只把「不裁就不能開卡」的抓出來；其餘照各卡建議走，runner 卡上會寫「先回寫問決策者再動手」。

我自己查出來的兩個跨批衝突（先裁這兩個）

D-X1 舊版證據分類退役已有人在管，第 3 批要不要再開？ 第 3 批 3-1 卡把 #9／#66／#67「M07 舊線退役」排進去，但 Notion 已有 CM-1849（FR-107.6 舊線退場＋收口，4 張子任務卡，Not started） 在管這件事，且 M07 模組頁第 77～87 行寫明退役要照完整清單逐支做（含被鎖定的網址清單要一起改、否則自動測試會失敗）。

• 我的建議：第 3 批不再開退役卡，3-1 只做 M13 快取複製品那半；#9／#66／#67 在 SUMMARY 標「由 CM-1849 處理」，5B-5 驗證卡改成「等 CM-1849 做完再驗」。兩張卡做同一件事只會互撞。

D-X2 「匯出時把 = + - @ 開頭的字標成純文字」這支共用函式，只准有一份 5A-4（jedi-common 抽一支，給 jedi-log 與 jedi-issue 的匯出用）與 5C-7（BE 抽一支，給 Word／Excel 匯出用）會各自長一份。5C 子集實查過：FR-113 README 說「早就抽過、三個出口沿用」的那支函式不存在。

• 我的建議：合併成一張卡，函式放 jedi-common（BE 與所有套件都拿得到），先做套件側再回 BE 接上，序列 5A-4 → 5C-7 同一個 runner。

各批「動手前必裁」的（其餘見各批檔）

不用裁、我會直接照建議進卡的

D-b2-1／2／4／6／7／8、D-b3-1（由 D-X1 取代）、D-b4-2（首腦盤點）、D-b5A-2／5／6／7／8／9／10、D-b5B-1～6、D-b5C-1／3／4／5／6／7／9／10（由 D-X2 取代）／11——各項的問題與建議在對應批次檔末段，你若對哪項有意見再點名。

1. 第 3 批 11 個入口座標（派 opus 一支補查，唯讀）
2. 第 4 批 249 檔與 15 檔清單（唯讀 grep，只列路徑）
3. 第 1 批 5 個待補：detection complete_job 要不要跟著收嚴、batch_add_task_assignees 是否經過單筆、project_group_participant_service.py 三支寫入整支無守門是不是 #109 漏記的、survey_discussions 有沒有軟刪欄位、內建範本有沒有超過 100 節點
4. 第 5 批 A/B 共 5 個待補（FE 日誌轉送下拉元件、_read_entries()、重抽入口、if entity.xml:）
5. 第 2 批 1 個：稽核輪次同檔統計功能要不要一次補完

• runner 做完程式後順手把該條在模組頁（docs/security-report/M<NN>-*.md）與 SUMMARY.md 的狀態改「已修」＋修法一句，重 build（python scripts/deliverables/render_index.py docs/security-report/ --site-root docs/security-report/），再 Notion 回寫。只動狀態欄與修法那句，不重寫段落。
• 每個入口 file:line 都是驗收項，每個入口都改了才收（同一個問題常有 route＋service＋FE 三個入口）。
• 功能不能壞（原則三）、安全措施不可擋正常客戶（原則十一）、刪除前零引用（原則十五）。
• 套件 path dependency 改動不 commit；顯式 git add；做完立刻 commit＋回寫＋狀態改「修正待驗證」；不 push、不切 branch、不發版。
• 檔案內註解只寫「為什麼」與「陷阱」，做了什麼進 commit message。
• 動到已超過 800 行的檔（例：workflow_execution_service.py 1,374 行）新邏輯一律新開檔。