FR-057 派工監督棒 — 中繼交接(2026-07-28)

項目 內容
緣由 FR-057 設計/開卡/派工 prompt 全部完成,三條實作線已交外部 session 執行;本棒剩「監督進度 + 驗收」。原 session context 已長,寫此 handoff 當保險——2026-07-29 06:00 排程檢查若發現原 session 變笨或已關,下一棒照本文冷接
Branch BE feature/instance-agent(FR-057 文件 commits 未 push);agent/FE repo 由實作 session 各自處理
本棒角色 首腦/監督,不親自實作——實作在另外三個 session(見 §2)
接手前必讀 本文 §0 讀序
預估時間 檢查一輪約 10 分鐘;驗收視完成量

🧭 原始需求 / WHY

FR-057 = 在 FR-056 檢測工具整合平台上接入第二個掃描工具 OpenSCAP(CIS/STIG 組態合規稽核),並開出 connector 第三種連線型態 SSH。

大圖:FR-056(已隨 v1.11.0 上線)讓租戶設定檢測工具 → 任務按開始 → 客戶端 Agent(evidence-agent,Docker)心跳領派工 → 掃描 → 報告自動回收成任務證據。第一版只有 OpenVAS(API 型)。本案價值:①客戶多了組態合規稽核能力(不只弱掃)②connector 架構證明可擴(SSH 型開出後,未來 Lynis 等 CLI/SSH 工具同軌)。

關鍵設計事實(討論中 user 反覆確認過的):

  • OpenSCAP 是純 CLI 無 API,遠端掃描=官方 oscap-ssh 模式:Agent(Docker,不變)SSH 登入目標主機、在目標上執行目標自己的 oscap、報告拉回。目標主機需一次性裝 openscap-scanner+scap-security-guide——這是官方正規用法(Red Hat Satellite 同模式),不是我們的妥協
  • 憑證=租戶層一組共用稽核帳號(Tenable 同款業界標準),金鑰/密碼二擇一推薦金鑰+sudo,沿用既有加密鏈
  • 證據=每台一份 HTML 原樣上傳 → 牽動 result 回收鏈單檔→多檔(FR-057.3 的由來)
  • 設計全文:docs/features/FR-057-2607-openscap-ssh-connector/design.md(D1–D7);討論稿 Artifact https://claude.ai/code/artifact/e3f6864b-501e-474f-b6c3-cdc97dd59879

§0 接手讀序

  1. 🔒 先懂需求 gate:本文「🧭 原始需求」全讀 + design.md §1–§2(背景與 D1–D7)全讀
  2. 本文 §2(三條實作線狀態模型)+ §3(檢查 SOP)
  3. Notion 母案(全案索引):https://app.notion.com/p/3ab346da4cd081af9cfac78397f7acfb
  4. 需要細節時才開:design.md §4(詳細設計)/ §5(拆分表)

冷接自檢:①FR-057 解決什麼問題?②為什麼目標主機要裝 scanner 而 Agent 不用改實體安裝?③三條實作線各自範圍與依賴?④本棒的角色是什麼(監督驗收,不是實作)?——答不出回去讀。

§1 現況:已完成 vs 進行中

已完成(本棒/前棒做完):

  • design.md + discussion.html(mermaid 已修三輪,init 內嵌圖首)+ README FR 登記——commits 3e39607e/81301ee1/8c17aefa
  • Notion 12 張卡:CM-938 母案 / CM-939~941 三子需求 / CM-942~949 八子任務,全 Not started 起始,母子 mention 已回填
  • .claude/skills/big-feature-workflow/ skill(commit 92b28070)
  • 三份派工 prompt 已交 user,由 user 發給外部 session

進行中(外部 session,狀態以 Notion 為準):見 §2

§2 三條實作線狀態模型

依賴 執行方式
FR-057.1 CM-942(T-1.1 BE migration)→ CM-943/944(FE 欄位型態) 無,先行 user 已拿 prompt 發外部 session
FR-057.2 CM-945→946→947(agent connector) 只等 CM-942 變「修正待驗證」(該 session 每小時輪詢) 同上
FR-057.3 CM-948(agent task_executor 多檔)→ CM-949(BE handler 多檔) 無,立即開工 同上

跨線契約(驗收時要盯):connector run()list[ScanResult];.2 不動 core/task_executor.py,.3 不動 core/task_executor_connectors/*;result_ref 多檔=upload_uids 陣列且向下相容單數 upload_uid;OpenVAS 迴歸不可壞。

§3 排程檢查 SOP(2026-07-29 06:00 觸發時做)

  1. Notion 查 CM-942~949 八張卡「狀態」property(搜尋或逐卡 fetch properties,不用讀全文)
  2. 彙報格式:三條線各自進度(幾張修正待驗證/幾張 Not started)、卡住的線與原因
  3. 有卡變「修正待驗證」→ 提醒 user 可驗收,但不自動驗收不自動改卡狀態(驗收是 user 的事;user 下令後才做獨立抽查:實查 commit diff + 跑測試,不信卡上自報)
  4. 全部 Not started 且超過半天 → 提醒 user 外部 session 可能沒起跑
  5. 檢查後回報即停,不往收尾跑

§8 行為規範提醒

  • 不切 branch / 不 push(等 user 明示)/ 顯式 git add
  • 文件產出派 subagent(1M model);監督/抽查/派工 prompt 主 session 做
  • 驗收=獨立實查,不信 runner 自報(cf. memory feedback_brain_worker_orchestration_pattern)
  • 收尾(spec/SUMMARY/Notion Done 標記)一律等 user 下令

§10 不在本棒 scope

  • 不親自實作任何一張卡(外部 session 的事)
  • 不做 FR-057 收尾文件(全案完成後 user 下令才走 closing-and-handoff)
  • install.sh 安裝精靈(user 明示最後再做)、Nessus/SonarQube connector、ARF findings 解析——都不碰

§11 本棒 commits(BE repo,未 push)

92b28070 feat(skills): big-feature-workflow skill
8c17aefa fix(fr057): mermaid init 內嵌圖首(Artifact 雲端渲染)
81301ee1 fix(fr057): mermaid 深色模式配色(頁尾 script,後證僅本機有效)
3e39607e docs(fr057): 設計定案 design.md + discussion.html + FR 登記

§12 給 fresh session 的超短 prompt

請讀 ~/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-057-2607-openscap-ssh-connector/handoff/2026-07-28-fr057-dispatch-watch-handoff.md,
先過「🧭 原始需求」與冷接自檢,然後照 §3 SOP 檢查 FR-057 三條實作線的 Notion 卡狀態並彙報。
你是監督棒:只檢查、彙報、等 user 指令,不實作不收尾。