FR-151 GRC 延伸 — 首腦 STATE（living，只描述此刻）

日期：2026-10-21（第 6 棒：⑨ 驗收、準備合回 main）　｜　branch：BE／FE／jedi 皆 feature/FR-139　｜　未 push　｜　LOG：FR-151-LOG.md　｜　母卡：CM-2914

公司要過 ISO 27001 或 CRA，稽核一堆沒過。老闆要在一頁看出「哪個部門幾條沒過、找哪位主管」。PM 定調補 GRC 的 G（責任）與 R（風險），C 平台本來就有。決策者 2026-10-19 結論：第一版先把 GRC 核心產出來，鎖定 Compliance／Cybersecurity 面向；供應商、財務等領域留接口慢慢加。

站 docs/features/FR-151-2610-grc-governance-risk-extension/，SA 式多頁：1-requirement/（01 背景、02 領域知識、03 使用情境）、2-analysis/（04 現況、05 決策紀錄、06 外部對照）、3-plan/（07 第一版、08 第二版含備註、10 總計畫）。PM 看 10 總計畫，決策者的結論在 10 置頂「結論」節。 舊單頁稿在 archive/。側欄分組靠 scripts/deliverables/render_index.py 的 GROUP_STAGE／GROUP_LABELS。改 md 後 python scripts/deliverables/render_index.py <資料夾> 再 commit。

• A1：RACI 對象＝專案 SSP 控制項實作（2026-10-19）。
• 第一版八題 A2～A5、B1、B2、C1、C2 全裁（2026-10-19），皆照首腦建議，裁示原文在 05。含：同意動 jedi-iam 套件加部門主管（B1）；負責部門住 SSP 不另開公司層預設表（B2，決策者理由：資源庫與 SSP 綁在一起、部門跟著 C）。
• 第一版範圍＝找頭兒最小版加 RACI 四格掛 SSP（推翻上一棒「不做 RACI」）。
• C 合規證據類不做：政策生命週期、意識訓練、三道防線（框架控制項已涵蓋／無框架要求）。
• 兩版：一找頭兒（G）、二風險總表（R）。沒有第三版。供應商清單、事件紀錄、KRI 水位線是總表之外的紀錄表或設定，不在計畫，留接口。
• 名詞：「風險登錄」統一改「風險總表」。
• 兩版合併為一版、約四週（2026-10-20）。D1：風險只存一張表——現有 oscal.ssp_risks 升格公司層風險總表（綁專案改可選），顧問只在總表填，SSP 頁籤「風險評估」改唯讀顯示關聯風險，CRA 匯出與評估目標照原路讀；不另立公司層表、不做「升級」。
• 風險關聯控制項存框架控制項編號（三個 CRA 專案同一條只勾一次），關聯專案由編號系統算出不用填（2026-10-20）。
• 熱圖不做（評分、等級門檻、五乘五等級對照圖要做）；接受簽核不做（狀態留「已接受」值）；專案風險升級刪除（2026-10-20）。
• RACI 表是通用掛點：對象類型欄給風險、政策文件、供應商等未來模組共用（2026-10-20）。
• 跳過雛形直接開卡，畫面風格跟既有頁一致（2026-10-20）。
• 文件結構 SA 式多頁、側欄分類。
• 第 4 棒（2026-10-20 手測後）新裁：
  • 專案總報告（final）也要補責任節與風險節 → 開 ⑩ CM-2924（已做）。
  • 刪風險要清 RACI 孤兒列 → ⑦ 已補 delete_subject。
  • 資源庫編輯頁也要能設負責部門與責任矩陣，與專案同一份資料 → 開 ⑪ CM-2925（已做）。決策者確認的概念：控制項綁部門就決定 A（部門主管）與 R（任務處理人）的預設，RACI 矩陣是看全表＋處理例外（改 R、設 C／I）。
  • 規劃頁要能批次設定負責部門（勾群組或個別控制項、可跨群組），且規劃頁與資源庫共用同一個對話框。
  • R 落到評估目標（第 3 案）：一條控制項多個評估目標各有處理人時，矩陣維持控制項層、預設 R 依負責條數排出代表顯示「Bob 等 N 人」；報告與 GRC 總覽列沒過項目時只取沒過那幾條評估目標的處理人；人工 R 優先。預設 R 不存表、不需 migration、不影響已手動設的 RACI。
  • 責任矩陣上兩顆批次鈕收成一顆「批次設定」選單（負責部門／R／C／I）。
  • 風險表單：Dialog 標題照全站表單寫法放大、沒關聯的欄位不並排（只留部門／A、衝擊可能性／對照圖兩組）、全欄 placeholder、必填要有文字訊息；寬度先加到 64rem，拆獨立頁先不做（決策者喊停）。
  • 風險總表要有分頁與排序，照既有 DataTable 模式（useTableQuery），不自刻。
  • 部門管理頁加租戶篩選；部門主管不可選到別租戶的帳號（bug，已修在 jedi-iam）。
  • 資源庫編輯頁（ModuleFrameTemplateEditView.vue 1,395 行）要重構，與專案規劃頁大量重疊——另開 FR，不在 FR-151。
• 第 5 棒（2026-10-20，決策者手測後連續裁示；全文在 05，這裡只列結論）：
  • A2 補裁：R／C／I 一律只存人，部門只是挑人的篩選；所有設 RACI 的畫面與後端統一。
  • A6：部門 RACI 預設（責任分工設定頁，全公司一份）；R 取值＝人工 → 評估目標處理人 → 部門預設 → 空。晚間改判：SSP 內不設 RACI，矩陣只是控制項頁籤的唯讀總覽；設定只在控制項表單或 Excel。
  • A7：R 自動補進沒指派的任務，已指派（含覆核者）一律不動。
  • D4：總表補欄位（對照 PM 的 GRC Overview Dashboard.xlsx）；算的欄位讀時算；Review Date＝風險自己的下次審查日（複查日），空值依等級帶週期、只填空。Excel「Open Issues」＝未結改善計畫，不是第二版的「事件」。
  • D5：風險新增／編輯改獨立頁；選部門即時帶 RACI 預覽；控制項四層過濾可跨框架。D6：處理計畫改關聯資源庫，可當場新增。
  • D7：GRC 總覽砍掉重練成主管簡報式儀表板（雛形 prototype/grc-dashboard.html）；風險快照與趨勢先不做。
  • D8：單筆風險現況報告做可列印頁，不做 popup、不做 Word；編輯頁「系統記錄」卡拿掉。
  • D9：風險總表欄位選擇器（預設 10 欄、29 欄可勾）。D10：SSP 現況 Excel 補負責部門欄、責任矩陣 sheet 可匯回；任務配置匯入不加 RACI。D11：風險總表 Excel 匯入（編號空白新增、有編號更新）。
  • 輪次頁責任矩陣只有兩列是對的：GRC測試專案的資源庫只勾兩條控制項。
  • 結案報告 Word 與頁面排版差異：決策者另開 session 處理（FR-145 範圍），已 commit e89bdb4ba（Word／PDF 改由程式依報告頁元件順序產生、單一新範本 closing_report_template.docx），首腦第 5 棒交接時代驗：closing report 四支測試 58 過、FR-151 207 過、無殘留引用、build 腳本資料檔斷言不涉舊範本。
  • ⚠️ 歷史歸屬錯位：舊範本兩份與 closing_report_docx_responsibility.py／_risks.py 四支的刪除落在首腦交接 commit 4c70ef1db，不在 e89bdb4ba——那個 session 先 git rm 進了 index，首腦 commit 時把整個 index 一起帶走。HEAD 內容正確、未 push，不改寫歷史；查這四支檔的去向要看 4c70ef1db。

• ✅ 2026-10-21 決策者裁（照首腦建議）：風險 Excel 匯出加「說明／受影響資產／備註」三欄（29→32）、三欄皆可匯入；專案頁「風險等級」只改名「剩餘風險等級」、不加固有等級欄。實作卡 CM-2965（Stage 1，sonnet／high）。SPEC risk-register 頁隨卡改。
• 其餘待裁見 §5.0 第 10 列（已全部裁完）。

顧問今天的風險評估做完就丟還是持續維護／客戶部門分工對得到框架群組嗎／老闆會自己開系統嗎／一家客戶同時幾個專案／客戶有沒有在管供應商、記事件。列在 01 待驗表與 10 待驗節。

任務總表（此刻）

下一步（每項單獨等令）

決策者 2026-10-21 宣告準備整理後把 feature/FR-139 合回 main。這條 branch 從 2026-10-14（merge-base 24cc72972）起帶了 FR-135／138～151 共十餘個 FR，收尾是跨 FR 的事；FR-151 的部分併在下面「合回 main 前總清單」裡，不再單獨列。

5.0 合回 main 前總清單 → 已拆成 FR-154

整條 feature/FR-139 合回 main 的收尾（套件發版、還原 pin、出貨基線、SPEC 補齊、收尾修正、權限矩陣、arc-review、進版 1.27.0）已自本節拆出為獨立 arc FR-154：docs/features/FR-154-2610-fr139-branch-merge-closeout/handoff/FR-154-STATE.md，Notion 母卡 CM-2975（子卡 CM-2965～2974）。本節不再更新。FR-151 自己剩下的：21 張子卡等決策者複測、母卡 CM-2914 等收 Done。

5.1 決策者手測清單（DEV，blsadmin；先重啟 BE）

DEV 部門 99 已改名「產品研發部」。CMMC 專案 AC.L1-b.1.i 與 GRC測試專案兩條控制項上有決策者自己設的 C／I 例外，首腦沒動。

• 責任（G）：部門管理設主管、租戶篩選、子租戶主管下拉；責任分工設定頁設 R／C／I 預設（部門當篩選、只存人）、Excel 匯出匯入；規劃頁批次設定負責部門；控制項表單 RACI 四格（改了標「個別指定」、可還原）；控制項頁籤「責任矩陣」唯讀總覽；資源庫同樣能設、與專案同一份；R 有人時沒指派的任務自動被指派、已有人的不動；SSP 現況 Excel 主表「負責部門」欄與「責任矩陣」sheet 改完匯回。
• 風險（R）：風險總表欄位選擇器、跳轉篩選膠囊；新增／編輯獨立頁（選部門即時 RACI 預覽、四層選控制項可整群組／整版本加入、分組顯示、處理計畫綁資源庫並可當場新增、頁尾儲存、「現況」卡）；現況報告頁與列印預覽；風險 Excel 匯出與匯入（編號空白新增、有編號更新、壞資料標問題）；專案規劃頁 SSP「風險評估」頁籤不分框架都顯示。
• 儀表板：GRC 總覽四層、熱圖固有／剩餘切換與點格跳轉、匯出簡報 PDF、部門主管只看自己子樹。
• 要先走完一輪稽核才看得到：自動建風險與待納入、合規狀態、未結改善計畫、儀表板三張待決卡與專案通過率、現況報告第 3／4 段、階段與總報告的責任節與風險節。

• 決策者的提問不是裁示；他說「寫進去」才動文件、build、commit。
• 決策者連問時只回答，不改檔。他要先理解全部再裁。
• 市面平台對照出的缺口不能直接變功能，先問「我們的框架控制項機制是否已涵蓋」。
• 大需求討論稿必含使用情境（memory feedback_big_feature_discussion_needs_use_case_and_verify_pm_claims）。
• 首腦不開 subagent。
• 驗收用 API 實打時：登入 POST /api/1.0/login body 是 {"username","password"}（不是 login_name），帳號 TEST_ADMIN_USERNAME／TEST_PASSWORD 在 test repo .env.e2e；控制樹回應含控制字元，python 解析用 json.loads(..., strict=False)。RACI 寫格 body 要包 {"cells":[...]}。驗完把測試資料還原（RACI 列、部門主管、控制項部門歸零）。
• 監控卡片狀態用 Monitor 每 10 分鐘 python scripts/notion_case.py get CM-xxxx | grep 狀態，只在「修正待驗證」時叫醒；「Not started」是還沒人接手不是回報。zsh 不吃 ${!v} 間接展開。
• 同一工作樹會有平行 runner（第 4 棒實際撞到 ⑪ runner 在卡片還是 Not started 時就動工）：首腦自己改檔前先 git status，看到不是自己的改動就別碰那支檔；commit 一律顯式 git add <檔>，commit 前 git diff --cached --stat 核對。卡片狀態不可信，以工作樹為準。
• DEV 資料會被決策者同時手測：測試前先記下原狀，測後只還原自己寫的那幾筆；看到不是自己寫的資料不動、回報。
• 首腦今天直接改了很多 code（決策者手測回饋說「你就直接修正」）——那是決策者當次授權，不是常態；沒有這句話時照 §7 開卡派工。
• 前端分頁一律 useTableQuery＋lazy DataTable（照機關單位管理頁）；Dialog 標題用 #header 放 <h2>；必填用 required-mark＋p-error 文字訊息；沒關聯的欄位不並排。
• 新增 GRC 錯誤碼要登記 test/fixtures_frozen_error_codes.py 並同步 FE error-code.json 兩語系，否則守衛紅。
• 開卡指路徑前先查：⑭⑮ 卡寫「動 jedi-oscal-v2」錯（風險 model 在主專案）、⑱ 寫「⑥ 已有分數區間篩選」錯、⑮ 寫讀 compliance.poams 錯（舊表、0 筆、無人寫入，現行是 oscal.poam_items）。都是 runner 查實後糾正。指名檔案、表、既有功能前 grep 一次。
• 新頁一律預設要一支路由 seed（前端守衛比對 ui_routes 登記表，不登記誰都進不去）；⑭⑲ 兩次都漏寫「需 migration」。
• 列手測項前先看讀取路徑：「匯出有那張 sheet」不等於「匯入會讀」（⑤ 那條匯回其實驗不過，㉑ 才補）。FR 新增欄位時主動盤「哪些 Excel 匯入匯出要跟上」。
• 工作樹被平行卡弄髒時，驗收測試在乾淨 worktree 跑：git worktree add <scratchpad>/wt HEAD，連 .env，用主 repo 的 .venv/bin/python -m pytest，跑完 git worktree remove --force ＋ prune。
• zsh 陷阱："$SSP:AC..." 的 :A 會被當修飾符展開成路徑，打出 GOV_400003 假錯誤；變數後接冒號一律寫 ${SSP}:。
• 決策者另開 session 共用同一支 8000 BE 時，首腦不重啟；要重啟先問。
• 🔴 commit 前先看 index 有沒有別人 staged 的東西：git add <檔> 只是加，不會把別人已 staged 的改動排除；git commit 帶走整個 index。平行 session 共用工作樹時，commit 前 git diff --cached --stat 逐行看，有不是自己的就先 git restore --staged <檔>（不動工作樹內容），或改用 git commit <檔...> 只提交指定路徑。第 5 棒交接 commit 因此帶走了結案報告 session 的四支刪除。
• seed migration 的自我驗證要容許「已經是最終態」：新裝客戶的出貨 seed 是基線庫的最終態，之後 migrate 才補套各支 seed；斷言寫死「當下中間態」（某選單還沒出現、還在舊群組）在 DEV 能過、新裝必炸。重產基線後一律在乾淨 postgres:16 跑 init＋兩輪 migrate 才算驗完（FR-144／148 兩支即此坑）。
• 決策者要「參考業界」時要真的查完再畫（Eramba／CISO Assistant／ServiceNow IRM／Drata／Vanta 的對照已寫在 05 D7），不能拿 PM 的 Excel 頂。

接 Notion CM-xxxx（FR-151 ⑦ <卡名>，母卡 CM-2914）。
前置：CM-yyyy 卡尾已有首腦「✅ 驗收通過」註記。
工作目錄 ~/Projects/Billows/Audit-Manager/compliance-manager-be；FE 在 ~/Projects/Billows/Audit-Manager/compliance-manager-fe。兩 repo 都在 feature/FR-139，不切 branch。
先讀卡，卡上「怎麼做／在哪裡／手測／紀律」已自足，照卡做；只動 DEV。
<本卡關鍵提醒一到三句>
注意：pyproject.toml 的 jedi-iam path dependency 改動不要 stage；平行卡只 git add 自己的檔。
<若有主線 migration：回寫時明講「出貨基線待重產」（決策者已裁：等 FR 結束一起重產，不要自己動）。>
做完：各 repo 顯式 git add 檔名 commit、回寫本卡白話補充（commit hash、手測清單、打折處）、狀態改「修正待驗證」。push 等令。
model opus／effort high。（⑧ 用 sonnet）

spec 與建卡結果：handoff/notion-cards-bugs-from-fr152(.json|-made.json)。