核心信念

在 blueprint 裡：這些就是各 preset 的 principles。
init 會把它們原封不動地編譯進你 repo 的手冊與 agent 守則。
它們全部落在守則裡、不進 lint，
因為這些要的是判斷，不是機器查得動的東西，
只能靠 agent 每次改動時自己守住，見 運作守則。

手冊裡每一條規則，最後都收斂到這幾條信念；
後面各章其實都是它們的展開。

1. 依責任切分，不是依大小

該不該拆，看的是「這個單元做了幾件事」，
不是「這個檔案有多長」。
行數只是衍生出來的訊號 —— max-lines 是唯一以行數把關的底線，
max-statements 跟函式層級的量測都只是初篩。

2. 單一真實來源

能算出來的值就用推導的（computed / useMemo），
別另外存一份會失去同步的可變狀態。
同一筆資料，不該同時活在兩個可寫的地方。

3. 介面收窄

輸入收窄、輸出精簡 ——
讓非法狀態在型別上就根本表達不出來，
呼叫端也只依賴它真正需要的部分。

4. 知識放在用到它的地方

衍生邏輯放在需要它的子元件；
可寫狀態放在「最靠近的共同讀寫者」那一層；
生命週期放在真正擁有那個責任的單元裡。
預設就是不要往上抬。

5. 死碼：刪掉，或標記

沒有人用的抽象就是死碼。
哪次改動讓它變成孤兒，就在同一次改動裡清掉；
真的要留，就用 @deprecated 標清楚原因跟替代方案，
別指望以後有人看得懂。

6. lint 是入口，不是判決

機械性檢查（行數、複雜度、被依賴數）只能做初篩。
內聚性、有沒有好好建模、有沒有守住單一真實來源、結構上的不變量 ——
這些只有 code review 抓得到。
lint 全綠 ≠ 合格。

7. 驗收條件是起點，不是聖旨

當一張票照字面做，會破壞某個抽象該扛的責任，
去修那個問題是在「守住設計」，
不是偏離這張票。

8. YAGNI —— 別過度設計

小改動不用套一堆設計模式的儀式。
「以後搞不好會共用」，
不構成現在就上提、就抽象的理由。

9. 成本是第三個維度

值算對了（框架用得對）、結構乾淨了（分層清楚），都還不夠。
成本 = 每次事件的工作量 × 事件發生的頻率 ——
而「頻率」這個數字不在程式碼裡。
任何掛在資料來源上的邏輯都得估它的成本；
沿用現成的寫法，不等於可以跳過這一步。