這張卡做什麼（白話）

出貨基線的真相來源是 DEV 資料庫的 dump，但 DEV 兩年來累積了測試租戶、測試專案等大量非系統資料。本卡在做基線 dump 之前，把 DEV 清成「只剩系統該有的東西」＋把各資料表的流水號（sequence）歸位——讓新客戶拿到的庫乾淨、id 從合理起點開始，而不是一開帳號 id 就從幾千起跳。

• 母案 CM-1189：https://app.notion.com/p/FR-065-Installer-3bc346da4cd081c4abf3ce74a28ba384
• 所屬子需求卡 CM-1244：https://app.notion.com/p/FR-065-2-bundle-3be346da4cd08103adb2e1803cf7b42c
• 設計文件：docs/features/FR-065-2608-onprem-installer/design.md §5（.2 段 T-2.0）；清理範圍真相源 db-init-inventory.md §3.3

具體實作內容

• 清理範圍照 db-init-inventory.md §3.3：測試租戶 102／131／152／153／158 整族（含其 org、roles、users、module_frames、flow_templates 等掛載資料）、業務資料全族（專案／SSP／評估／證據等）、三張垃圾表 drop、NOTIFY_CONFIG 含真實 secret 的資料列
• 保留 §3.1 產品必備字典與 root tenant／org id=1（硬約定不可動）
• reset sequences：清完後各表 setval 歸位——腳本化，逐 schema 掃 sequence 對 max(id)，不逐條手寫
• 清理以 SQL 腳本形式落 repo：scripts/sql/ 走 sql-migration 慣例（日期註解＋檔頭 -- Date:），envs 標 dev 專屬（不進 STG/POC 套用清單）；腳本可重跑驗證

易踩雷提醒

• 🔴 只動 DEV，絕不碰 STG/POC（CLAUDE.md 環境異動鐵律；POC 等同 production）
• 清理前先 pg_dump DEV 留完整備份，出事可整庫還原
• 刪除順序要照 FK 依賴（先子後父），否則 constraint 擋刪
• root tenant／org id=1 是硬約定不可動
• 清理後跑 CM-1207 附錄的權限掃描與 RLS 驗證，確認沒把權限／policy 相關資料清壞

驗收條件

• DEV 清理後只餘系統資料（§3.1 保留集＋root id=1）
• sequence 全數歸位（掃描核對 last_value vs max(id)）
• BE 起服務、登入正常