母案：FR-058 檢測工具擴充（四工具接入）— FR-058 檢測工具擴充（四工具接入）（母案）
依賴：FR-058.2 InSpec / CINC Auditor — FR-058.2 InSpec / CINC Auditor（Windows + Linux 組態檢測）｜無法立刻開工 ⛔（GCB 不另立引擎，跑的就是
.2的 connector）｜Repo：BE + evidence-agent
<aside> 🎯
這是 D7 明確定案，實作與驗收都要守這條。
本子需求不是 content 工程——只要證明端到端鏈路（WinRM 連線 → 認證 → profile 執行 → 結果解析 → 證據上傳）可運作，一條規則也能證明鏈路通。
不追求規則覆蓋量。 不要把驗收拉成「涵蓋了幾條 TWGCB-ID」。
</aside>
被排除出本案的（D7）：
TWGCB-01-015）——基準 2026/6 才發布、版本尚新，且現有 connector 未曾處理 macOS<aside> 🔌
content 不可硬編進 connector 或 agent image，必須設計成可從外部載入。這是本案必須做到的，不是後續事項。
理由：content 本質上是會持續變動的資料，不該綁在程式版本裡。日後要接後台更新機制時，若當初把 profile 打包進 agent，等於每次更新 content 都要重新發版並更新所有客戶站點的 agent。
這個接口現在留成本極低，事後補要改動 connector 結構。
</aside>
| 面向 | Linux GCB | Windows GCB |
|---|---|---|
| 引擎 | 統一走 FR-058.2 的 CINC Auditor（SSH transport） | 同左（WinRM transport） |
| 引擎層工作量 | 已由 .2 承擔，GCB 不需新 connector | 同左 |
| 本案 content | 不做 | 一份最小 Demo profile，僅用於驗證鏈路 |
| content 載入方式 | 一律從外部載入 | 同左 |
| content 格式（D8） | InSpec profile（Ruby DSL） | 同左——Windows GCB 只有這條路走得通 |
引擎統一的真正目的是 content 格式統一（D8）。若 Linux 走 OpenSCAP、Windows 走 InSpec，同一份 TWGCB 基準要用兩種語法各寫一次，TWGCB 改版時要改兩份。
| 平台 | 可用來源 | 自動化程度 |
|---|---|---|
| Windows（Win11 / Server 2016、2019、2022 + Chrome / Edge） | GPO backup ZIP（含 registry.pol • GptTmpl.inf） |
約七成 |
| Linux（RHEL 8 / RHEL 9 / Ubuntu 22.04） | 只有 DOCX / PDF | 幾乎零 |
| macOS 15 | 只有 DOCX / PDF | 幾乎零（已由 D7 排除） |
官方說明文件頁有完整的 RHEL 8 / RHEL 9 / Ubuntu 22.04 / macOS 15 基準，但沒有任何對應的機器可讀部署檔——連 shell script 都沒有。Windows 有 GPO 檔這個結構化來源可直接參考，寫一個最小 Demo profile 的成本最低。
這是選 Demo 平台的理由，不是要在本案做 Windows content 工程。
.2 沒有，.3 沒東西可跑。T-3.1 依 T-2.1，T-3.2 依 T-2.3。