/audit-round/ /audit-round/
＋狀態機（作答→送審→核可/退回）
＋設定規格（審核開關，D18）
＋頁面路由
PLAT-->>SURVEY: ok（平台不認識「問卷」是什麼）
Note over PLAT: 平台只存：型別代號／狀態圖／設定規格
USER->>PLAT: 完成一個 survey 任務
PLAT->>PLAT: 查設定：這個租戶要不要審核？
alt 審核開啟
PLAT->>PLAT: 狀態 作答完成 → 待審核
PLAT->>SURVEY: 通知審核者（走平台的指派與通知）
else 審核關閉
PLAT->>PLAT: 狀態 作答完成 → 完成
end
```
**現況離目標比想像中近**：`app/task_survey/common/task_survey_code.py` 已經有 `TaskSurveyStatusCode`（UNFILLED／EDITING／UNDER_REVIEW／ADD_NOTES／COMPLETED）——**審核狀態本來就在**。差別只在於，推進這些狀態的邏輯目前散在 `workflow_execution_service`（1,679 行）裡，而不是由問卷插件自己申報。
::: {.callout .decided}
**「客戶 A 要審核、B 不要」怎麼走**
走 D18 設定 schema 申報制：問卷插件申報一個租戶層級的開關（`survey.review_required`，預設值寫在程式裡），值存在主程式的 `system_configs`。這是**現成的表、現成的 `(tenant_id, group, key)` 唯一鍵，不需要新開表**。平台推進狀態時查這個開關，決定要不要走 UNDER_REVIEW。
**交付成本：從「兩套客製程式」降為「一個勾選項」。**
:::
---
## 待決項（D 編號，請逐項拍板） {#pending nav="待決項"}
**這節在講什麼：9 個看不準的地方，每個附建議與理由，請決策者逐項裁。**
::: {.callout .pending}
**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 步再切三份。]{.rec}
:::
::: {.callout .pending}
**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 確立後，它不再是孤兒，而是平台包的種子。]{.rec}
:::
::: {.callout .pending}
**D-3｜job_import_service.py（464 行）該歸通用還是稽核？**
**現況**：任務批次匯入／匯出是通用動作，但 Excel 欄位裡含 AO 和控制項對應（participant 34／device 29／ap-ar 7）。
[**建議：算通用，但欄位定義改成申報制，因為機制和規格是可以分開的。** 平台提供匯入匯出的機制（讀 xlsx、驗證、批次建立），欄位規格由各任務型別的插件自己申報。如果覺得現在判斷太早，第 1 步就整支帶走留在稽核那邊，第 3 步再議。]{.rec}
:::
::: {.callout .pending}
**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 支不隨包走」**。]{.rec}
:::
::: {.callout .pending}
**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，守衛測試就能證明）。]{.rec}
:::
::: {.callout .pending}
**D-6｜job_dto.py（361 行）裡那 6 處稽核欄位怎麼辦？**
**現況**：整體是任務 DTO（通用），但裡面含 6 處 ap／ar 欄位。
[**建議：整支當通用帶走，6 處稽核欄位改由插件擴充，因為為了 6 個欄位把整支判成稽核並不划算。** 做法比照 D8 的 JSONB 擴充容器／`project_extensions` 模式。第 1 步不動，第 2 步再處理。]{.rec}
:::
::: {.callout .pending}
**D-7｜review_service.py（123 行）和 review_marks 這張表該歸誰？**
**現況**：「審閱標記」這個機制本身是通用的（標記某個東西已審閱、記下誰在什麼時候標的），但被標記的東西是 control／AO，而且權限走 `ParticipantRole.MANAGER/REVIEWER`。
[**建議：算通用，因為「東西可以被標記為已審閱」是任何流程產品都會有的能力。** 被標記的對象用軟參照（D17 律②：只存識別碼、不建外鍵），由插件決定標的是什麼。如果反對意見成立（覺得現在就通用化太早），退回稽核那邊也不影響第 1 步。]{.rec}
:::
::: {.callout .pending}
**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 面看起來停了，程式面卻還接著線，屬於「上了膛的槍」那一型。]{.rec}
:::
::: {.callout .pending}
**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 步不動它。]{.rec}
:::
---
## 動工分步計畫（草案） {#plan nav="動工計畫"}
**這節在講什麼：四步怎麼走、每步做什麼、怎麼驗收。**
::: {.callout .warn}
**這是草案，四步的實際範圍以拍板後的 D 裁決為準。** 每一步各自都能交付、都能停下。
:::
### 第 1 步：搬出來（機械搬家，不做任何分家） {#plan-1 nav="-"}
**做什麼**：`app/flow_control/`＋`domain/flow_control/`＋`infra/flow_control/`＋`api/flow_control/` 整包搬成套件（照 jedi-iam「先搬家、後裝修」的先例），import 名稱不變、業務邏輯原樣帶走。D-4 那 4 支讀寫混合的 query **原地不動**，並在套件 README 誠實寫明不隨包走。
**驗證**（照 3.1 全額）：① URL 集合比對——搬前搬後 `flask routes` 的輸出逐字相同；② 守衛測試 `python -m pytest test/test_module_boundaries.py` 全綠（目前基準 **64 綠**）；③ 拔掉測試（D6 驗收核心）；④ 稽核主流程手測。
**風險**：這是整個案子最大的一次搬遷（226 個檔）。**建議先做 D-5（兩支純讀 query 補進 readmodel）和 D-8①（3 支 dark stub 退役）當熱身**——兩件都是低風險的機械工作，而且能把第 1 步要搬的面積縮小。
### 第 2 步：分家（通用部分下沉） {#plan-2 nav="-"}
**做什麼**：把 §5 判為通用的那 12 支（加上拍板後從「看不準」轉進來的）下沉（往下移到共用的底層）成 task 平台層；`workflow_execution_service` 那四條真正跨模組的線改成 port（D-9）；stage_advance／stage_rollback 從 flow_engine 移到稽核那邊。
**驗證**：手測同上；**另外加一條**——請 Claude 證明「平台層 grep 不到 poam／audit_round／assessment_plan／ssp」。這條是分家成功與否的機械判準。
### 第 3 步：改成申報制 {#plan-3 nav="-"}
**做什麼**：`FlowControlJobType` 從寫死的枚舉改成申報制；`job_service` 切成三個 handler（D-1）；問卷插件申報審核狀態機和設定規格（D18）。
**驗證**：問卷任務的「送審／核可／退回」走得通；**把設定開關關掉之後審核步驟消失**——這一條是「設定不是客製」的驗收核心。
### 第 4 步：打包 {#plan-4 nav="-"}
**做什麼**：task 平台包（吸收 jedi-project 種子）和稽核插件各自上 Nexus，照 [extraction-sop](extraction-sop.md) 的 D6/D7 標準（register 簽名／standalone harness／接入 README／拔掉測試）。
**驗證**：`poetry show` 看得到兩個版號；**拔掉稽核插件之後系統仍然起得來**（只是沒有稽核功能）。
::: {.callout .decided}
**順序刻意安排成「先分家、後打包」**——第三階段已經證明：邊界切乾淨之後再補外殼，是機械工。反過來先打包，會把「哪些算通用」的判斷錯誤鎖進套件版號裡，之後要改，貴十倍。
:::
---
## 邊界與凍結事項 {#limits nav="邊界"}
**這節在講什麼：哪些東西一個字都不能動，以及這份稿子刻意不碰的範圍。**
::: {.callout .crit}
**這些東西一個字都不能動（重申 D5）**
1. **error code 的字串值**（`GRC_404001` 等）——這是對外契約，前端 `error-code.json` 靠字串比對做多語系。改類別名稱可以（`GrcErrorCode`→`FlowControlErrorCode` 就做過），**改值不行**。
2. **對外 API 的 URL 路徑**——前端已經在用。所以 §6 判定「4 條 stage route 歸稽核」時，路徑 `/project/