U8 檢查結果：流程背景作業（排程總表、流程圖存檔、孤兒清理、覆核輪承襲）

檢查日期 2026-09-25｜對應卡片 CM-2160（母卡 CM-2152）｜檢查範圍 8 個檔案 1,716 行｜工具 run ID wf_fc0b9dcb-c09｜驗證章 verified

這棒沒有找到跨公司的洞。有兩個「同公司內權限太鬆」的問題：一條工具報、三人面板 3 票通過；一條是我照卡片追出來的。另外有一個「將來會靜默失效」的陷阱，我在 DEV 實測重現了。

1. 🟡 低（工具報，面板 3:0）：在「流程圖編輯器」存檔時把方塊刪掉，後端會把對應的稽核任務連同證據一起硬刪。這條路只問「你有沒有改範本的權限」，不問你是不是這個專案的管理人；規劃頁刪同一筆任務則要管理人才行。同一件事有兩個入口，門鎖不一樣。FR-112 設計時決策者裁過這個做法（2026-09-20），工具建議重新評估，因為刪任務會連帶刪掉證據。
2. 🟡 低（runner 開檔追出，未經三人面板）：「證據蒐集執行進度」這支查詢（套件路由，本棒範圍內的查詢是它的資料來源）只驗登入，不驗你是不是這個專案的成員。同公司任何人把網址換成別的專案編號，就能看到那個專案的任務完成數字。
3. 🟡 陷阱（runner DEV 實測，未經三人面板）：孤兒清理排程的「孤兒」判定是「這筆綁定指向的任務查不到」。如果排程沒有帶系統身分，資料庫隔離會讓它看不到任何任務，於是把所有綁定都當成孤兒刪掉。現在排程有帶身分，所以不會出事。但這個判定與身分完全綁死，程式碼上沒有任何保險。實測見 U8-3。

卡片問的核心問題「這八支用原生 SQL 直寫沒隔離的表，資料是不是從同一個已驗證的物件來」，答案是是：來源與目的地的編號都是程式自己從同一筆已驗證的輪次或流程實例推出來的，沒有任何一個是使用者各自傳進來再拼起來的。詳見「卡片點名的疑點逐條回答」。

這 8 支是「背景作業」：大多不是使用者直接按按鈕觸發，而是排程定時跑，或別的功能跑到一半順帶呼叫。

先釐清三件事實（2026-09-25 15:13～15:31 +08，在 DEV 唯讀查證；刪除測試全部整段回滾）：

• 卡片提到的五張「沒隔離」表，DEV 現況是：job_evidences、job_execution_devices、job_execution_org_units、workflow_templates_trans 都沒開資料庫隔離（relrowsecurity = f）。task_assignees 已經開了（FR-094 CM-1800，scripts/sql/packages/jedi_task_platform/003-participant-rls.sql，規則是「看得到專案才看得到指派」）。所以盤點表第 6 節寫「task_assignees 無 RLS」已經過期。
• 排程怎麼跑：9 支排程全部用 system_context("<名字>") 包住，也就是**「一個具名系統身分，掃全部客戶」**，沒有任何一支是逐家客戶切換身分的。對這些排程來說，資料庫隔離等於沒開（系統身分會直接繞過）。這跟 U5／U6 看到的一樣。
• job_evidences 對任務表的外鍵是 ON DELETE CASCADE：任務被刪，證據列會被資料庫連帶刪掉。U8-1 的影響就是從這裡來的。

現況（2026-10-01）：本棒各條後來的處理結果如下（過程紀錄保留，不改）。

• U8-1（流程圖刪方塊硬刪任務）＝總表第 201 項，✅ 已修（CM-2208，commit 1516d90bc，1.21.0 出貨）。
• U8-2（執行進度只驗登入）＝總表第 202 項，✅ 已修（CM-2211，套件 commit cdb83526，1.21.0 出貨）。
• U8-3（孤兒清理沒帶身分的陷阱）＝總表第 203 項，✅ 已修（CM-2211，commit fe928859f，1.21.0 出貨）。

工具報的：一條（U8-1），三人面板 3 票全數確認。 U8-2、U8-3 是我照卡片逐支追、再到 DEV 實測出來的，沒有經過三人面板。

F1 → U8-1 🟡 在流程圖上刪方塊＝刪任務，這條路不問你是不是專案管理人（低，3:0）

• 在哪：app/flow_control/service/workflow_xml_sync_service.py:124（逐筆呼叫 delete_job_from_diagram）。刪除本體在 app/flow_control/service/job_service.py:217-228，那支方法刻意不做專案管理人檢查，註解寫明理由。
• 怎麼走到的：入口是 api/module_frame/routes/module_frame_item_route.py:95-112，只掛了 @require_capability("module-frame.update")，也就是「你這個角色能不能改範本」。接著 app/module_frame/service/module_frame_item_service.py:69-70 把整份 XML 交給 sync()。sync() 會把資料庫裡有、新圖上找不到編號的任務全部列成「要刪」（:85-86），然後逐筆硬刪（:121-124）。
• 為什麼跟規劃頁不一樣：規劃頁刪任務走 job_service.py:212 的 _require_manager(project_uid)（FR-112 design.md 寫的 :179 是當時行號），要是專案管理人。編輯器這條只有範本權限＋:91-92 的「輪次凍結」檢查。那道檢查在查不到輪次時直接放行（:141-143，倉儲那支註解說舊資料約一半查不到）。
• 刪了會連帶刪什麼：刪任務時程式會清問卷快照、task_survey 與四張綁定表。job_evidences 對任務是 ON DELETE CASCADE（DEV pg_constraint 15:31 實查），所以證據列會被資料庫連帶刪掉。
• 為什麼只到同公司：範本、流程實例、任務三張主表都有開隔離（workflow_templates、workflow_executions、job_executions），呼叫者看不到別家客戶的範本就拿不到它的流程實例。存檔端點在使用者的請求裡跑，受隔離約束。
• 是設計不是漏寫：docs/features/FR-112-2609-planning-task-parallel-flow/design.md:307 寫「編輯器刪任務走範本能力守門（module-frame.update），不要求專案管理人身分（決策者 2026-09-20 裁）」。理由是存檔端點只拿得到範本編號，多數範本反查不到專案。所以這條要決策者決定要不要重新裁，不是單純的 bug。 工具提出重新評估的理由是：當初的考量是「刪任務」，但實際上連證據也會一起消失。
• 建議修法：sync() 算出有要增減的任務時，先從流程實例反查專案。反查順序照倉儲已有的兩條路：workflow_execution_control_mapping.round_id → project_audit_rounds.project_id，或 task_assignees.project_id。查到就要求專案管理人；查不到就擋下增減（只准改走向）。不要再像現在這樣放行。
• 與總表的關係：第 137 項（改範本流程圖不檢查範本歸屬）、第 153 項（匯入只問建立權限）都在同一支 update_module_frame_item_xml，但問的是「範本是不是你家的」。本項問的是「你是不是這個專案的管理人」，是不同的缺口，建議另登一項。修第 137 項時可以一起看。
• HIGH 級自行核對：工具評為低，不屬 HIGH。以上檔案行號我逐一開檔確認過。

U8-2 🟡 「證據蒐集執行進度」同公司任何人都看得到別的專案（低）

• 在哪：資料來源是本棒範圍內的 infra/flow_control/repository/task_execution_query.py:214（get_prep_job_progress）。守門該在的地方在套件：路由 jedi_task_platform/task/api/routes/task_execution_route.py:56-60 只掛 @jwt_required() 和 @require_license("project")；服務 jedi_task_platform/task/app/service/task_execution_service.py:138-141 直接轉呼叫查詢，沒有任何角色檢查。
• 對照組：同一支服務檔的 start_task_execution（:69）有呼叫 _check_manager。同一個專案、同一個頁面，「按開始」要管理人，「看進度」連成員都不驗。這是「有人守了一半」的「只檢查了寫入卻沒檢查讀取」那一型。
• 外洩什麼：四個數字：這一輪任務總數、已完成、進行中、未開始。
• 為什麼只到同公司：查詢一開始用專案編號找當前輪次（task_execution_query.py:61-66 join compliance.projects），projects 有開隔離。所以別家公司的專案編號查不到輪次，會走舊鏈 fallback，一樣 join projects，最後回 0。
• 建議修法：get_prep_job_progress 開頭照 _check_manager 的寫法先解析專案，再呼叫 assert_project_participant（common.authz 已有，不要另寫）。
• 是不是舊帳：我在總表與既有掃描報告搜 task-execution/progress、get_prep_job_progress、TaskExecutionProgressRoute 都零命中。FR-048 的端點盤點只列了 start-task-execution。判斷是淨新增。

U8-3 🟡 孤兒清理「沒帶身分就把全部當孤兒刪」的陷阱（低／陷阱）

• 在哪：判定條件是 infra/flow_control/repository/job_binding_orphan_query.py:121-128 的 DELETE … WHERE NOT EXISTS (SELECT 1 FROM compliance.job_executions …)。

• 為什麼是陷阱：四張綁定表（留言、設備、部門、問卷）沒開隔離，所以不管誰來查都看得到每一列。但 job_executions 有開隔離，沒有身分時一列都看不到。「任務查不到」在沒身分的情況下對每一列都成立，於是每一列都被判成孤兒。

• DEV 實測（15:27～15:29 +08，job_execution_devices 共 5 列，全屬客戶 102，都指向真實存在的任務）。原封不動跑這支檔案的 DELETE 句，三種身分各一次，每次整段 ROLLBACK：

  身分	刪掉幾列	應該刪幾列
  系統身分（app.is_super_admin = t，排程現況）	0	0
  沒有身分（session_scope 沒身分時的樣子）	5	0
  客戶 131 的一般使用者（allowed_tenant_paths = /1/131/）	5	0

  跑完再數一次，還是 5 列，沒有殘留。同一時間用 count 查另外三張表：沒身分時，部門綁定 5 列全判孤兒、留言 6 列全判孤兒；問卷綁定表本來就 0 列。

• 今天會不會發生：不會。core/scheduler.py:447 有 with system_context("job_binding_orphan_cleanup"):，service 的 docstring（job_binding_orphan_cleanup_service.py:33-40）也寫了「必須由呼叫端設好身分」。總表第 46 項的修正正是補上這個身分。

• 為什麼還要登：這條規則目前只靠註解和呼叫端記得。第 46 項講的是「沒身分會掃到 0 筆、靜默不做事」，剛好反過來：對「NOT EXISTS 判孤兒」這種寫法，沒身分不是掃到 0 筆，而是全部判成孤兒。也就是第 46 項那句「省略身分就會靜默掃到 0 筆」對這支檔案不成立，漏帶身分的後果是大量刪資料。將來若有人照 U5／U6 的建議把排程改成「逐家客戶切換身分」，這支就會把每家客戶看不到的別家任務的綁定全刪掉。

• 建議修法：delete_orphans 刪之前先做一次自我檢查。例如 SELECT current_setting('app.is_super_admin', true) = 't'，不是就整輪停手並記 ERROR。或者把判定改成「帶著任務所屬客戶一起比」，但綁定表沒有客戶欄位，這條比較難。另外 JOB_BINDING_ORPHAN_CLEANUP_MODE=report 這個逃生門已經存在，可以在修之前先在客戶環境設成 report。

• 我沒能做的實測：本想直接把 service 以 report 模式（只數不刪）在本機起一次，比較有沒有身分的差別。但本機起 app 時撞到 FlowControlJobRepoImpl 少實作 resolve_project_id_for_job 的 TypeError（應是平行修正線的套件介面先行、主專案還沒跟上），起不來。所以實測改在資料庫層直接跑同一句 SQL，沒有經過 Python 那層。 這是打折處。

範圍內沒問題的：

• task_existence_query.py：只是轉呼叫，建構時就強制注入、不會降級成「查不到就跳過守門」（:45-57，arc-review I-6 已修掉的舊病），沒問題。
• task_execution_query.py 的 activate_jobs：用 job_ids 批次改狀態，沒帶專案條件，但 job_ids 是同一個 service 從「已驗管理人的專案」查出來的（task_execution_service.py:69-76），不是使用者傳的。get_detection_jobs_without_execution 同理。
• job_binding_orphan_query.py：表名用字串拼接，但有白名單（:62-70），沒有 SQL 注入面。

• 「這幾條存在嗎」：U8-1 經過三人面板完整投票（3 票全投、零漏投），驗證章 verified。U8-2、U8-3 是我開檔追的；U8-3 在 DEV 用資料庫層實測重現，未經三人面板投票。
• 「只有這幾條嗎」：範圍 8 支我逐支通讀完。範圍外讀了追下去需要的檔：job_service.py 刪除段、module_frame_item_service.py、module_frame_item_route.py、flow_control_job_repo_impl.py 存檔相關五支方法、套件 jedi_compliance_audit 的 launch_reverify 與 _check_role、套件 jedi_task_platform 的 task_execution_service.py 與 task_execution_route.py、jedi_common 的 session_scope 與 system_context。打折處：
  • U8-3 實測在資料庫層直接跑同一句 SQL（用 SET LOCAL 模擬三種身分），沒有經過 Python 的 session_scope。本機起 app 撞到平行線造成的介面缺實作，起不來。
  • U8-1、U8-2 沒有起後端打真的 HTTP 請求，都是讀程式碼判斷。
  • DEV 查詢時間點 2026-09-25 15:13～15:31 +08；平行修正線可能改變資料與隔離設定。

• 盤點檔 scan-inventory.md 第 6 節「compliance.task_assignees 無 RLS」已過期：DEV 已開（CM-1800）。U6 報告若沿用這個前提，那一張表的結論要重看。
• U8-3 與總表第 46 項方向相反（第 46 項說「沒身分＝掃到 0 筆」），建議在第 46 項補一句「對 NOT EXISTS 型的判定是相反的，沒身分＝全部判中」，避免將來有人照第 46 項的描述推論這支漏身分時無害。