本卡屬 FR-114（母卡 CM-2019），CM-2119 評估結果，決策者 2026-09-24 裁另開卡、下一批做。清理卡，只改 BE。不擋這批發版。

問題是什麼（白話）

FR-050 做「階段退回」時發現：輪次主流程上的任務沒有指派列，舊的專案反查（翻指派表）恆查無，連專案管理人都被守門擋下。當時的解法是開一條旁路——呼叫端自己帶已知的專案編號（known_project_id），跳過反查。CM-2113／2119 把反查改走輪次鏈後，DEV 536 個有主流程的輪次逐一反查全部回到正確專案（0 查無、0 查錯），這條旁路已經沒有存在理由。留著的風險：多一條「信呼叫端給的專案編號」的路，以後有人照抄就是跨專案漏洞的起點。

在哪裡（CM-2119 runner 列出，開工先 grep 確認）

BE app/flow_engine/service/workflow_execution_service.py
  assert_project_participant(workflow_execution_id, known_project_id=None)   :127-139
  revert_job(..., bypass_round_frozen_gate=False, known_project_id=None)     :824-852（docstring 836-844 整段講這條旁路）
BE app/flow_engine/service/job_operator_guard.py:22-35  assert_job_operator(..., known_project_id=None)
BE app/flow_engine/service/stage_rollback_service.py:160  傳 known_project_id=project_id 的唯一呼叫端（:172 附近回傳 project_id 的註解也要改）
BE test/test_workflow_execution_service_revert_job_bypass_gate.py::TestKnownProjectIdBypassesBrokenReverseLookup（在「反查恆查無」前提下寫的，要改寫成驗「不帶旁路也查得到」）

怎麼修

• 拿掉三處 known_project_id 參數與 stage_rollback_service 的傳參；守門一律走 _resolve_project_id_from_workflow（已委派唯一判斷）。
• bypass_round_frozen_gate 不動——那是「階段退回時輪次本來就不在規劃期」的業務旁路，跟專案反查無關，拿掉會讓 FR-050 階段退回 100% 失敗。
• docstring 拿掉旁路的來龍去脈（進 commit message），只留一兩行現況。

驗證

• FR-050 階段退回相關既有測試全跑；改寫的 TestKnownProjectId… 驗「輪次主流程任務不帶旁路也通過守門、非成員仍擋」。突變：把 _resolve_project_id_from_workflow 改回查指派表 → 改寫後的測試要紅。
• DEV 唯讀：對 CM-2119 用過的輪次主流程任務呼叫 assert_project_participant（不帶旁路），manager 通過、非成員 403。
• 手測（留總測）：稽核流程頁做一次階段退回，成功。

紀律

• 工作區 BE .claude/worktrees/wt-fix-security（branch fix/security-b1），主 checkout 不動；不碰 pyproject／lock。workflow_execution_service.py 超標：只准刪減，不加邏輯。
• 註解只寫為什麼與陷阱；顯式 git add；commit message 結尾 Co-Authored-By；不 push、不切 branch。DEV 只准 SELECT。回寫不得含憑證。
• 做完立刻：commit → 本卡 append 白話補充 → 狀態改「修正待驗證」。

已完成修正（白話補充）

做了什麼：拿掉 known_project_id 這條旁路。原本 revert_job／assert_job_operator／

assert_project_participant 三處都多一個參數，讓呼叫端（StageRollbackService）自己帶專案編號