FR-092 第 15 棒 drop 16 張沒人讀寫的表——OSCAL cd_* 六張、flow-engine hi_* 四張、device_monitors 兩張、role_members、alembic_version、DEV 兩張備份表；同步基線庫重產 02/04（實作，走 sql-migration）

本卡屬 FR-092（母卡 CM-1703），第 7 棒盤點（CM-1710）A＋D 類產出。只套 DEV 與基線庫，STG／POC 等上版放行。報告 docs/features/FR-092-2609-dead-code-cleanup/scan-orphan-tables.md 為準。

問題是什麼（白話）

DEV 庫 189 張表裡有 13 張從建表起一列資料都沒寫過、程式碼零引用（ORM／原生 SQL／view 三方都沒有），而且全部隨出貨基線進每個客戶的庫。另外 alembic_version 主專案根本不用 alembic 卻隨基線出貨還帶假 stamp；DEV 還有兩張一次性腳本的備份表。留著每次升級都要跟著 migrate、跟著 RLS、跟著基線重產，還誤導後人。

首腦核對：cd_* 六張全 codebase 零命中、主專案無 alembic.ini／alembic/ 目錄、04-seed-core.sql:1221 確實灌 alembic 假 stamp。屬實。

在哪裡

A 類 13 張（零引用零資料，基線庫也有）：
  oscal.component_definitions  oscal.cd_capabilities  oscal.cd_components  oscal.cd_control_implementations  oscal.cd_implemented_requirements  oscal.cd_statements
  compliance.hi_workflow_executions  compliance.hi_element_variables  compliance.hi_workflow_templates  public.hi_job_executions
  public.device_monitors  public.device_monitor_archive
  public.role_members
D 類 3 張：
  public.alembic_version（基線也有；04-seed-core.sql:1221 灌 stamp 要一起拔）
  survey.question_answers_dedup_backup_20260428（只在 DEV）
  config.detection_tool_profiles_deprecated_20260803（只在 DEV）
連帶：scripts/sql/2026-07-20-*-cleanup.sql 與 2026-08-17-fr065-t20-shipping-baseline-cleanup.sql 的 truncate 清單提到 cd_*，migration 套完那些歷史腳本不改（已套過），但 scripts/check_env_scoped_migrations.py 若列了 system_logs_old／deprecated 表要對一下

怎麼修

先讀 sql-migration skill 與 scripts/init/README.md「改基線庫必跑 regenerate」段。這不是寫一支 migration 就完：02-schema.sql／04-seed-core.sql 是產生檔，不可手改。
① 寫 scripts/sql/2026-09-XX-cm<本卡號>-drop-orphan-tables.sql：每張 DROP TABLE IF EXISTS <schema>.<table> CASCADE; 加日期註解；檔頭 -- Date:；role_members 若有 FK 被他表引用先 \d 確認 CASCADE 範圍不會拖到活表；收尾 INSERT public.schema_migrations。兩張 DEV 專屬備份表用同一支但註明 envs=dev——不對，manifest 一行一檔，環境專屬要分成第二支 ...-drop-dev-only-backup-tables.sql，manifest envs=dev。
② 登記 scripts/sql/manifest.tsv 兩列（主檔 envs=*、DEV 專屬檔 envs=dev），跑 scripts/check_migration_manifest.sh 過。
③ psql --single-transaction -v ON_ERROR_STOP=1 用 cmmgr 套 DEV（-p 25432 -d guidant_ai_dev）。
④ 主檔再套基線庫 guidant_ai（同 host 同 port），然後 scripts/init/gen_schema_sql.sh 與 gen_seed_sql.sh 重產 02／04；diff 確認只少了這 14 張表的 CREATE 與 alembic 那筆 INSERT，沒有其他漂移（gen_schema 的 diff 是唯一照妖鏡）。
⑤ 「帶舊資料升級」驗證：對一份有這 13 張空表的舊 DEV dump（或直接用套之前的 DEV 狀態）套本 migration，確認 IF EXISTS 讓已無該表的環境也能重跑。
⑥ 不動：B 類三張（operations／project_job_execution_device_mapping／system_logs_old）等決策者裁；compliance.subtask_status_histories 等 CM-1706 第 3 棒刪完 ORM 後再補進下一支 drop；jedi-flow-engine 那 34 支 hi_* 套件檔屬套件改版另案。

要寫測試

不寫 unit test。驗：套完 DEV python main.py 起得來＋守衛三檔綠＋python -m pytest test/test_build_integrity_manifest.py -q；基線庫重產後 scripts/build/assert_db_current.sh 過（若該腳本吃基線）。

手測

DEV：\dt oscal.cd_* 回空、\dt public.alembic_version 回空 → 前端開 SSP 頁、專案頁、設備頁各一次正常 → 角色管理頁正常（驗 role_members drop 不影響 jedi-iam）。

連帶

docs/claude/database-schema.md 若列到這 16 張表，拔掉。