AO 任務配置與啟動（Task Config）

功能群：專案管理｜上層見 專案規劃頁（本頁＝其 Tab0「控制項實作」的 AO 任務配置，規劃頁功能總覽第 4／5／6 項）

事實基準：2026-07-06 從 FE / BE code 掃出；表結構對 db_schema.json、endpoint 對 routes.json、欄位對 marshmallow serializer + service 組裝碼逐條核

變更紀錄：

• 2026-08-01（FR-059）：profile 下拉動態化——CINC Auditor / GCB 的 profile 欄位改由「掃描設定檔庫」動態餵選項：param_schema 升 v2 加 "options_source": "profile_library" 宣告並拿掉靜態 options，FE 偵測宣告改呼 profile menu API（帶工具 uid 過濾，GCB 池與 CINC 池分開）；型別維持 select_or_text、手填能力保留。取值來源三層並存：庫內檔案型（profile:<uid> 參照）/ 庫內連結型 / 現場手填（既有任務存的舊靜態選項值照常可用）。設定檔的上傳與維護見新頁 掃描設定檔管理
• 2026-08-01（FR-058.5/.6/.7）：檢測工具下拉新增 SonarQube（原始碼安全檢測 SAST），三種取源模式以 scan_mode 參數分流——pull 讀取既有結果／scan 掃描公開 Git repo／upload 上傳源碼壓縮包（各自參數與適用情境見 §5「SonarQube 的掃描參數與三種執行模式」）；scan／upload 為寫入行為（會在客戶 SonarQube 建立/更新 Guidant-AI- 前綴專案），任務卡加橘色警語區塊事前告知（D24 配套）；upload 模式的壓縮包不在本頁上傳（於任務抽屜發起執行時提供，D26）；upload 任務不進「開始執行任務」自動派發（D33，批次發佈 confirm 文案加註提示）；condition.value 語法擴充支援陣列形式（一欄可同時綁多個模式值）。另 GCB 的 profile 下拉由 1 筆示範擴為 8 支 TWGCB 作業系統類基準（fr058-18；後續已由 FR-059 改為設定檔庫動態餵）
• 2026-07-31（FR-058）：檢測工具下拉新增四款（ZAP / CINC Auditor / Nmap / 政府組態基準 GCB），各自的掃描參數見 §5「四款新工具的掃描參數」；任務層敏感參數加密（param_schema 的 secret:true 欄位如 ZAP 登入密碼，DB 存密文、API response 整個 key 剝除、FE 靠 secret_keys_set 顯示「已設定」）；掃描參數必填驗證（原本完全不驗、缺參數的任務照樣存檔到 agent 執行期才失敗，改為存檔前擋下且 condition-aware）；CINC Auditor 的 profile 參數由 text 改 select_or_text
• 2026-07-29（FR-057）：檢測工具任務新增 select_or_text 掃描參數型態（下拉常用選項 + 自由輸入，OpenSCAP profile 欄位用）；選定工具後有 default 值的參數欄位自動帶入預設值（onSelectDetectionTool 新行為，見 §5 / §10）
• 2026-07-27（FR-056）：任務類型新增 detection_tool（檢測工具執行）——選定工具後動態渲染掃描參數 + 完成模式（manual/auto）；「開始執行任務」批次動作新增自動派 detection 任務首次掃描（見 §6.3）
• 2026-07-06 FR-047 從 project-planning.md 拆出並納入快速配置 / 開始執行

1. 功能描述

AO 任務（prep-job）是「為每個控制項評估目標（AO）蒐集證據」的工作項。本頁涵蓋任務域的三件事：①單一任務逐欄配置（inline 編輯）、②快速配置（一鍵把多位人員批次併入所有可編輯任務）、③開始執行（PM 把已指派任務批次轉 PROCESSING 並通知）。

規劃頁 Tab0 的左樹選到某個 AO 後，右面板下方列出該 AO 的任務卡；每張卡片直接 inline 編輯（非獨立 Dialog）：任務名稱 / 描述 / 指南、任務類型（一般 general / 問卷 survey）、指派人員（可標審核人）、部門、設備、問卷（可標審批要求）。儲存以 PUT job 一次寫回，關聯欄位採 full-replace 語意（送 [] 清空、省略 = 不動）。快速配置與開始執行是 Header 的批次動作：前者 FE 端逐一 PUT 合併、後者呼叫專屬 start-task-execution endpoint。

任務真相來自範本 BPMN 的 userTask（見規劃頁背景）；儲存時 BE 會在同一 transaction 同步回寫 BPMN userTask，讓 BPMN 編輯器與規劃頁兩端一致。與 SSP 編輯不同，任務指派不受 SSP 凍結影響，只要輪次在 planning 階段、使用者對該節點有三層遞進的 manager 權即可編。

主要使用者：對該控制節點有 manager 權者（專案 / 群組 / 控制項任一層 manager）。

角色速覽（完整定義見 _overview §3）：

1.1 功能總覽（本頁全部功能）

UC（§2）展開兩條核心路徑：UC-TE-01（單一任務逐欄 inline 編輯，含 M2M / 審核人坑）與 UC-PP-02（快速配置 → 開始執行的批次流）。快速配置 ⚠️ 有清空關聯的坑（見 §12）。

2. Use Case

角色速覽（同 §1）。流程圖視覺慣例：菱形 = 判斷、橘底 = 例外/擋下、紅框 = 錯誤（標 error code）、綠框 = 成功終點、虛線 = 可選路徑。

UC-TE-01 編輯 AO 任務

UC-PP-02 快速配置與開始執行

3. 權限矩陣

⚠️ FE / BE 權限不對齊：FE 用三層遞進的 canEdit 擋按鈕，但 PUT job route 層只有 JWT 登入、無任何角色檢查——任一登入者繞過 FE 直接打 API 都能改任務指派。與規劃頁 §3 / §12 記載的同一 finding。唯有「開始執行」有 BE manager 守門（GRC_403002）。

4. 狀態機與前置條件

承接輪次階段 gate（見 規劃頁 §4）：

5. UI 設計

版面骨架（Header 批次動作 + AO 任務卡 inline 編輯，含 survey 型條件層 + 代表性 API）：

📸 截圖待補（亮色模式）：AO 面板 + 任務卡展開（general 型）taskedit-general.png、survey 型（含問卷 + 審批 + 審核人 switch）taskedit-survey.png。（規劃頁 §5 已有 planning-ao-tasks.png 概覽可參考）

任務卡 inline 表單（ProjectPlanningView.vue Panel 卡片，無獨立 Dialog）。欄位：

select_or_text 型態（FR-057 新增）：PrimeVue editable Dropdown——下拉列常用選項，也可直接輸入清單外的自由字串。用於各工具的 profile 欄位（OpenSCAP 的 xccdf profile id 會因目標主機自帶的 SSG 版本不同而有自訂值；CINC Auditor / GCB 的 profile 可以是 Git 網址、Agent 主機上的本機路徑或 Supermarket 名稱）。FR-058 把 CINC Auditor 的 profile 由 text 改為 select_or_text（FE 元件早已支援，FE 與 agent 零改動）。渲染元件與檢測工具管理 §5 設定表單共用同一 DetectionConfigField.vue。

profile 下拉動態化（FR-059）：欄位定義帶 "options_source": "profile_library" 宣告時（CINC Auditor / GCB 的 profile 欄位，param_schema v2 起），DetectionConfigField 不再讀欄位內的靜態 options 陣列，改呼 GET /detection-tool-profiles/menu?detection_tool_uid=（帶當前工具 uid——GCB 抽屜只見 gcb 池、CINC 只見 inspec 池）動態組選項；選項的 value 是 BE 組好的 profile:<uid> 庫內參照，派工時展開。選項載入走 src/composables/useDetectionProfileOptions.js 的模組層級快取（規劃頁 N 個任務列共用、同工具只打一次 API）；menu 拉不到時顯示警示但欄位照常可手填（不擋畫面）。取值來源三層並存：庫內檔案型 / 庫內連結型 / 現場手填（URL、Agent 本機路徑、Supermarket 名稱——不進庫、單次執行用；既有任務存的舊靜態選項值屬手填路徑，升級後照常可用）。回顯相容：值不在選項內時 editable Dropdown 原樣顯示該字串；已停用的 profile:<uid> 參照補一個唯讀 fallback 選項標示「庫裡已沒有的項目」，不露裸 UUID（DetectionConfigField.vue::profileOptions:82-92）。沒有宣告的欄位維持靜態 options 行為零影響；機制 tool-agnostic，新工具 seed 宣告即接庫、FE 零改。設定檔的維護見 掃描設定檔管理。

四款新工具的掃描參數（FR-058，DEV 實查 config.detection_tool_param_schemas 當前生效版）

Nmap 的 hosts ≠ targets：其餘工具「登進去掃自己」，hosts 同時是登入對象與掃描對象；Nmap 是 Agent 以 SSH 登入 hosts 這台執行主機，再由該主機對 targets（可能是整個網段）送出探測封包。兩個欄位語意不同，任務執行抽屜 的摘要卡與執行詳情視窗因此分開顯示兩者。

ZAP scan_mode='authenticated' 對單頁式應用（SPA）不可使用：不只是掃不到——會引發登入無限重試，累積到 ZAP 保護門檻後 daemon 主動停止，連帶中斷其他租戶正在執行的掃描。詳見 檢測工具管理 §12 坑 14；ZAP 卡片的部署前提說明已明白標示。

profile 下拉一律用 tarball 形式（.../archive/refs/heads/master.tar.gz）而非裸 GitHub 網址：裸網址走 CINC 的 git fetcher，需 shell out 呼叫 git 查 default branch；實測把 agent 容器內的 git 移走後裸網址直接失敗、tarball 照常可用。下拉是平台預置的建議值，選少一個故障點的形式。

GCB 的 profile 選項演進：fr058-13 上架時僅 1 筆 Windows 最小示範（2 項）；fr058-14 加入 TWGCB-01-011 Server 2022 完整基準後，fr058-16 把示範筆移出下拉（select_or_text 手填仍可用）；fr058-18 擴為 8 支 TWGCB 作業系統類基準——Windows 組 4 支（007 Server 2016／009 Server 2019／010 Windows 11／011 Server 2022，各 540／539／108／558 項自動檢查）＋ Linux 組 4 支（008 RHEL 8／012 RHEL 9／013 RHEL 9／014 Ubuntu 22.04 LTS，各 53／74／60／35 項）。排序先 Windows 後 Linux、組內照編號；012 與 013 是 NICS 官方兩份不同的 RHEL 9 基準（非重複），label 一律帶 TWGCB 編號區分。來源集合共 23 支，其餘 14 支（macOS 15、browser／application／network／cloud 類）可自動檢查項數皆 0 或標的形態接不上 SSH/WinRM transport，不上架。2026-08-01 起選項來源再改為掃描設定檔庫動態餵（FR-059 options_source，見變更紀錄），上述 8 支已搬遷為庫內 SYSTEM 公版。

SonarQube 的掃描參數與三種執行模式（FR-058.5/.6/.7，DEV 實查 param_schema v4 當前生效版）

SonarQube 是平台第一個拉取快照（pull-snapshot）與平台發動掃描並存的工具，以 scan_mode 參數在同一張工具卡內分流三種取源模式（D17 ZAP 式單卡多模式；憑證兩模式共用同一組 base_url＋User Token）：

各模式的參數欄位（condition 綁 scan_mode，不可見欄位不必填也不送出）：

三個必知限制與配套：

• scan／upload 是寫入行為且沒有 dry-run——每次掃描都把結果推上客戶 SonarQube，專案不存在會自動建立。FE 於 scan_mode 為寫入模式時（含舊 v1 任務 scan_mode 未存值、實際生效預設 scan 的情況）在參數區塊顯示橘色警語（D24 配套①，ProjectPlanningView.vue::isWritingScanMode）；setup_guide 另載收緊做法（預先建好專案＋移除 token 帳號的 Create Projects 全域權限）。
• 支援語言僅七種 A 類純源碼語言（Python／JS／TS／Go／PHP／Ruby／Kotlin，D18）——不需編譯即可分析。C#／VB.NET 永遠只能走 pull：這不是取捨而是架構限制——.NET 的分析發生在編譯器內部（Roslyn analyzer 隨 MSBuild 編譯執行），SonarScanner CLI 明文不支援，且送進去不會報錯、只會靜默淺掃（產出一份看似正常實際幾乎沒分析到的報告），故 setup_guide 以醒目警語要求改用 pull。Java／C／C++ 目前亦不支援。
• upload 的壓縮包不在本頁提供（D26）——任務設定只選模式；檔案於任務抽屜發起執行時上傳（壓縮包是「這一次要掃的源碼快照」，不是「任務怎麼掃」的設定），已上傳的檔案 sticky 保留供重掃沿用（D29）。格式與限額見任務抽屜頁 §11.1。

出處：param_schema v4 seed scripts/sql/2026-08-01-fr058-21-sonarqube-upload-scan-mode.sql（v1→v4 演進：2026-07-31-fr058-17（pull 兩欄）→ fr058-19（scan 模式＋setup_guide 改寫）→ 2026-08-01-fr058-20（標籤精簡）→ fr058-21（upload 選項））；FE 警語 ProjectPlanningView.vue:1008-1023；condition.value 陣列支援 src/utils/detectionFieldValidation.js＋DetectionConfigField.vue（純擴充，字串形式行為不變）。

任務層敏感參數加密（FR-058.0）

param_schema 的 secret: true 欄位（現況只有 ZAP 的 login_password）屬某一次掃描任務的機密，不是工具連線設定，只能落在 config.job_execution_detection_tools.tool_params（JSONB，與非機敏欄位混雜）。租戶層那套「整欄加密」無法直接套用，故另做「同一個 JSONB 內挑欄位加密」的機制（common/util/detection_secret_params.py）：

為何用 envelope 而非裸密文：密文存進 JSONB 後與明文同為 string，無法從值本身判斷是否已加密。若靠「查 schema 哪些 key 是 secret」決定要不要解密，正確性就綁在 schema 上——而 param_schema 是版本化的（is_current 切換），改版後舊任務會解錯。改存 envelope 後值本身就說明自己加密與否，schema 只用來決定「新寫入的值要不要加密」，不參與解密判定。換工具時 FE 會一併清空 toolSecretKeysSet（否則新工具的同名 secret 欄位會誤顯示「已設定」，使用者不填就存 → 存進空密碼）。

掃描參數必填驗證（FR-058.2）

原本 FE 對掃描參數完全不驗，缺參數的任務照樣存檔 → 派工 → 到 agent 執行期才失敗（ZAP 缺 logged_in_indicator 實測踩過兩次）。改為 saveTask 前檢查，缺漏時 toast 列出欄位名稱並不送出。判斷是 condition-aware 的：因 condition 不成立而隱藏的欄位不算必填（被動掃描時 ZAP 的登入四欄不該被誤擋）；secret 欄位已設定過（在 toolSecretKeysSet 內）留空＝沿用原值、不算缺。與 DetectionConfigField 的 visible / showError 同源——三處都呼叫 src/utils/detectionFieldValidation.js 的 isDetectionFieldVisible() / findMissingRequiredDetectionFields()，不各判一套。出處：ProjectPlanningView.vue::saveTask:1037-1057。

FE 別名坑：指派人員的審核旗標，FE 早期送 is_admin，serializer AssigneeInputSchema 以 @post_load coalesce 進 is_approver（api/grc/serializers/job.py:105-114）。新資料一律 is_approver。

狀態呈現：無 socket；儲存中 per-任務 spinner（taskSavingSet Set）；儲存後前端 state 更新（不整頁重載）。

6. API 規格

Envelope：成功 {"status": true, "data": …}、失敗 {"error_code": "…", "msg": "…"}。

6.1 總清單

批次啟動 POST /grc/project/{uid}/start-task-execution 屬規劃頁功能 6，見 規劃頁 §6.4。

6.2 核心 endpoint

[PUT] /grc/project/{project_uid}/job/{job_uid}

任務更新。全部欄位選填（load_default=None）；關聯陣列 full-replace（送 [] 清空、null/省略 = 不動）。Request（JobUpdateRequestSchema，Meta.unknown=EXCLUDE）：

{
  "name": "訪談紀錄蒐集",
  "description": "…",
  "guide": "…",
  "job_type": "survey",
  "control_uid": null,
  "assignees": [{ "uid": "<user uid>", "is_approver": true }],
  "department_uids": ["<org_unit uid>"],
  "device_uids": ["<device uid>"],
  "surveys": [{ "uid": "<survey uid>", "approval_required": true }],
  "tool": { "uid": "<detection_tool uid>", "params": {"hosts": "<target host>"}, "completion_mode": "manual" }
}

出處：request api/grc/serializers/job.py:128-153（含 DetectionToolBindingSchema:138-153）、route api/grc/routes/job_route.py:100-136、service app/grc/service/job_service.py（update_job + _reconcile_task_surveys:228 + _replace_detection_tool_binding）

Response data（JobResponseSchema，形狀同 control-tree 的 Job 節點）：

出處：api/grc/serializers/job.py:71-98（JobToolResponseSchema，含 secret_keys_set）／:86-（JobResponseSchema）；加解密與剝除 util common/util/detection_secret_params.py；寫入端 app/grc/service/job_service.py::_encrypt_tool_secret_params:338-370

6.3 批次動作

快速配置（無專屬 endpoint，FE 逐一 PUT）

FE-only 編排：多選人員（來源 = 專案參與人員）→ 迴圈所有可編輯（canEditCtrl）控制項底下的任務 → 每個 job 把選取人員 additive 併入既有指派（已存在者跳過）→ 逐一 PUT job。⚠️ 每筆 PUT 送 department_uids: [] / device_uids: [] / surveys: []——因 full-replace 語意，會清空該任務既有的部門 / 設備 / 問卷關聯（見 §12 坑）。出處：ProjectPlanningView.vue:executeQuickConfig:1192-1230。

[POST] /grc/project/{project_uid}/start-task-execution

無 body。把該專案「已指派且 TODO」的 prep-job 批次轉 PROCESSING 並發站內通知。限專案 manager（_check_manager，否則 GRC_403002）；idempotent 可重按。Response data：{"activated_count": int, "detection_dispatched_count": int}（分別為實際轉 PROCESSING 的任務數、自動派出首次掃描的 detection_tool 任務數）。

FR-056：自動派 detection_tool 首次掃描——批次轉 PROCESSING 的同時，對其中 job_type='detection_tool' 且查無任何 detection_executions 紀錄（NOT EXISTS，冪等防重）的任務逐筆呼叫 DetectionOrchestrationService.start_execution() 派出第一次掃描；單筆派工失敗（如未設定憑證）用 SAVEPOINT 隔離、不擋整批發佈與其餘任務，失敗的任務留給執行者從 任務執行抽屜 手動補派。出處：service app/grc/service/task_execution_service.py（_check_manager:49-56、start_task_execution:58-96、_auto_dispatch_detection_scans:98-134）、query infra/grc/repository/task_execution_query.py::get_detection_jobs_without_execution:134-、serializer api/grc/serializers/task_execution.py。

scan_mode=upload 的任務不進自動派發（FR-058.7，D33）：自動路徑不帶檔案，upload 任務必然打中「首次無檔」400（DETECTION_TOOLS_400005），且該錯誤被批次派發的 try/except 吞掉只留 warning log——PM 看到成功 toast、執行者無感，又因失敗不產生執行紀錄、冪等條件永遠成立，每按一次「開始執行任務」就再失敗一次。故在挑選階段排除：get_detection_jobs_without_execution 的查詢排除 tool_params->>'scan_mode'='upload' 的綁定（task_execution_query.py:142/:169），upload 任務一律由執行者在任務抽屜上傳檔案後手動執行（抽屜有無檔不給按執行的前置擋門）；pull／scan 自動派發行為不變。FE 配套：批次發佈 confirm 文案加註「上傳型掃描任務需由執行者上傳檔案後手動執行」（i18n start_task_execution_confirm_message）。已執行過的 upload 任務本來就不在冪等清單內，不受影響。

7. 前端檔案地圖（compliance-manager-fe/）

8. 後端檔案地圖（本頁核心鏈路）

⚠️ DDD 提醒：PUT job route 層無角色守門（別比照為權限典範）；問卷關聯跨到 survey schema 的 task_surveys（非 compliance.job_execution_surveys），維護留意 schema 邊界；detection_tool 綁定表 config.job_execution_detection_tools 屬 config schema（非 compliance），跨 schema 命名慣例注意。

9. DB

9.1 資料表總清單（本頁讀寫的全部表）

9.2 ER 圖

9.3 核心表欄位（取自 DEV DB dump，含 DB comment）

compliance.job_executions — 任務本體

compliance.task_assignees — 指派人員

compliance.job_execution_org_units / job_execution_devices — 部門 / 設備關聯

survey.task_surveys — 問卷關聯（跨 schema）

⚠️ schema 註：問卷關聯在 survey schema 的 task_surveys（job_service._reconcile_task_surveys 管理），不是 compliance.job_execution_surveys（那是另一張簡單映射表，本更新路徑不寫）。欄位一律取自 db_schema.json。

config.job_execution_detection_tools — 任務↔︎檢測工具綁定（FR-056）

10. 頁面邏輯與資料對應

任務隨 control-tree 一次載入（內嵌於 AO 節點）。欄位對應：

選定檢測工具的預設值帶入（FR-057，FR-058 補清 secret 狀態）：切換 task.toolUid 時先把 toolParams 清成 {}、toolSecretKeysSet 清空（換工具＝換一套 schema，舊工具的 secret 已設定狀態不再適用），取回該工具的 param_schema 後，遍歷欄位定義找出有 default 值（非 undefined/null）的欄位組成預設物件，一次性寫回 toolParams——避免使用者看到全空表單以為沒有預設值可用（如 timeout_sec 預設 3600、Nmap port_range 預設 1-1024、CINC Auditor transport 預設 ssh）。出處：ProjectPlanningView.vue::onSelectDetectionTool:1011-1023。

儲存流程：saveTask 依序做 client 檢查——① detection_tool 型必須選定工具（warn_tool_required）→ ② 掃描參數必填檢查（FR-058，condition-aware，缺漏列出欄位名，見 §5）→ ③「survey 有審批要求但無審核人」→ 任一不過皆 toast warn 不送 → PUT → 前端 state 更新。錯誤對應：GRC_404005（任務不存在）/ GRC_409033（問卷已有填答無法移除）→ toast。

11. 背景行為與外部依賴

12. 邊界情況與已知坑

1. PUT job 無 BE 角色守門：route 僅 @jwt_required()，FE 靠三層 canEdit 擋；繞過 FE 直打 API 任一登入者都能改任務指派（與規劃頁 §12 同一 finding）。
2. 審核人檢查只在 FE：「survey 有審批要求則至少一審核人」只在 saveTask 前 client 檢查（toast 不送），BE 無此驗證——直打 API 可存出「有審批要求卻無審核人」的任務。
3. 問卷關聯跨 schema、非直覺：任務問卷走 survey.task_surveys（_reconcile_task_surveys），不是 compliance.job_execution_surveys；後者是另一映射表，本路徑不動。
4. surveys[].approval_required 送 null 保留既有值：SurveyInputSchema 的 approval_required load_default=None——BPMN 編輯器同步問卷時不帶此欄（無此 UI），送 null → _reconcile_task_surveys 保留既有審批旗標，不誤蓋規劃頁設定；規劃頁顯式送 True/False 行為不變。
5. is_admin → is_approver 別名：FE 早期送 is_admin，serializer @post_load coalesce 進 is_approver；下游只讀 is_approver。
6. 關聯 full-replace 語意：assignees/department_uids/device_uids/surveys 送 [] 清空、null/省略不動；部門 / 設備關聯是全刪重建（reconcile）。
7. 問卷已有填答不可移除：移除已有答案的問卷 evidence → GRC_409033（GRC_SURVEY_HAS_ANSWERS）。
8. ⚠️ 快速配置會清空部門 / 設備 / 問卷關聯：executeQuickConfig 對每個 job 只 additive 合併指派人員，但送 department_uids: [] / device_uids: [] / surveys: []——因 full-replace 語意（[]＝清空），會把該任務既有的部門 / 設備 / 問卷關聯一併清掉。若已配置這些關聯，用快速配置補人員前要留意會被清空（ProjectPlanningView.vue:1218）。
9. survey × device 笛卡爾積：任務掛多問卷多設備時 survey.task_surveys 列數會乘開（每問卷 × 每設備一列），指派前想清楚資料量。
10. date-only 顯示 08:00 陷阱：任務時間相關欄位 BE 慣例吐 YYYY-MM-DDTHH:MM:00 無 tz，前端 date-only 顯示要留意時區偏移（見 _overview 時區慣例）。
11. job_execution_detection_tools.tenant_config_id 恆為 NULL（FR-056 已知坑）：欄位建表時預留、讀取端（start_execution）會讀，但寫入端 _replace_detection_tool_binding 從未寫過此值——實務上憑證解析一律 fallback 走 (tenant_id, detection_tool_id) 反查（該組合有 UNIQUE 約束可唯一定位）。若使用者「先建任務、後設工具憑證」，查詢時解析比綁定時寫死更穩，故此設計非遺漏；該欄位是否退役留待未來討論。
12. secret 掃描參數留空＝沿用、不是清空（FR-058.0）：encrypt_secret_params() 對空值會從既有綁定沿用舊密文——因為 FE 對已設定的 secret 欄位承諾「留空＝沿用原值」，不沿用則使用者每次改別的參數（如 timeout_sec）都會把密碼清空，且症狀要到掃描時才浮現。代價是「清空單一 secret 參數」沒有 UI 入口；真要清空得換工具（onSelectDetectionTool 會清 toolParams 與 toolSecretKeysSet）或直接改 DB。
13. 換檢測工具會清空全部掃描參數：onSelectDetectionTool 切換 toolUid 時先把 toolParams 清成 {}、toolSecretKeysSet 清空，再依新工具 param_schema 帶入 default。這是刻意的——不清會讓新工具的同名 secret 欄位誤顯示「已設定」，使用者不填就存 → 存進空密碼。誤按下拉再切回原工具，參數要重填。
14. tool_params 的加密判定看值不看 schema：is_encrypted() 只認 envelope 的 __enc__ 標記，不查 param_schema 哪些 key 是 secret——因為 param_schema 版本化（is_current 可切換），若靠 schema 判定，改版後舊任務會把明文當密文解（拋例外）或把密文當明文送給 agent（帳密以密文形式送出，掃描失敗且難查）。改動加解密路徑時勿引入 schema 依賴。
15. 檢測工具任務不走 flow-engine complete 觸發掃描：detection_tool 型任務的「開始執行」走獨立的 DetectionOrchestrationService（見 任務執行抽屜 §11.1），與本頁「儲存任務」/「開始執行任務」的批次轉 PROCESSING 是兩件事——後者只是把任務從 TODO 轉 PROCESSING 讓任務「可以」被執行，掃描本身另外觸發（規劃頁批次轉 PROCESSING 時會自動觸發首次掃描，見 §6.3）。

13. 開發與驗證

• 跑起來：起 BE + FE；登入見 .env / 部署文件測試帳號（需該節點 manager；開始執行需專案 manager）
• 導航：規劃頁 Tab0 → 左樹選 AO → 右面板任務卡展開編輯；快速配置 / 開始執行在 Header
• 前置資料：需 AP=planning 的專案 + 至少一個控制項有 AO 任務；備 user / org_unit / device / survey master 測四關聯；切 survey 型測問卷 + 審批 + 審核人 switch 連動；測快速配置後檢查部門/設備是否被清空（坑 8）
• 相關：現況編輯 / 程序書見 現況編輯；批次匯入見 批次維護；任務真相＝範本 BPMN userTask；問卷設計見 survey 功能群