本卡屬 FR-092（母卡 CM-1703），第 7 棒盤點。只盤不修；DEV 庫只 SELECT，STG／POC 不連。
程式碼層清乾淨後，資料庫還會留著沒人讀寫的表：功能退役時表沒 drop（第 3 棒退 subtask_status_history 後那張表就會變這樣）、FR-069 抽套件時宿主與套件都不再碰的表、只剩 view 在讀的表。你要把 DEV 庫的全部表對照主專案 22 個 ORM model 檔與 jedi 套件 154 個 model 檔，再對照原生 SQL 字串與 view 定義，列出三方都沒人碰的表。
沒人碰的表每次升級都要跟著 migrate、跟著 RLS policy、跟著 gen_schema 基線，而且會誤導後來的人以為資料還在用。但 DROP 是不可逆動作，所以本棒只盤、每張表要附「為什麼確定沒人用」的證據，drop 由首腦另開卡走 sql-migration skill。
feedback_views_and_sql_strings_evade_guards）：pg_views 的 definition、infra/readmodel/ 與 infra/*/repository/*_query.py 裡的 text("""...""") 都要 grep 表名，ORM 對不到不代表沒人讀。scripts/sql/ 內的一次性清理腳本會讀哪些表。schema_migrations、schema_version、RLS 相關的系統表屬基礎設施，不列。oscal_* v1 命名）是最可能的候選。compliance.project_device_mapping（2026-05-22 C3 退役）——先確認 DEV 是否真的已 drop，若還在就是首例。本範圍從未系統性掃過。docs/claude/database-schema.md 是人工維護的表清單，可當對照但不是真相。DEV 連線：192.168.50.188:25432 庫 guidant_ai_dev 帳號 cmmgr，密碼查 .env 的 DB_SECRET。
第一步：撈 DEV 全表與 view：
psql -h 192.168.50.188 -p 25432 -U cmmgr -d guidant_ai_dev -Atc "select schemaname||'.'||tablename from pg_tables where schemaname not in ('pg_catalog','information_schema') order by 1" > tables.txt
psql ... -Atc "select schemaname||'.'||viewname||E'\t'||replace(definition,E'\n',' ') from pg_views where schemaname not in ('pg_catalog','information_schema')" > views.txt
第二步：撈程式碼端的表名——三個來源合併：① grep -rhoE "__tablename__\s*=\s*['\"][^'\"]+" --include='*.py' infra ~/Projects/Jedicogy/module/jedi-python-package/*/ ；② __table_args__ 裡的 schema=；③ 原生 SQL：grep -rhoE "(FROM|JOIN|INTO|UPDATE)\s+[a-z_]+\.[a-z_]+" --include='*.py' -i infra app ~/Projects/Jedicogy/.../ 。
第三步：每張「程式碼零命中」的表再做三件事：查 views.txt 有沒有 view 引用；select count(*) 看有沒有資料、max(created_at) 看最後寫入；scripts/sql/ grep 表名看哪支 migration 建的、有沒有後續 migration 宣告退役。
第四步：分類——A 零引用零資料：可 drop；B 零引用有資料：列出筆數與最後寫入時間，首腦裁；C 只有 view 引用：連 view 一起列；D 只有一次性腳本引用：可 drop 但要註明腳本。