一句話：本卡屬 FR-100（記錄卡 CM-1820），第 2 棒：
jedi-flow-engine的workflow_execution_service.py（548 行）早已被主專案那份 1,321 行取代、主專案零處使用，但檔案裡沒有任何一個字說它不該用。本棒只加警語與對齊三處過期註解，不刪程式、不改行為。
系統裡有一支程式管「流程跑到哪一步、誰該做、做完往下推」。當初把它抽進套件時用的是複製不是搬家，之後主專案那份繼續改了半年，套件那份原封不動。
結果同一支東西有兩份：套件裡 548 行（沒人用、停在半年前）、主專案 1,321 行（正在跑）。兩份的方法參數已經對不上了。
這一棒不解決重複本身（那要動整個流程架構，是另一件大工程）。這一棒只做一件事：在套件那份的檔頭寫清楚「這份已被取代、不要用」，讓將來拿這支套件去裝新產品的人不會誤用到舊版。
首腦 2026-09-16 實查：這支不是孤立的死檔，而是有一整圈接線和守衛圍著的死檔。要刪就得連帶處理下列每一項，那些又跟套件的插件契約纏在一起——工作量遠大於「刪一個檔」，而且交付前不值得動契約層：
jedi_flow_engine/plugin/wiring.py 檔頭紅字：「不是「沒人用的 import」——本模組沒被 import 的話，WorkflowExecutionService 的每個方法都丟 RuntimeError」jedi_flow_engine/plugin/__init__.py:71 同一段警告jedi_flow_engine/app/wiring/__init__.py 為它做的 repo 延遲建構機制（檔頭說明 repo 內含 session-bound 狀態要每次現建）tests/unittest/test_repo_wiring.py:92 守衛測試，釘死「workflow_execution_service.py 的原始碼不得再出現 infra repo 的 import」tests/unittest/app/service/test_workflow_execution_service.py 等至少三支測試檔在測它決策者 2026-09-16 裁：走加警語這條（B 案），理由是它解決了這個債的唯一實際傷害（有人裝了套件、拿到舊引擎而不自知），成本接近零，且不會跟日後的大改造衝突——大改造來的時候本來就要重新處理這支。
主專案零處使用：grep -rn "jedi_flow_engine.app.service.workflow_execution_service" api app domain infra di_containers core → 0 命中。同目錄另三支則活著：workflow_template_service 7 處、element_variable_service 2 處、job_execution_service 1 處。
⚠️ 套件整體是活的，不要誤解成整支套件廢棄：主專案用到套件 38 個不同 import 路徑，BPMN 產生器（2,428 行）、BPMN 工具（713 行）、拓撲驗證（330 行）、entity／model／repo 全都在用。套件 6,746 行裡只有這一支 548 行是死的。
兩份已經長歪，方法簽名對不上（首腦逐一比對）：
complete_job(...) 套件版 6 個參數
主專案版 7 個（多 suppress_notify）
revert_job(...) 套件版 6 個參數
主專案版 9 個（多 suppress_notify、bypass_round_frozen_gate、
known_project_id）
主專案版另有 12 個套件版沒有的方法——稽核輪次凍結檢查
（_assert_round_not_frozen_for_workflow）、專案參與者權限
（assert_project_participant）、通知派工（notify_user_todo_job／
notify_users_batch_assigned）、問卷屬性處理（process_survey_property）等。
為什麼不能把主專案那份貼回套件：主專案版已長進稽核業務（輪次凍結、專案參與者），貼回去等於在通用零件裡塞稽核專用邏輯，正是抽套件要消滅的事。這就是這個債卡住的原因。
🔴 那支死檔目前連 docstring 都沒有——檔案第 1 行直接是 import json，沒有任何一個字告訴讀者它已被取代。這正是本棒要補的。