24,600 行要切在哪裡

D-1｜job_service.py 這支 1,144 行的大檔案要怎麼分家？

現況：稽核詞全 0（看起來是乾淨的通用候選），但檢測工具詞 88／問卷詞 73／指派詞 33——它其實把三種任務型別的處理全塞在同一支：_replace_detection_tool_binding（檢測）、_reconcile_task_surveys／_replace_survey_snapshots（問卷）、_resolve_job_assignees（指派）。

建議：切成三份，因為這三種型別的程式碼已經物理上相鄰，切開就直接變成三個 handler。 ① 任務 CRUD＋指派＋通知 → task 平台層；② _replace_detection_tool_*（約 400 行）→ 檢測插件申報的 handler；③ _reconcile_task_surveys／_replace_survey_snapshots（約 150 行）→ 問卷插件申報的 handler。這支正是「任務型別 handler 申報制」最好的第一個示範。但這是第 3 步（平台化）的工，不是第 1 步（搬出來）的工：第 1 步整支帶走，第 3 步再切三份。

D-2｜project_service.py（812 行）跟 jedi-project 之間該怎麼理？

現況：專案 CRUD 是通用動作，但 get_project() 會去拼 participants、living SSP 的 inventory 分類、devices/audit_systems、owner nickname（盤點 #5：教科書級的套餐窗口，DTO 的四個欄位來自四個不同模組）；participant 這個字出現 55 處。同時 jedi-project（399 行）已經被掏空，而且反過來 import 主專案（jedi_project/app/dto/*.py 有三支 import app.common.dto.base_dto，本棒實查才發現）。

建議：拆成兩支，因為 CRUD 和聚合查詢本來就是兩件事，混在一起才讓歸屬看不準。 ① 專案 CRUD／狀態 → 併入 task 平台包（吸收 jedi-project 當種子，同時把反向 import 修掉）；② get_project() 的聚合部分 → infra/readmodel/ 或 app/readmodel/。這樣也順勢解掉 D15「jedi-project 疆界待決」——路 B 確立後，它不再是孤兒，而是平台包的種子。

D-3｜job_import_service.py（464 行）該歸通用還是稽核？

現況：任務批次匯入／匯出是通用動作，但 Excel 欄位裡含 AO 和控制項對應（participant 34／device 29／ap-ar 7）。

建議：算通用，但欄位定義改成申報制，因為機制和規格是可以分開的。 平台提供匯入匯出的機制（讀 xlsx、驗證、批次建立），欄位規格由各任務型別的插件自己申報。如果覺得現在判斷太早，第 1 步就整支帶走留在稽核那邊，第 3 步再議。

D-4｜4 支讀寫混合的 infra query 該怎麼處置？

現況（實查）：flow_control_job_repo_impl（1,015 行／21 處寫入／13 表／3 schema）、flow_control_project_repo_impl（720／1／13）、task_execution_query（277／1／12）、reverify_clone_query（175／6／8）。readmodel 的規則寫死「會寫入的一律不收」，所以這 4 支進不去；但它們的 SQL 跨 3–4 個 schema，誤搬進套件就會靜默出錯（4.A 當初建 readmodel 就是為了防這個）。

建議：逐支切成兩半，因為讀和寫的搬遷風險完全不同。 純讀的跨模組查詢方法抽出來放進 infra/readmodel/，會寫入的方法留在原模組。reverify_clone_query 是例外：它整支在做「跨模組搬運」（複製任務＋證據＋問卷作答＋設備關聯），本質是主程式的編排工作，整支留在主程式。逐支評估切法是第 2 步的工，第 1 步先原地不動，並在套件的 README 誠實寫明「這 4 支不隨包走」。

D-5｜auditor_dashboard_query.py（106 行）要不要補進 readmodel？

現況：純讀，跨 compliance／oscal 兩個 schema 四張表，形狀跟 4.A 已經搬過去的那五支完全一樣，只是當時漏收，還留在 infra/flow_control/repository/。同型的還有 job_batch_complete_query.py（271 行／純讀／compliance＋oscal）。

建議：兩支都補進 infra/readmodel/，因為它們跟已搬的五支同型，留在原地只是不一致。 同時更新該目錄 __init__.py 的成員表。這是低風險的機械工作，可以在第 1 步之前先單獨做掉（純搬檔＋改 import，守衛測試就能證明）。

D-6｜job_dto.py（361 行）裡那 6 處稽核欄位怎麼辦？

現況：整體是任務 DTO（通用），但裡面含 6 處 ap／ar 欄位。

建議：整支當通用帶走，6 處稽核欄位改由插件擴充，因為為了 6 個欄位把整支判成稽核並不划算。 做法比照 D8 的 JSONB 擴充容器／project_extensions 模式。第 1 步不動，第 2 步再處理。

D-7｜review_service.py（123 行）和 review_marks 這張表該歸誰？

現況：「審閱標記」這個機制本身是通用的（標記某個東西已審閱、記下誰在什麼時候標的），但被標記的東西是 control／AO，而且權限走 ParticipantRole.MANAGER/REVIEWER。

建議：算通用，因為「東西可以被標記為已審閱」是任何流程產品都會有的能力。 被標記的對象用軟參照（D17 律②：只存識別碼、不建外鍵），由插件決定標的是什麼。如果反對意見成立（覺得現在就通用化太早），退回稽核那邊也不影響第 1 步。

D-8｜已停用的東西怎麼處理：3 支 dark stub service，加上 oscal_audit_service（409 行）？

現況：control_service／control_group_service／assessment_object_service（225 行）的 route 都已經在 api/flow_control/__init__.py 註解停用（2A dark stub 回空、前端沒有人在呼叫），只剩 DI 註冊還活著。app/project/oscal_audit_service.py（409 行）是舊的 AP-scoped 生命週期，新模型走 /audit-round/*——但它仍然被 AuditService 和 stage_advance_service 引用（實查有活的引用鏈），不是純粹的死程式。

建議：分兩類處理，因為「route 停了」和「程式沒人接線」是兩回事。 ① 3 支 dark stub：搬遷前先退役（route 已停、只剩 DI），省下 225 行的搬家成本——但退役前必須先驗證拔掉 DI 註冊不會炸（flow_control_containers.py 有 713 行的交叉引用）。② oscal_audit_service：不動，跟著稽核那邊走；它到底是不是殭屍需要另派一棒查證——route 面看起來停了，程式面卻還接著線，屬於「上了膛的槍」那一型。

D-9｜workflow_execution_service.py（1,679 行）要怎麼切？

現況：它是 flow-engine 這邊最大的一塊未定案——26 個依賴橫跨 participant／task_survey／notification／associations／module_frame 五個模組（盤點的「假聚合清單」#4 判定其中 12 個是 jedi_flow_engine 自家的，真正跨模組的只有 4 條線）。而 #11–14 這四條還在用的 route 全都吃它。

建議：算通用（歸 task 平台層），因為真正跨模組的只有 4 條線，改成 port 注入就乾淨了。 四條線的改法：TaskSurveyService→改由任務型別 handler 申報、NotificationService→改走 INotifier port（D17 律③已經有樣板）、ProcessParticipantService／ProjectControlParticipantService→改用平台自己的指派能力（P12 完成後 participant 已經是套件）、UserService→改走身分名冊 port（D8 標準件）。這支是第 2 步的主戰場，第 1 步不動它。