C2b 掃描報告：階段歷程、回退標記、規劃完成度檢查（CM-2099）

範圍：15 檔／1,612 行，跨兩個 repo。

• 套件側 jedi-compliance-audit 14 檔：接縫檔 audit_round_app_service.py，階段歷程、回退標記兩組（entity／repo 介面與實作／domain service／mapper／model），加上 planning_readiness_checker.py。
• 主專案側 1 檔：app/flow_control/service/prep_job_generation_service.py。

掃描工具：Claude Code 官方 claude-security plugin，effort low，只看正式程式碼。兩側各掃一次。 掃描基準：套件側 eafc7ae511d5（monorepo 主 checkout，feature/review）；主專案側 8ac028f8ccd7（feature/review）。兩邊工作區都有其他 session 未提交的改動。 驗證章：兩次都是 verified。只掃不修（掃描當時紀錄；後續修正見 README）。

---

卡片要追的「歷程與回退兩張表只用輪次編號查」，實際情況是：寫入這兩張表的每一條路都先過了角色檢查，而且檢查的就是同一個輪次；讀取只有一條路（階段歷程），那條就是總表第 52 項。回退標記的三支讀取方法確認是死碼，整個系統沒有任何地方呼叫。

工具這次報的三條，和 C2a 套件側那三條是同一批（輪次清單、單筆輪次、階段歷程）。原因是接縫檔 audit_round_app_service.py 兩棒都在範圍內。本棒沒有新增漏洞。

規劃完成度檢查的「查不到資料就放行」確認只是提醒、不是權限檢查；覆核輪產生證據蒐集任務時，歸屬也是伺服器決定的，這兩件都不是洞。

---

「階段歷程」是每一輪稽核往前推、往回退的時間軸，經理退回時要填理由，會記在這裡。「回退標記」是退回時，把已經產生的東西（凍結的 SSP、稽核計畫、改善計畫）標成「作廢」，不真的刪掉。這兩張表沒有客戶欄位、資料庫隔離也沒開，所以程式層只要漏一處，資料就一路通到底。

要回答：

1. 讀寫這兩張表的呼叫端，有沒有先確認「這一輪是你的」？
2. 回退標記的三支讀取方法，是死碼還是有路打得到？
3. 規劃完成度檢查在查詢失敗時會放行，會不會被拿來當權限檢查用？
4. 覆核輪產生證據蒐集任務，任務的歸屬是不是伺服器決定的？

---

主專案側（prep_job_generation_service.py）零發現：研究員讀完沒有提出任何可疑點，面板沒有東西可投票。

上表三條都經過三人面板投票；第 4、5 節是我自己開檔追的，沒有經過投票。

---

三條都和 C2a 報告第 4.1～4.3 節是同一件事，場景與修法請看 scan-C2a.md。這裡只補本棒角度多看到的一點：

C2b-1 階段歷程：面板特別指出，歷程表是在 FR-050 的 migration（2026-07-19-fr050）裡刻意不開隔離的，設計時預期「一定先經過輪次表查詢，由輪次表的隔離擋」。但輪次表在出貨版 02-schema.sql 沒開隔離（C2a 第 6 節），這個前提在新客戶機器上不成立。面板把這點列為「跨客戶」的前置條件。

修正分支已補：套件 fix/security-b1 的 list_stage_transitions 已補上「網址專案要和輪次歸屬一致，不一致回 404」與成員檢查（面板引用 commit 3e82b625），但和 C2a 一樣還沒合回，也同樣是「選填參數、沒傳就不檢查」的寫法。

---

5.1 歷程與回退兩張表「只用輪次編號查」：寫入全部有守，讀取只有第 52 項那一條

我把整個系統（套件 monorepo 全部套件＋主專案 app／api／di_containers／common）裡碰這兩張表的地方全部找出來：

階段歷程表（round_stage_transitions）

回退標記表（round_rollback_supersessions）

結論：repo 只用輪次編號過濾本身不是問題（repo 層本來就不該守門），關鍵在呼叫端。寫入路徑的呼叫端都已驗過，讀取路徑只有第 52 項那一條漏了。

5.2 回退標記的三支讀取方法：確認是死碼

RoundRollbackSupersessionDomainService 的 is_superseded、list_by_entity_ids、list_by_round，全系統 grep 沒有任何呼叫者。主專案的 DI 只把這個 domain service 注入給 AuditRoundAppService，而那裡只呼叫 .add()。

白話說明：系統目前「只記作廢、從不讀作廢」，所以沒有任何畫面會根據這張表把東西藏起來或顯示「已作廢」。這是功能面的缺口（回退後被標作廢的 SSP、稽核計畫、改善計畫，列表上看不出來），不是資安問題。DEV 目前這張表有 13 筆、歷程表有 48 筆（13:53 唯讀實查）。

建議列進 FR-092 死碼清單，或者確認產品是否本來要做「作廢顯示」卻漏做了（第 7 節）。

5.3 規劃完成度檢查「查不到就放行」：只是提醒，沒有被當成權限檢查

planning_readiness_checker.py 唯一的呼叫者是主專案 oscal_stage_handlers.py 的 LaunchAuditOnCompleteHandler.execute（「規劃」階段推進時）。追下去的順序是：

1. StageAdvanceService.advance_stage 先做角色驗證（stage_advance_service.py:292，不符就 403），force=true 還要求必須是經理。
2. 然後才呼叫 handler，handler 才跑這支檢查。
3. 檢查有問題時回「警告」，畫面跳確認框，使用者按確認（force=true）就放行。
4. 之後才呼叫套件 launch_audit，那裡又再用輪次自己的專案驗一次經理。

所以這支檢查前後都有真正的權限檢查夾著，它本身只決定「要不要跳提醒」。它失敗時放行，最壞情況是「該跳的提醒沒跳」，使用者本來就能按確認跳過，不構成安全問題。

另外確認兩個子查詢都沒有外洩：檢查 A（未完成的證據蒐集任務數）只回一個數字；檢查 B（缺哪些角色）只回角色名稱（manager／auditor／reviewer），都是給已經通過角色檢查的人看的。

5.4 附帶發現：推進階段用「網址上的專案」驗角色，不是用「輪次自己的專案」

advance_stage 的角色驗證（stage_advance_service.py:292）是 _get_user_role(project_uid, user_id)，project_uid 來自網址；但它推進的輪次 round_uid 也來自網址，兩者沒有比對是否屬於同一個專案。理論上，A 專案的經理可以填「A 專案＋B 專案的輪次」，通過第一道角色檢查。

但實際上打不穿：推進後真正改資料的 handler（launch_audit／start_auditing／finalize_audit／close_round）都會在套件裡再用輪次自己的專案驗一次角色，所以會在那裡被擋。歷程表寫入（5.1 表中第一列）是在 handler 成功之後才寫，所以也寫不進去。

漏網之魚只有兩個：

• review_decision 這個 handler 不呼叫套件、不做第二道檢查。但 DEV 的 stage_objects 顯示內建流程沒有綁 review 階段（程式註解也說「本期 builtin 無 review stage」），目前打不到。
• 「查看目前階段」get_current_stage_info 同樣只用網址專案驗角色，而且不會擋，只回「你能不能推進」，會把 B 輪次的階段、進度、前置條件結果回給 A 專案的人。

已查證：這條已在 FR-088 H1 報告登記（scan-H1-stage-advance-rollback.md F4：get_current_stage_info 用網址專案查角色、用網址輪次撈資料、兩者不核對；該報告第 144 行也建議 advance_stage 一併補），既有案、本棒不另計。

5.5 覆核輪產生證據蒐集任務：歸屬由伺服器決定

prep_job_generation_service.generate 有兩個呼叫者：

請求內容帶不進任何歸屬欄位。新建的流程執行與任務由資料庫觸發器 trg_wfexec_fill_tenant_org_insupd、trg_jobexec_fill_tenant_org_insupd 自動補上客戶與部門（DEV 13:53 實查）。流程範本的 clone 走一般 insert，要受隔離規則 with_check 約束，範本表的隔離在 DEV 是開的。

一個小地方要提一下：generate 會直接用 SQL 更新 oscal.catalog_control_parts.props（專案成立模式才做）。它更新的是「這個專案的 cloned catalog」裡的 AO part，id 來自伺服器端查詢，不是外部輸入，所以不是洞。

---

出貨版 02-schema.sql 三張都沒開，詳見 C2a 報告第 6 節。

---

1. 回退標記的三支讀取是死碼（5.2）：列進 FR-092 死碼清單，還是先問產品「回退後被作廢的東西，列表上本來要不要標出來」？如果本來要做而漏掉了，這是功能缺口，不是清死碼的問題。
2. 推進階段「網址專案」與「輪次歸屬」沒有比對（5.4）：已是 FR-088 H1 F4，既有案。本棒只補一點給修正卡參考：將來如果啟用 review 階段，review_decision 這個 handler 沒有第二道檢查，那時 advance_stage 自己的歸屬比對就會變成唯一防線。建議修 H1 F4 時照該報告第 144 行的建議，把 advance_stage 也一併補上。
3. 歷程表「刻意不開隔離、靠輪次表擋」的設計前提，在新客戶機器上不成立（第 4 節）：建議併進決策者已裁定的「出貨基線隔離不一致」查證卡。

---

「工具報的三條存在嗎」：可信度高。套件側 9 票全數投出，三條都是 3:0；主專案側零候選。三條都是 C2a 已報的重複項。

「第 5 節」：runner 自行開檔核對，未經投票。關鍵事實都實查過：

• 兩張表的全部呼叫者：grep 整個套件 monorepo＋主專案 app／api／di_containers／common。
• 推進流程的檢查順序：逐行讀 stage_advance_service.py 與 oscal_stage_handlers.py。
• 內建流程沒有綁 review 階段、兩個觸發器存在、隔離狀態：DEV 唯讀實查（13:53，ROLLBACK）。

「只有這些嗎」：不保證。

1. 用的是最快的檔位（effort low）。
2. 主專案側只跑了一分鐘、零候選，只能說明「一輪快速讀過沒看到」，不是完整稽核。
3. 全程沒有實際打任何網址。

---

工具報告的 F 編號對照：套件側 F1＝C2b-2（輪次清單）、F2＝C2b-1（階段歷程）、F3＝C2b-3（單筆輪次）。

主專案側比套件側早跑：決策者先送了主專案側的指令，兩次掃描互不相依，不影響結果。