Ticket 系統裡只剩「修復書籍搜尋問題」「要加那個功能」這類標題時，它已經失去了任務追蹤的作用：沒有驗收條件就無法判定完成，沒有步驟就無法判斷從哪開始，而幾天後回來看的人拿不回當初的判斷依據。

Ticket 承載的是任務的完整生命週期——狀態、欄位、進入條件，都要能被外部檢查。

四個狀態，一條主線

待執行（Pending）：Ticket 準備好而還沒開始。進入條件是標題格式正確、五個核心欄位填寫完整、前置依賴都已完成。

進行中（In Progress）：核心紀律是即時記錄，遇到問題就寫進日誌，不留到最後回憶。建議上限 8 小時——超過通常代表 Ticket 太大，要拆。

Review 中（In Review）：驗證的環節，重點聚焦在驗收條件：逐項打勾，通過或不通過。建議 1 到 2 小時內完成，避免卡住後續流程。

已完成（Completed）：不可逆的終態。進入條件是所有驗收條件打勾、Review 通過、測試全數通過、靜態分析零錯誤、工作日誌更新，缺一不可。

Ticket 標題：動詞加目標

標準格式是「動詞 + 目標」。動詞反映任務類型：「定義」用於介面或規範，「撰寫」用於測試文件，「實作」用於具體功能，「修復」用於 Bug，「重構」用於改善結構。

對比「做 Repository」與「實作 SQLiteBookRepository」：後者在領取前就交代了工作規模。

五個核心欄位

背景說明為什麼需要這個任務。判準是三個月後回來的人能不能只靠這一欄理解來龍去脈。

目標一句話說清楚要達成什麼，建議不超過 30 字。可驗證的目標：「實作 SQLiteBookRepository，符合 IBookRepository 介面，通過所有單元測試」。不可驗證的：「優化資料儲存」。

步驟列 3 到 5 個具體動作，每個指明操作對象與預期結果。它要回答的是「領取之後從哪裡開始」。

驗收條件是任務的契約，客觀可勾選。不是「程式碼品質良好」，而是「dart analyze 0 錯誤」；不是「測試通過」，而是「覆蓋率 100%，通過率 100%」。寫法見 驗收條件是一份契約。

參考文件連結設計文件、需求規格、相關 Ticket，讓執行時的上下文完整。

執行的七個步驟

領取前先確認依賴都完成、工作量合理，再標記進行中。

閱讀背景與目標，把參考文件看完再動手。

執行時遇到問題即時記進日誌。

自檢時逐項勾選驗收條件，全過才進下一步。

提交時標記為 Review，附上自我檢查結果。

處理 Review 結果：通過則關閉，未通過依反饋修正再提交。

記錄經驗：完成時回答學到了什麼、有什麼可改進、是否需要建立 error-pattern 防止重複。這一步最容易省略，而它是唯一讓知識離開單張 Ticket、進入系統的環節。

阻塞狀態要有出口

Blocked 最容易被誤用成「標記了就等著」。原則是阻塞不超過 24 小時，必須採取行動。

行動方式取決於原因：缺前置條件就派發前置任務、技術問題不清楚就建調查任務、需要決策就建評估任務。每個阻塞轉成一個有人負責的子任務之後，等待才會有結束的條件。

從「修復那個問題」到「修復書籍搜尋在 ISBN 格式不一致時回傳空結果的問題」，中間隔的是這套欄位與進入條件。

一張 Ticket 該切到多小，走 Atomic Ticket 方法論；完成之後的 Review 什麼時候跑，走 即時 Review 機制。