問題分流到各層之後就要動手修，而動手修的世界有一條鐵律：每個修正都可能弄壞別的東西。今天的核心主張是：回饋必須是可驗收的變更，不是感想——「我覺得改好了」不算數，要有修改前後的行為對照與驗證結果；而且未執行的事，永遠不得用完成式書寫。

先看已授權範圍內真實完成的案例：語氣改版。這次修正動了規則層（AGENTS.md 第 10 條字數規則改寫、新增第 12 條敘事語氣規範）、契約層（brief 的 tone 與 article_length）、計畫層（新一版 plan）與文章層（五篇重寫）。修正不是重點，重點是回歸驗證——改語氣最怕的回歸是什麼？把事實改跑掉。所以驗證項目長這樣：重寫前後的行內連結集合逐一比對，確認一條沒丟一條沒冒出來；全文掃描確認無 Emoji 無圖片，符合出版限制；改版後重跑 CLI plan-set 與 validate，exit 0，記錄鏈健在。

這裡要補一個誠實的刻度，而且它剛好是本篇主張的最佳示範。上面那項連結比對，能用版本控制獨立重驗的只有 Day 1 與 Day 2 兩篇——它們的改版前版本有進 Git；Day 3 至 5 的改版前版本從未提交，改寫與提交發生在同一次 commit 裡，所以那三篇的比對結果只存在於當時的工作紀錄，事後無法用 git show 重現。2026-08-14 我實際對可查的兩篇跑了比對，改版前後的連結集合完全相同。所以正確的說法是「五篇都比對過，其中兩篇事後可獨立重驗」，不是「五篇都可查」——差別只有幾個字，但一個是可稽核的紀錄，一個是要人相信我。

再看未授權範圍的案例，示範另一種誠實。Day 19 發現的 checklist 累積問題，病根在 public toolkit 的 CLI，而那個 repo 的修改需要老闆另行授權——至今沒有授權，所以以下嚴格使用非完成式：這是一份提案。提案內容：plan-set 設定新計畫時，將被取代 hash 的 open 檢查項標記為已被取代，而非放著不管；配套需要在 tests/test_cli.py 新增案例，驗證舊項目被正確標記、且核准閘門行為不受影響；驗收條件是全套 pytest 通過加上狀態摘要不再累積誤導性的 open 計數。這份提案沒有被實作、沒有被測試、沒有產生任何 diff——三個「沒有」寫得這麼用力，因為完成式的誘惑就是這麼大：把「打算做」寫成「做了」，只需要改一個動詞，而讀者完全無法從文字分辨。

三個案例合起來就是本篇的全部方法論：授權內的修正，交付變更加驗證證據；驗證證據本身也要標明哪些可被獨立重驗；授權外的發現，交付提案加驗收條件。三者共用同一條底線——文字裡的每一個完成式，背後都要有一次真實的執行。

修東西不難，難的是修完還敢讓人查。敢讓人查的修正才叫工程，其他的叫許願。