# 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 未做 |

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

### 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 任務類型不受影響

## 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 母卡狀態應由驗收通過後才更新，未特意先改 |

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

1. **驗收**：完全沒做。按 `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 附近，該處刻意不送某些欄位的既有慣例)
2. **`TaskSetupView.vue` 斷頭頁本身**：仍然存在（`fetchTree()` 404 bug），依原裁決不修，僅記錄在 CM-919 卡內，需 user 之後決定是否清除。
3. **push**：BE/FE 皆未 push，需 user 明示才做。
4. **56.3 runner 進度**：本 session 未接觸，不清楚現況，交由主導 session 依 §3b 另外追蹤。
5. **56.4**：依 §3c，需 .2 + .3 都驗收放行才派工，尚未到這一步。

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

```bash
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），需和之前一樣暫時解封鎖再測完還原。