這張卡做什麼（白話）

出貨基線取自 DEV 庫的 dump，但 DEV 裡有兩支開發期留下的除錯用 view（debug_org_units／v_tenant_parent_debug）不該跟著出貨。D11.9 裁定：確認全 codebase 零引用後，連 DEV 一併刪掉——這樣之後取的基線 dump 自然乾淨。這是一支走正規 migration 流程的前置小卡。

• 母案 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 §2.1 D11.9

具體實作內容

1. grep 全 codebase（BE＋FE＋jedi-* 套件＋scripts/）確認 debug_org_units／v_tenant_parent_debug 零引用——走 CLAUDE.md「DROP 退役表前安全四查」鐵則
2. 開 migration drop 兩支 view：scripts/sql/ 新檔，走 sql-migration skill 規範（檔頭 -- Date:、語句日期註解、收尾 INSERT public.schema_migrations）
3. 只套 DEV（psql --single-transaction -v ON_ERROR_STOP=1 用 cmmgr，host 192.168.50.188:25432 db guidant_ai_dev）——STG/POC 等上版放行，開發期絕不碰
4. 附帶 D11.9 裁定：cm_app_group 空群組保留（利未來多 app 帳號），不要順手刪

易踩雷提醒

• 絕不可套 STG/POC（環境異動鐵律；本卡只有 DEV）
• 安全查核要含 orphan code 檢查——表刪了但 code 還 live 引用是上膛的槍（memory 有案）
• grep 記得涵蓋 jedi-* 套件路徑 ~/Projects/Jedicogy/module/jedi-python-package/

驗收條件

• 零引用查核紀錄成文（貼實際 grep 輸出）
• DEV 已 drop 兩支 view、schema_migrations 有登記
• 之後取的基線 dump 自然不含（供 T-2.1 取基線時確認）

依賴

• 無前置卡（但需在 T-2.1 取基線 dump 前完成，否則基線要重取）