# FR-151 LOG（append-only，每棒一 block）

## 2026-10-19 首腦第 1 棒：會議記錄、討論稿 v1～v4
- 錄音轉錄成 meeting-2026-10-19.md；單頁 discussion.md v1～v4（`8eb5fbc67`～`ca22fbf52`）：三層十二卡、D1～D14。
- STATE 寫「討論口頭收斂為最小版、不做 RACI」（`56b62e453`）。
- 教訓：決策者連問時被當成裁示；討論沒收斂就改文件、build、commit，決策者兩度點名浪費。

## 2026-10-19 首腦第 2 棒：重來討論、重組文件、定 G／R 兩版
- 推翻第 1 棒「不做 RACI」：那是決策者不理解時的追問，RACI 要做，對象 SSP 控制項實作（A1 唯一有日期的裁示）。
- 用鼎泰科技五幕情境與一張表單逐題講到決策者理解 RACI、I 是誰、按框架群組整批設、風險總表＝老闆在意的事情總表、KRI＝水位線。
- 文件重寫為 SA 式多頁站（`370148a7f`）：1-requirement／2-analysis／3-plan／archive，render_index 加四個 group；05 決策紀錄拆「建議」與「裁示（日期）」。
- 刪 C 合規證據類（`c04902d3b`）：政策生命週期、意識訓練、三道防線。查 DEV 實證 CMMC AT.L2-3.2.x、CRA.II.5 是框架控制項，證據機制已涵蓋；三道防線無框架要求；三項全來自 06 市面對照非 PM。
- 第三版拿掉（`a305fbc0b`）：供應商／事件／KRI 併入 08 備註，決策者兩度點名。
- 結論寫進 10 置頂（本棒末 commit）：鎖定 Compliance／Cybersecurity 核心，其他領域留接口；「登錄」統一改「總表」；06 補 ServiceNow IRM 對照結論；STATE 移 handoff/，建本 LOG。
- memory 新增 `feedback_big_feature_discussion_needs_use_case_and_verify_pm_claims`。
- 推翻了什麼：第 1 棒 STATE「不做 RACI」；第 2 棒自己前段「第三版六塊」「合規證據管理」「第三版風險來源」三次分類，皆被決策者追問拆穿。
- 教訓：市面對照只能列缺口；決策者問「上課簽到放哪」才發現控制項證據機制已涵蓋。給建議前先把名詞講到決策者能自己複述。

## 2026-10-19 首腦第 3 棒：第一版八題裁定、寫進 05／07／10
- 接手後先用白話複述 §0 與 10 結論、列八題建議，等令。
- 決策者逐題追問 A3「格子」「系統先算」三次才懂：講到「依據只有部門主管欄與控制項負責部門兩筆人填資料，不是風險設定」才通。裁丙，其餘七題「都照你建議」。
- 決策者問「會不會被綁死在 SSP」：首腦一度提議公司層「控制項預設部門表」接口，決策者以「資源庫本來就每家公司設定、資源庫與 SSP 綁在一起」駁回，B2 維持存 SSP、理由寫進裁示。推翻了首腦自己的接口提案。
- 教訓：解釋「系統算」要先說「算的依據是哪兩筆人填的資料」，不要先講選項；決策者問「會不會綁死」時先答「GRC 本來就是設定好關聯」再談層級，不要急著加表。

## 2026-10-20 首腦第 3 棒（續）：R 線裁示、兩版合併、G 線開卡
- 決策者裁：兩版合併一版；D1 風險只存一張表（`ssp_risks` 升格公司層、綁專案可選、SSP 頁籤唯讀）；關聯控制項存框架編號、關聯專案系統算；熱圖不做但矩陣要素（每級定義、公式、門檻、對照圖）要；簽核不做留狀態值；升級刪除；RACI 表通用掛點。08 表單三次改到對齊（`72882c040`、`97d25676d`、`d6600ec74`）。
- 決策者「這版雛形先不過，直接開卡，風格跟既有一致」。首腦盤點座標（DEV schema、jedi-iam org_unit 四層、oscal-v2 IR model、closing_report、export_excel、FE 頁與選單 seed 先例）後開 G 線六張卡 CM-2914～2919，spec `handoff/notion-cards-G1.json`。
- 推翻了什麼：首腦自己「兩表並存＋升級」（D1 舊建議）、「B2 留公司層預設部門表接口」、「⑧熱圖整張卡」三個提案都被決策者以「一份真相／資源庫與 SSP 綁在一起／必要性」駁回。
- 教訓：講「系統算」要先說依據是哪兩筆人填的資料；決策者問「A 跟 B 是不是同一件事」時，答案常是「是，所以合併」，不要急著多一張表。

## 2026-10-20 首腦第 3 棒（續）：①②③ 驗收、④⑤⑥ 派工、交接
- ①②③ 依序回報，首腦親驗（DB、commit、測試、API 實打、border-left）全部通過，卡尾與母卡注記。②③ 的 runner 都有提待裁點：② 同資源庫專案共用部門設定（首腦裁：符合 B2，不擋）；③ 順手改出貨安裝腳本 schema 清單（首腦看 diff 接受）。
- 決策者早上裁：出貨基線等 FR 結束一起重產；派 ④⑤⑥。
- 教訓：Monitor 用 zsh 語法；守衛測試那條 `grc.review-step-template.manage` 紅是 FR-148 既有，每棒都會看到，別誤判。登入 body 是 username。

## 2026-10-20 首腦第 4 棒：④～⑧ 驗收、開 ⑨⑩⑪、決策者手測回饋直接修、R 落到評估目標
- **驗收**：⑤ 退回一次（Excel 第二張 sheet locale 傳 None→英文），`c1d36b09e` 修好；⑧ 退回一次（commit 帶進平行卡 ④ 未追蹤檔的 import，HEAD 單獨會 ImportError），`e7cc1b205` 修好；④⑥⑦⑩⑪ 一次通過。每張都開檔、跑測試＋突變、DEV API 實打、headless 截圖，測後還原。
- **開卡**：⑨ CM-2923 SPEC、⑩ CM-2924 總報告補責任／風險節（決策者裁「要補」）、⑪ CM-2925 資源庫編輯頁負責部門／責任矩陣（決策者：資料本來就掛範本 SSP，入口要開在資源庫）。
- **決策者手測後首腦直接改**（當次授權「你就直接修正」）：風險表單改版（`1c01cc40`、`fdfac53e`）；風險總表後端分頁排序（BE `59a40079d`／FE `c80806a1`，等級篩選換成分數區間，`score_range_of` 與 `level_of` 互為反函數）；部門主管跨租戶 bug（jedi-iam `ebafb338`，選單蓋掉呼叫端租戶＋存檔只驗看得到）＋部門頁租戶篩選（`6205dec1`）；批次設定負責部門（BE `d5d5e39af`／FE `cd11ec61`，批次端點加 control_ids，GRC_400182）；R 落到評估目標（BE `d24e20613`／FE `923b1ad1`）；資源庫補掛共用對話框（`331e95a4`）；兩顆批次鈕收成選單（`cc42c643`）。
- **推翻了什麼**：
  - 首腦寫 ⑪ 卡時判「寫入守門已支援範本 SSP，只需改讀取」——錯。沒開過專案的範本寫入也 404（resolver 先反查專案就失敗），②③ 驗收沒抓到是因 DEV 兩支範本剛好都開過專案。⑪ runner 一起修。
  - 首腦的共用批次對話框原本讀 control-tree，對純範本 404。⑪ runner 的 reviewer 已擋過「整個放寬讀取守門」（新模式專案的 living SSP 就是範本，放寬等於非成員看得到專案任務），所以不放寬，改讀 RACI 矩陣。
  - 第 3 棒以為「控制項的 R＝一個人」；實際一條控制項多個評估目標、各有處理人，預設 R 會列多人。決策者裁第 3 案。
- **教訓**：
  - 平行 runner 在卡片還是 Not started 時就動工了，工作樹裡有它的未提交改動——首腦改檔前 `git status` 看清楚、只 add 自己的檔，卡片狀態不可信。
  - 派工後在卡尾補要求（掛共用對話框）runner 會漏；要補的事寫進派工 prompt，事後補只能自己做或退回。
  - 新錯誤碼要登記 frozen 基準表，守衛會抓。
  - 「預設值不存、讀時算」的設計讓第 3 案這種行為調整不需要 migration、不影響既有手動資料——這是 A5／A3 當初裁示的紅利，後續類似需求先想能不能也這樣做。

## 2026-10-20 首腦第 5 棒：手測表單、A6 部門 RACI 預設裁定、開 ⑫
- 接手盤點後決策者要手測表單，給 A 前置／B 不需稽核／C 需稽核三段 26 條；決策者問「哪裡設 RACI」，查 FE 給三個入口（規劃頁 SSP 頁籤、資源庫編輯頁頁籤、風險表單區塊）。
- ⑪ runner 卡尾兩段：矩陣部門格可點（FE `84f199b4`，未實點）→ 決策者說先不驗；設計提案「部門 RACI 預設＋獨立設定頁」→ 首腦建議採用但 R 順序改處理人優先、全公司一份、進 FR-151；決策者再問「矩陣頁籤還需要嗎」→ 首腦答需要但降為總覽＋例外，控制項畫面逐項只選部門；決策者裁「照你說的，進 ⑫，寫進去開卡」。
- 寫 05 A6、10 加 ⑩⑪⑫ 列、STATE §2／§5、開卡 CM-2926（spec `handoff/notion-cards-G3.json`）。
- **推翻了什麼**：runner 提案「部門預設 R 優先於任務處理人」——與同日早上「R 落到評估目標處理人」裁示衝突，處理人是真實分工，部門預設墊底。
- **教訓**：runner 在卡尾寫設計提案是好事（決策者疑問被記下來），但「要首腦裁的三點」裡 runner 自己的建議不等於首腦建議，要逐點重判。
- ⑫ CM-2926 驗收通過（BE `89101e858`／FE `c697b489`）：首腦實打取值順序、守門、例外回預設、突變測試、headless 實點新頁與矩陣頁籤，測後還原。⑨ 可派。
- 決策者問「這樣設計對嗎、RACI 是否該綁模組」：首腦答兩層（對象 RACI 綁模組、部門預設是公司層）設計正確，名字易誤導、預設不分模組是反悔條件。
- 決策者手測 ⑫ 後：「不同專案 C／I 不同」在各自矩陣改例外即可；「RACI 有 R 但任務未指派」是單向同步——裁 A7 乙「R 回填沒指派的任務，已指派不動」，開 ⑬ CM-2927（spec `handoff/notion-cards-G4.json`）。首腦原建議丙（建議值要人確認），決策者以省 PM 工選乙。
- 教訓：⑫ 卡寫「R 預帶任務處理人」時沒把「反向」講清楚，決策者設完 R 看到任務未指派才發現是單向；設計「系統算」的欄位時要同時講「它會不會寫回來源」。
- ⑬ CM-2927 驗收通過（BE `3d4e7a80f`）：runner 沒實打，首腦補打三觸發點與「已指派不動」，測後刪 8 筆測試指派。
- 決策者授權首腦直接修兩處 FE：例外標籤「個別指定」（`eb11c415`）、專案端風險評估頁籤不綁 CRA（`8b4e5c3d`，⑥ 升格總表後該頁籤是唯讀關聯清單，不該看資源庫表單設定）。
- 決策者問「受影響資產／依據標準」來源：兩欄只有 CRA 資源庫表單能填，總表表單漏了，⑥ 升格時沒補。待決策者定。
- **教訓**：zsh 裡 `"$SSP:AC..."` 的 `:A` 會被當修飾符展開成絕對路徑，打出 GOV_400003 假錯誤。驗收實打時變數後接冒號一律寫 `${SSP}:`。第 4 棒與本棒 14:38 那筆 400 都是這個。
- 決策者裁 RACI 格子只存人（推翻 A2 的 C／I 存部門），首腦直接修 BE `b55945235`／FE `1600677d`。決策者交代「不用做太多驗證、手測會持續，遵照開發規範就好」——之後首腦直修只跑守衛與既有測試、API 抽打一兩下，不跑瀏覽器。
- 決策者手測第二輪七項回饋＋PM Excel 對照。首腦核 Excel A～R 欄：缺八項（Record ID／Category／Compliance Status／Open Issues／Aging／Severity／Days to Review／Review Alert），兩欄表單漏放。查實：改善計畫表無嚴重度欄、DEV 到期日全空、風險自己有「下次審查日」（⑥ 既有、意為複查日）→ 建議 Review Date 對它、Issue Severity 取稽核判定等級、空審查日依等級帶週期；決策者同意。講清「下次審查日」是風險複查不是改善到期，兩者並存。
- 裁 D4／D5／D6、A6 改判（SSP 內矩陣只看）、風險表單改獨立頁（推翻第 4 棒喊停）。開 ⑭～⑰（`handoff/notion-cards-G5.json`）：按「同一個表單／同一條資料鏈／獨立功能／反向調整」切四張。
- 推翻了什麼：A6「矩陣頁籤可改例外」（改為只看）；第 4 棒「拆獨立頁先不做」；⑫ 把控制項表單的可編輯 RACI 區塊拿掉（⑰ 放回，因為它變成唯一設定入口）。
- 教訓：PM 給的範例表要先看哪些欄是公式、哪些是人填、資料是不是假的，再對我們的欄位；「Issue」「事件」「稽核發現」三個詞層次不同，先講清楚再拆卡。
- ⑯ CM-2930 驗收通過（BE `258a5b7ea`／FE `39c11174`）：首腦補 build、匯出實打、清空規則突變；決策者交代驗證從輕，匯入畫面留給手測。
- ⑰ CM-2931 驗收通過（FE `813f33b0`）：開檔核對掛點、刪檔無殘留、build、守衛；畫面留給決策者手測。
- ⑭ CM-2928 驗收通過（BE `c3ff3bab0`＋`89d10c5d9`／FE `efac3f17`）；接受 runner 兩處偏離（編輯頁守 read 唯讀、依據標準不加白名單）。更正首腦開卡時的錯誤：風險 model 在主專案，⑭⑮ 不需發 jedi-oscal-v2。順手補 ⑫ seed 的 manifest 登記。
- 教訓：開卡寫「動哪個套件」前要 grep 該 entity 實際在哪，⑭⑮ 兩張都寫錯了套件異動，幸好 runner 查實後沒照做。
- ⑮ CM-2929 驗收通過（BE `d59134870`／FE `88204e5f`）：接受 runner 改走 poam_items（卡上寫的 compliance.poams 是舊表）、不動套件、嚴重度無「嚴重」級。⑭～⑰ 全部驗收完，⑨ 可派。
- 教訓：開卡指路徑前要查「這張表現在還有沒有人寫」（compliance.poams 0 筆、無寫入者）；memory feedback_card_check_capability_index_before_prescribing_path 再踩一次。
- 決策者要 GRC 總覽砍掉重練、要專業有質感、熱圖必有。首腦先偷懶只查一家被點名，補查五家（Eramba／CISO Assistant／ServiceNow IRM／Drata／Vanta）；雛形第一版平板一排數字卡，第二版改主管簡報式（態勢儀表＋三件待決→熱圖與合規→佇列與部門→複查排程），決策者問「做得到嗎」→ 逐塊對資料全可（唯趨勢要快照）→ 裁「快照與上月比較先不用」。裁 D7、開 ⑱ CM-2932（`handoff/notion-cards-G6.json`）。
- 教訓：決策者說「參考業界」就要真的查完再畫，不能拿 Excel 頂；儀表板第一版「每塊等重」是外行相，主管要的是「態勢→決定→證據」的順序。
- 決策者手測 ⑭⑮：頁尾要儲存（直修兩筆）、算出來的欄位編輯頁要有（直修加「現況」卡）、再問「要不要 popup 把所有資訊整理一頁」→ 首腦建議可列印頁不做 popup、Word 先不做，決策者裁。寫 D8、開 ⑲ CM-2933（`handoff/notion-cards-G7.json`）。
- 教訓：⑮ 卡寫「表單加分類與編號」太字面，算出來的欄位本該一起上編輯頁；開卡時要想「這個數字使用者在哪裡做決定」，不是只想「列表有沒有」。
- 決策者問「系統記錄是什麼」→ 答四樣（關聯專案／來源／建立／歷程）→ 裁「報告會有就不用」→ 併進 ⑲：拿掉該卡、關聯專案搬處置段資源庫下方。卡已 In progress 才 append，決策者說親自請 runner 補；驗收時對卡尾追加段。
- ⑱ CM-2932 驗收通過（BE `fe7f31b98`／FE `0d7d42da`）：乾淨 worktree 測試、DEV 端點實打；接受 runner 四處判斷（母數扣已關閉、補跳轉篩選、剩餘落格法、件數去重）。首腦卡上「⑥ 已有 score_range 篩選」寫錯，runner 查實後補做。
- 教訓：工作樹被平行卡弄髒時，驗收測試要在 `git worktree add <HEAD>` 的乾淨樹跑，不然紅綠分不清是誰的。
- ⑲ CM-2933 驗收通過（BE `5f31f1b41`／FE `a5410957`＋`d4a08b1e`）；接受 runner 多一支 seed（內頁路由）與一支預覽端點。⑱ 驗收後決策者手測又追加兩筆（BE `8c93e63e0`／FE `658245ed`），已註記卡上。**十八張實作卡全部驗收完，只剩 ⑨ SPEC。**
- 教訓：我開卡寫「無 migration」漏想「新內頁要登記路由表」——⑭⑲ 兩次都是 runner 補的；之後任何新頁一律預設要一支路由 seed。
- 決策者問風險總表「是不是沒把所有欄位印出來、是你設計的嗎」→ 首腦答是刻意切（列表掃描／Excel 分析），但領域／分類變小字、固有分數要點進去兩點切得不好 → 給甲維持／乙選擇器／丙加到 14 欄，建議乙 → 裁乙。寫 D9、開 ⑳ CM-2934（`handoff/notion-cards-G8.json`）。
- 教訓：列表欄位這種「誰看什麼」的取捨，不要替三種角色一次決定；專案沒有欄位選擇器是個缺口，這次順手補成可重用元件。
- 決策者問三件：輪次頁矩陣不是全控制項（查實：該專案資源庫只勾兩條，矩陣正確）；SSP 匯入沒負責部門欄（對）；任務配置匯入要不要 RACI（建議不加，責任掛控制項、任務一列多筆會打架）。裁開 ㉑ CM-2935（`handoff/notion-cards-G9.json`）補前兩項。
- 更正：首腦早上手測單 B10「改一格 R 再匯回」是錯的，⑤ 只做匯出；沒查清楚就列進測試單。
- 教訓：「匯出有 sheet」不等於「匯入會讀」，列手測前要看讀取路徑；凡 FR 新增的欄位，要主動盤「哪些既有 Excel 匯入匯出要跟上」，不等決策者發現。
- ⑳ CM-2934 驗收通過（FE `01f12894`）；決策者自行手測。⑯⑱ 各一筆手測追加已註記。決策者說結案報告 Word 與頁面排版差異另開 session 處理，首腦不碰（FR-145 範圍）。
- 決策者要風險總表 Excel 匯入（匯出格式、編號自動）。首腦補「有編號＝更新」（匯出檔帶編號、改完匯回是自然用法）與三類欄位處理，裁 D11、開 ㉒ CM-2936（`handoff/notion-cards-G10.json`）。㉑㉒ 兩棒都要人名解析，卡上寫「先進的抽、後進的接」。

## 2026-10-20 首腦第 5 棒交接（收束；上面各行是本棒逐筆紀錄）
- **範圍**：接手時 ⑨ 以外十張已驗；本棒決策者手測兩輪＋連續追問，裁 A2 補裁、A6（含晚間改判）、A7、D4～D11，開並驗收 ⑫～㉒ 十一張（CM-2926～2936）。**FR-151 二十一張實作卡全部首腦驗收，只剩 ⑨ SPEC 未派。**
- **首腦直修（決策者當次授權）**：例外標籤「個別指定」FE `eb11c415`；專案端風險評估頁籤不綁 CRA `8b4e5c3d`；RACI 格子只收人 BE `b55945235`／FE `1600677d`；風險編輯頁頁尾儲存 `54c21aef`＋`625de2da`、「現況」卡 `f069bd84`、關聯控制項分組與整批加入 `2f2976a7`；manifest 補登 ⑫ seed（隨 docs commit）。
- **推翻了什麼**：A2「C／I 存部門」→ 一律只存人；A6「矩陣可改例外」→ SSP 內只看、設定回控制項表單（⑫ 拿掉的可編輯 RACI 區塊由 ⑰ 放回）；第 4 棒「風險表單不拆獨立頁」→ D5 拆；runner 提案「部門預設 R 優先於處理人」→ 處理人優先；首腦自己「只查一家就拿 Excel 頂」被點名後補查五家。
- **待裁兩題**（STATE §3）：風險 Excel 匯出要不要加說明／受影響資產／備註三欄；專案頁風險等級欄名。
- **環境**：8000 BE 是決策者另一 session（結案報告 Word，FR-145）也在用的行程，㉑㉒ 新端點要重啟後才有，首腦沒重啟。工作樹裡 `app/closing_report/*`、`app/oscal/templates/closing/*` 的未提交改動屬那個 session。
- **教訓**（已寫進 STATE §6）：開卡指名檔案／表／既有功能前 grep；新頁預設要路由 seed；列手測前看讀取路徑；平行卡弄髒工作樹時在乾淨 worktree 驗；zsh `${VAR}:`；共用 BE 不擅自重啟；「參考業界」要真查。
- **交接後補記（同日 22:4x）**：決策者說「剩下那一項也好了」——查實不是 ⑨（仍 Not started、無 SPEC commit），是結案報告 Word session 的 `e89bdb4ba`。首腦代驗通過（closing report 測試 58、FR-151 207、無殘留引用）。**發現首腦交接 commit `4c70ef1db` 把那個 session 已 `git rm` 的四支舊檔刪除一起帶走**：`git add` 指定路徑不會排除別人已 staged 的項目。HEAD 內容正確、未 push，不改寫歷史，STATE §2 註明歸屬錯位；§6 補「commit 前看 index、用 `git commit <檔>` 或先 restore --staged」。

## 2026-10-21 首腦第 6 棒：⑨ 補範圍、驗收，盤點合回 main
- ⑨ CM-2923 卡尾 append「追加範圍」（⑩～㉒ 每張寫進哪頁、被推翻的規則清單、待裁題照現況寫）；runner 交 `01a30338c`（四頁新頁＋九頁補節＋手冊＋07 頁一處）。首腦抽查 nav、沿革 grep、截圖、兩處「以程式為準」偏離（匯入只收說明／備註兩自加欄、部門預設每租戶一份）皆成立；決策者確認後改 Done。**FR-151 二十二張子卡全部完成**。
- 推翻：05 D11「說明／受影響資產／備註三欄可寫」與程式不符（實作只收兩欄、受影響資產不收），併入 §3 待裁第一題，不改 05。
- 決策者宣告準備合回 main。首腦唯讀盤點整條 `feature/FR-139`（merge-base `24cc72972`，BE 694 commits、十餘個 FR），結果寫進 STATE §5.0：六支套件待發版＋還原 pin、53 支 migration 未進出貨基線（守衛 `test_host_capabilities_are_seeded` 紅）、STG／POC 全缺屬正常、SPEC 缺 FR-143／147／148、八張母卡未收、FR-149.3 實作卡未派、arc-review 未跑、進版未做。
- 教訓：總驗收 STATE 停在 10-17、只管 FR-139～147；branch 上後來的 FR 沒人彙總收尾清單——長 branch 收口要以 git（merge-base、manifest、lock、套件 version-bump commit）重新盤點，不能拼各 FR 的 STATE。
- **同棒續：決策者令「先做 1-3」**：① 六支 jedi 套件 bump、相依下限修正、publish Nexus（jedi `56a2f0de` detection 守衛放寬、`bdd5b90c` 進版）；② BE 還原 pin `7bc35752c`；③ 出貨基線重產 `8f7cc9bc5`（188 備份 `guidant_ai_baseline_20261021_0022_before_FR139-151.dump`，補套 38 支）。乾淨庫重演抓到三個坑並修：04 產生器漏 `is_menu`、FR-144 與 FR-148 seed 斷言寫死中間態。
- 教訓：重產基線的「驗」不能只看 diff 與 stamp gate——那兩關都過了，新裝客戶照樣 migrate 失敗。乾淨庫 init＋migrate 實跑是唯一抓得到「出貨 seed 已是最終態」這類順序坑的方法。
- **同棒續：FR-149.3 派出並驗收**（CM-2903 → `b6e835785`，新檔 `ssp_template_docx_parties.py`，11 測試綠、突變驗過；runner 揭露未重啟 8000 故未對真實資源庫匯出，留決策者手測）。首腦先確認「需求仍成立」（範本三段亞航字仍在、母卡無改判）再派，而非只確認「沒人做」。
- **同棒續：合回 main 四題全裁（照首腦建議）**：風險 Excel 加三欄且三欄可匯入、「風險等級」只改名；FK 索引這版補；FR-147 空格語意不統一只寫明；FR-138 #69 併進版、#71 下版。
- **開十張收尾卡 CM-2965～2974**（spec `handoff/notion-cards-merge-prep.json`）：2965 風險三欄＋欄名、2966 FK 索引 migration、2967 權限矩陣重產、2968～2972 五個 FR 的 SPEC、2973 #69、2974 arc-review（Stage 2）。每張帶母卡／Stage／Model／Effort 四欄。
- 教訓：**用 agent-workshop 的 `notion_create_case.py` 建卡會建到工作坊自己的任務庫**（DATASOURCE_ID 不同、卡號不是 CM-、專案欄預設 Agent Workshop）。先建錯十張已 archive，改用其 spec 格式配 BE `notion_case.py` 的 DATASOURCE_ID 重建。BE 自己那支不支援四欄，開卡前要先補一支。
- 教訓：開十張跨六個 FR 的卡，探脈（每張的檔案行號、design 節、FE 元件、既有 SPEC 落點）佔了大半時間；決策者問「開這麼久」。下次先回報「要查 N 處、預估多久」再動，或先出一張、其餘分批。
- 補開母卡 **CM-2975**「feature/FR-139 合回 main 收尾」，十張子卡母卡欄改指它（原本散掛六張 FR 母卡，決策者點出）。教訓：工作坊是「選母卡派」，一批要一起派的卡就要同一張母卡，不能照功能歸屬散掛；「這不是哪個 FR 的功能」正是該另開母卡的訊號。