累積一批 Ticket 再一起 review 有一個結構性的代價：review 抓到第一張的架構方向有問題時，後面幾張已經建在那個方向上。修正的範圍不是一張 Ticket，是這一批。

即時 Review 機制的核心是一句話：Ticket 完成就 Review，不累積。

三個原則

即時觸發。Ticket 完成的當下就觸發，不等 Wave 結束、不等當日收工。錯誤的架構決定會在下一張 Ticket 開始前就影響後續設計，等待的成本隨後續張數線性增加。

30 分鐘完成。這個時間限制同時是設計訊號：一張 Ticket 的 Review 超過一小時，代表它太大，該在規劃時就拆。

標準清單。16 項固定檢查項，分功能正確性、架構合規性、測試通過率、文件同步性四類。不論由誰執行、在哪個時間點，判定標準相同。

怎麼跑

觸發：完成實作、驗收條件全滿足、測試全數通過、靜態分析零錯誤，狀態標為「Review 中」。

執行：30 分鐘內跑完 16 項。功能正確性 10 分鐘、架構合規性 8 分鐘、測試通過率 5 分鐘、文件同步性 2 分鐘，最後 5 分鐘記錄結果。

偏差糾正：發現問題照固定流程走——暫停、記錄根因、建修正 Ticket、執行、再 Review。流程結構化是關鍵：沒有既定下一步的時候，問題最容易被記下來然後留在那裡。

問題分三級

P0（阻塞）：功能錯誤、架構偏差、測試失敗。在 Review 通過前修正。

P1（重要）：邊界處理缺失、文件不完整。建 Ticket 追蹤，當前 Ticket 可先通過。

P2（建議）：命名改善、程式風格。記錄即可。

分級要同時滿足兩個條件：Review 保持快速，重要問題不被跳過。

超時是粒度訊號

Ticket 完成後 2 小時內開始 Review，目標 30 分鐘，最長 1 小時。超時的解讀是 Ticket 範圍太大，而不是 review 做得太慢——這個訊號讓 Ticket 的粒度可以被持續校正。

這套機制換到的是什麼

固定觸發時機與固定清單之後，「Review」從一件時機不定、標準不一的事，變成偏差被控制在單一 Ticket 範圍內的常規動作。

16 項清單另外帶來一個作用：Review 結果可以互相比較、可以追蹤，判定的依據離開了個人當下的感覺。

Ticket 在哪個狀態進入 Review、進入條件是什麼，走 Ticket 生命週期管理；Review 抓到的架構違規怎麼在 commit 階段就擋掉，走 架構合規交給機制。