工作紀律

與 blueprint 的關係：本頁就是 blueprint config 裡的 playbook 欄位 —— 工具管不到的判斷規則。
init 會將它們轉譯進專案的手冊與 Agent 守則，讓它們在每次改動時都在場。

分三塊講：執行期負載、死碼與抽象、重構與協作。

執行期負載紀律

功能對不對，只回答了一半 —— 另一半是「它多久跑一次」。
這個維度，lint 跟結構規則都看不到。
本節是信念第九條在講的事。

• 掛事件處理之前，先估成本。
  掛到 WebSocket、輪詢、捲動、輸入這類事件之前，先回答三題：
  每秒觸發幾次？每次帶多少資料？每次處理大概多重？
  答不出來，就先別掛上去。
  「別人也是這樣寫」正是這種失誤的放大器 —— 頻率不在程式碼裡。
• 高頻更新，就地改、只改變的那個欄位。
  容器跟沒變的節點，參照要保持不變；整包替換只留給「重建基線」用。
  一次事件之後，某個屬性若「參照變了、值卻沒變」，那就是病徵。
  寫法不能跨框架照抄 —— React 靠不可變資料＋記憶化，Vue 靠屬性層級的追蹤。
• 渲染問題別用猜的，照四步走：
  誰在渲染（效能分析器）→ 誰觸發渲染（渲染追蹤）→ 誰產生新參照（找賦值點）→ 值不值得（對照事件的資料量）。
• 效能講法要能驗收。
  「減少重新渲染」是形容詞；「一次事件最多重渲染 N 個元件」才是驗收條件。
  用渲染次數或參照穩定性的測試把它釘住 —— 沒被測試釘住的效能宣稱，等於不存在。

死碼與抽象紀律

• 抽象要在同一個 Pull Request 裡就接上至少一個正式的使用者 ——
  只有自己的測試在呼叫它，那不是抽象，是偽裝成架構工作的死碼。
• 拿掉某段程式碼最後一個呼叫點時，因此走不到的程式，同一個 Pull Request 就一起刪掉。
• 要停用、又得留著的程式，用 @deprecated 標起來、指到說明文件 —— 標在那個實體本身，不是標在它的測試上。
• 把反模式搬到隔壁檔案、加個 lint 豁免註解，不叫「修好」；一行一行豁免也不叫「遷移」。

重構與協作

• 先鋪保護網、再動手，分三階段：補齊邊界測試 → 拆分或修改 → 整理測試。
  一個階段一個 commit，讓每次 review 只看一件事。
• 從原始碼抽，不要憑記憶重寫 —— 抽完跟版本歷史比對一次；「測試過了」不能單獨證明你抽對了。
• 抽之前先遞迴掃一遍依賴 —— 所有識別字都算，不是只看響應式的那幾個。
• 保護網測試，別綁在這次重構本來就要改的介面上。
• 架構上的修正，要講成「在維護設計」，不是「偏離工作項」——
  先說你在守哪一條原則，再說「照票面字面做」為什麼會違反它。
• 已經定案的設計，別再翻出來重談；真有疑慮，一次把話講完、附上理由，別丟一張選項清單回去讓大家重選。
• 「使用者可以繞過」不是把問題擱著的理由 —— 該不該修，看的是影響範圍、還有它獨立造成的影響有多大。