TDD 的四個階段（Phase 1 設計介面、Phase 2 寫測試規格、Phase 3 實作、Phase 4 重構評估）與 Ticket 的生命週期（建立、認領、完成、歸檔）各自運作良好，而兩者沒有銜接點時，會出現一個特定的失效：實作開始之後才發現手上這張 Ticket 其實包含三件事——或者沒發現，三件事就這樣被塞進同一張 Ticket 完成。

失效的來源是 Ticket 設計決策沒有固定時間點，也沒有固定標準。需求進來時設計、Phase 1 結束後設計、開始實作前隨手建一張，三種時機同時存在時，判斷依據也跟著浮動。職責混亂的 Ticket 帶著技術債走到 Phase 4 才浮出來，那時的修改範圍已經跨越多個已完成的實作。

收斂的方式是把 Ticket 設計決策集中到一個階段，用一套固定標準判斷。

Phase 3a 是唯一的決策點

第一條規則：Ticket 設計決策只在 Phase 3a 進行。

Phase 1 專注功能設計、Phase 2 專注測試設計，這兩個階段分心去設計 Ticket 結構會稀釋當階段的品質。到 Phase 3a 時手上已經有完整的測試規格，「這個任務需不需要拆分」在這個時間點才有足夠的資訊可以判斷，而且判斷結果直接決定 Phase 3b 怎麼執行——決策與執行相鄰。

Phase 3b 按 Phase 3a 的評估結果執行，Phase 4 做跨 Ticket 的重構評估、不新增 Ticket。

量化指標判斷不了職責

常見的拆分依據是量化估計：修改幾個檔案、幾個測試案例。這些數字有形狀，而它們量的不是職責。

一個修改 10 個檔案的任務，若全都針對同一件事（把某個 API 改名，所有用到它的地方跟著更新），那是原子任務，不需要拆。反過來，只改 2 個檔案，若同時做「驗證邏輯」與「效能最佳化」，就該拆成兩張。

工作量大小與職責數量是兩個獨立的維度。

四大檢查

四個問題確認同一件事：這個任務是不是只做一件事。

語義檢查：能用「動詞 + 單一目標」描述嗎。「實作 startScan() 方法」通過，「實作掃描功能和離線支援」不通過——任務的問題常常在名字上就看得出來。

修改原因檢查：這個任務只有一個修改原因嗎。這是 SRP 搬到 Ticket 層次：將來若要修改這張 Ticket，觸發修改的原因有幾個。同時受「API 規格變更」與「離線儲存格式變更」影響的是兩個原因，拆開之後 API 改變時只需要動一張。

驗收一致性檢查：所有驗收條件都指向同一個目標嗎。驗收清單同時包含「startScan() 通過測試」「stopScan() 通過測試」「離線快取功能正常」時，這張 Ticket 在追求三個目標。

依賴獨立性檢查：拆分後的部分之間會不會產生循環依賴。兩件事看起來該分開、而 Ticket A 的實作需要 B 完成、B 又需要 A 完成時，維持為同一張才對。

決策邏輯是四項全部通過就繼續執行，任何一項未通過就拆分。不確定的預設為未通過。

不確定時選擇拆分

四大檢查沒有明確說要拆、而任務的規模感偏大時，預設拆。

依據是代價的非對稱。拆了但其實不需要，代價是多幾張 Ticket 與追蹤開銷；沒拆但其實應該拆，代價是職責混亂的實作、測試難以隔離、Phase 4 的重構牽一髮動全身。兩邊的量級不同。

拆分之後

判定需要拆分時，Phase 3a 的工作是把任務分解成多張各自通過四大檢查的 Atomic Ticket，並建立它們之間的依賴關係（哪張必須先完成、哪些可以並行）。

規劃結果記錄到工作日誌，按 Wave 順序執行——有依賴的先完成，無依賴的並行。每張 Ticket 完成後立即 Review，不等全部完成再回頭看。

拆分出來的每張 Ticket 本身也要通過四大檢查；還是不通過的，繼續拆。

實作途中才發現要拆

Phase 3a 評估通過、而 Phase 3b 實作途中發現任務包含多個職責時，這代表 Phase 3a 有遺漏。

處理方式是停下來，回到 Phase 3a 重新評估、拆分，從拆分後的第一張 Ticket 重新開始。已知職責混亂的任務繼續實作下去，混亂會被寫進程式碼結構裡。

積極派發子任務

實作中遇到預期外的情況——發現新問題需要調查、範圍比預期大、需要做技術決策——原則是建立子任務，不在同一張 Ticket 裡處理所有事情。

作用是可追蹤性：每個被處理的問題都有對應的 Ticket，日後回頭審查開發歷程時，每個決策的前因後果都在紀錄裡。

整合之後的狀態

Phase 3b 拿到的每張任務都職責明確，實作途中不需要再判斷「這個應不應該一起做」。Phase 4 的重構評估也更聚焦——每張 Ticket 的邊界清晰，影響範圍可估。

兩套系統會相互強化：Ticket 設計讓 TDD 的階段執行不被拆分問題打斷，而 TDD 的階段順序讓 Ticket 的職責判斷有測試規格當依據。

四大檢查的完整定義與拆分範例，走 Atomic Ticket 方法論；測試該耦合行為而不是結構，走 行為優先的 TDD。