前面的功能偏小，今天把難度提高：讓使用者編輯已存在任務的標題。這看起來只是一個輸入框，實際上會連到清單操作、伺服器更新、資料庫寫入、驗證、錯誤回饋與測試。跨檔案任務最容易出現「每個局部都合理，整條流程卻斷掉」的情況。

先畫出完成路徑

使用者在清單中選擇編輯，看到目前標題；修改後送出，畫面只在伺服器確認成功時更新。空白標題被拒絕，原資料保持不變；任務不存在或儲存失敗時，畫面顯示錯誤，不把修改當成成功。取消編輯時不送請求，清單仍保留原標題。這些條件從 Day 4 PRD 延伸而來，也會成為 Day 12 的測試素材。

資料流預定是：編輯表單提供輸入與回饋、伺服器驗證識別碼和標題、任務服務處理更新規則、資料存取層寫回資料庫，清單再取得確認後的內容。實際檔案名稱要由 Repository 決定，不能因為架構圖寫了「服務層」就強迫 Codex 造出多餘的抽象。

交給 Codex 的任務

「請先閱讀新增與列表流程、相關測試，以及目前資料存取方式。實作編輯任務標題：可開啟、取消、送出；成功後畫面與資料一致；空白、任務不存在與寫入失敗要有清楚結果。保持既有新增、完成與篩選行為。先說明預計修改的檔案與資料流，再實作、執行相關測試並回報 diff。不要為了這個功能重寫整個清單。」

這份任務沒有指定檔案，但指定了外部行為與不得破壞的既有流程。若 Codex 發現 PRD 和現有程式互相矛盾，應先說出差異；不能默默選一邊。若需要改 Schema，也要把 Migration 和資料完整性當成獨立風險提出，而不是把它藏在「順便更新資料庫」裡。

先守住既有功能

新增與編輯都會碰到標題驗證，很容易出現兩套近似但不相同的規則。若 Codex 為了快速完成編輯，在新路由複製一份驗證，之後兩邊可能逐漸分岔；但若它為了共用而大幅改寫新增流程，又可能引入回歸。這個取捨要以現有程式為準：先確認是否已有可重用的規則，再做最小調整，並用新增與編輯兩種測試保護行為。

另一個陷阱是只測試資料庫「有更新」，沒檢查錯誤狀態下畫面是否維持一致。若回應延遲，使用者重複送出怎麼辦？若編輯期間別的操作改了同一筆任務，畫面顯示哪個版本？第一版不一定要解決所有併發問題，但至少要辨識會影響當前驗收的情況，並把未處理的邊界寫出來。

Review 時要看跨層一致性

我會從使用者操作一路追到資料庫，再反向看結果怎麼回到畫面。UI 上裁掉空白、伺服器卻沒裁，會造成兩邊規則不同；資料庫更新成功、畫面仍顯示舊標題，會讓使用者以為失敗；畫面先更新、寫入失敗卻不回復，則是假成功。檢查重點是每一層是否對同一個結果有共同理解。

今天的結果與限制

本文定義了跨檔案 Feature 的可操作驗收與審查路徑。因目前沒有 Repository，尚無實際修改、測試或回歸結果。實作時會保留第一版 diff 和修正輪次，檢查 Codex 是不是只完成 Happy Path。

今天學到什麼？

跨檔案功能不是檔案數變多而已，而是資料與使用者期待要在每一層保持一致。明天用測試把這些不容易靠截圖看出的錯誤抓出來。