前兩天都在講這個筆記庫的儲存層——搬家的決定，和雲端同步碟咬出來的三類症狀。今天正式介紹它本身。Karpathy 的 LLM Wiki 架構是 Raw / Wiki / Schema 三層分工，我加的是「域優先」——用生活域當頂層資料夾，讓查詢有路徑可循，LLM 每次只讀 2 到 4 個檔而不是掃全庫。這篇講五個取捨：為什麼不用 RAG、為什麼域優先、為什麼 raw 不到五個檔不准開 wiki、為什麼規範要用 hook 擋、以及 skill 怎麼從原子指令收斂成管線。附三個實際踩過的判斷錯誤。
昨天講了搬家的決定，但那之前的五個月只帶過一句。今天把它寫完整：一個同時活在兩台機器上、又刻意不用版本控制的筆記庫，會被雲端同步碟咬出三類症狀——檔案脫水成佔位檔、rename 被雲端還原、以及最危險的靜默衝突副本（本尊消失、副本才是新版）。以及我為它長出的三層防線：慣例、hooks、巡檢，各自攔在錯誤的不同時間點，也各自有攔不到的東西。
放在 iCloud 的第二大腦 vault，五個月累積了檔案脫水、衝突副本、rename 被還原一整套症狀，甚至逼我長出一支專掃衝突副本的 hook。搬到 Obsidian Sync 才發現它排除所有 dot 資料夾，.claude/ 的 16 個 skill 和 4 支 hook 一個都不同步。這篇記錄三個方案怎麼比、為什麼最後整個 vault 改用 git，以及三個坑：文件宣稱可攜但程式碼寫死、dispatcher 靜默不執行、我自己把路徑長度算錯。
店家頁的「常見風味」在線上永遠是空的，但負責統計的純函式有十幾條測試、全綠——問題不在算法，在查詢根本沒撈那兩個欄位。這篇記錄為什麼不直接把欄位加進去、假的 Supabase client 要假到什麼程度才抓得到這種 bug，順帶收掉草稿按「還原」就被清掉與全新安裝 SQL 缺欄位兩件，以及驗證修正時我怎麼用一行 git 把自己的修正刪掉。
coffee-review 原本的「杯測」其實是自己沖一支豆，真正的杯測是一次擺 N 杯、每杯用編號識別。這篇記錄舊名字讓位、編號預設手動、未評分當成一級狀態這些產品取捨，為什麼資料分成兩張表而不是一個 jsonb 陣列，以及一組評分元件怎麼輪流裝 N 杯。