本卡為 FR-162 母案。建一份跨框架對照庫（控制項層＋評估目標層，存 jedi-oscal-v2），灌官方 CMMC↔800-171↔800-53↔ISO 鏈；資源庫對照維護工作台；新專案一鍵帶入其他專案證據；AI 建議評估目標配對。九張子卡五批。子卡清單在末段。

這系列在做什麼（白話）

客戶導入合規框架常不只一套：先做 CMMC，之後又要 ISO 27001 或 CRA。兩套框架有一半的要求其實是同一件事，但現在系統裡是兩個獨立專案，證據要重新上傳一遍，客戶覺得在重工。

本案讓系統知道「框架 A 的這條要求就是框架 B 的那條」，細到評估目標（AO，每條控制項底下要逐一判定的小項）。有了這份知識：①新專案建好進規劃頁，系統主動提醒「CMMC 專案有 87 個評估目標的證據可以帶入」，點進去看一張預覽表、按一次就全部帶入，沒對應的順便列成「這個框架比上一個多要什麼」的清單；②顧問在資源庫有一個工作台，看得到所有對應、能調、能用 Excel 匯進匯出；③官方只對到控制項層的部分，由 AI 讀兩邊評估目標的文字建議配對，顧問確認。

帶入的是證據檔不是判定結果：檔案本體一份不複製，每個專案各有一筆證據紀錄指到同一個檔並標「從 CMMC 專案帶入」；稽核員仍在新專案判一次。

為什麼要做

決策者 2026-10-24 提出；盤點結論見分析文件：v2 沒有跨框架對應（v1 曾有 oscal_control_mapping 表但隨 FR-038 退役且當時沒有業務呼叫點）；OSCAL 1.2.2 的 mapping-collection 原生支援對到 part 層所以評估目標層合規；NIST 官方有 800-53↔ISO 27001:2022（OLIR 2023-10-12，91 個 Annex A 全部命中我們的 ISO catalog）與 800-171↔800-53（附錄 D），CMMC↔800-171 是恆等關係；官方全部不給關係型別。CRA、SEMI 無官方對照。

關鍵設計決策

• D1 對照存 jedi-oscal-v2 獨立兩表（決策者裁「這應該是套件功能」），不塞 catalog。對應 OSCAL Control Layer 的 Mapping Collection model。
• D2 鍵用控制項代號（A.5.1／AC.L2-3.1.1）與評估目標 part_id（A.5.1_obj.3），不綁數字 id——資源庫與專案 clone 都會長新 id，綁代號則全部共用一份對照。
• D3 雙粒度：同一張表容納控制項層與評估目標層；解析時評估目標層有就用，沒有退控制項層並把信心度乘 0.7。
• D4 證據重用走跨專案帶入，不做一專案多框架（決策者裁 OK）。帶入＝新開一筆 job_evidences 同 file_id，形狀比照覆核輪承襲 inherited_from_round_id。
• D5 官方層與覆寫層分開：origin 分 official／curated／ai-suggested；顧問改官方那條＝原列 status='disabled'、新 curated 列 overrides_entry_id 指回。重匯官方不沖掉顧問改的；沿鏈往回走就是歷史。
• D6 匯入是更新不是覆蓋：同鍵覆蓋、新鍵新增、檔內沒有的不刪；整批換走「重建」並二次確認。
• D7 800-53／800-171 這種沒有 catalog 的中繼框架：在既有 oscal.frameworks／framework_versions 各建一筆、catalog_id NULL，畫面標「參考用」。不另開表。
• D8 評估目標層怎麼產：CMMC↔800-171 規則生成 equivalent-to；其餘對「控制項層已對上」的組跑 AI 兩兩比（每組 6×7 量級，不做全配）；顧問確認。
• D9 帶入入口：專案層一鍵批次為主（決策者：「一筆一筆勾很蠢」），任務層單筆為輔。預設勾 equivalent-to 且 confidence ≥ 0.7。
• D10 三個提醒點：規劃頁橫幅（建好專案時）、任務 drawer 提示列、來源專案補新證據後橫幅再亮。
• D11 「其他專案」第一版＝同租戶：compliance.projects 沒有資訊系統欄，資訊系統過濾等 ISO 資產設計落地再加。

怎麼拆（五批）