一支 API 能回 200，不代表可以上線。到期時間加入後，伺服器需要處理型別、格式、權限邊界、找不到資料與資料庫錯誤，並讓前端得到一致結果。今天把 Prototype 的更新端點補成可預期的介面。

輸入不可信，錯誤也要有契約

伺服器驗證任務識別碼、標題與到期時間，不依賴前端已經檢查。未知欄位要依 API 規則處理，不能直接寫入資料模型。到期時間統一解析和儲存格式；無效日期、空白標題與不存在任務各有可辨識錯誤。一般使用者看不到內部堆疊、SQL 或路徑。

錯誤回應應有穩定結構，例如機器可辨識的 code、給使用者的 message 和必要的欄位資訊。HTTP 狀態碼要反映結果：輸入錯誤、找不到資料與伺服器失敗不能全部回相同成功狀態。Log 可保留內部追蹤識別碼，但不記錄 Secret 或不必要的個人資料。

從攻擊錯誤輸入開始測

測試正常更新、純空白標題、錯誤日期格式、不存在識別碼、超長內容、額外欄位與資料庫失敗。若端點需要使用者身份，還要測試未授權與越權；目前 MVP 尚未建立帳號，因此公開 Demo 不應聲稱已有完整授權模型。

交給 Codex 的任務

「審查更新任務 API 的輸入、資料存取、錯誤回應和 Log。依既有慣例建立一致驗證與錯誤契約，覆蓋正常及失敗案例；不得把內部錯誤或敏感資料回傳給客戶端。先列出目前缺口，再做最小修改並執行相關測試。」

Review 時我會檢查驗證是否在真正的信任邊界、錯誤是否被過度吞掉、前端是否能依 code 做正確回饋。把所有例外都轉成「更新失敗」雖然簡單，卻會讓找不到任務、輸入錯誤和系統故障無法區分。

今天的結果與限制

目前形成後端驗收矩陣與錯誤契約原則，尚未實作端點或取得測試輸出。帳號與正式授權仍在 MVP 範圍外，部署文章必須再次說明這項限制。

今天學到什麼？

可靠 API 的差異不在成功路徑，而在錯誤是否一致、可診斷且不洩漏內部資訊。明天把整個系統放到部署環境，看看本機假設還剩多少。