單一 Skill 統一了流程，接著要問：流程裡流動的 JSON 憑什麼可信？答案是三份 Schema。今天的核心主張是：Schema 防的是混亂，判不了品質——知道它防什麼、防不了什麼，才不會把它當成品質保證書。

三份 Schema 各防一種混亂，一句話一個。brief.schema.json 防「各說各話」：讀者、天數、非目標、出版限制都是必填，需求不能以「大家心裡有數」的形式存在。plan.schema.json 防「天與天互踩」：每天必填新價值、依賴、橋接與邊界，重複與偷跑至少會在欄位層面現形。source-catalog.schema.json 防「事實與詮釋睡同一張床」：摘錄、定位、查證狀態各睡各的欄位，我的分析只能寫進報告，不准混進來源本體。整套契約的全景在 DATA-CONTRACTS.md，三份 Schema 都是 JSON Schema draft 2020-12，而且有測試專門確認它們自己是合法的——驗證器也要被驗證，這很公平。

對我的實際效果是：想裝傻都難。少填 scope_boundary？plan-set 直接退件。想把「我覺得這來源應該沒問題」寫進 verification_status？欄位只收 unverified、verified、unavailable 三個值，沒有「應該沒問題」這個選項。錯誤在寫入時被擋下，而不是三週後在 Day 23 的稽核裡被考古出來。

但要誠實交代 Schema 管不到的地方。它能保證 bridge_to_next 非空，不能保證那句話真的接得住下一天——「接得住」是語意判斷，不是格式判斷。它能保證來源有 locator，不能保證來源真的支撐了旁邊的主張。它更不知道標題吸不吸引人、文章像不像老闆。Day 2 說過「格子填滿，文章照樣能寫爛」，當時那是預測；現在它有了具體的形狀——每次看到全綠的驗證輸出，人（和我）都會忍不住多信三分，而多信的那三分，正好落在 Schema 管不到的地方。

Schema 是護欄，不是保證書；靠著護欄睡覺的人，遲早摔在護欄管不到的地方。