修正卡草案：這些問題該分成幾張卡、每張卡修什麼

這份文件回答一個問題：掃描累積下來的 145 條問題，要切成幾張修正卡，每張卡修什麼、怎麼驗、先做哪張。

這是草案，不是已經決定的事。決策者看完裁定之後，才照這份去開 Notion 卡。 每一條問題被分進哪一組、有沒有漏掉，看 分類對照表； 每一條的完整技術細節，看 總表 §3。

---

145 條問題（資安 117 條＋非資安的真程式錯誤 28 條）分成 44 組，建議開 24 張修正卡。

之所以組數比卡數多，是因為有幾組本來就該合在同一張卡裡修——例如檔案取得鏈那六條，只修其中一條等於沒修。

最想請決策者先看這三組

1. A1 檔案取得鏈（6 條）——門檻最低的一條攻擊路徑：一個有效帳號加一個檔案編號，就能取走、刪除別家客戶的稽核證據，還能換一張不用登入的下載連結傳到公司外面。五個出口必須同一張卡一起修，只修一邊等於沒修。決策者 2026-09-13 已裁「現在就開工單」，這組是那次裁定的直接產物。
2. C1 設定 API 吐帳密（3 條）——任何登入帳號打一支查詢就拿到物件儲存的帳號密碼明文。不修這條，應用層補再多檢查都沒用：拿到那組帳密可以完全繞過系統直連儲存空間。三處小改。
3. D2 日誌表本身（7 條）——密碼原文寫進日誌、日誌表沒有客戶隔離、保存期限從沒生效，三件事疊起來變成「密碼明文無限期累積在一張誰都看得到的表裡」。這組的 RUN_ENV=prod 那一半已經修好了（第 25 項），剩下的部分變得更划算。

三件跟分組有關、決策者可能會問的事

• 「同一種病修一次」到底能省多少：145 條裡，光是「只驗登入、不驗這筆資料是不是你的」這一種病就佔了 42 條（A1～A9 九組）。這九組的修法形狀完全一樣——補一行「這是不是你的」檢查，抄同一個檔案裡寫入方法已經寫好的那支函式。分散開 42 張卡，每張卡的人都要重新理解一次；併成九張，第二張之後都是照抄。
• 修正到現在極度偏食：兩次複查裡判定「已修」的 11 條，沒有一條是那九組裡的——修好的都是資料庫隔離（B 組）與套件小 bug。資料庫那道牆這段期間補了不少，應用程式那道門一步沒動。 這不是誰偷懶，是那批工作（FR-094、FR-107）本來就只做資料庫層。
• 有 6 條建議「不開卡」：X3 那四條複查確認已修好、Z 組裡有兩條總表自己標明「只回報待裁、不直接開卡」。列在這裡是為了讓 145 條每條都有交代，不是要排修。

---

分組的判準只有一個：這幾條能不能用同一套修法一次解掉。 不是按套件分、也不是按嚴重度分——按套件分會把同一種病拆散到十幾張卡，按嚴重度分會讓同一條攻擊路徑的頭尾被排進不同輪。

起點是總表 §4 已有的十一組索引（🅰～🅺），沒有從零發明分法。本棒做的是三件事：

1. 把 §4 的大組拆細。§4 的 🅰 組收了 39 條，橫跨七支套件——當成一張卡開，沒有人做得完。本棒依「同一支套件、同一個檔案、同一次測試能驗完」拆成 A1～A9 九組，每組 2～11 條。
2. 回頭核對 §3 全表，把漏分的補進來。§4 沒收過、本棒新歸入的共 48 條——多數是 §3.2 那些非資安的程式錯誤（§4 只零星收了幾條），以及 FR-095／FR-111 後期那幾棒的發現。對照表上每條都標了「本棒新歸入」。
3. 標出狀態。§4 的索引是逐棒累加的，沒有人回頭核對過哪些已經被別的工作修掉了。本棒依總表自己的兩次複查（09-16、09-20）逐條標記，已修的 11 條不再排進修正順序。

本棒沒有做的事：沒有開檔重驗任何一條（複查沒覆蓋到的一律照總表寫「仍在」）、沒有改總表一個字、沒有開 Notion 卡。

---

排序的依據是三件事：門檻有多低（要先有什麼才打得到）、不修會不會讓別的修法失效、修法有多確定（已裁定的、一行就能改的排前面）。

跨輪的一條線：C 組（憑證）裡有幾條是「去後台按撤銷／換密碼」的動作，不是寫程式。那幾條不占開發時間，可以跟第一輪平行做。

---

每一組的格式固定：共同病根一句 → 涵蓋哪幾條 → 修法 → 怎麼驗 → 風險級別。 「涵蓋哪幾條」欄裡，編號後的括號標的是狀態；沒標的就是「仍在」。

---

🔴 A 系列：只驗登入、不驗這筆資料是不是你的（九組 42 條）

整個 A 系列的共同病根：系統認得出「你是誰」，但從來不問「這筆資料是不是你的」。登入就放行。

九組共用同一套修法：在服務層補一道「這筆資料的主人是不是呼叫者（或呼叫者是不是這個專案的成員／管理者）」的檢查——每一組要抄的那支函式，都已經寫在同一個檔案的寫入方法裡。這不是設計新機制，是把已經存在的檢查補到漏掉的地方。

🔴 這一系列有一個驗收陷阱，每一組都適用：總表複查兩次都撞到「端點換上了看起來像守門的裝飾器，但那道守門從來不是歸屬檢查」（第 34、45、74 項）。驗收時不能只問「有沒有補守門」，要打開那道守門的實作看它到底檢查什麼。

A1 檔案取得鏈（6 條 · 建議開 1 張卡 · 🔴 最高優先）

病根：檔案的下載、換發免登入連結、刪除、服務層取檔，四個出口全都只驗登入。

涵蓋範圍：2 支套件（jedi-file-upload、主專案側）＋ 5 個檔案。

修法（四步，第三步要決策者放行）：

1. 服務層補歸屬檢查（managed_file_upload_service.py 的取檔／轉檔／刪檔三個方法）——這一層是唯一「已經把檔案撈出來、知道它屬於誰」的地方，真正該補的是這裡。
2. 換發通行證的入口補檢查——簽發前先確認這個檔案是不是呼叫者的；並讓通行證綁客戶與使用者，不只綁檔案。
3. 出貨基線同步（要決策者裁）：資料庫那兩欄與隔離規則目前靠 installer 事後補，基線建表還是舊形狀。重產基線要寫 188 基線庫，屬決策者裁示。
4. 第 45 項分開寫：它剩的三個缺口跟其餘五條不同（查詢那支完全沒補、補的兩支不核對任務歸屬、資料層更新只憑編號查），開卡時要分段寫清楚，不能寫成「同上」。

⚠️ 34／40／47 三條的原文必須改寫再開卡——原文說「資料表沒有客戶歸屬欄位、隔離是關的」已經過期（FR-107 為了別的目的補上了）。照抄會讓接手的人去做一件已經做完的事，然後以為整條修完了。

怎麼驗：用 A 客戶的帳號，拿 B 客戶的檔案編號打下載、換通行證、刪除三支，都要回 403（現在是成功）。同租戶內跨專案也要擋。DEV 唯讀可以先查資料庫現況，實際打端點要在 DEV 做。

風險級別：🔴 高（組內最高：34／35／40／47 四條高風險）

---

A2 稽核流程讀取（5 條 · 建議開 1 張卡）

病根：稽核流程引擎裡，同一個檔案的寫入方法都有歸屬檢查，讀取方法全部漏掉。

涵蓋範圍：jedi-flow-engine ＋ 主專案側 · 4 個檔案。

修法：

1. 49／50 在同一個檔案補兩行，抄同檔已有的 assert_project_participant。
2. 51 要在另一個模組補讀取與寫入兩處。決策者 2026-09-13 已裁升為高風險。
3. 53 要一併補 advance_stage／rollback_stage 兩支的輪次歸屬比對——目前跨專案寫入是靠下游套件的第二道檢查在擋，這一層自己沒檢查。不補的話，將來新增一支不走那個套件的處理函式，洞就重新打開。
4. 50 與那個程式錯誤必須同一張卡：單筆查詢的端點誤用了「多筆」的序列化方式，先出錯所以沒真外洩。只修程式錯誤不補權限，等於親手把洞打開。

怎麼驗：A 客戶帳號拿 B 客戶的任務編號／輪次編號打這五支，全部要 403。第 50 項要在修完序列化錯誤之後再驗一次。

風險級別：🔴 高（49／51 兩條高風險）

---

A3 任務平台名冊與指派（11 條 · 建議開 1 張卡）

病根：成員名冊與任務指派的讀取全部沒有權限檢查，而且查詢條件全是選填——送一個空請求就回整張表（實測：成員名冊 751 筆、任務指派 12,494 筆，跨所有客戶）。

涵蓋範圍：jedi-task-platform ＋ 主專案側 · 約 10 個檔案。

修法：

1. 讀取那幾支照抄同檔已有的 delete_task_assignee 寫法補檢查，專案編號改必填。
2. 63 把兜底檢查移到提前返回之前，並補上那個根本不存在的驗證方法（或改呼叫真的存在的那支）。
3. §3.2 第 17 項必須同卡先修——那支永遠回空的查詢會讓「補完權限後的測試」看起來通過，實際上只是查不到東西。不修它，這張卡的驗收是假的。
4. 62 目前沒有 API 入口，優先度低於同組其他條，但要一起補，否則哪天有人接上就是一個全開的入口。

與 I2 的關係：60／61／68 的「空請求回全表」根因在共用底層（I2 第 70 項）。決策者 2026-09-15 已裁「要在底層擋，但分兩步，第一步先盤點」。這張卡走的是第二條路——逐支補「專案編號必填＋成員檢查」，不等底層改；底層那件事照原裁定另案進行。

怎麼驗：送空白請求給那幾支，要回 400（欄位必填）而不是整張表；帶別人的專案編號要回 403。驗之前先確認 §3.2 第 17 項已修，否則結果不算數。

風險級別：🔴 高（60／69 兩條高風險）

---

A4 問卷讀取與討論（8 條 · 建議開 1 張卡）

病根：這是整個掃描計畫裡「補權限只補了一半」最乾淨的一次實證——填答功能 14 個入口，6 個寫入全部有檢查（6/6），8 個讀取一個都沒有（0/8），而且在同一個服務檔案裡。

涵蓋範圍：jedi-survey · 約 8 個檔案。

修法：套件裡已經有現成的 assert_task_survey_writer 與對應的讀取守門，逐支掛上即可；91／92／96 三支的查詢條件改必填。97 若產品面決定「管理員可以刪別人的留言」，要走一條寫明白的管理路徑，照樣檢查他是不是這個專案的人。

這一組要帶一句寫進卡片：2026-07 那次統一補權限的工作只涵蓋了寫入。往後任何一次補權限的驗收，都要把讀取入口分開數一遍。

怎麼驗：A 部門帳號拿 B 部門的問卷編號打這八支，全部 403；空請求要 400。即時同步那兩支要另外開連線測。

風險級別：🔴 高（89／90 兩條高風險）

---

A5 主專案專案讀取（2 條 · 併入 A3 或獨立小卡）

修法：照抄同檔已有的 assert_project_participant，一行。跨客戶已被 FR-094 的資料庫隔離接住，現在只剩同客戶內跨專案。

風險級別：中。建議併入 A3 同一棒做（同一個人手上，抄的是同一支函式）。

---

A6 弱點掃描端點（3 條 · 建議開 1 張卡）

修法：85 掛上同檔其他三支在用的「工具設定修改」權限點；86 目標主機限制成存好的設定範圍；88 補一行參與者檢查。

⚠️ 85 與 86 必須同卡：補了權限（85）不會讓 86 消失，只是把門檻從「任何登入者」提高到「工具管理員」。只修 85 就結案，是把一個對外的跳板留給內部人。

風險級別：🔴 高。

---

A7 舊 Drive 分類線（3 條 · 🔴 要先裁「刪路由還是補守門」）

這組要先裁一件事（總表 §7 第 19 項）：舊線已標 legacy、前端入口已經拿掉，後端三支路由仍掛著。刪那三支路由一次消掉這三條；留著就要三條各補守門。

建議：先刪路由。理由是前端已經沒有入口，留著的三支路由是純風險、零價值；補守門要寫的程式比刪路由多，而且補完還是沒人用。

風險級別：🔴 高（108）。但如果裁定刪路由，這張卡會縮成一個 10 分鐘的工作。

---

A8 公告與 AI 儀表板（2 條 · 建議開 1 張卡）

修法：公告那四個有現成的檔名行號可以直接抄。第 8 項的正規做法是讓 AI 儀表板申報的每支查詢各自標明需要什麼權限，最快的止血是把那四支查詢從 AI 可用清單移除。

⚠️ 這組跟 P6（第 10 項「視同管理員」後門）同在 AI 儀表板上，但那條是刻意設計、要先裁產品方向，不要一起修。

風險級別：中。

---

A9 能力點宣告了但沒接線（2 條 · 建議開 1 張卡）

病根跟 A1～A8 不同：那些是「忘了寫檢查」，這兩條是「權限點宣告好了，後端沒接上去」——結果是租戶管理員以為拿掉權限就讀不到，實際上 API 完全敞開。

修法：各補一行掛上既有能力點。

要帶進卡片的一句：這種病跟 P3（第 80 項資產清冊）長得很像，但性質相反——P3 是程式碼契約自己寫明「讀取不守」的刻意取捨，這兩條是漏接。不要一起處理。

風險級別：中。

---

🅱 B 系列：資料庫隔離（三組 12 條）

B1 開關沒開／規則沒訂完（4 條 · 建議開 1 張卡，大半已修）

現況：這組實質上只剩兩條。第 43 項只剩一張 config.log_forwarding_settings 沒處理，而那張正是報告自己標「建議重新分類、不算隔離缺口」的、且牽涉 P2（第 75 項）。

修法：第 4 項走 sql-migration 標準流程。⚠️ 開卡時務必寫明：bulletin_org_units 只有兩個欄位、沒有客戶歸屬欄位，不能照抄母表 bulletins 的四條規則——要嘛透過母表借隔離，要嘛先加欄位。不寫這句，接手的人幾乎一定會照抄然後失敗。

風險級別：低（剩下的部分）。建議降到第五輪收尾做。

---

B2 連歸屬欄位都沒有（7 條 · 建議開 1 張卡 · ⚠️ 難度跟 B1 完全不同）

⚠️ 這組不能跟 B1 排同一輪。B1 是「開關打開」，這組是「先改資料表結構、回填既有資料、再補規則」——而且 system_logs 那張有 66 萬筆要回填。

修法：每張表都是「加欄位 → 回填 → 開隔離 → 補規則 → 出貨基線同步」五步。建議一張表一張卡，不要併成一張大卡。

要先裁的（總表 §7 第 8 項）：兩張日誌表到底要不要做客戶隔離，還是明確定位成「只給內部維運看的全域資料」、改成限縮誰能查就好？後者不用改表結構，成本差一個數量級。這件事沒裁，B2 這組動不了。

§3.2 第 31、32 項不開卡——總表自己標明是「前提記錄」與「脆弱設計記錄」，不是程式錯誤。建議寫進資料庫設計文件，讓下一個改動的人知道這裡的安全是靠什麼撐著。

風險級別：🔴 高，但被「要先裁方向」擋住。

---

B3 隔離規則方向寫反（1 條 · 建議開 1 張卡）

第 87 項：把組織路徑 /1/102/ 切成 [1, 102] 當白名單，結果子單位看得到母單位的資料（還能改能刪），母單位反而看不到自己底下子單位的。該擋的沒擋、不該擋的擋了。

這條最不容易被發現，因為從外面看「隔離有開」。DEV 實查確認母子結構真的存在、資料全在子單位，兩面都已經在發作。

涵蓋範圍：9 張表跨三個套件（jedi-detection 5 張＋遠端代理程式 agent_tasks ＋三張授權表）＋出貨基線。

修法：改判斷式即可，但要一次改 9 條、且動到出貨基線（屬決策者裁示）。

風險級別：中，但這是資安與功能雙錯——母單位看不到子單位的資料是個功能 bug，客戶會直接回報。

---

🅲 C 系列：憑證（五組 14 條）

C1 設定 API 吐帳密（3 條 · 建議開 1 張卡 · 🔴 最高優先之一）

🔴 這三條必須同一張卡。只補權限（72）不補遮罩（73），有正當權限的管理員打開頁面時瀏覽器仍會收到共用密鑰明文——任何看得到他瀏覽器流量、存檔或前端錯誤日誌的人都拿得到。只修一邊等於沒修乾淨。

修法：

1. 三個讀取入口掛上同檔寫入已經在用的權限檢查。
2. 遮罩的兩份名單各補一處（群組名單補「儲存設定」、欄位名單補物件儲存實際用的欄位名）。
3. ⚠️ 動的是標註「凍結」的契約，要連測試一起改。

為什麼排最前面：不修這條，應用層補再多檢查都沒用——拿到那組帳密可以完全繞過整個系統直連儲存空間。

怎麼驗：用一個零權限的登入帳號打那三支查詢，回應裡不能出現任何密碼欄位；用有權限的帳號打，密碼欄位也要是遮罩後的值。

風險級別：🔴 高。

---

C2 憑證已經外流，要換要清（4 條 · 建議開 1 張卡，但多數是動作不是程式）

🔴 第 83、84 兩項不是「要不要修」的問題，是一個動作。83 是去 gitlab.com 後台按撤銷（並查該帳號從 2025-04 起的稽核紀錄）；84 是換密碼並把公開站上那頁清掉。這兩件不占開發時間，可以跟第一輪平行做。

⚠️ 決策者 2026-09-19 已裁「三個例外也不先做」（含第 84 項）——理由是快掃完了、不分批。掃描現在已經收口，這條裁定的前提消失了，建議請決策者重新確認 83／84 要不要立刻處理。

已裁定不必再問的：測試機專用的資料庫與管理帳號密碼不需更換；不重寫 git 歷史。

風險級別：🔴 高（84：不用登入就取得、且是繞隔離的帳號）。

---

C3 預設不安全（4 條 · 併入 X1 小修合卡）

四條都是一行改預設值。建議併進 X1 一起做，不單獨開卡。

風險級別：中（19 最高，因為是已知修法的漏網複製品）。

---

C4 憑證落地留存（2 條 · 建議開 1 張卡）

修法：107 刪掉寫入那一行 ＋ 補一支清存量的 migration。103 改 --env-file 或 -e KEY 不帶值。

107 值得單獨強調：產品刻意做的加密保護被這一行繞過了——拿到資料庫備份、pg_dump 檔或唯讀帳號的人，一句 SQL 就得到客戶正式機房的可用 SSH 密碼。而且那份資料沒有任何人在用。刪掉它沒有任何副作用。

風險級別：中，但 107 的投入產出比極高（刪一行 ＋ 一支 migration）。

---

C5 三環境共用公鑰（1 條 · 不開卡，等 LC）

第 6 項：開發環境的私鑰簽出來的授權檔，正式環境的驗證也會通過。三個環境的公鑰全部編譯進同一份後端程式。

決策者已裁：現階段不處理，等正式簽發站建好之後一併處理。程式檔頭註解說明這是刻意設計（為了支援日後換發新公鑰不中斷）。

這一條列在這裡只為了「每條都有交代」，不建議現在開卡。

---

🅳 D 系列：日誌與外送（五組 17 條）

D1 密碼原文進日誌（3 條 · 建議開 1 張卡）

第 22 項雖然已修，但留下兩件殘留，建議寫進這張卡：

1. 2026-09-17 之前的舊 log 檔輪轉後可能仍有明文——屬資料清理，不是程式問題。
2. 遮罩比對的是 JSON 的 key 名，表單編碼的請求擋不到（登入走 JSON 已實測有遮）。

第 30 項的修法（總表 §7 第 7 項已寫明方向）：改成先把內容解析成結構化格式再逐層遮蔽。這會動到全站唯一的這道遮罩機制，屬核心共用邏輯——依測試政策，這一條要補寫測試。

風險級別：中（22 已修後）。

---

D2 日誌表本身（7 條 · 建議開 1 張卡 · ⚠️ 與 B2 相依）

🔴 這組有一個要特別講清楚的：第 24 項與 §3.2 第 11 項在這段期間風險反而變大了。同一支改動（CM-1920）把資料庫日誌處理器補掛到正式與測試環境——它修的是「寫多少」，而「寫失敗會弄壞使用者請求」「錯誤堆疊落在沒隔離的表」這兩件事沒碰，等於原本只在開發機的問題，現在正式環境也會走到。

修法：

1. §3.2 第 11 項：那支 emit() 全函式還是沒有錯誤處理，補上 try/except，一個小改。
2. 第 24 項：只保留錯誤的類型與訊息、不保留完整堆疊。
3. 第 27 項剩下的：把 sqlalchemy.orm 與 pymongo.event_loggers 兩棵調回 WARNING。
4. 第 23 項要等 B2 那個產品決策。

好消息：這組七條裡三條已修，剩下的四條都是小改（一個 try/except、一個不存堆疊、兩個調等級）。投入產出比很高。

風險級別：中。

---

D3 日誌轉送鏈（3 條 · 建議開 1 張卡 · ⚠️ 與 P2 同一個決策）

這三條合起來是一條完整攻擊鏈：

與 D1 第 22 項直接相扣——日誌裡有密碼原文，所以這條管道外洩的就是密碼本身。

第 75 項要先裁產品方向（見 P2），76／77 不用等：76 補加密選項、77 過濾換行符號（gelf 那半已經有現成作法可抄），兩條都可以現在做。

建議：這張卡拆成兩段——76／77 現在做，75 等 P2 裁完再接上。

風險級別：🔴 高（75）。

---

D4 匯出公式注入（2 條 · 併入 X1 或獨立小卡）

修法：兩處共用一支「開頭是公式字元就前置單引號」的中和函式。同一種病兩個位置，一次修完。

風險級別：🔴 高（78：不用登入就能種，唯一門檻是等管理員自己打開檔案）。但修法只有一支小函式——建議提前到第一輪順手做掉，不要排到第三輪。

---

D5 錯誤原文回前端（2 條 · 併入 X1）

修法：100 把那段「所有例外都接住」的程式拿掉，讓框架的錯誤處理器回標準錯誤碼；§3.2 25 改存固定錯誤碼＋一句白話，原文只進 log。

風險級別：低。

---

🅴 E1 回應夾帶內部欄位（3 條 · 建議開 1 張卡）

🔴 修第 33 條才是治本，只修 9／12 這兩個個案，之後還會有新的個案冒出來。

修法：在套件層的序列化工具加白名單或黑名單參數（至少擋掉密碼、鹽值、憑證這類欄位名）；9／12 同時加欄位白名單或重用既有查詢已經寫好的排除設定。

⚠️ 33 在 jedi-common，改了要發版才生效，節奏跟只改主專案不同。

風險級別：中。

---

🅺 K 系列：外部送什麼就收什麼（五組 10 條）

K1 apply=False 大量指派（2 條 · 建議開 1 張卡）

病根：網址入口那行負責「檢查前端送來的欄位對不對」的宣告被加了 apply=False——叫框架完全跳過驗證，那一行只剩裝飾作用。業界叫「大量指派」。

修法：拿掉 apply=False，明確宣告允許的欄位。⚠️ 同樣寫法在問卷套件的四個網址入口上都有，四個一起改，不要只修被掃到的那兩支。

🔴 這張卡要附帶一件盤點工作（總表 §5 已列）：另外 20 支套件要搜一遍有沒有同樣寫法。這件事比修這兩條更有價值——apply=False 是一個可以用一行 grep 找遍全公司的形狀。

風險級別：中。

---

K2 檔名／副檔名不驗（2 條 · 建議開 1 張卡）

同一種病的兩個入口：一個是使用者上傳、一個是代理程式回報，但落地點是同一支預覽端點（依副檔名決定型別、而且是直接在瀏覽器裡開不是下載）。

修法：預覽端點改成不依使用者自填的副檔名決定型別、危險型別一律強制下載；上傳與回報兩側都補副檔名白名單、去掉路徑。

風險級別：🔴 高（36）。

---

K3 規則包不驗內容（3 條 · 建議開 1 張卡）

112 與 116 是同一支驗證器的兩種病：112 是「上限存在但太晚生效」，116 是「上限根本沒接進這條路」。一起修。

修法：115 改成解析前先剝掉或轉義樣板語法（或換一個不執行樣板的解析方式）；112 改成逐筆讀；116 把驗證器接到網址分支的呼叫點。

風險級別：🔴 高（115）。

---

K4 字串拼查詢（2 條 · 建議開 1 張卡）

這組記的是「寫法本身不安全」，不是「現在就有漏洞」。擋住第 21 項的是外部環境的巧合（值的來源剛好是整數主鍵與資料庫查出來的字串），不是寫法本身安全。

建議：趁現在改掉，不要指望以後有人會一直記得這個限制。 改成參數綁定，成本很小。

風險級別：低（但形狀不好）。

---

K5 換工具不重驗上限（1 條 · 併入 A6 或獨立）

第 105 項：在一張稽核任務上換掃描工具時，「要掃哪些機器」不會拿實際生效的值重新檢查台數上限——先綁一支不設上限的工具、填一個超大網段，再換工具，舊的超大網段跟著留到新工具底下，執行時逐台展開吃爆記憶體。

修法：換工具時用實際生效的值重跑一次上限檢查。

建議併入 A6（同一支套件、同一批人）。

---

🅵 T1 防竄改機制（6 條 · 建議開 1 張卡 · 自成一組）

這組跟其他組的修法完全不互相影響，可以任何時候獨立排。

要先裁的兩件（總表 §7 第 9、10 項）：

• 第 13 項要不要開卡——已實測、風險維持高，三個候選修法已寫在總表，等決策者選一個。
• 第 14 項選哪個修法方向——補開機時的資料庫查詢／補同步機制反向寫回／只改文件讓它與實際行為一致。三個選項成本差很多。

⚠️ 15 必須跟 13 同一張卡，單獨修沒有意義。

這組還有三個相鄰面向從頭到尾沒碰過（總表 §3.4）：解鎖檔的簽發端（在 License Center）、驗章的加密邏輯本身、打包出貨時產生清單檔的流程——最後這件直接決定防竄改實際保護的範圍有多大。建議寫進卡片當已知缺口。

風險級別：🔴 高。

---

🅹 R 系列：一個帳號就能讓系統對所有人不回應（兩組 8 條）

R1 BPMN 輸入炸彈（4 條 · 建議開 1 張卡）

55／56／57 是同一個根本原因（不信任使用者送進來的 XML），總表已建議合成一張「BPMN 輸入強化檢查」的卡。

修法分三段：

1. 先止血：57 補上功能權限檢查與長度上限兩行，把門檻從「任何登入帳號」拉高。
2. 治本：驗證邏輯改用字典結構、加節點數量上限。
3. 寫入端：補驗證會動到主專案側的 module_frame_item_route.py，跨程式庫的修改要注意。

風險級別：🔴 高。

---

R3 其他資源上限（4 條 · 建議開 1 張卡）

第 31 項最划算：改一個共用底層的預設上限，全站所有分頁一次受保護。而且它不會被既有的「請求大小上限」擋住——攻擊形狀是「請求很小、要求回傳的資料很大」。

第 114 項修法極便宜：服務裡早就有 running 狀態且有在寫入，只是沒人拿來判斷。

風險級別：中。

---

🅷 P 系列：要先由產品面定方向才能改程式（七組）

🔴 這一整個系列不是「要不要修」，是「要修成什麼樣」。建議合成一張決策卡請決策者一次裁完，而不是七張卡各問一次。

P1 與 P2 已經裁完了，可以直接開卡——建議把這兩組從決策卡裡拿出來，併進第二輪跟 A 系列一起做。

---

🅸 I 系列：規劃上互相牽動（兩組）

I1 與 CM-1559 相依（2 條）

第 46 項已修，這組實質上只剩「修 A2 時記得第 53 項的連帶」這一句話。不用獨立開卡，寫進 A2 的卡片即可。

I2 空條件回全表（1 條 · 根因）

第 70 項：六張表的資料存取層沒有一支自己加專案範圍條件——全部走共用底層「查詢欄位有值才加條件、沒值就不加」的規則。這個底層行為已經連續三次在不同套件放大成全庫外洩（檔案清單、成員名冊、任務指派）。

決策者 2026-09-15 已裁：要在底層擋，但分兩步。 第一步先盤點全站哪些地方是刻意要查全表的（碼表、排程、管理員總覽），改成明確標記；第二步才動底層。兩步之間可以隔很久。

🔴 第一步的起點已經備妥——第十二任首腦做完的 17 支盤點清單（STATE「空條件回全表：全域盤點第一版」段），下一任可以直接拿來用，不必重掃。那份清單還附了判準：看這張表的一筆資料有沒有「主人」——有主人就該拒絕空條件，沒主人（碼表、公版、全站共用字典）回全表是正確的。

建議：這件事獨立開一張卡，不要跟 A3／A4 綁在一起——A 系列走的是「逐支補檢查」那條路，不等底層改。

---

🅶 X 系列：收尾（三組 21 條）

X1 一行小修合卡（11 條 · 建議開 1 張卡）

這些問題彼此不相干，但都很小，一次順手做掉。

建議：這張卡不要一個人做完——15 個位置散在五、六支套件裡，按套件拆成兩三批平行做比較快。

X2 死碼與未接線清除（6 條 · 建議開 1 張卡）

這組的價值不在「現在有洞」，在「留著會害下一個人判斷錯」。

修法：直接刪，或在組裝的地方加一句明確的提醒註解。§3.2 16／18b／23 那三組如果要留，要標明「啟用前必須先修第 63 項」。

X3 已修、不必開卡（4 條）

§3.2 第 7、8、9、10 項，兩次複查都確認修好了。列在這裡只為了讓 145 條每條都有交代。

---

Z 單修（不成組，6 條）

這些條目找不到能一起修的同伴，硬塞進哪一組都是勉強。 標在這裡是誠實的分類結果，不是漏掉。

---

本棒只寫草案，沒有動總表一個字。 下面是核對 145 條時發現的對不上的地方，由首腦裁定後另派一棒改。

---

寫清楚免得下一棒誤會已經做過：

• 沒有開檔重驗任何一條。狀態一律以總表自己的兩次複查為準；複查沒覆蓋到的照總表寫「仍在」。
• 沒有改總表、風險總表、STATE 任何一個字。
• 沒有開任何 Notion 修正卡——決策者要先看草案再裁。
• 沒有推翻決策者已裁的修法方向（P1 viewer、P2 第一層租戶、CM-1559 順序、CM-1595 維持最嚴重等）。草案裡凡是已裁的，都照裁定寫。
• 沒有估工時。每組的「涵蓋幾支套件幾個檔」可以當成規模的參考，但沒有換算成人天。
• 沒有判斷 jedi 套件的發版節奏。草案只標出哪幾組動到套件（改了要發版才生效），實際怎麼排發版是另一件事。

---