畫面壞了可以重新整理，資料被錯誤 Migration 改掉卻未必能復原。今天替任務加入可選的「到期時間」，藉此檢查 AI 是否只會修改 Schema，還是能同時考慮既有資料、部署順序與回復方案。

先說清楚資料規則

到期時間可以不填；填寫時必須是有效時間，顯示與排序要有一致時區規則。第一版不做重複任務或提醒。既有任務在 Migration 後應保留，新的欄位預設為空。API、畫面與資料庫對「沒有到期時間」的表示方式必須一致。

Migration 不是直接改正式資料庫

先在開發或測試資料上產生 Migration，檢查實際 SQL、鎖表風險和既有資料影響，再用備份或可重建資料驗證升級。若變更不可逆，回復方案不能只寫「執行 down」；要說明如何恢復資料、需要多久，以及部署期間舊版程式能否和新版 Schema 共存。

對新增可空欄位，風險相對低，但仍要考慮索引、排序與時區。若未來需要把欄位改成必填，應分階段補資料、驗證完整性，再加限制，避免一次部署讓舊資料全部違規。AI 提出的 SQL 只能當候選，必須由人類看過並在非正式環境驗證。

交給 Codex 的任務

「先閱讀目前 Task Schema、Migration 工具、資料存取與部署流程。為可選到期時間提出最小 Schema 變更，說明既有資料、時區、索引、向前相容與回復方式。先產出計畫和預計 SQL；確認後才建立 Migration、更新程式與測試。不得直接連正式資料庫。」

驗收包含 Migration 在空資料庫與含舊資料的資料庫都能執行，既有任務仍可讀寫，新欄位的空值與有效值行為正確，舊版與新版切換風險已說明。若測試只在全新資料庫通過，還不能代表升級安全。

今天的結果與限制

目前完成資料規則、Migration 流程和驗收案例，尚未執行資料庫變更。實作後會記錄耗時、鎖定與回復測試，而不只放成功建立欄位的畫面。

今天學到什麼？

資料庫修改的完成標準包含既有資料和失敗後復原，不只是新版程式能讀新欄位。明天把到期時間帶進前端，檢查介面是否真的能用。