讓使用者看得見「這份基準到底要驗什麼」

D1 · 主從欄位歸屬

哪些欄位屬「基準本身」（主檔）、哪些屬「某一版」（從檔）？這決定了改名、分類、版更各自會動到什麼。

我的建議：
主檔——name / description / 分類三軸（標的類型 / 標的產品 / 基準體系）/ scope / tenant_id / org_unit_id / detection_tool_id / is_active / current_version_id
從檔——source_type / file_id / url / sha256 / version / is_current / supports / extraction_status / 控制項統計索引（總數 / 待判數）

判準一句話：「換一版會不會變」——會變的進從檔，不會變的進主檔。supports（執行平台）放從檔是因為它是從該版的 inspec.yml 抽出來的，不同版可能不同。

被排除：分類放從檔——那等於每次上傳新版都要重填一次分類，且同一支基準的不同版可能分到不同類，篩選結果會前後矛盾。

D2 · 當前版指標：is_current 布林 vs current_version_id 外鍵

兩種寫法都能表達「哪一版是現行版」，但保證強度差很多。

我的建議：保留 FR-059 現行的 is_current 布林 ＋ partial unique index（UNIQUE (profile_id) WHERE is_current）。資料庫直接擋住兩筆 current，demote_current 先降後插的順序是被索引強制的，不是靠開發者記得。

被排除：current_version_id 外鍵——這正是 oscal.frameworks 走過的路，而且官方已認錯並事實廢棄（2026-06-16 改用純字串欄，外鍵降級為冗餘、列入待 DROP）。三個具體傷害：① 循環外鍵逼得 DDL 拆兩段、Python model 退化成 plain int；② 刪除流程被綁死，不能先刪版本只能靠 cascade；③ 資料庫保證不了唯一性，而應用層從頭到尾沒實作過切換。

折衷可行：current_version_id 仍可以存在當作查詢便利欄（避免每次列表都要 join 從檔篩 is_current），但唯一性的保證來源是 partial unique index，不是這個外鍵。兩者不衝突。

D3 · 從檔 RLS 寫法：冗餘欄位 vs EXISTS 子查詢繼承

從檔一定要自己掛 RLS（PostgreSQL 不沿外鍵繼承，理由見 §2C）。問題是租戶判定的欄位從哪來。

我的建議：從檔冗餘存 tenant_id / scope / org_unit_id，policy 與主檔逐字對稱。

理由三條：① 本專案零 EXISTS 繼承前例——detection_executions、job_execution_detection_tools 等子表全部是冗餘欄位形狀，跟進既有形狀降低理解成本；② 效能——EXISTS 每一列都要跑一次子查詢；③ 子查詢本身還會再套一次主檔的 policy，形成 policy 套 policy，除錯時極難推理。

冗餘的代價：改主檔的 scope / tenant 時要同步更新從檔。但實務上 scope 與 tenant_id 建立後幾乎不變（fork 是建新列而非改欄位），代價很低。建議在 app service 層集中處理，不要散在各處。

⚠️ 提醒：本專案目前沒有任何「主從兩表都帶 RLS」的前例，FR-060 是首例，設計時請額外附上跨租戶讀取的驗證查詢。

D4 · uid 歸屬

拆表後主檔與從檔都需要 uid。舊表那 13 個 uid 該給誰？

我的建議：從檔逐列沿用舊 uid，主檔另生新 uid。

理由：舊 uid 是凍結契約——job_execution_detection_tools.tool_params 的 4 筆 profile:<uid>、agent_tasks.params 的 6 筆 _profile 都指著它。從檔沿用等於這 10 筆既有引用零轉換、零風險；而且語意也對——派工綁的本來就是「某一版」不是「某支基準」。

被排除：主檔沿用舊 uid——那 10 筆引用全部要改寫（改 JSONB 內容），而且語意變成「派工綁基準」，與已拍板的「鎖版」相牴觸。

D5 · 分類三軸的定義與 enum 來源

決策者指出兩個現象：CINC 的 profile 不只作業系統，連瀏覽器都有；profile 一多下拉會很長、會選錯。需要一套分類軸。

我的建議：三軸
① 標的類型（受控 enum）：作業系統 / 瀏覽器 / 應用程式 / 資料庫 / 網通設備 / 雲端服務 / 容器 / 其他
② 標的產品（自由文字）：Ubuntu 22.04、Google Chrome、PostgreSQL 15 …
③ 基準體系（受控 enum）：TWGCB / CIS / STIG / dev-sec / 自訂
④ 執行平台——不是第四軸，從 inspec.yml 的 supports 自動抽取、唯讀不可編（它是事實不是分類）

為什麼標的產品用自由文字而非 enum：產品名稱長尾極長（客戶自帶的 profile 可能是任何東西），硬做 enum 會逼使用者選「其他」，反而失去篩選價值。以自由文字 ＋ 前端 autocomplete 既有值的方式處理。

待決：enum 值來源——(a) FE 寫死常數，改一次要發版；(b) 存 DB（比照 DeviceManage.vue 用 system_menus 的做法），可由 root 維護。我傾向 (a) FE 寫死：這八個類型是穩定的分類骨幹、不該讓租戶隨意增刪（增刪會讓篩選語意漂移），要新增類型時發版一次是合理成本。若決策者認為需要客戶自訂，再走 (b)。

D6 · platform_hint 退役

現行有一個 platform_hint 欄位。實查 DEV 12 筆資料，值有兩種形態：空字串 '' 與大寫的 Windows——髒值已經存在。

我的建議：退役此欄位。它的功能被 D5 的三軸完全覆蓋而且更精確：「這支基準是給什麼用的」由標的類型＋標的產品表達，「它能在哪些平台跑」由 supports 自動抽取表達。一個沒有約束、已經有髒值、語意含糊的自由文字欄位撐不起分類。

退役方式：拆表時不搬到新表，值隨舊表一起保留在 rename 後的 _deprecated 表裡（觀察期內若發現有人在用，還撈得回來）。不要在新表建一個空的 platform_hint 欄位——那會變成第二個沒人維護的髒欄位。

被排除：保留並清洗——清洗 12 筆很容易，但清洗完它仍然與新三軸功能重疊，只是多一個要同步維護的欄位。

D7 · 改名的語意

使用者改了名稱，歷史版本要跟著改，還是只改當前版？

我的建議：整鏈一起改，且不升版。拆表後改名就是主檔一列 UPDATE，所有版本天然共用同一個名稱——這個行為是拆表的自然結果，不需要額外邏輯。

理由：名稱是「這支基準叫什麼」，不是「這一版的內容」。若歷史版本保留舊名，列表上會出現兩個看起來不同的基準其實是同一支，比不改更混亂。

被排除：改名建新版——版號應該反映內容變更。改個錯字就升一版，會讓版號完全失去意義（也讓「有新版了」的提示變成噪音）。

D8 · 「只改描述」不再算版更 → 新增編輯端點

承 D7：既然改名 / 改描述 / 改分類都不升版，就需要一個純粹的「編輯基本資料」端點。

我的建議：新增 PUT /detection-tool-profiles/<uid>，消費那顆已 seed 但至今沒人用的 detection-profile.update capability（FR-059 spec §12 坑 2 稱它為「預留孤兒」）。

附帶效益：這顆 capability 從「孤兒」變成有實際消費者，權限矩陣不再有一列是死的。

權限規則：租戶只能編自己的（scope = TENANT 且 tenant_id 相符）；公版（scope = SYSTEM）只有 root 能編。這個判定走 common/authz/ 的資源域守門（app service 層），不要另立 helper。

D9 · fork / copy_to_tool 的版本複製語意

fork 一支有 3 個版本的基準，新的那支要有幾個版本？

我的建議：只複製當前版，成為新基準的 v1（與現行為一致），並把 fork 與 copy_to_tool 抽成共用的 _clone_profile()。

理由：fork 的意圖是「我要以這份為起點做我自己的」，歷史版本對新的那支沒有意義（那是原基準的演進史，不是新基準的）。且複製全部版本會讓儲存量與 file_id 引用倍增。

拆表後的簡化：fork 與 copy_to_tool 的差異收斂成三個參數（scope / tenant_id / tool_id），版本複製邏輯完全相同 → 一個方法帶參數即可，不必兩套。

控制項要不要一起複製：建議複製（而非重新抽取）——內容完全相同、重抽要再等 28～117 秒沒有意義。但要注意 extraction_status 要一併設為 succeeded。

D10 · 抽取非同步化與 extraction_status 欄位落點

實測 708 條的 profile 抽取要 117 秒，遠超任何 HTTP 逾時 → 非同步是必然，不是選項。需要一個狀態欄讓前端知道進度。

我的建議：extraction_status 四態 pending / running / succeeded / failed，放從檔——抽取是對某一版做的，不是對整支基準。再配一個 extraction_error 文字欄存失敗訊息（給使用者看，也給支援人員除錯）。

為什麼不放主檔：主檔若只有一個狀態欄，上傳 v3 失敗會讓 v1、v2 的狀態一起被覆蓋成 failed，但那兩版的控制項其實好好的。

前端呈現：列表與版本子表顯示狀態徽章；pending / running 時輪詢（建議 5 秒一次，抽取本來就要幾十秒）。不建議走 WebSocket——為一個低頻操作接推播不划算，且專案的 SocketIO 走另一個 port。

D11 · 抽取失敗的判定條件

承 §2A 的第七種錯誤形狀：Ruby 語法錯會導致 exit 0 ＋ stderr 全空 ＋ JSON 合法 ＋ controls: []。

我的建議：exit != 0 或 controls == []，兩者任一都算失敗。

理由：若只看 exit code，使用者會拿到一支「抽取成功但零控制項」的基準——他會以為是這份基準本來就沒東西，而不是解析壞了。靜默的錯誤比明顯的錯誤更貴。

誤判風險評估：真的存在「合法但零控制項」的 profile 嗎？理論上有（純 wrapper profile 只有 depends 沒有自己的控制項），但那種 profile 在本系統的使用情境下也是無效的（掃了什麼都不會驗）。把它判成失敗是正確的，錯誤訊息寫「未解析到任何控制項，請確認 profile 內容」即可。

D12 · 控制項的存儲形式

234～708 條控制項，存成一個大 jsonb，還是拆成一條一列？

我的建議：一條一列拆表（detection_profile_controls），欄位以「跨格式共通的最小集合」為正規欄，格式專屬的中繼資料整包進 attributes jsonb（詳見 D19），丟掉 code、丟掉與 descriptions.default 重複的 desc（省 59.6% 體積，實測）。

拆表的理由（決定性）：FR-061 的豁免要能綁單一控制項——那需要控制項是一列可被外鍵參照的資料，不是 jsonb 陣列裡的一個元素。這是不可逆的架構決定，現在做對成本很低，之後改要動 FR-061 已寫好的東西。

其他理由：搜尋 / 篩選 / 分頁走 SQL 而非 Python；「人工待判 199 條」這種統計是一句 COUNT(*) WHERE is_pending；未來要跨 profile 找「哪些基準有驗這條」也有路。

🔴 欄位命名不可用 InSpec 專有名詞（D19 定調）：嚴重度欄位不叫 impact——那是 InSpec 的 0.0–1.0 浮點語意，XCCDF 用的是五級列舉，其他工具各有各的。改成 severity_raw（原樣存來源值，文字）＋ severity_norm（跨工具可比的統一級距）。is_pending 保留欄位名，但判準寫在各格式的 extractor 裡（InSpec 是 impact == 0.0，XCCDF 另有 role=unchecked），不是寫死在表結構的假設裡。

格式專屬中繼資料進 attributes jsonb：InSpec 放 tags ＋ descriptions；XCCDF 放 ident（CCE／CCI）／fixtext／rationale；未來格式放它自己的。這一格就是「加資料不加欄位」的著力點——第二個工具入庫時不必 ALTER TABLE。實測理由同樣成立：tag key 集合隨 profile 變動（TWGCB-01-011 比 -014 多一個 service_display_name），外來 profile 更不可能有 TWGCB 那套 key → schema 本來就不可寫死。為常用 key 建 GIN 索引（至少 category）。

丟 code 的代價：使用者看不到「這條實際怎麼檢查」的 Ruby 原始碼。我認為可接受——目標受眾是合規負責人不是 InSpec 開發者，且 47.8% 的體積換一個幾乎沒人看的欄位不划算。若日後有需求，從 source_ref 可以定位到檔案，不是完全無路。

完整欄位建議：正規欄 control_id ／ title ／ description ／ severity_raw ／ severity_norm ／ is_pending ／ source_ref（剝掉絕對路徑前綴的相對路徑）；標記欄 extraction_format（哪個格式抽出來的）＋ origin（extracted ｜ custom，FR-061 自訂項用，兩者正交）；其餘全進 attributes jsonb。

D13 · menu API 的形狀：扁平 vs 巢狀

下拉要分組，分組資料由誰組？

我的建議：BE 保持扁平 [{value, name, target_type, target_product, benchmark_family, ...}]，FE 自己 groupBy。

理由：① 相容性——JobExecutionDrawer.vue:279-282 的 for (const m of items) 若拿到巢狀會靜默失效（不 throw、不進 catch），任務抽屜的參數顯示直接退回裸的 profile:<uuid>；② 彈性——FE 想改用哪一軸分組（依標的類型 or 依基準體系）不必動 BE；③ 符合 CLAUDE.md 的 Menu pattern（回傳 List[MenuDto] 不包 PageDataDto）。

被排除：BE 回傳巢狀——省了 FE 十幾行 groupBy，換來一個靜默失效的相容性風險，不划算。

🔴 不論選哪個，D13 都必須配 §2D 的 fallback 修補：DetectionConfigField.vue:82-92 的 opts.some(o => o.value === current) 在選項變巢狀後必然全 miss，每個已選值都會多長一個「已不可用」項。要先攤平再比對，fallback 項自己也要包成群組。

D14 · 列表語意：主列表 vs 版本歷史

拆表後列表一列代表什麼？現有的「顯示已停用與舊版」開關語意會分裂成兩件事。

我的建議：主列表一列 = 一支基準（主檔），預設只顯示 is_active 的；版本歷史走展開列（expander，pattern 抄 SheetPreviewControls.vue）＋ 另有獨立分頁 API（給版本多的情況）。

「顯示已停用與舊版」開關的分裂：拆表後這是兩個獨立概念——「已停用的基準」（主檔 is_active = false）與「非當前版」（從檔 is_current = false）。建議拆成兩個開關：主列表上是「顯示已停用基準」，版本子表上是「顯示歷史版本」（子表本來就該全顯，這個開關可能根本不需要）。

被排除：一列一版本（維持現行形狀）——那等於沒拆表，改名、分類、篩選全部回到原點。

D15 · is_active 只放主檔，還是從檔也要狀態欄

現況 id 33 是列級停用（is_active = f）。拆表後這個語意要放哪一層？

我的建議：第一期 is_active 只放主檔（＝停用整支基準），從檔不另設停用欄。

理由：現況 13 筆裡沒有任何「想停用某一版但保留其他版」的需求證據（唯一的停用列 id 33 是整支不要了）。先不做，等出現實際需求再加——加一個 boolean 欄很便宜，但憑空設計一套「版本級停用」的語意（停用當前版後哪一版變 current？）很貴。

id 33 的搬遷處理：它會變成「一支 is_active = false 的主檔，底下有一個版本，但 current_version_id 是 NULL」——這是合法狀態，UI 要能顯示（不要因為 current 是 NULL 就渲染爆掉）。migration 的驗證查詢也要預期 current_version_id IS NOT NULL 只有 12 筆而非 13。

未來若要加：從檔加 is_deprecated（而非 is_active，避免與主檔同名混淆），且要定義「棄用當前版時 current 怎麼移轉」。

D16 · 舊表 rename 保留、觀察期後另開 migration 才 DROP

這是專案慣例的確認項，不是新決策。

我的建議：本案的 migration 只做 ALTER TABLE ... RENAME TO detection_tool_profiles_deprecated_20260803，不 DROP。DROP 另開一支 migration，於觀察期（建議一個 release 週期）後執行。

前例：2026-06-03-log-tables-partitioning.sql:66、2026-05-19-ssp-system-implementation-restructure.sql:255-280（附反向 ROLLBACK 註解）、2026-05-24-ssp-oscal-alignment-drop-old.sql（獨立成一支才真正 DROP）。

⚠️ rename 不會自動改索引名稱 → 新表的索引一律用新前綴（idx_dp_* / idx_dpv_* / idx_dpc_*），避免與舊表殘留的索引名撞名導致 migration 中途失敗。

DROP 前的檢查：比照 CLAUDE.md「DROP 退役表前安全四查」，確認沒有任何 live-wired 的 code 還在引用（拆表後應該沒有，但要實際 grep 確認，不要假設）。

D17 · 既有 13 筆的分類補登策略

拆表後主檔多了三個分類欄位，13 筆既有資料要填什麼？

我的建議：migration 內做「有把握的才填，其餘留 NULL」——名稱裡含 twgcb-01-* 明確是作業系統、twgcb-02-003-google-chrome 明確是瀏覽器，這類從名稱可高信心推導的直接填；推不出來的留 NULL，由使用者在管理頁補。

被排除：全部留 NULL 等人工補——13 筆裡有 10 筆是我們自己 seed 的 TWGCB 公版，我們比使用者更清楚它們是什麼，讓使用者補等於把已知資訊丟掉。

被排除：全部靠猜測規則自動填——猜錯比留白更糟（使用者會信任錯誤的分類去篩選，篩掉他該看的東西）。寧可空著也不要猜。

「未分類」群組的位置：下拉分組時，未分類的項目放最後（不是最前）——分類明確的是常態，未分類是待補的例外。列表篩選要有「未分類」這個選項讓使用者找得到待補的。

D18 · 兩個懸空 i18n key：field_scope / hint_scope_system

FR-059 當初為「root 建立公版」預留了這兩個翻譯 key，但 UI 沒做——createDialog.scope 恆為 TENANT，root 目前沒有辦法從 UI 建公版（只能靠 migration seed）。

我的建議：補做 root 建公版的 UI，讓這兩個 key 活起來。

理由：本案要開放編輯基本資料（D8），編輯 Dialog 與新增 Dialog 是同一組欄位。既然都要重構那 600–700 行，順手把 scope 欄位補上（對非 root 隱藏或唯讀）成本極低。而且公版只能靠 migration 建本身就是 FR-059 未收乾淨的尾巴——每加一支公版又要寫 migration，正是 FR-059 立案時要消滅的維運模式。

被排除：標記刪除這兩個 key——那等於承認「公版只能靠 migration 建」是最終狀態，與 FR-059 的立案動機相牴觸。

若決策者認為範圍太肥：至少要在 FR-060 的 spec 明寫「公版建立目前仍走 migration」，不要讓這兩個 key 繼續懸空無人知曉。