有一段時間，我手上同時有幾個 repo 在修改。每個 repo 都開了不少 issue，有些已經開始做，有些正在等 review，也有一些做了一半停在那裡。

我想用一個頁面看到目前的整體進度，於是做了 GitHub dev-status。它不會改 GitHub 上的資料，只會讀取各個 repo 的 issue，計算 task list 裡有多少 checkbox 已經勾選，再顯示成進度條。

頁面做出來以後，我才回頭確認一件很基本的事：那些 checkbox 是誰勾的？

答案是 coding agent。

我讓 agent 完成一項工作後回到 issue 打勾，Dashboard 再把勾選數量換算成百分比。也就是說，頁面可以正確顯示 GitHub 上的數字，卻無法判斷那些數字是不是真的代表工作完成。

當時我在 issue 裡直接寫下這個限制：

工具本身不會驗證真假。顯示的進度條要是真的，靠的是 coding agent 的紀律。

這段紀錄現在還留在 cyclone-agent-config issue #70。它也成為我後來修改工作規則的起點。

原本的需求很難驗收

我以前交代工作時，常直接說「幫我改一下這個功能」或「把這一段整理好」。agent 會讀現有檔案、選一個它認為合理的做法，完成後回報結果。

如果結果看起來正常，我通常就往下一件事走。但這裡有兩個判斷其實都由同一個 agent 完成：它先決定要改到什麼程度，再判斷自己是否已經做完。

這不是 agent 故意填假進度，而是我沒有先提供可以從外面檢查的標準。它只能依自己的理解做事，也只能依自己的理解勾選完成。

後來我開始在開發型 issue 裡寫驗收 task list。每一項都要能回答三件事：這次要改到哪裡、要用什麼方式檢查，以及看到什麼結果才算通過。

例如，「完成規則同步」太模糊。比較能驗收的寫法是：四種 agent 的規則檔都必須包含同一項要求，執行安裝腳本後，再跑 audit 指令確認四邊內容一致。這樣檢查的人不需要猜 coding agent 當時的想法，只要照著指令驗證結果。

我也會把這次不做的事情寫進 issue。agent 很容易在讀程式時發現附近還有其他問題，然後順手一起處理。那些建議可能沒有錯，但會讓原本可以驗收的範圍越長越大。非目標寫清楚後，至少能知道哪些改動應該留到下一次。

checkbox 要在工作進行時更新

issue #70 最後訂下的規則是：開發型 issue 必須有驗收 task list；完成一項，就在當下更新一項，不要等全部做完後再回來一次勾完。

原因不是要把流程弄得很正式，而是隔一段時間再補紀錄時，很容易只留下最後成功的版本。中間曾經卡在哪裡、哪一項其實還沒驗證，通常會被省略。

這條規則實施後，進度頁面仍然只是讀取 checkbox。它沒有突然獲得判斷真假的能力。差別是 checkbox 背後開始有比較清楚的驗收條件，也能沿著 issue、PR 和測試結果往回查。

所以我現在不會只看進度顯示百分之百。我還會看每一格是依什麼條件勾選，以及對應的證據放在哪裡。Dashboard 幫我找到工作狀態，是否完成仍要由驗收結果決定。

明天

寫得出驗收條件以前，我得先知道自己到底要做什麼。明天會寫我怎麼讓 AI 在動工前一次問一題，把原本只有一句話的想法整理成規格。