架構不是技術名詞的購物清單。Day 4 已經把產品收斂為個人任務的新增、管理與篩選；今天要選的，是能支持這些流程、又不讓 30 天實驗被維護成本拖垮的做法。我會讓 ChatGPT 提出候選方案，再用相同條件比較，最後自己決定。

三個能做出畫面的方案

方案 A 是純前端，加上瀏覽器本機儲存。它最容易快速展示，但不適合用來驗證伺服器 API、資料庫 Migration 與部署後的資料行為，會讓 Day 20–26 和之後的實驗失去主線。方案 B 是單一全端 Web 專案：畫面、伺服器邏輯與資料存取在同一個程式庫，使用關聯式資料庫保存任務。方案 C 則拆成獨立前端與 API 服務，邊界清楚，但需要額外處理跨服務部署、設定與整合測試。

比較標準是能否覆蓋 30 天要觀察的工程問題、初期完成速度、部署與維護成本、未來調整的難度。A 開發最快但實驗覆蓋不足；C 有獨立服務的好處，但對目前單人、單功能主線而言增加了太多協調成本。我暫選 B：先完成一條端到端流程，把時間留給驗證、錯誤處理與修正。這是根據目前需求作出的取捨，不是宣稱 B 對所有產品都最好。

這次比較不是憑喜好投票。若只追求最快的第一張畫面，A 會勝出；若已經有多個客戶端共用 API，C 可能更合理。但系列的實驗目標包含資料層、API、測試與部署，而使用者只有一種核心情境，因此 B 在目前條件下比較平衡。文章後面遇到真實障礙時，我會回頭檢查這些前提，而不是修改評分標準替當初的選擇辯護。

暫定架構：一條請求要走得清楚

第一版會採 TypeScript 的單一全端 Web 專案，以 Next.js 承載頁面與伺服器端處理，使用 PostgreSQL 保存任務。瀏覽器送出新增或修改要求後，伺服器先驗證輸入，再執行資料存取，最後回傳明確的成功或錯誤結果；畫面根據結果更新狀態。具體套件版本、部署平台與資料庫服務，等真正建立專案時再核對相容性與成本，不在這篇虛構已完成的設定。

資料模型先保持小：Task 有識別碼、標題、完成狀態、建立時間與更新時間。標題必填，伺服器端負責最後一道驗證；前端驗證則用來及早回饋。API 不直接暴露資料庫細節，程式碼中的資料存取集中處理，讓 Day 21 的 Schema 和 Migration 有清楚的修改位置。公開展示時只使用測試資料，資料保存／重置政策需在上線前確認。

預定的資料流是：使用者操作畫面 → 伺服器驗證請求 → 任務服務處理規則 → 資料存取層讀寫 PostgreSQL → 回傳結果 → 畫面呈現成功或錯誤。這個順序刻意讓驗證和業務規則有固定位置；否則 Day 7 之後每加一個功能，條件判斷就可能分散在多處。實作時若框架本身提供更合適的組織方式，我會以清晰資料流為原則調整目錄，而不是硬套圖上的名稱。

主要風險有三個：資料庫連線和 Migration 會增加環境設定負擔；公開 Demo 的假資料必須避免被誤認為私人資料；單一專案若沒有模組邊界，久了也會變得難讀。對應做法是先跑通最小資料操作、部署前定義 Demo 資料政策、用測試和模組分層守住邊界。這些仍是設計方案，真正有效與否要等後續實作檢驗。

把決策寫成可被推翻的假設

選單體架構的前提是：使用者流程少、開發者少、目前沒有獨立擴縮不同服務的需求。若後續出現需要獨立部署的 API 消費者，或前後端節奏明顯分離，再評估拆服務。反過來說，如果實作發現資料庫成本或環境設定對系列過重，也應回到 PRD(產品需求文件) 檢查資料保存需求，而不是硬守今天的技術選型。

今天的 Prompt、結果與限制

我給 ChatGPT 的架構任務是：「根據以下 PRD，提出三種能交付 MVP(Minimum Viable Product) 的架構。對每種方案說明資料流、開發時間、維護與部署負擔、最可能的失敗點；不要直接選贏家。最後列出會改變決策的未知條件。」我的選擇是方案 B，理由是它覆蓋系列要測的 API、資料庫、測試和部署，同時把初期系統數量控制在一個專案。今天的產出是架構決策，還沒有 Repository、效能數據或實際部署結果。

今天學到什麼？

好的架構決策要能說清楚「為什麼現在選它」和「什麼情況下會重選」。Day 6 會把這些決策、啟動方法與合作規則寫進 README 和 AGENTS.md，讓 Codex 接下來的實作有一致的起點。