本卡屬 FR-088（母卡見 FR-088 母案），第 6 棒 P2：套件本體的流程執行、任務執行、流程變數三條鏈與插件組裝根（jedi monorepo）。只掃不修。

這一棒在做什麼（白話）

套件這一半是「零件」：建立流程執行紀錄、把任務標完成、算下一個任務、讀寫流程變數、把資料存進資料庫。它自己沒有任何對外網址，安全判斷全交給主專案。這一棒掃 42 檔：這些零件在被宿主呼叫時，有沒有假設「呼叫者已經檢查過」但其實沒有；以及零件本身有沒有可被覆寫、可被塞任意資料的地方。只找問題、不修問題。

為什麼切這一塊

套件的 complete_job／revert_job（app/service/workflow_execution_service.py:206／:318）零授權檢查、零租戶檢查——設計如此（宿主包一層）。但「宿主包了幾條、漏了幾條」只有把套件的全部公開方法列出來、逐一對回宿主呼叫者才答得出。另外套件的三張表（流程執行、任務執行、流程變數）隔離全關、其中一張無租戶欄（DEV 實查）。

重點看什麼

行號已開檔核對，是思考起點不是檢查清單：

• 🔴 公開方法清單 vs 宿主守門對照：把 app/service/workflow_execution_service.py（549 行）、job_execution_service.py、element_variable_service.py 的每支公開方法列成表，grep BE repo 找呼叫者，標「宿主呼叫前有無 assert_project_participant」。首腦已知：宿主 H2 的留言 route 直接呼叫套件 element_variable_service.update_element_variable（:49）沒守門；本棒要補完整張表。
• 🔴 repo 注入可被無條件覆寫：app/wiring/__init__.py set_repo_providers() 檔頭自陳「刻意採無條件覆寫，後注入者勝出」；plugin.py 在 import 時注入。要驗：程序內任何一次 import／呼叫都能把四支 repo 換掉——有沒有 request 期可觸發的路徑？（多半只是啟動期，記錄即可，但要把「誰能呼叫」寫清楚。）
• 插件沒有 route 也沒有接線守衛：plugin.py:158-159 自陳「本套件現階段無 route，故 _assert_api_wiring() 不存在；真的長出 route 的那一棒必須同時補」。確認 create_blueprint()（:207）建的 blueprint 確實是空的、register()（:232）沒掛任何 resource。
• 三張表的隔離狀態（DEV 實查，本棒可再唯讀查一次核對）：compliance.workflow_executions 關、3 條規則（缺 SELECT）、有租戶欄、10,944 筆；job_executions 關、0 規則、有租戶欄、10,783 筆；element_variables 關、0 規則、無租戶欄、3,011 筆。套件 model 只有 WorkflowTemplate 掛 TenantScopedMixinModel，其餘三張（infra/models/workflow_execution.py／job_execution.py／element_variable.py）沒掛——租戶欄是誰填的？
• 流程變數是 JSONB 任意寫：infra/models/element_variable.py:28 value: JSONB；element_variable_service.py:31-76 add／update 不驗 value 形狀。留言（H2）就是寫進這裡的 list。要驗：value 大小無上限、type 欄位可控值、delete_element_variable_by_main_workflow_execution_id（:82）誰能叫。
• 建立任務時把 BPMN 屬性當 JSON 解析：workflow_execution_service.py:119 json.loads(job.properties['devices'])——屬性來自範本 XML（H3 證實存入不驗），壞 JSON 在啟動流程時炸；:140-146 on_job_created hook 把 created_user 等整包交給宿主 callback。
• 完成任務的條件參數：:206 complete_job(..., condition_param: dict=None)——條件參數決定走哪條分支（P1 的 _parse_condition_param_to_string）；由宿主的哪裡餵？使用者可控嗎？（例如 review 的 decision）。
• query entity 的 _gen_filters：infra/repository/job_execution_repo_impl.py:55-73 用 query entity 動態組 filter——列出 query entity 每個欄位，確認沒有「傳 None 就等於不過濾」而被宿主誤用成全表查詢的情形（FR-079 F13 同型）。

已知背景（只是參照）

• CM-1514：app 層 23 處自建 repo 的架構違規，改成 get_repos() 注入——app/wiring/__init__.py 就是那次的產物，檔頭有完整理由。
• FR-087 T1 第 4／5 項與 CM-1559：job_executions 的 03:10 排程靠 fail-open 運作。
• P1（第 3 棒）擁有 BpmnUtils 與範本鏈（10 檔），本棒只看呼叫端餵進去的是什麼，不重審解析器；越界讀允許，越界報要標「P1 範圍」。H4（第 5 棒）是宿主側的對照組，兩份報告首腦會對照看。
• 本範圍從未掃過。