一句話：2026-08-31 的 flow-boundary-design.md 每個數字都已過期（兩包從 260 檔／32,000 行縮到 114 檔／14,350 行），依賴關係也變過。本棒重新逐檔實查 flow_engine ＋ flow_control 兩包，產出新的歸屬判定取代舊稿，舊稿刪除。只分析不動程式。

這一棒在做什麼（白話）

系統裡管「流程」的程式分散在兩個地方：flow_engine（流程引擎，管一個流程跑到哪一步）與 flow_control（稽核流程控管，管稽核專屬的規則）。這兩包長年混在一起——有些程式明明是通用的卻放在稽核那邊，有些是稽核專用的卻放在引擎那邊。

去年 8 月做過一次盤點，判定每一支該歸哪邊，寫成一份設計稿。但那份稿子現在不能用了——之後有人動過兩次大的，程式少了六成，稿子上的數字沒有一個對得上。

這一棒把兩包重新逐檔查一遍，重新判定歸屬，產出一份新的、可信的圖。不動任何程式——決策者要的是「有正確的圖才動刀」，在錯的圖上動手會留下比現在更難清的東西。

為什麼舊稿不能用了（首腦實查，2026-09-16）

舊稿寫於 2026-08-31。之後兩筆 commit 已經改變了地貌：

結果是舊稿判給「🟦 引擎」的那四支已經全部處理完了——camunda_service.py（2,852 行）、bpmn_generator.py（2,428 行）、bpmn_topology_validator.py（330 行）在主專案已不存在，後兩支現在在套件 jedi_flow_engine/common/utils/。

數字對照（舊稿 → 現況實查）：

app/flow_engine    9,183 行  →  3,041 行（16 檔）
flow_control 全包  24,047 行 →  8,019 行（34 檔）
                   226 檔    →  34 檔

另外 domain/flow_control 現在是 0 檔（舊稿把它列為要整包搬遷的四層之一）

依賴關係也變過：舊稿判 stage_rollback_service 歸稽核，理由是「import AuditRoundAppService」——現在已經不 import 了（實查其依賴只剩 jedi-common／jedi-flow-engine／jedi-task-platform）。原判的證據本身失效。

🔴 教訓（本卡要避免重蹈）：舊稿正文自己記著「卡片寫 6,375 行，實查是 9,183」「卡片寫 19 條 route，實查是 16 條還在用」——它當初就是為了更正卡片數字而做的實查，結果半個月後自己也過期了。本棒的產出必須標明實查日期與當時的 HEAD commit，並寫明「引用前先重驗」。

本棒範圍：兩包 114 檔／14,350 行（首腦已精算）

flow_engine（80 檔 / 6,331 行）
  api/flow_engine       17 檔 / 1,320 行   19 條 route 註冊
  app/flow_engine       16 檔 / 3,041 行   6 支 service
  domain/flow_engine    27 檔 /   852 行
  infra/flow_engine     20 檔 / 1,118 行

flow_control（34 檔 / 8,019 行）
  api/flow_control       7 檔 / 1,151 行   12 條 route 註冊
  app/flow_control      17 檔 / 3,995 行
  domain/flow_control    0 檔（已空）
  infra/flow_control    10 檔 / 2,873 行

為什麼兩包一起做、不能只做 flow_engine：stage_advance_service（702 行）import jedi_compliance_audit、stage_rollback_service 的稽核依賴已消失——這兩支歸哪邊，取決於 flow_control 的邊界怎麼畫。只看一半就判不了。

首腦已查出的六支 service 依賴現況（app/flow_engine，可直接用不必重查）

檔                                    行     實查依賴（2026-09-16）
──────────────────────────────────────────────────────────────────────
workflow_execution_service         1,321   app.associations / app.notification /
                                           domain.module_frame / jedi_survey /
                                           jedi_task_platform / jedi_iam /
                                           jedi_flow_engine
stage_advance_service                702   jedi_compliance_audit / jedi_task_platform /
                                           domain.flow_engine / jedi_flow_engine
stage_rollback_service               189   jedi_task_platform / jedi_flow_engine
                                           ⚠️ 舊稿說它 import AuditRoundAppService，
                                              現已不 import——原判證據失效
flow_template_app_service            265   只有 app.flow_engine / domain.flow_engine /
                                           jedi_flow_engine（最乾淨）
job_evidence_service                 181   jedi_file_upload / jedi_survey /
                                           domain.flow_engine / jedi_flow_engine
workflow_template_snapshot_service    94   只有 jedi_flow_engine
                                           ⚠️ 舊稿判稽核（理由是 snapshot 屬輪次語意），
                                              但依賴上看更像引擎——需重判

主專案內部誰在用這六支（首腦實查，15 處）：api/flow_engine/routes/ 六支 route 各對一支；app/flow_control/service/job_batch_complete_service.py 與 app/module_frame/service/module_frame_service.py 用 WorkflowExecutionService；di_containers/flow_control/ 用兩支 stage service；di_containers/flow_engine/ 用其餘四支。