FR-060 · 需求索引 · 本頁由 build 掃資料夾生成
FR-059 把掃描設定檔（profile）收進了後台，但平台把它當成 opaque binary——使用者在管理頁與任務下拉看到的只有一個名字，不知道選下去會驗什麼、驗幾條、哪些其實根本不會自動檢查。
目前只有項目，user 完全不知道這個東西會驗證什麼，我怎麼知道我要選什麼？哪些基準可以參考，我可以先請負責人去判斷、提前先處理，而不是等報告出來才去處理。 — 決策者原話（2026-08-03）
一個支撐急迫性的實測數字：目前最常被選的 TWGCB-01-014（Ubuntu 22.04 政府組態基準）共 234 條控制項，其中 199 條是人工待判項（impact 0.0，執行時直接 skip），真正會自動檢查的只有 35 條。使用者現在完全看不到這件事——選了、掃了、拿到一份 85% 是 skip 的報告，才發現。
本案範圍三件事：瀏覽 profile 的檢驗內容（核心）／修改基本資料含改名（現在打錯字只能砍掉重建）／分類體系（profile 一多下拉會很長、會選錯）。同時做一次資料模型重構：現行單表以 (detection_tool_id, tenant_id, name) 推斷版本鏈，拿 name 當身分正是改名改不動的根因，故拆成「基準主檔／版本從檔／控制項」三層。
現況：討論稿已產出並發 Artifact，D1–D18 待拍板，拍板後才落地 design.md。詳見下方文件與 handoff。
以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。
| 文件 | 類型 | 標題 | 最後更新 |
|---|---|---|---|
| discussion ／ md | 需求討論稿 | 讓使用者看得見「這份基準到底要驗什麼」 | 2026-08-03 |
cards/（3 份）其他文件
| 文件 | 類型 | 標題 | 最後更新 |
|---|---|---|---|
| CM-1077-1-usage-judgement ／ md | 文件 | CM-1077.1 檢測基準「是否被使用過」判定服務 | 2026-08-04 |
| CM-1077-2-edit-and-delete ／ md | 文件 | CM-1077.2 修正來源 ＋ 刪除（BE 寫入端） | 2026-08-04 |
| CM-1077-3-fe-actions ／ md | 文件 | CM-1077.3 — 前端：把「修正來源」與「刪除」接進操作 menu | 2026-08-04 |
由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。
| 日期 | 文件 | 標題 |
|---|---|---|
| 2026-08-07 | fr060-STATE ／ md | FR-060 檢測基準內容管理 — STATE（living，永遠只描述「此刻」） |
| 2026-08-07 | fr060-LOG ／ md | FR-060 檢測基準內容管理 — LOG（append-only，每棒追加一 block） |
| 2026-08-03 | 2026-08-03-fr060-discussion-to-design-handoff ／ md | FR-060 中繼交接 — 討論稿已產出，等 D1–D18 拍板後落地 design.md |
| 2026-08-04 | 2026-08-03-fr060-arc-SUMMARY ／ md | FR-060 檢測基準內容管理 — 全案收尾 SUMMARY |
牽動的 SPEC 頁（連向線上 SPEC 手冊，開新視窗）：
相關需求：