FR-060 母案 — 全案完成（2026-08-04）。 三個子需求 .1／.2／.3 全數落地，七張子任務卡 CM-1060～CM-1066 ＋ 三張延伸卡 CM-1072／1075／1076 全數收口，橫跨 BE ＋ FE 兩個 repo，均已 push。
設計文件：
docs/features/FR-060-2608-detection-profile-content-management/design.md（1030 行，D1–D19） ｜ SUMMARY：同資料夾handoff/2026-08-03-fr060-arc-SUMMARY.md｜ 交接：handoff/fr060-STATE.md（現況）＋fr060-LOG.md（七棒脈絡）
前作：FR-059 檢測 Profile 庫 — FR-059 檢測工具 Profile / Content 庫（掃描設定檔後台管理）（母案）（它把 profile 檔搬進後台，本案讓平台看懂內容）
讓使用者在**選擇掃描基準「之前」**就看得見這支基準的內容，而不是等掃完拿到報告才發現。
三個需求：
明確不在本案範圍：選用範圍／豁免／人工判定／自訂項四項屬 FR-061（本案只定模型契約 design.md §6）；profile 內容線上編輯（與 InSpec「上游不可變、疊加物獨立」的設計哲學逆行）；公版名稱與描述的多語化（決策者裁示不擴大範圍，缺口記於 design.md §6.3）。
決策者原話：
「目前只有項目，user 完全不知道這個東西會驗證什麼，我怎麼知道我要選什麼？哪些基準可以參考，我可以先請負責人去判斷、提前先處理，而不是等報告出來才去處理。」
FR-059 做完了「掃描設定檔管理」，但平台把 profile 當成不透明的二進位檔，完全不理解內容——使用者在管理頁與任務下拉看到的，從頭到尾只有一個名字。
支撐急迫性的實測數字：TWGCB-01-014 Ubuntu 22.04 LTS 共 234 條控制項，其中 199 條是人工待判項（impact 0.0，執行時直接 skip），實際自動檢查只有 35 條、自動覆蓋率 15%。使用者選了、掃了、等了一輪，拿到一份 85% 是 skip 的報告才發現這件事——等於白等一輪掃描。
同樣形態在另外兩支的落差極大（收尾日實查）：
| 基準 | 總控制項 | 人工待判 | 自動檢查 | 自動覆蓋率 |
|---|---|---|---|---|
| TWGCB-01-014 Ubuntu 22.04 LTS | 234 | 199 | 35 | 15% |
| TWGCB-01-007 Windows Server 2016 | 699 | 159 | 540 | 77% |
| TWGCB-Windows-2025 | 708 | 150 | 558 | 79% |
差距從 15% 到 79%——這正是「選之前必須看得到」的理由：同樣叫「TWGCB 基準」，選錯一支等於整輪掃描交白卷。
為什麼一個「瀏覽」功能要順帶拆資料表：現行單表用 (detection_tool_id, tenant_id, name) 當唯一索引——拿 name 當身分，這正是「改名改不動、唯一改名途徑是 fork 複製」的根因；而分類三軸是「這支 profile 是什麼」的屬性、不是「這一版是什麼」的屬性，存單表會每版重複、版更漏帶就漂移。當時是最便宜的時機：DEV 僅 13 筆、FR-059 上線才兩天、沒有租戶真的在用。