FR-162 交接紀錄（LOG）

append-only：每棒收工追加一個 block，既有 block 永不改。發現舊 block 有誤，在新 block「推翻了什麼」欄更正。現況看 FR-162-STATE.md。

做了什麼

• 盤點：v2 無跨框架對照；v1 oscal_control_mapping 已退役且無業務呼叫點；source_identifier 是同框架跨版本代號；OSCAL 1.2.2 mapping-collection 的 mapping-item.type 可指 part，AO 層合規。
• 官方對照盤點（含網查、決策者下載 8 份檔）：CMMC↔︎800-171 恆等；800-171↔︎800-53 附錄 D；800-53↔︎ISO 2022 NIST OLIR（91 個 Annex A 全命中）；CRA 官方只對 Common Criteria（ENISA EUCC 附錄），對 800-53 有 OSA 社群 36 條；SEMI 官方無，SunSquare 第三方 12 條對 62443、METI 對 CSF。官方全不給關係型別。
• 文件：兩份 analysis、design.md（D1～D11）、README、三頁雛形、FR 登記；Notion 母卡 CM-3057 ＋ 九張子卡 CM-3058～3066（四欄齊）。
• 順手發現：catalog_service.py:90 預設 oscal_version="1.1.2"，DEV 53 筆錯標 → 開 CM-3059。

commits（BE feature/FR-139，未 push）：c26eb5a6b 4042d936c 8ce3a4d5a 939f329dd 6c2793322 435d1b9da 86c6cb09a 3e9152e16 df4505b38 c42d0f6a7 d96ea1043 c73bf133c d39d17774 54c43b443 a9d2f7eca 5e438892a

關鍵決策（決策者裁）：對照進套件；鍵用控制項代號；跨專案沿用不做一專案多框架；AI 兩模式（控制項層初配＋AO 配對）＋規則回填關係；專案層一鍵批次為主；定名「證據沿用／reuse」；工作台矩陣視圖、主軸凍結、參考框架隱藏；常駐入口按鈕；二級來源標 curated；「先出一版」。

推翻了什麼

• 第一版只做 AO 層 AI → 決策者指出 CRA／SEMI 控制項層空，加模式 B。
• 第一版任務層單筆勾選 → 改專案層批次為主。
• 第一版工作台一對一配對 → 改矩陣。
• 第一版「CRA、SEMI 真的沒對照」→ 重查後 CRA 有官方（對 CC）與社群（對 800-53），SEMI 有第三方（對 62443）。
• 第一版五批 → 2a／3a、2b／3b／3c 各改同一登記型檔，重排七批。

教訓

• 雛形要在 design 前：我跳過雛形直接開卡，決策者看雛形後改了三處（矩陣、凍結欄、常駐按鈕），每處都要回頭改 design 與卡。照規範先雛形，這些在開卡前就會抓到。
• 分批要逐張問兩題（用到誰的產出／改到同一檔），「不同模組」不等於「不同檔」——error code 表、migration manifest、FE api.js／locales 是登記型檔，任何兩張卡同時加列就撞。
• 「真的沒有官方對照」要查到檔為止：第一輪網查結論太早下；決策者說「我記得有」就該再找一輪，結果 CRA 有、SEMI 半有。
• 提示類 UI 必配常駐入口：橫幅／提示列可關閉或會消失，關掉就沒入口是設計洞。

未驗證假設（交給下一棒驗收時對照）：1a 是否做批次 resolve_many；OSA iec-62443.json 代號是否對得上 SunSquare；AI 配對準確率。

派出／收回：批 1（CM-3058、CM-3059）由決策者在工作坊派出；本棒無收回。

做了什麼

• 接手時盤點：STATE 寫批 1 剛派，實查批 1～11 已由工作坊首腦驗收完畢（CM-3058～3071 皆 驗收通過待確認），CM-3072／3073 暫緩；本棒「驗收批 1」任務已過時，改做規格補強與新一輪開卡。
• design.md 新增「各框架怎麼轉到 ISO 27001：轉乘路線」節：圖 3（實線官方、虛線第三方）、路線表、與第 1 棒同日補的每跳來源公信力表合併；再補 DEV 實灌九冊表（含 AI 直達冊 267／268）、OSA 官網與 GitHub 檔案路徑、SunSquare 文章完整網址；origin 由三值對齊成四值（third-party，套件 024）。
• 第 9 輪開卡（決策者工作台實測五個問題）：CM-3074 9a／3075 9b（BE，批 14）、3076 9c（FE，批 15）、3077 9d（FE，批 16），四欄齊、已接母卡、母卡尾段 append 批次清單。開卡腳本 gen_notion_cards_r9.py／patch_workshop_fields_r9.py。

commits（BE feature/FR-139）：78187f451（圖 3）、5ab551010（DEV 實灌表、網址、origin 四值）、本次開卡 commit。

關鍵發現（已核對）

• 問題 1 根因：五框架間無直接對照、全經 800-53 中轉，ISO×CRA 每格皆兩跳；FE ControlMappingSidePanel.vue 對 hops>1 一律唯讀，BE override／disable 只作用最後一跳邊。解法不是改中繼邊，是在主軸↔︎目標建 curated 直連（解析規則 6「hops 最少優先」會蓋過多跳；not-related-to 當刪除）。
• 問題 3 根因：catalog_controls.sort_order 是群組內序號（ISO 93 條只 37 個相異值），套件 get_by_catalog 全表 ORDER BY sort_order 讓群組首條交錯；get_by_catalog 有 7 個呼叫者，改在主專案 mapping_common._load_catalog 讀取端排序，不動套件。
• 問題 4／5：AXIS_REM=24／COL_REM=18 寫死＋fit-content；全螢幕先例 FilePreviewDialog.vue 的 maximizable。

推翻了什麼

• 第 1 棒 2667e52a9 的來源表把二級來源標 curated，與套件 024 之後的實作（third-party）不符，本棒對齊；design.md D5、DDL、不做段同步。
• STATE 寫「未 push 18 個」，實查 origin 已與 HEAD 一致。

教訓

• 接手前先 fetch 卡狀態再信 STATE：STATE 是交棒當下的快照，工作坊多個 session 平行推進時幾小時就過期；本棒開場盤點與一小時後重查，DEV 從「無表」變成「九冊」。
• 分批時兩張 FE 卡改同一個 i18n 檔就不能同批：9c／9d 都改 control-mapping.json 與 ControlMappingMatrixTable.vue，拆成批 15／16。

未驗證假設：9a 用直連 curated 列蓋多跳的做法，解析器規則 6 在「同目標、直連 1 跳 vs 多跳」的確取直連（讀碼推斷，runner 寫測試驗）；9d 全螢幕 Dialog 疊 Sidebar 的 z-index 要實測。

第 10 輪（同日續）：決策者審側面板退回。討論：容器三案（對話框／下方詳情區／寬抽屜）→ 決策者裁對話框，首腦原推下方詳情區的「不用一直開關」理由被駁（常駐面板一樣要開關）；狀態文案三輪（部分重疊→符合／部分符合→通用／部分可用），決策者定「通用／部分可用」，「不可用」不是顯示狀態；內容七塊。開 CM-3078（10a BE）／3079（10b FE），9c append 縮範圍。commits bafc108b9、f8f786aca。

教訓（第 10 輪）

• 文案要從「使用者在這格要做什麼決定」出發，不是列同義詞：第一批（可參考／部分符合／需補強）被決策者點名「幾乎都沒認真想過」；改從「舊證據拿來能不能過」出發才收斂。
• 「資料庫有什麼就顯示什麼」不是設計：側面板倒出五個欄位，真正有價值的（兩邊條文、誰說的、怎麼轉）一樣沒放；設計面板先問「點開的人要回答什麼問題」。
• 替代方案要先驗它跟被退方案的本質差別：下方詳情區／寬抽屜與抽屜同是常駐面板，決策者一問「乙跟抽屜有什麼差別」就倒。

第 11 輪（同日續）：決策者實測規劃頁沿用對話框退回四點。首腦探脈抓到真 bug：來源範圍「同租戶」把另一組織單位的鼎盛專案列進來（使用者列表看不到卻能拉它的證據），屬跨組織單位資料外洩，也解釋 CM-3072 那次 3,599 筆爆量；封存專案也沒排除。定案（design D9／D10／D11 改判）：入口「證據作業」下拉；比照自動分類做獨立三頁；一來源一份設定不做批次、每次調整留唯讀紀錄；可見性照 _visible_project_ids。開 CM-3080（11a BE，資安優先）／3081（11b FE 入口）／3082（11c FE 三頁）。CM-3072／3073 決策者在工作坊跳過。commits e5ae16fe2、本次。

教訓（第 11 輪）

• 「同租戶」不等於「使用者看得到」：RLS 只擋租戶，組織單位與參與者可見性在應用層；任何「列其他專案給使用者選」的功能都要走專案列表那套可見性，不能自訂範圍。D11 當初寫「第一版＝同租戶」就是沒查可見性模型。
• 「3 個選項只有 2 個專案」要查到人：先假設是封存沒排除，實查 DB 才發現是別的組織單位的專案；資料面查到底才知道是資安問題不是 UI 小 bug。
• 開卡後決策者一問「有正確分批嗎」才實查：11b／11c 撞 api.js／router／menu.json 三個登記型檔，原排同批是錯的，改 11c 先、11b 後。分批要用腳本掃卡內文列到的檔名求交集，不憑「不同模組」判斷——這是 LOG 第 1 棒就寫過的教訓，第 2 棒又犯一次。
• 決策者連續簡化三次（批次→一份設定→只要紀錄→紀錄放彈窗）：先問「user 反悔時要做什麼」再設計資料模型，批次 id 整套是為沒人要的「復原某一次」做的。

第 12 輪（同日續）：決策者問重複證據。查明三種情境（同任務同檔已有唯一索引擋；同檔多 AO 是關聯模型本身，254 檔最多掛 56 任務；同內容不同檔要靠 sha256 但 96% 空、全專案無上傳路徑在算，MinIO adapter 只算 md5）。定案不硬擋、看得見＋地基補 hash；決策者同意動套件 jedi-file-upload。開 CM-3097（12a 套件＋BE 回填，批 22）／3098（12b BE 加欄＋FE Tag 與上傳提示，批 23）。

推翻了什麼（第 12 輪）

• 我的 STATE／任務總表停在「批 14 待驗收」，決策者一問才 fetch 實況：批 14～21 全部已驗收通過待確認、11c 已合回。開新卡前必須先 fetch 母卡全部子卡的 Stage 與狀態，不能用自己手上的快照排批次（又一次「STATE 是快照、工作坊平行推進幾小時就過期」）。

第二道檢查（第 9～11 輪，決策者定雙重驗證）：九張卡的「首腦復核」段都在且有打折處；六支新路由實打 401（存在）；四支新測試檔 43 條綠；origin 四值分佈正常；事件碼已登記；FE 側面板與規劃頁沿用元件已刪、無「間接」、無粗左框、沿用頁無 SSP。抓到三件工作坊首腦沒標的：①守衛 test_module_boundaries 1 支紅是 FR-162 自己的（套件 resolution service domain→infra import，CM-3058 起就在，歷棒都寫「開工前就紅」）；②ISO 專案 3,741 筆有效 REUSED 列（19:54 blsadmin 寫），比 3072 清掉的還多，來源未查；③共用 8000 跑 18:18 舊程式，工作坊首腦是另起 8034 驗的——決策者要邊測，本棒已重啟 8000。

頁面改名：決策者「框架對照這個名稱好爛」→ 候選後定「控制項關聯管理」（「管理」把可編輯講出來）。FE i18n 13 處＋BE seed migration 改 ui_routes／能力點描述，已套 DEV。commits FE 431b1ffc、BE 3ada4f2ed。

本棒 commits（BE feature/FR-139，未 push）：78187f451 5ab551010 49e2cebc9 bafc108b9 f8f786aca 7a862cdea e5ae16fe2 d7b4b4948 be3aecf35 98dd936ea 86c733d6f 3ada4f2ed；FE 431b1ffc。

教訓（收尾補）

• 第二道檢查要看「歷棒都說與本卡無關」的紅：每棒各自對比自己的 diff 說守衛紅不是我造成的，沒人回頭問「那是誰造成的」——跨棒累積的紅只有首腦看得到全貌。
• 共用 8000 不等於決策者看到的版本：runner 與工作坊首腦都另起埠驗，8000 可能停在幾小時前；決策者說要邊測，先比對進程啟動時間與最後合回時間。

派出／收回：第 9～11 輪九張由決策者在工作坊派，全部驗收通過待確認（工作坊首腦驗、本棒二檢）；第 12 輪 CM-3097 In progress（runner 在套件主線直接改）、CM-3098 待派；本棒無收回。

做了什麼

• 接手盤點：CM-3097 已轉修正待驗證但 BE 段在 worktree 未合回；3,741 筆 REUSED 查出 3,740 筆是 10-25 00:13 CM-3072 爆量殘留。
• 決策者在 5180 實測後逐項口頭裁示、令首腦直接改（未開卡、未經工作坊），約 30 個 commit：
  • 控制項關聯管理矩陣：膠囊帶名稱、有對應的格也能＋／×、群組帶編號、拖曳直接生效且只能同層搬、每格清空、評估目標列直接列出控制項層帶出的全部評估目標（只顯示不寫資料，刪／搬／新增前才 expand）、左欄編號名稱兩行、欄分隔線、欄頭拖曳排序、欄寬自動符合／平均分配、工具列兩列、批次作業／維護兩個選單、還原出廠設定（停用不刪、清覆寫指向）、AI 建議與 OSCAL 隱藏、新增對應改多選挑選器。
  • 共用挑選器 AOPickerDialog 改左右兩欄（雛形四方案中決策者選 D），三處共用。
  • 證據沿用：右欄依控制項分組、中欄檔案可預覽、挑選器顯示正在歸檔的檔名、沿用提示移到流程列下方、控制項層對應與評估目標層一視同仁、按鈕改「一鍵勾選通用對應（N）」。
  • 關聯表 Excel 重做版面（機器鍵藏第 5 列，匯出再匯入零變動），匯出主軸對全部框架。
  • 套件 jedi-oscal-v2 026：CRA.A2.8 的 17 條評估目標→控制項跨層列改成 12 條控制項層（已套 DEV）。
  • 抽 SegmentButtons（照待辦任務頁、small），修好 FE v-can-guards 守衛紅（CM-3076 起就紅）。

commits：BE 6aa56172b 42265a3cf 108d27e87 c3be5af8f 333ba9da0 ff82e549b 053ff6884；套件 1ef1403b；FE f68c143a 起至 5a9499a3（約 27 個，git log --grep=FR-162 可列）。都未 push。

關鍵決策（決策者裁）：只能同層對；控制項層有、評估目標層沒細分＝全部評估目標適用，顯示不寫資料；人工新增一律通用、信心 1；重建＝還原出廠設定；分段按鈕統一。全部已寫進 STATE §2。

推翻了什麼

• 第 2 棒「AI 建議原廠限定」靠能力點 is_platform——super_admin 帳號 break-glass 仍看得到；決策者改裁「先對所有人隱藏」。
• 我自己：承繼對應先做成「點了展開就寫資料」→ 決策者指出證據沿用本來就全部給、展開不必寫 → 改成只顯示；再被裁「不要分群不要收合，全部列出」。
• 我自己：控制項層刪除排除會連帶評估目標，原以為「逐顆標評估目標」就能清空，DEV 試跑發現藏在後面的多跳控制項層對應會重新冒出來，改寫控制項層不可用——結果在評估目標列寫出跨層列（本棒留下的阻斷 bug，STATE §3 第 1 項）。

教訓

• 動 UI 前先查現成的，記憶裡就有：分段按鈕（feedback_list_page_filter_baseline_my_tasks）、導航樹（feedback_fe_nav_tree_rewritten_per_page_reuse_first）兩條記憶都早寫了，我還是自刻 .cm-seg／.ao-seg 與第 8 棵樹，被決策者連續點名「到底為什麼」「這頁到底自己刻了多少東西」。
• 只靠 build 就回報＝把驗證丟給決策者：欄寬兩模式看不出差別、按鈕太大、間距擠、主軸被撐寬，都是決策者看了才發現。靜態頁截圖幾秒鐘就能看出來。
• 寫死色碼與自訂字型在淺色主題下會脫節：決策者用淺色主題（奶油底），token 會跟著切、寫死的不會。
• 雛形與實作要一致：雛形是「群組 → 控制項」兩層、群組顯示 A.5，實作卻顯示 ISO27001-A5，決策者「那做雛形幹嘛」。
• 「_obj.N」不是字母序：ISO A.5.1 [a]＝_obj.3，拿數字當字母會標錯；字母只能從文字取。
• 解析器的「有評估目標層就不退回控制項層」是所有寫入入口的共同陷阱：×、拖曳、新增、清空都踩過一次。
• 群組不能拿顯示代號當鍵：ISO 群組顯示代號被藏起來後是空字串，四個群組同一個鍵、點一個全選。
• 工作坊合回會讓 BE 起不來：CM-3097 合回 import 了未發版套件函式，venv 還是舊版；先查 venv 再重啟。

未驗證假設：所有 FE 改動沒有實際登入看過（本機無可用 auth-state）；「專案規劃進不去」原因未明，可能來自同日 FR-164 對總覽頁的大改。

派出／收回：本棒無派工、無開卡；CM-3097／3098 已由工作坊首腦驗收通過待確認並合回，本棒未做第二道檢查（決策者改要直接改頁面）。

做了什麼

• 接手盤點：「專案規劃進不去」決策者回報已好，結案。
• 跨層清空（CM-3100，修正待驗證）：根因在套件解析器——排除判定只比同一節點或控制項層排除，評估目標層的不可用擋不住多跳的控制項層退路，前一棒只好寫跨層排除列。套件 _is_excluded 加一條（排除了某控制項任一評估目標，該控制項的控制項層命中就不成立）；BE add_entry 一處把關：評估目標→控制項的直連展開成逐條評估目標，其他跨層 400 GRC_400189；FE clearCell 評估目標列改送同層。DEV 那 12 筆跨層列停用。這一修同時蓋掉詳情對話框確認／改狀態／標不可用的同一個洞。
• 證據刪除行為（FR-162.14，無卡）：決策者裁「只刪當下、不連帶其他專案、同專案多處讓使用者選」。BE 新增刪除前影響範圍端點、刪除帶 scope=this|project、沿用刪了寫 NOT_APPLICABLE（新 migration）、沿用候選排除、調整頁標 dismissed、下游標「來源已移除」。FE 新 JobEvidenceDeleteDialog.vue，抽屜原確認段移進去；五處沿用標籤帶 removed。

commits：套件 c792aa47；BE 25ba155c3（已被決策者 push）97cc679c1；FE cdbcb1d0 92b005b5。後三支未 push。

關鍵決策（決策者裁）：照同層逐條寫、不開例外；刪除只動本專案；沿用刪了＝本專案不適用、調整頁可加回；沿用是關聯不複製，來源刪除下游照常；job_evidences 不開 RLS。全部已寫進 STATE §2 與 design.md。

推翻了什麼

• 第 3 棒以為「逐條標評估目標不可用清不乾淨是筆數問題」，實際是解析器判定沒拿評估目標層排除去比控制項層節點；修一處判斷，同層寫法就清得乾淨。
• 我自己：先打算拿既有 USER_DELETED 當「不適用」不動 schema，DEV 實查當前輪有 3,738 筆歷史清理也是 USER_DELETED，會讓整輪沿用建議消失，改成新原因值 NOT_APPLICABLE。
• 我自己：一度建議 job_evidences 開 RLS 補強，決策者提醒影響面；查到背景／系統脈絡路徑十幾處，收回。
• design.md 原寫「upload_files 引用計數既有機制確保來源刪檔不影響」，實際沒有引用計數，是外鍵＋軟刪；已改寫。

教訓

• 開卡要用本 repo 的 scripts/notion_create_case.py：agent-workshop 那支預設寫進工作坊自己的任務清單（Case No #65、專案 Agent Workshop），母卡關聯也掛不上；而且預設 Not started 會被工作坊派走。本 repo 那支能在建立時帶 status，首腦直修的卡直接建成 修正待驗證。
• i18n JSON 用 json.dump 會把整檔重排（2 格縮排變 4 格，578 行 diff）；要用文字插入保留原格式。
• FE 匯入寫法照既有檔抄：BaseService 是具名匯出、API 是預設匯出，寫反 build 直接紅。
• 「刪除語意」先查歷史資料分布：同一個原因值被多種動作共用時，拿它當新語意的判準會把歷史全部算進去。

未驗證假設：所有畫面沒有實際登入看過；刪除與沿用排除只用行程內 dry-run（整段回滾）驗過資料層行為，HTTP 只驗到路由註冊（未登入回 401）。

派出／收回：本棒無派工；開 CM-3100 一張（首腦直修，直接建成 修正待驗證）。

追加（13:55，決策者令直接修）：誤建的 #65 卡移到 Notion 垃圾桶。修資安小縫 e55dd46b3：檔案下載的證據認領改成只認未刪的證據列（原本用通用查詢、已刪列也放行），補測試並做突變驗證（退回舊寫法 5 紅）；DEV 108 份只剩已刪證據的檔從此下載不到，查過沒有畫面或判定引用依賴它們。

追加（14:30，決策者令 push＋全部發版）：BE／FE 在我 push 前已由決策者推過，本棒 commit 全在遠端。套件四支 bump（oscal-v2 2.9.0、file-upload 1.3.8、compliance-audit 1.4.1、task-platform 1.4.1）commit 7e475c86 並 push；先試發 file-upload 驗認證，再發其餘三支，每支只推當版號的兩個檔（dist/ 有舊版殘留，用 --dist-dir 隔離，避免重推舊版被 Nexus 拒絕）；開包核對 oscal-v2 含 021～026 與解析器修正、compliance-audit 含 005。BE 9a996fd1d 還原 path、pin 對齊、poetry update 只點名四支；venv 四支無 editable，BE 用正式版重啟無錯。compliance-audit 1.4.1（FR-161.3）與 task-platform 1.4.1（FR-155）不是本 arc 的改動，因宿主早已依賴、且決策者令全部發，一併發。

追加（15:30，決策者令收尾：「測過了，四項文件全部寫掉」）：規格三頁（控制項關聯管理、證據沿用 hub、沿用調整頁）b186d3618，順手重產 db_schema.json（原檔停在 07-04、沒有 FR-162 的表）；使用手冊「跨框架對照與證據沿用使用指南」並掛技術支援站 04073fd75；決策分析 2026-10-26-fr162-same-level-mapping-and-evidence-delete-semantics.md；SUMMARY 2026-10-26-FR-162-SUMMARY.md。教訓：SVG wireframe 裡的錨點不會被 fix_anchor_ids.py 補 id，要從 build 出的 HTML 反查實際 id；json.dump 改 i18n 會整檔重排（本棒前段已記）。

追加（16:10，決策者令 Notion 全部 Done）：母卡 CM-3057 與 28 張子卡改 Done，以 GuidantAI 任務清單「母卡＝CM-3057」查詢複核 28/28。陷阱：母卡頁面的「子卡」反向欄位只列 25 張，漏了 CM-3097／3098／3100（後建、或建好後才 PATCH 母卡的），一定要用子卡的「母卡」欄位反查；agent-workshop 的 notion_case.py 的 DATASOURCE_ID 是工作坊清單，用它查 GuidantAI 卡會回 0。出貨基線決策者定發版前做。