調查報告結束時留下的建議清單（建立 W4-007、改進 W4-008、考慮 W4-009）在產出當下都成立，而它們接下來會經過一個沒有任何強制力的轉換：從報告變成 Ticket。轉換過程中第一條通常會被處理，其餘停在報告裡。

這不是誰忽略了什麼，是清單本身沒有狀態欄位。

建議為什麼會消失

調查完成後輸出三條行動建議，三條都被認為合理，而轉換為 Ticket 的動作一次只做一條——做完第一條之後，回到清單的動作沒有任何東西在提醒。

缺的是兩個機制：建議產生後沒有地方記錄它的狀態，建議與驗收條件之間也沒有連結。建議留在報告裡，而報告不會被再打開。

四種狀態，對應四種歸宿

每條建議都必須從「待決定」進入以下三種狀態之一，任務開始執行前不能還掛在待決定。

採納：決定實作。但採納不只是打個勾，必須把建議轉換為具體驗收條件，納入 Ticket 的 Acceptance Criteria，讓它在驗收時可以被明確確認。

拒絕：決定不做。拒絕是合理決策，但必須說明原因——範圍超出、成本太高、已有替代方案。沒有理由的拒絕等同於忽略。

延後：認可價值但現在不是時候。延後必須標註目標版本，否則和被遺忘沒有差別。

採納後的雙向連結

建議被採納後，在驗收條件中新增對應項目，並標註來源指回原始建議。建議追蹤表指向驗收條件編號，驗收條件表引用建議來源——雙向連結讓日後的審查可以追溯整個決策脈絡。

驗收時的強制檢查

Ticket 申請完成時，驗收者必須確認：所有建議都離開了待決定狀態、採納的建議已轉換為驗收條件並完成、拒絕的建議有明確理由、延後的建議有目標版本。任何一項未達成，驗收失敗。

這讓建議追蹤從驗收之外的自覺動作，變成驗收條件的一部分。

走一次完整流程

調查報告提出兩個建議：建立專責驗收代理人、建立自動化驗收 Hook。

第一個採納，對應驗收條件 AC-001。第二個因為架構尚未支援而延後到 v0.32.0，並建立追蹤 Ticket。

驗收時兩條建議都已離開待決定狀態：AC-001 對應的工作完成，延後的建議有明確去處。驗收通過。

這套機制改變的是什麼

每條建議都有一個決策、每個決策都有理由、每個採納都有對應的驗收條件——三者合起來讓「建議消失」需要一次明確的違規，而不是自然發生。

「那個建議後來怎麼了」的答案住在追蹤表裡，不住在記憶裡。

驗收條件本身怎麼寫成可勾選的形式，走 驗收條件是一份契約。