"Design"
- 資料袋與領域模型
判斷一個型別該是一袋欄位還是有行為的領域模型：判斷標準是「有沒有不允許任意組合的欄位」。含判斷標準用錯時規則退化成建議的機制、以及資料袋起步後升級的演化訊號。
- Gate 分類與三問設計法
每個 gate 設計時問三個問題：成功時做什麼、失敗時做什麼、使用者不知道發生什麼時做什麼
- 三層 log 設計
連線生命週期 log、protocol 訊息 log、使用者行為 log — 三層各自的職責、詳細程度和啟停控制
- 功能規格中的 log 點定義方法
把 log 點設計從 debug 階段前移到功能規格階段 — 每個功能的規格文件新增可觀測性欄位，列出啟動 / 步驟 / 錯誤 / 完成四類 log 點
- 欄位設計原則
source 標明來源、data 自由欄位、v 版本演進 — 三個設計原則讓 schema 在不同階段都能使用
- 「事後補 log」vs「設計產物 log」的品質差異
事後補的 log 是救火工具、設計產物的 log 是可觀測性基礎設施 — 從一次實機修復補 log 的教訓拆解兩者在格式、覆蓋率、維護成本上的差異
- 10.5 退場能力的設計前置：端點間接層、本地運作模式與引用的命名空間
服務上線時就決定、越接近關閉越難補上的設計：客戶端讀取服務位置的間接層、沒有雲端時裝置還能做什麼、外部引用落在提供者還是客戶的命名空間、使用紀錄與可交出的資料格式，以及依賴第三方契約與授權而無法移交的功能
- 1.16 Schema 設計決定的查詢代價：可空性、排序鍵唯一性、表寬、一對多的切法、比較規則與外鍵執法
建表時每一個決定有哪些選法、選了之後查詢要多做什麼、代價在什麼條件下才浮現、改回來要付的遷移成本，以及設計當下就能問的問題；輸出為 SQLite 與 PostgreSQL 的實測
- YAGNI 的真實適用條件：成本對稱性、可逆性、領域先驗劃出邊界
YAGNI 不是「永遠選最受限選項」、是「不為未來投入額外成本」的原則。用成本對稱性、可逆性、領域先驗三軸框架釐清「該選通用 default」與「該避免過度設計」的邊界、並補上 review checklist、架構規範、領域先驗清單三層制度補強。