三面檢查各自產出了清單，清單上的問題現在要處置。最直覺的處置是「哪篇有問題改哪篇」——直覺，而且經常是錯的。今天的核心主張是：問題要分流到正確的層級；在錯的層級修問題，症狀會消失，病會留著。

分流矩陣先攤開，精簡版：措辭與單篇結構的問題改文章；跨篇重複、依賴斷裂改 plan；需求本身變了改 brief；規則表述不清改 SKILL.md 或 references；工具行為錯誤改 CLI 並補測試；資料形狀不對改 Schema；說明過時改 docs。判準只有一個問題：這個毛病如果今天只修文章，下一篇會不會再犯？會，就表示病根在更上層。

用本案真實發生的事示範，而且刻意挑兩件表面症狀一樣、層級卻不同的。第一件：Day 5 與 Day 18 的示範例子撞在一起，兩篇都拿同一份 ZIP 與同一次 Release 查詢當範例。症狀是重複，但計畫層的 new_value 分工其實切得很乾淨——一篇講原則、一篇給現場紀錄——所以病根是我選例懶惰，層級在文章。處置：兩篇各換一組例子，計畫一個字沒動。第二件：Day 9 與 Day 20 都用同一條測試支撐同一個論點。症狀一樣是重複，但這次計畫層的 new_value 本身就有交集，只改文章下一版還會撞，層級在 plan。處置卻不是立刻動手——改計畫會產生新 hash 並要求重新核准，而當前計畫還卡在未核准，這時再推一版只會讓閘門更亂，所以本輪先在文章層降低重疊，計畫層調整列為待處理並附理由。同樣是重複，一個改文章、一個改計畫、而且改計畫的那個還得排隊。

第三件示範另一種層級：CLI 不自動關閉被取代計畫的 checklist 項目，open_check_count 越疊越高。這是工具行為問題，層級在 public toolkit 的 CLI——但那個 repo 未經老闆另行授權不得修改，所以處置是記錄成提案，附清楚的行為描述與建議測試，等授權。

至於「文章讀起來像規格書」那一件，層級又不一樣：五篇同時生硬就不是哪一篇的鍋，病根在契約層的語氣規格。處置是改 brief 的 tone、改 AGENTS.md 的敘事規則，然後才重寫文章——層級是 brief 加 article，Skill 一根汗毛都沒動。

反向的紀律同樣重要：不升級。單篇的措辭彆扭不需要動 SKILL.md，一個欄位偶爾填得敷衍不構成重設計 Schema 的理由。往上修的成本是指數成長的——改文章十分鐘，改計畫要重新核准，改 CLI 要測試加回歸——把小問題往上推，等於把牛刀的帳算在雞頭上。ADR 只在真的面對「有替代方案與後果」的決策時才寫，不是每個修正都配得上一份決策紀錄。

分流做完，每個問題都有了地址與責任層。修東西之前先問問題住在哪一層——這是這條產線教我的第一課，也是最省加班的一課。