↑ 需求首頁 ⌂ 需求中心

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

§1

2026-10-19 首腦第 1 棒：會議記錄、討論稿 v1～v4

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

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 棒自己前段「第三版六塊」「合規證據管理」「第三版風險來源」三次分類，皆被決策者追問拆穿。
  • 教訓：市面對照只能列缺口；決策者問「上課簽到放哪」才發現控制項證據機制已涵蓋。給建議前先把名詞講到決策者能自己複述。
§3

2026-10-19 首腦第 3 棒：第一版八題裁定、寫進 05／07／10

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

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 是不是同一件事」時，答案常是「是，所以合併」，不要急著多一張表。
§5

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。
§6

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 當初裁示的紅利，後續類似需求先想能不能也這樣做。
§7

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）。㉑㉒ 兩棒都要人名解析，卡上寫「先進的抽、後進的接」。
§8

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」。
§9

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 的功能」正是該另開母卡的訊號。