FR-080 唯讀盤點：六支「有殼無肉」jedi 插件

盤點日期 2026-09-09。宿主 HEAD 92412948（branch feature/FR-075），套件 monorepo HEAD 為當下工作區。 所有行號皆為當下實查，未讀 .venv。

六支裡只有五支是「有殼無肉」，jedi-system-menu 不是——它在 P3.5（CM-1471）已經做完 route 上移， 是七支補殼套件裡三支「完整體」之一，宿主 api/system_menu/ 目錄已刪、core/app_factory.py:388-391 真的呼叫 register(..., mount_api=True)。把它算進「有殼無肉」是誤判，本報告予以更正並保留其為對照組。

其餘五支（bulletin / device / information-system / flow-engine / system-config）確實是 零 route 的空 blueprint ＋ 宿主零呼叫 register()，套件在生產上只被當 library import。

A-1 五支空殼：create_blueprint() 掛 0 條，宿主 零呼叫

五支的 create_blueprint() 實作逐字相同（只有型別名不同）：

bp = Blueprint(cfg.blueprint_name, __name__, url_prefix=cfg.url_prefix)
bp.record_once(lambda state: state.app.extensions.__setitem__(EXTENSION_KEY, context))
return bp

• jedi-bulletin/jedi_bulletin/plugin.py:171-193（add_resource 出現 0 次）
• jedi-device/jedi_device/plugin.py:174-196（0 次）
• jedi-information-system/jedi_information_system/plugin.py:175-197（0 次）
• jedi-flow-engine/jedi_flow_engine/plugin.py:207-229（0 次）
• jedi-system-config/jedi_system_config/plugin.py:171-193（0 次）

五支的 plugin docstring 都寫死同一句（例：jedi-bulletin/jedi_bulletin/plugin.py:41-42）：

故本套件目前沒有 api 層，mount_api=True 掛出來的 blueprint 沒有任何 resource ——這是刻意的，且有測試焊死（tests/unittest/test_plugin_contract.py）。

焊死的測試是 tests/unittest/test_plugin_contract.py:113 test_blueprint_has_no_resources_by_design()。

register() 的 docstring 更把現況講明白（jedi-bulletin/.../plugin.py:213-215）：

⚠️ 本套件現階段兩種模式的對外行為完全相同（blueprint 是空的）， 差別只在 app.extensions 有沒有那個 key。

宿主呼叫次數：零。 全 repo grep jedi_*.plugin（排除 .venv）只命中兩處，且都屬 system-menu：

infra/system_menu/system_menu_plugin_wiring.py:35: from jedi_system_menu.plugin import SystemMenuAdapters, SystemMenuServices
core/app_factory.py:388:                                from jedi_system_menu.plugin import register as register_system_menu

即 jedi_bulletin.plugin / jedi_device.plugin / jedi_information_system.plugin / jedi_flow_engine.plugin / jedi_system_config.plugin 在宿主是 0 處 import。

🔴 flow-engine 是唯一有例外的：它的 plugin.py 除了空 blueprint 之外，還在 import 期做真事—— jedi-flow-engine/jedi_flow_engine/plugin.py:84-98 呼叫 set_repo_providers(RepoProviders(...)) 把四支 repo 實作注入 app/wiring。套件內 WorkflowExecutionService 有 22 處 get_repos() （jedi-flow-engine/jedi_flow_engine/app/service/workflow_execution_service.py），沒接線就 RuntimeError。 但因為宿主完全不用套件那支 WES（見 C-4），這條接線在生產上也沒有任何效果。

A-2 對照組 jedi-system-menu：掛 5 條，宿主真的呼叫 register

jedi-system-menu/jedi_system_menu/api/__init__.py:151-160 mount_routes()：

/api/1.0/system/menu/<string:group>     GET   僅登入（CM-779 明文例外，消費端點不加 platform 守門）
/api/1.0/system/menus                    POST  登入＋platform-admin
/api/1.0/system/category-menu            GET   登入＋platform-admin
/api/1.0/system-menu                     POST  登入＋system-menu.create＋platform-admin
/api/1.0/system-menu/<int:id>            PUT/DELETE  登入＋能力點＋platform-admin

凍結清單在 jedi_system_menu/api/__init__.py:166-172 FROZEN_URLS（測試做集合比對，不是比數量）。

宿主呼叫點 core/app_factory.py:388-391：

from infra.system_menu.system_menu_plugin_wiring import build_system_menu_adapters
from jedi_system_menu.plugin import register as register_system_menu
register_system_menu(app, build_system_menu_adapters(container), mount_api=True)

config/app_modules.py:21-26 已把 "system_menu" 註解掉、api/system_menu/ 目錄已刪。

A-3 harness 起來後有哪些端點可打

五支空殼：一條都沒有。 harness 是 harness/dev_app.py + docker-compose.yml（各自佔一個 port 避免互撞：bulletin 5491、system-config 5492、device 5493、information-system 5494、flow-engine 5498）， 做的事是「建表 → CRUD 走 model↔︎mapper↔︎entity → 斷言 → 非零退出」，不起 HTTP server 打端點。 harness 檔頭自陳（jedi-bulletin/harness/dev_app.py:21-22）：

故本 harness 做到「掛得上 ＋ CRUD 會動」，做不到 jedi-iam 那種「實打一支端點走通」。 如實記錄，不用假端點充數。

flow-engine 的 harness 改成餵最小 BPMN 進 BpmnUtils 走一遍解析並斷言，同樣沒有端點。

system-menu 沒有 harness 目錄（ls jedi-system-menu/ 無 harness/）——它的「拔掉測試」 是在宿主端做的（註解掉 app_factory.py:391 那行 → 五條 URL 全 404）。

B-1 jedi-bulletin

宿主自己寫的業務：

1. 公告發給哪些部門——bulletin_org_units 橋表（infra/bulletin/models/bulletin.py:13-27），寫入在 app/bulletin/service/bulletin_service.py:136-145（新增）與 :161-172（更新先刪後建）。
2. 時間窗驗證——_assert_bulletin_time_window()（bulletin_service.py:158-166），expire_time <= release_time 丟 ErrorCode.BULLETIN_INVALID_TIME_WINDOW。
3. 部門可見性過濾——auth=True 且使用者有 org_unit_id 時，把清單縮成該部門（bulletin_service.py:76-82）。
4. 「僅限本人建立」的搜尋不失效寫法——用 owner_created_user 而非 created_user，避免與搜尋關鍵字落進同一 OR 群組讓搜尋框失效（bulletin_service.py:83-90 註解）。
5. 審計 nickname——建構子注入 jedi_iam 的 UserDomainService（bulletin_service.py:65）。
6. org_unit uid → id 解析＋不存在丟 404（bulletin_service.py:141-144）。

B-2 jedi-device

宿主自己寫的業務：

1. 審計欄位 nickname enrich——_fill_user_names()（device_app_service.py:30-54），批次查 jedi_iam UserQueryEntity(_in_login_name=...) 把 login_name 換 nickname。
2. 刪除前引用計數——get_device_reference_count()（device_app_service.py:89-98），查三張稽核關聯表：compliance.job_execution_devices、compliance.job_execution_device_mapping、compliance.project_job_execution_device_mapping（實作已於 FR-069 搬進 jedi_task_platform/task/infra/repository/device_reference_query.py:26-36，raw SQL 三表 UNION count）。 ⚠️ 套件 README 寫「DeviceReferenceQuery（infra/flow_control/）」，該路徑已過時——現在在 jedi-task-platform 套件內。
3. 設備不存在丟 404（device_app_service.py:96-97，用套件的 DeviceErrorCode.DEVICE_NOT_FOUND）。

B-3 jedi-information-system

宿主自己寫的業務：

1. 列表的審計 nickname enrich——information_system_app_service.py:23 enrich_audit_nickname_objs(...)（唯一的 wrapper 理由）。
2. IUserLookup 實作——infra/information_system/jedi_auth_user_lookup.py，套件以 dependency inversion 依賴抽象、由宿主注入 jedi_iam 的 UserDomainService（FR-032 G 的先例）。

⚠️ 這支是五支裡最接近可以整組上移的：只差一支 24 行的 nickname wrapper。

B-4 jedi-flow-engine（規模差距最大的一支）

⚠️ 套件 README 說的「6,375 行」已過時——那是 2026-08-31（a1332c8d）當時的數字， 當時 app/flow_engine/ 有 9,183 行含 camunda_service.py 2,852 行與 bpmn_generator.py 2,428 行； 前者已於 CM-1486 退役（561922d4），後者已於 CM-1492 歸建套件（48e7923）。現值 3,263 行。

宿主自己寫的業務（每項一句）：

1. 階段推進 / 回退——stage_advance_service.py（702 行）＋ stage_rollback_service.py（189 行）， 靠 BPMN UserTask 的 stage_object_code / main_role extension property 識別階段， handler 由 grc 模組啟動時註冊進 stage_completion_registry（domain/flow_engine/service/stage_completion_registry.py，186 行）。
2. FE 流程編輯器範本管理——flow_template_app_service.py（264 行），builtin 範本＝全域共用、 一般租戶唯讀、平台管理員可維護（CM-906）；表是 compliance.flow_templates（14 筆），不是套件的 workflow_templates。
3. 任務證明（job evidence）——job_evidence_service.py（181 行）＋ domain / infra 三層。
4. 專案參與者守門——assert_project_participant()（workflow_execution_service.py:122）走 common.authz.workflow。
5. 輪次凍結 gate——_assert_round_not_frozen_for_workflow()（:155）。
6. 問卷關聯——process_survey_property()（:1466），actionType == 'SURVEY' 時把 job 綁 jedi_survey 的 TaskSurvey。
7. 設備 × 部門任務組合展開——build_task_combinations()（:1497，itertools.product）。
8. 四類通知——notify_users_batch_assigned / notify_user_todo_job / notify_control_reviewers_on_task_complete（:1265 / :1310 / :1376），走 NotificationService ＋ flask_babel i18n。
9. 控制項對應——workflow_execution_control_mapping（public.workflow_execution_control_mapping 表 ＋ domain service 32 行 ＋ repo 93 行）。
10. 擴充的執行體查詢——ExtWorkflowExecution（infra/flow_engine/models/ext_workflow_execution.py，164 行） 對 jedi_participant 的三張參與者表做 relationship / association_proxy / hybrid_property，是套件 model 沒有的。

B-5 jedi-system-config

宿主自己寫的業務：

1. 共用設定寫入釘死 ROOT——shared_config_app_service.py（88 行）：SMTP / LDAP 兩組設定讀取端一直讀 ROOT 那列， 但寫入端是 tenant-scoped，客戶存了不生效且無錯誤訊息；白名單 SHARED_ROOT_CONFIGS 把寫入拉回 ROOT（CM-1283 ③）。
2. 安全政策 group 粒度讀寫——security_policy_app_service.py（207 行，CM-1423）。
3. 出廠儲存快照還原——storage_config_restore_app_service.py（81 行，CM-1333）。
4. 租戶儲存設定 seeding——tenant_storage_config_seeder.py（118 行）＋ tenant_config_seed_writer.py（86 行）。
5. ROOT 設定直讀——system_config_root_reader.py（321 行，繞 tenant scope 的 raw 讀寫）。
6. 可見性守門——guarded_system_config_service.py:41-42 覆寫 get_system_configs() 過濾。

B-6 jedi-system-menu（對照組）

宿主只剩 80 行：infra/system_menu/system_menu_plugin_wiring.py（58 行，只組 adapters） ＋ di_containers/system_menu/system_menu_containers.py（22 行）。 沒有 api/ / app/ / domain/ 目錄。這就是「肉搬進套件之後」宿主該長的樣子。

C-1 jedi-bulletin BulletinService（7 個 public method）→ 100% 死碼

證據：grep -rn "jedi_bulletin.app.service" --include='*.py'（排除 .venv）在宿主 0 命中。 宿主用的是同名不同物的 app/bulletin/service/bulletin_service.py。 domain/bulletin/service/bulletin_domain_service.py（宿主，47 行）也是另寫一份， 與套件 jedi_bulletin/domain/service/bulletin_domain_service.py（43 行）方法名幾乎一樣但多了 locale 參數與 get_bulletin_by_uid / get_bulletin_by_id。 → 套件的 app 層 + domain 層 在生產上完全沒被執行，實際活著的只有三支 base class（entity / model / DTO）。

C-2 jedi-device DeviceService（8 個 public method）→ 2/8 死碼（25%）

C-3 jedi-information-system InformationSystemService（8 個 public method）→ 1/8 死碼（12.5%）

C-4 jedi-flow-engine（4 支 app service）

app service 死碼比例（按行）：549 / 920 ≈ 60%。

⚠️ 這代表 plugin.py:84-98 的 set_repo_providers() 接線（CM-1514 做的 app/infra 解耦） 在生產上不會被執行到——那 22 處 get_repos() 全在死掉的 WES 裡。

C-5 jedi-system-config SystemConfigService（10 個 public method）→ 1/10 死碼（10%）

C-6 jedi-system-menu SystemMenuService（9 個 public method）→ 3/9 死碼（33%），且呼叫者是套件自己的 route

宿主對這 9 支 0 直接呼叫——這正是「完整體插件」該有的樣子（宿主只給 provider，不碰 service）。

D-1 搬不進去的「產品知識」逐項

D-2 資料面的產品知識（DB 實查，DEV guidant_ai_dev @ 188:25432）

system_menus 的資料本身含產品知識（16 個 group）：

DEVICE_TYPE 11 | ssp_party_role 9 | ANS_TYPE 7 | AUDIT_METHOD 6 | TASK_TYPE 5
USER_STATUS 4 | PDF_PARSER 4 | STORAGE_TYPE 4 | FEEDBACK_TYPE 4
PROJECT_SELECT_RULE 4 | BULLETIN_CATEGORY 4 | SYSTEM_TYPE 3 | PERMISSION_OPTION 3
COMPLIANCE_FRAMEWORK_PUBLISH_STATUS 3 | ENABLE_STATUS 2 | AGENT_TYPE 1

AUDIT_METHOD（檢視 / 訪談 / 測試 / 文件檢查 / 電腦設定比對 / 門禁系統設定比對）、 ssp_party_role、COMPLIANCE_FRAMEWORK_PUBLISH_STATUS 全是稽核產品的字典值， seed 在宿主 scripts/init/04-seed-core.sql:138-143 與 scripts/sql/2026-06-20-audit-method-menu.sql。 套件搬走了 route 與 service，資料（seed）仍留宿主——這是 system-menu 現況的疆界形狀， 也是「合併成 jedi-system-dict」時要注意的：表結構可以是套件的，字典內容不可能是。

⚠️ system_menus 無 tenant_id、無 RLS、(group,key) 全域唯一——套件 plugin 的三個守門 刻意無預設值就是為了這件事（jedi-system-menu/.../plugin.py:220-224：缺接線直接拒絕掛載， 不是靜默跳過；預設放行＝任何人都能改到全站 UI 下拉選項，服務照常起、健康檢查照樣綠燈）。

D-3 搬家時要凍結的契約（宿主 route URL ＋ FE 常數）

bulletin（api/bulletin/__init__.py:20-24） | URL | FE 常數（compliance-manager-fe/src/config/api/api.js） | FE 引用數 | |---|---|---| | GET/POST /api/1.0/bulletins | BULLETINS（:88） | 1 | | POST /api/1.0/bulletin | BULLETIN（:89） | 5 | | GET/PUT/DELETE /api/1.0/bulletin/<uid> | BULLETIN + uid | （同上） |

device（api/device/__init__.py:22-27） | URL | FE 常數 | FE 引用數 | |---|---|---| | POST /api/1.0/devices | DEVICES（:327） | 3 | | GET /api/1.0/devices/menu | DEVICES_MENU（:328） | 2 | | POST /api/1.0/device | DEVICE（:329） | 4 | | GET/PUT/DELETE /api/1.0/device/<uid> | DEVICE + uid | （同上） | | GET /api/1.0/device/<uid>/references | DEVICE_REFERENCES（:330，函式型） | 1 |

information-system（api/information_system/__init__.py:23-26） | URL | FE 常數 | FE 引用數 | |---|---|---| | GET /api/1.0/information-systems/menu | INFORMATION_SYSTEMS_MENU（:197） | 4 | | POST /api/1.0/information-systems/list | INFORMATION_SYSTEMS_LIST（:198） | 1 | | POST /api/1.0/information-systems | INFORMATION_SYSTEMS（:199） | 1 | | GET/PUT/DELETE /api/1.0/information-system/<uid> | INFORMATION_SYSTEM（:200） | 3 |

system-config（api/system_config/__init__.py:26-36） | URL | FE 常數 | FE 引用數 | |---|---|---| | POST /api/1.0/system/config | SYSTEM_CONFIG（:334） | 16 | | GET/PUT/DELETE /api/1.0/system/config/<uid> | SYSTEM_CONFIG + uid | （同上） | | GET /api/1.0/system/configs/<group> | SYSTEM_CONFIGS（:335） | 1 | | GET/POST /api/1.0/system/config/storage/restore-default | FE api.js 無對應常數（未查證是否有硬編碼） | — | | GET/PUT /api/1.0/system/security-policy | SECURITY_POLICY（:449） | 2 | | GET/PUT /api/1.0/system/config/<group>/<key> | SYSTEM_CONFIG 拼接 | （同上） |

⚠️ api/system_config/__init__.py:29-36 有兩處路徑順序陷阱（註解已寫明）： storage/restore-default 與 security-policy 都必須避開 <group>/<key> 動態規則， 搬家時順序不可調換。

flow-engine（19 條 live，api/flow_engine/__init__.py:38-93） | URL | FE 常數 | |---|---| | /flow-engine/process/comments/<id> | PROCESS_COMMENTS（:101） | | /flow-engine/task/complete/<id> | TASK_COMPLETE（:102） | | /flow-engine/task/revert/<id> | TASK_REVERT（:103） | | /flow-engine/process-definition/<uid> | PROCESS_DEFINITION（:100）← 唯一吃套件 service 的那條 | | /flow-engine/task/queue | TASK_QUEUE（:104） | | /job-evidences、/job-evidence、/job-evidence/<uid> | JOB_EVIDENCES（:106）/ JOB_EVIDENCE（:105） | | /flow-engine/stage-objects | FLOW_ENGINE_STAGE_OBJECTS（:109） | | /flow-engine/flow-templates（＋ /validate、/<uid>、/<uid>/duplicate、/<uid>/publish、/<uid>/unpublish，共 6 條） | FLOW_ENGINE_FLOW_TEMPLATES（:110） | | /project/<pid>/audit-round/<rid>/stage/{info,advance,rollback,transitions}（4 條） | STAGE_API（:113） |

⚠️ /flow-engine/flow-templates/validate 必須註冊在 /<uid> 之前（__init__.py:68-70 註解）， 否則 validate 會被 uid converter 吃掉。

system-menu（已在套件，FROZEN_URLS 5 條） | URL | FE 常數 | FE 引用數 | |---|---|---| | /system/menu/<group> | SYSTEM_MENU（:25） | 16 | | /system-menu（POST） | SYSTEM_MENU_OBJECT（:26） | 4 | | /system/menus | SYSTEM_MENUS（:27） | 1 | | /system/category-menu | SYSTEM_MENU_CATEGORY（:28） | 1 | | /system-menu/<int:id>（PUT/DELETE） | SYSTEM_MENU_OBJECT + id | （同上） |

E-1 補殼 commit 一覽（monorepo git log）

E-2 「為什麼當時沒把 route 搬進來」——原話逐支抄錄

jedi-flow-engine（738f13d commit message，同文亦在 jedi-flow-engine/README.md:173-186 與 plugin.py:20-45）：

原卡（P3.4）要求照 3.1 jedi-iam 範本把主專案 api/flow_engine/ 的 route 上移進本 套件。實查後證明做不到，已停手回報、決策者 2026-08-31 裁示降級（(a)＋(c)）：

• 主專案 api/flow_engine/ 共 19 條 live route，只有 1 條 （/flow-engine/process-definition/<uid>）吃本套件的 service；
• 其餘 18 條吃主專案 app/flow_engine/（6,375 行）與 app/flow_control/ ——流程範本管理、階段推進／回退、任務證明。搬進來＝套件反向 import 主專案。
• ⚠️ 系統內有兩套同名不同物的「流程範本」：主專案 flow_templates（FE 編輯器 畫的 BPMN，6 條 API）vs 本套件 workflow_templates（引擎執行期快照，1 條）。 原卡指的是前者，它整組不在套件裡。

route 歸屬已排入第四階段「流程疆界」設計（flow-engine／flow_control／project 三方同席，與 P12／P13 同場）。

plugin.py:37-43 另補一句紅字：

在那之前，不要因為「順手」把主專案的 service 用 provider 名冊接進來——那不是 補殼，是把 flow_control 的疆界問題偷渡進本套件。

jedi-bulletin（README.md:26-36、plugin.py:23-38）：

主專案 api/bulletin/ 的 5 條 route 吃的是主專案的 app/bulletin/service/bulletin_service.py（181 行），不是本套件的 BulletinService。 那支主專案 service 的相依是產品知識、不是公告知識：

• BulletinOrgUnitDomainService——公告↔︎部門對象關聯（domain/bulletin/ 在主專案）
• jedi_iam 的 UserDomainService / OrgUnitDomainService——審計欄位 nickname、部門樹
• 主專案 common.code.ErrorCode——BULLETIN_INVALID_TIME_WINDOW 等業務規則碼

把它們搬進來等於套件反向 import 主專案（正是抽套件要消滅的東西）；把它們宣告成套件的 provider 名冊，則是把「公告要發給哪些部門」這個產品規則偷渡進通用套件。

jedi-device（README.md:26-40、plugin.py:23-41）：

主專案 api/device/ 的 4 條 route 吃的是主專案的 app/device/service/device_app_service.py（98 行），不是本套件的 DeviceService。 那支 wrapper 的存在理由正是產品規則：

• 審計欄位 nickname enrich……這是本產品的 API 回傳規範……不是設備知識。
• DeviceReferenceQuery……刪除前查「這台設備被幾個稽核任務引用」。稽核任務是主專案的疆界，設備套件不該知道它存在。

⚠️ DeviceReferenceRoute 這種「被誰引用」的查詢天生跨疆界（要問稽核那邊）， 故留宿主是正確的分工，不是遷就。

jedi-information-system（README.md:26-37、plugin.py:23-36）：

主專案 api/information_system/ 的 6 條 route 是混合的：

• 4 條（menu / create / detail get・put・delete）直接吃本套件的 InformationSystemService ✅
• 1 條（InformationSystemListResource）吃主專案的 InformationSystemAppService…… 它做的事是審計欄位 nickname enrich……那是本產品的 API 回傳規範，不是資訊系統知識。

只搬 4 條、留 1 條在主專案，會讓同一個資源的端點散在兩個 blueprint 裡——URL 前綴 相同、真相卻有兩處，比現狀更難維護。故整組留宿主，等 D8「身分脈絡名冊」定案 （把 nickname enrich 變成套件可用的 port）之後再整組上移。

jedi-system-config（README.md:26-42、plugin.py:23-38）：

主專案 api/system_config/ 的 route 分兩群，都不能上移：

• SystemConfigRoute / SystemConfigsRoute / SystemConfigGroupRoute（混合）： 同一個 handler 同時吃本套件的 SystemConfigService 與主專案的 SharedConfigAppService（app/system_config/，88 行）——後者處理「共用設定 （ROOT tenant 那份）怎麼與租戶自己的那份合併」，那是多租戶的產品規則。
• StorageConfigRestoreRoute / SecurityPolicyRoute（純主專案）： 分別吃 StorageConfigRestoreAppService（81 行）與 SecurityPolicyAppService（207 行） ——出廠儲存快照與安全政策，兩者都是產品功能，不是「設定表 CRUD」。

主專案 app/system_config/ 合計 585 行，全部是產品知識。

jedi-system-menu（README.md:12-20，反面說明為什麼它搬得動）：

P3.5 補殼七支裡，只有三支（本支／jedi-issue／jedi-log）做了 route 上移， 判準是service 在哪：

	本套件	同批的 bulletin／device／system-config／information-system
service	全在套件內	在主專案（wrapper app service，含產品規則）
route	已上移進套件 ✅	留宿主（搬進來＝套件反向 import 主專案）
D6 五件套	全做到（含拔掉測試）	只做到三項（無 api 層＝無拔掉測試可驗）

四支空殼共用的「驗收邊界誠實聲明」表（例 jedi-bulletin/README.md:13-21）：

E-3 flow-engine 特別調查：宿主 6,375 行 vs 套件 workflow_execution_service.py 的關係

結論：宿主是 2025-07-14 從套件 fork 出去的，之後兩邊各自演化 14 個月，套件那支從此在生產上零使用。

證據鏈：

1. fork 時間點——套件那支的第一版出現在 c57b16b（2025-07-13，「更新Table 名稱 process_definition → workflow_template…」）； 宿主那支的第一次出現是 65fedaa7（2025-07-14，「flow-engine refactor V1.4」，+525 行）。間隔一天。

2. fork 時兩檔幾乎逐字相同——把兩個歷史版本抓出來對比：

   • 套件 c57b16b 版：485 行
   • 宿主 65fedaa7 版：524 行
   • diff 輸出僅 63 行，且差異全部集中在四個點：
     • +import json
     • +from jedi_flow_engine.domain.entity.hi_workflow_template_query_Entity import HistoryWorkflowTemplateQueryEntity
     • +from app.task_survey.service.task_survey_service import task_survey_service ← 這就是 fork 的動機
     • 一段 35 行的新邏輯：把 job properties 的 devices 拆成 element variable ＋ actionType == 'SURVEY' 時呼叫 task_survey_service.link_task_survey(...)

   也就是說：fork 的直接原因是「要在建 job 時關聯問卷」，而 task_survey_service 在主專案。 （套件後來為此開了 on_job_created callback hook，見 jedi-flow-engine/.../workflow_execution_service.py:31-37 ——但宿主沒有回頭改用那個 hook，fork 已經走遠。）

3. 演化落差（現況）：

   	套件 jedi_flow_engine/app/service/workflow_execution_service.py	宿主 app/flow_engine/service/workflow_execution_service.py
   行數	549	1,559
   method 數	13	29
   建構子	(workflow_template_service, on_job_created=None)	15+ 個注入參數（di_containers/flow_engine/workflow_excution_containers.py:128-150）
   repo 取得方式	get_repos()（CM-1514 的 wiring 縫隙，22 處）	建構子注入的 domain service
   宿主獨有 method	—	assert_project_participant、_assert_round_not_frozen_for_workflow、complete_main_workflow_job、add_job_comment、get_ext_main_workflow_executions_and_pager、notify_*×3、process_survey_property、build_task_combinations、get_ext_workflow_execution_by_uid…
   共同 method 也已分歧	complete_job(…, user_nickname)	complete_job(…, user_nickname, suppress_notify=False)
   	revert_job(…, user_nickname)	revert_job(…, suppress_notify, bypass_round_frozen_gate, known_project_id)
   	update_job_comment	同名但宿主另有 add_job_comment
   	start_workflow_execution(…)	start_workflow_execution(…, locale=None)

4. 套件那支現在有沒有人用？零。 grep -rn "jedi_flow_engine.app.service.workflow_execution_service" --include='*.py'（排除 .venv）在宿主 0 命中； 在套件內部除了自己與 tests 也沒有 caller。 → 套件的 WorkflowExecutionService（549 行）是純死碼， 而 CM-1514（3502e3e）為它做的 app/infra 解耦（app/wiring/ ＋ plugin 的 set_repo_providers） 是對死碼做的架構修正——測試會綠，生產不走這條路徑。

5. 另一半是真的在用的：WorkflowTemplateService（237 行）被宿主 5 處 import、 ElementVariableService（84 行）被 2 處 import——它們沒被 fork，宿主直接吃套件版。 也就是說 flow-engine 不是「整包沒被用」，而是四支 app service 裡最大的那支被 fork 掉了。

F-補充：一個容易誤讀的比例

「套件行數 vs 宿主行數」不是「該不該併」的直接指標，因為兩邊的內容性質不同：

• bulletin：套件 647 行幾乎不執行，宿主 878 行是全部真相 → 套件是影子。
• device / information-system：套件是真核心（770 / 1,146 行都在跑），宿主 412 / 405 行是薄殼 → 這兩支離完整體最近。
• system-config：套件 921 行在跑，宿主 1,740 行也在跑，兩邊都是真肉 → 疆界確實混。
• flow-engine：套件 6,728 行裡 549 行是死的、bpmn_generator.py 2,428 行是 CM-1492 才搬進去的真資產；宿主 7,011 行是產品流程 → 兩邊都大，且有一塊重複。

1. jedi_flow_engine.app.service.JobExecutionService 是否真的零使用——它在 DI container 有註冊（di_containers/flow_engine/workflow_excution_containers.py:111-114），但我 grep 不到取用 job_execution_service provider 的呼叫端。可能有 Provide[...] 的間接取法我漏掉。若確認零使用，flow-engine 死碼比例會從 60% 升到 65%。
2. /system/config/storage/restore-default 的 FE 呼叫端——compliance-manager-fe/src/config/api/api.js 沒有對應常數，未查證是否有頁面硬編碼字串或走 SYSTEM_CONFIG 拼接。搬家時這條契約沒有 FE 常數當錨點。
3. STG / POC 的 system_menus 內容是否與 DEV 一致——本次只查 DEV（guidant_ai_dev）。若三環境字典內容有落差，「搬字典」的成本會比看起來高。
4. 各套件 tests/ 內是否還有第二個 service 使用者——我只查了 <mod>/ 本體與宿主，套件自己的 test 也算「有人用」但不算生產使用；死碼比例是以生產呼叫為準統計的。
5. jedi-bulletin 宿主 domain service 與套件 domain service 的差異是否只有 locale 與兩支 by_uid/by_id——我比對了方法簽名，沒有逐行 diff 內部實作。若內部邏輯也已分歧，就是第二個 fork（性質同 flow-engine WES）。
6. information-system 的 get_information_systems（app 層）與 domain 層同名 method 是否語意等價——宿主全部走 domain 層那支，app 層那支標為死碼；若兩者行為不同（例如 app 層多做 DTO 轉換或 user_lookup enrich），這個「死碼」標籤可能是「該用而沒用」而非「不需要」。