FR-056.2 runner 完工交接（T-2.1 / T-2.2 / T-2.3 全數完成，待主導 session 驗收）

項目	內容
交接日期	2026-07-26
本 session 角色	56.2 runner（Sonnet 5）——負責實作，不負責驗收放行
對應母交接	`2026-07-26-orchestrator-mid-arc-handoff.md`（同資料夾）§3b「56.2 或 56.3 完成回報 → 驗收」就是接下來要做的事
Branch（BE/FE 皆同）	`feature/scan-plugin-integration`（未切過 branch）
一句話現況	T-2.1/T-2.2/T-2.3 三個子任務全數完成、程式碼已 commit、關鍵路徑已真實手測驗證；Notion CM-917/918/919 已回填；尚未經過獨立驗收，且 push 未做

§1

這一棒做了什麼（照子任務）

T-2.1（CM-917）：`GrcJobType.DETECTION_TOOL` 列舉 + BPMN 同步

Commit：a5a7cf4c
內容：enum 新增值、_sync_task_to_template_xml() 擴充寫入 actionInfo/toolParams/completionMode（camunda:property）

T-2.2（CM-918）：`config.job_execution_detection_tools` 綁定表 + param-schema 讀取 API + completion_mode

主要 commit：d378596e（binding 表 DDD 九層 + API）
後續修正 commit（同一子任務範圍內，驗收時應一併看）：
- c51bd884：讀取端（list_jobs/get_job）補回 tool 欄位——寫入端做完後自行發現讀取端沒回傳，會讓「重開任務參數還在」的驗收失效，主動補上
- afdb9b44：RLS policy bug——新表的 RLS policy 抄了 T-1.1 修正前的舊寫法（逗號分隔、is_super_admin 比 'true' 而非 't'），真實非 super-admin 登入會炸 InvalidTextRepresentation；已修正對齊 T-1.1 已修正版本
- 8efbb6b2：Step 0.5（中途主導 session 追加的範圍外補洞）——config.detection_tool_param_schemas 原本零 seed，補 OpenVAS 的 4 欄位 param_schema（hosts 必填 + timeout_sec/scan_config_id/scanner_id 選填），key 命名對齊 evidence-agent connector 消費端

T-2.3（CM-919）：FE 任務類型 UI —— 有落點錯誤返工，這是本棒最大的插曲

第一次实作落錯頁：加在 TaskSetupView.vue（FE commit f7d4968），事後手測才發現這頁是斷頭頁——ui_routes 無選單條目、程式內無任何導覽點、fetchTree() 打的 API 路徑（缺 /ap/<ap_uid>/ 段）本身就是 404。此判斷經主導 session 獨立確認。
返工：
- git revert f7d4968 → FE commit fd2e837
- 在真實頁面 ProjectPlanningView.vue（路由 /project/projects/:id/round/:roundUid/planning，「控制項實作」Tab 的任務面板）重做 → FE commit 5914df2
- BE 同步補上 control-tree 讀取端的 detection_tool 綁定 enrichment（因為 ProjectPlanningView 走的 get_control_tree/build_control_tree_by_ssp_id 是完全不同於 TaskSetupView 的資料路徑）→ BE commit 37451cd2
手測：在真實頁面（非暫時 patch）完整走過一輪：選 OpenVAS → 4 個參數欄位正確渲染（驗證 Step 0.5 seed）→ 填 hosts=192.168.50.100 → 選完成模式 auto → 存檔 → DB 驗證正確 → 重整頁面驗證 prefill 全部回填 → 確認 general/survey 任務類型不受影響

§2

Notion 現況（已回填，可直接查驗）

Case	page_id	狀態
CM-917（T-2.1）	—	修正待驗證（沿用先前回報格式）
CM-918（T-2.2）	—	修正待驗證
CM-919（T-2.3）	`3a9346da-4cd0-8134-8e92-dea4a6486607`	修正待驗證（含完整返工回報 + 執行紀錄，接在主導 session 原本的「落點錯誤返工」說明之後）
CM-909（FR-056.2 母卡）	`3a9346da-4cd0-8182-8451-f473f1bde2d5`	本棒未動——依 §3b 慣例，56.2 母卡狀態應由驗收通過後才更新，未特意先改

§3

尚未做 / 交給下一棒（主導 session）的事

驗收：完全沒做。按 2026-07-26-orchestrator-mid-arc-handoff.md §3b「56.2 重點」清單派獨立 subagent 驗收：
- GrcJobType 枚舉加值後全 call site 是否掃過
- BPMN userTask 同步線（_sync_task_to_template_xml()）正確性
- 綁定表 migration 鐵則（含這次修正過的 RLS policy）
- completion_mode 只是欄位不是狀態——確認沒人誤動 JobStatus/jedi_flow_engine
- FE 落點正確性——這點原始驗收清單沒寫,但這次有落點錯誤返工插曲,建議驗收時額外確認：TaskSetupView.vue 已確實 revert 乾淨（git show fd2e837 --stat）、ProjectPlanningView.vue 的改動沒有動到 executeQuickConfig()(L1271 附近，該處刻意不送某些欄位的既有慣例)
TaskSetupView.vue 斷頭頁本身：仍然存在（fetchTree() 404 bug），依原裁決不修，僅記錄在 CM-919 卡內，需 user 之後決定是否清除。
push：BE/FE 皆未 push，需 user 明示才做。
56.3 runner 進度：本 session 未接觸，不清楚現況，交由主導 session 依 §3b 另外追蹤。
56.4：依 §3c，需 .2 + .3 都驗收放行才派工，尚未到這一步。

§4

Pre-flight（下一棒接手先跑）

cd ~/Projects/Billows/Audit-Manager/compliance-manager-be
git branch --show-current   # 應為 feature/scan-plugin-integration
git log --oneline -12       # 對照上面 commit 列表
git status --short          # design.md / implementation-plan-phase2.md 有 M（主導 session 先前更新的 plan 文件，非本棒改動，勿覆蓋）

cd ~/Projects/Billows/Audit-Manager/compliance-manager-fe
git log --oneline -6        # 應看到 5914df2 / fd2e837 / f7d4968

DB 現況注意：測試期間曾暫時解除專案 296（compliance.project_extensions）的軟刪除標記做手測，已於測試後還原（deleted_at 恢復原值 2026-07-23 04:43:26.37393），驗收時若要重新手測，此專案的 control-tree（IA 群組、3 個 AO）可繼續沿用，但注意其 GRC-project 層級本身是軟刪除狀態（get_project API 會回 403），需和之前一樣暫時解封鎖再測完還原。