FR-121 子卡 .3。範圍：survey（10 表 21 欄）＋oscal（2 表 3 欄）。表屬 jedi-survey／jedi-oscal-v2。

固定步驟（每張子卡相同）

• 先盤點：SELECT table_name,column_name FROM information_schema.columns WHERE data_type='timestamp without time zone' AND table_schema='<本卡 schema>' ORDER BY 1,2;，逐欄判斷寫入端是本地（Asia/Taipei）還是 UTC（grep ORM default／server_default／寫入程式；已知 UTC 寫入：flow-engine 三張、iam 改密碼兩張），列表進回寫。判不了的先回寫問首腦，不猜。
• migration：ALTER TABLE <t> ALTER COLUMN <c> TYPE timestamptz USING <c> AT TIME ZONE 'Asia/Taipei'（UTC 寫入的欄用 'UTC'）。表屬套件放該套件 migrations/（先看既有放法），主線表放 scripts/sql/；照 sql-migration 規範（檔頭 Date、每句註解、schema_migrations、GRANT 不變）。只套 DEV。
• ORM：對應 model 欄位改 DateTime(timezone=True)；寫入 default 改 datetime.now(timezone.utc) 或 func.now()。
• git grep 這些欄位名：view、SQL 字串、::date、date_trunc、>= now() 比較——確認型別改後語意不變（view 與 SQL 字串是守衛盲區）。
• 驗證：套完再跑盤點 SQL，本 schema 歸零；抽三筆舊資料轉換前後讀出相同（本地 10:35 那筆仍 10:35，UTC 寫入那筆也正確）；把 DEV 連線時區改 UTC（SET TIME ZONE 'UTC' 或改容器 TZ）再讀一次仍正確；受影響套件測試帶 PYTHONPATH 全綠；BE 三支守衛。
• 回寫明講「出貨基線待重產」；版號：動到 models 的套件 bump（只 bump 不發）。

工作區（只能在這裡改，絕不碰主 checkout）

• BE：/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security
• 套件 monorepo：/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security
• 測試 PYTHONPATH：套件指向該套件目錄；BE PYTHONPATH=/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-integrity:/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-compliance-audit。
• DEV 連線看 .env（localhost:5432）。190 只讀。

範圍外／不要做

• 不 push、不切 branch、不發版、不出包、不動 190／STG／POC、不動 188 基線庫。只 add 自己的檔，禁 -A／-am；BE／套件分開 commit。與 .1／.2 平行時只動 survey／oscal 的表與對應 models。

做完

• commit → 本卡 append（盤點表、每欄選的時區、migration 檔名、驗證輸出、打折）→ 狀態改「修正待驗證」→ 停下。

已完成修正（小弟，2026-09-27）

做了什麼（白話）：問卷（survey）和 SSP 程序書池（oscal）這 12 張表的 24 個時間欄位，從「沒帶時區」改成「帶時區」。舊資料一筆都沒變：原本存的是台北時間，轉換時就當台北時間解讀。改完以後資料庫連線不管設成台北還是 UTC，讀出來都是同一個時間點。

盤點結果：24 欄全部是台北時間寫入，沒有 UTC 寫入者，不需要問首腦