本卡屬 FR-132（母卡 CM-2510），A.2 資料地基第 6 張。依賴：T-2.1～T-2.5。建議 model：opus。

這張卡做什麼（白話）

新裝環境永遠會過，會出事的是「帶著舊資料升級」。這張卡拿一份隔一版以上的真實客戶舊庫，在本機跑完整 migrate，逐角色比對升級前後每個角色實際能做的事（能力點集合）完全相同——不抽樣。另外列出每個租戶選到哪個角色當系統管理員、哪些 is_admin 角色沒轉，給決策者看。

在哪裡

~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/init/migrate.sh      正式升級路徑（三輪：主線、套件、能力點宣告與回補）
~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/      T-2.1～T-2.4 的 migration
產出：docs/features/FR-132-2610-access-management/inventory/a2-upgrade-rehearsal.md

怎麼做

• 舊庫來源：唯讀取得——從 POC 或 STG stack pg_dump（唯讀操作允許、不必請示）或決策者指定的客戶備份。取 dump 前先問決策者用哪一份最接近「隔一版以上的真實客戶」；restore 到本機另開的庫（例 guidant_ai_rehearsal），絕不回頭套 POC。
• 升級前快照：restore 後先存每個角色的能力點名集合（SELECT r.id, r.tenant_id, r.name, array_agg(c.name ORDER BY c.name) FROM roles r JOIN role_capabilities rc ON ... JOIN capabilities c ... GROUP BY 1,2,3）到檔案。
• 跑 migrate：走 scripts/init/migrate.sh（MIGRATE_DB_HOST=localhost MIGRATE_DB_NAME=guidant_ai_rehearsal），不要手動逐支 psql——要驗的是正式路徑。
• 升級後展開：用 T-2.2 的展開邏輯（或 T-3.1 的展開服務若已完成）算每個角色新表展開後的集合，以舊名比對（經 legacy_name 對照），全部角色逐一 diff。
• 另驗：用舊庫一個一般帳號、一個管理員帳號，BE 指向排練庫登入，選單與按鈕與升級前一致（升級前也要先登一次截圖對照）。
• 排練踩到的任何順序依賴（某支 migration 依賴某支沒在 manifest 前面）照實記錄並回寫。

要寫測試

• 排練本身即驗證；diff 腳本放 scratchpad 或 scripts/ 下需決策者同意才入版控。

驗收條件

• 逐角色 diff 全部一致（不抽樣）；舊帳號登入選單與按鈕不變。
• 排練紀錄列出每租戶選到的系統管理員、未轉的 is_admin 角色。

手測

• 本機排練庫：舊帳號登入側欄選單與某幾頁按鈕，與升級前截圖逐項對照。

紀律