這是系統性的問題。

建議為什麼會消失

調查代理人完成分析後，輸出三條行動建議。PM 認為都合理，但在轉換為 Ticket 的過程中，不知不覺只處理了第一條，後兩條就這樣掉落。

沒有人刻意忽略。問題在於缺乏機制：建議產生後，沒有任何地方強制追蹤它的狀態，也沒有把建議和驗收條件連結起來的橋樑。建議存在於報告裡，但沒有人對它的去向負責。

四種狀態，對應四種歸宿

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

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

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

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

採納後的雙向連結

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

驗收時的強制檢查

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

這讓建議追蹤從「應該做」變成「必須做」，不再依賴個人記憶。

實際範例

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

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

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

責任明確化

建議追蹤的本質是讓每條建議都有人負責。每個決策都有理由，每個採納都有對應的驗收條件，沒有任何建議可以在沒有決策的情況下消失。

引入這個機制後，不需要再追問「那個建議後來怎麼了」。答案永遠在追蹤表裡。