本卡屬 FR-166（母卡 CM-3109），批 6。repo：BE（主 repo，Repo 欄空著）。只改 BE。由首腦在驗收 P2-2（CM-3127）時發現的缺口開出。

這張卡做什麼（白話）

Agent 主控台的掃描工具分頁要照主系統下發的定義畫參數表單，但主系統現在只下發帳密欄位（config_field_schema），沒下發掃描參數欄位（param_schema），P2-3 畫不出表單。本卡讓 GET /agents/tool-schemas 每支工具多帶 param_schema。

在哪裡

repo：~/Projects/Billows/Audit-Manager/compliance-manager-be
改：core/plugins/_agent_tool_schemas.py
參考：jedi-detection 的 detection_tool_param_schema_domain_service（現役 param_schema 的唯一來源）

怎麼做

• _agent_tool_schemas.py 的每筆工具加 param_schema：取該工具「現行」那份 param_schema（用 jedi-detection 既有的 param_schema domain service，不自己查表）。版本號 _version() 要把 param_schema 納入，內容變了 Agent 才會重抓。
• 🔴 不可塞租戶設定值或密文（檔頭已寫明這份會明文落在 Agent）；param_schema 只有欄位定義，符合。
• 形狀與主站 DetectionConfigField 吃的 param_schema 相同（P2-3 會直接用那個元件），不要轉換格式。

驗收（可親手做、可親眼看）

• GET /agents/tool-schemas 回應每支工具有 param_schema（陣列），openvas／nmap／zap 至少有內容。
• param_schema 改了之後 version 會變。
• 既有的 tool-schemas 測試綠；新增一條斷言 param_schema 存在。

紀律

• 先 git status；顯式 git add 檔名，禁 -am；不切 branch；push 等令；不自派 subagent；只動 DEV。
• 先 git merge ws-CM-3109 把前面批次的成果併進來再動手（前幾批同批卡多次撞檔）。
• 不重複造輪子：先 grep 既有的再寫；extend 既有那支，不另開 V2。檔案註解只寫為什麼與陷阱。
• 資安規範讀 BE .claude/rules/security/ 八支；動到認證／授權／密碼學要寫測試且含突變。
• 做完 commit＋卡上回寫（commit hash、改了哪些檔、reuse／extend／new、資安對照、手測清單），狀態改「修正待驗證」。

建議模型與思考強度（首腦判斷）