2026 iThome 鐵人賽參賽系列。以個人興趣做的網站為出發點，從 Infra 工程師的角度，記錄用 Claude 把想法落地成工具的過程與取捨。
系列開場：用 Claude 把個人興趣做成網站，先盤點手上的四個 Side Project——Coffee Review、Commute、Daily 與正在製作的 Art-Tracking，以及前三個共用的「GitHub Pages + Supabase」架構。
Art-Tracking 第二版動工前，先決定它是給誰用、抓什麼、狀態怎麼分、首頁要不要逼我表態、排序聽誰的、來源壞了怎麼辦。這篇記錄六個產品面的取捨與背後的理由，以及每一個取捨落到資料模型、ingest 合約與程式碼上長什麼樣。
Art-Tracking 第一版跑在 Vercel + Supabase 上，第二版（2026-09）整個搬到 Cloudflare Workers。這篇講為什麼不能像 coffee-review、commute 一樣用 GitHub Pages + Supabase，為什麼不留在 Vercel，以及 Hono、Drizzle、D1、R2、Vitest workers pool 這幾個選擇各自的理由與代價。
Art-Tracking 上線後的第一個問題：只有 workers.dev 網址、API 全 401。記錄把它掛上 art.kiwi-walk.com、用 Cloudflare Access 保護整站卻讓 agent 路徑 bypass 的取捨，Worker 端怎麼自己驗 JWT 做到 fail closed，以及靠 302 裡的 AUD 抓出 policy 設錯的過程。
Coffee Review 品鑑表單最上面的「店家」有兩個問題：店家筆記只能從店家頁填，所以沒人填；選店家又拆成「選擇」和「新增」兩套，猜錯就撞 unique constraint。記錄把筆記搬進表單、把搜尋合成一個輸入框時的取捨（筆記要不要自己的儲存鍵、dirty 跟誰比、什麼時候才問 Google），以及 code review 才抓出來的三個坑：listener 疊兩層讓 chip 點了沒用、失敗 toast 被成功訊息蓋掉、把 LatLng 的方法拆下來呼叫讓從 Google 新增店家整條壞掉。
coffee-review 原本的「杯測」其實是自己沖一支豆，真正的杯測是一次擺 N 杯、每杯用編號識別。這篇記錄舊名字讓位、編號預設手動、未評分當成一級狀態這些產品取捨，為什麼資料分成兩張表而不是一個 jsonb 陣列，以及一組評分元件怎麼輪流裝 N 杯。
店家頁的「常見風味」在線上永遠是空的，但負責統計的純函式有十幾條測試、全綠——問題不在算法，在查詢根本沒撈那兩個欄位。這篇記錄為什麼不直接把欄位加進去、假的 Supabase client 要假到什麼程度才抓得到這種 bug，順帶收掉草稿按「還原」就被清掉與全新安裝 SQL 缺欄位兩件，以及驗證修正時我怎麼用一行 git 把自己的修正刪掉。
放在 iCloud 的第二大腦 vault，五個月累積了檔案脫水、衝突副本、rename 被還原一整套症狀（細節明天單獨寫一篇）。搬到 Obsidian Sync 才發現它排除所有 dot 資料夾，.claude/ 的 15 個 skill 和 4 支 hook 一個都不同步。這篇記錄三個方案怎麼比、為什麼最後整個 vault 改用 git，以及三個坑：文件宣稱可攜但程式碼寫死、dispatcher 靜默不執行、我自己把路徑長度算錯。
Day8 只交代了搬家的決定，把事故本身整篇往後推。這篇補上：一個同時活在兩台機器上、又刻意不用版本控制的 vault，被 iCloud 咬出的三類症狀——檔案脫水成佔位檔、rename 被雲端還原、以及最危險的靜默衝突副本（本尊消失、副本才是新版）。還有我為它長出的三層防線：CLAUDE.md、PreToolUse hook、定期巡檢，各自攔在錯誤的不同時間點，也各自有攔不到的東西。
前兩天都在講這個筆記庫的儲存層——搬家的決定，和雲端同步碟咬出來的三類症狀。今天正式介紹它本身。Karpathy 的 LLM Wiki 架構是 Raw / Wiki / Schema 三層分工，我加的是「域優先」——用生活域當頂層資料夾，讓查詢有路徑可循，LLM 每次只讀 2 到 4 個檔而不是掃全庫。這篇講五個取捨：為什麼不用 RAG、為什麼域優先、為什麼 raw 不到五個檔不准開 wiki、為什麼規範要用 hook 擋、以及 skill 怎麼從原子指令收斂成管線。附三個實際踩過的判斷錯誤。