這才建立了 5W1H 自覺決策方法論：在建立任何任務之前，必須強制回答六個問題。不是「可以回答」，而是「必須回答」，任何一個缺失都阻止任務建立。

為什麼直覺判斷不夠用

直覺判斷的門檻太低。任何模糊的想法都可能直接變成任務被付諸實作，等發現重複了或架構位置錯了，才知道白花了時間。

5W1H 框架在任務建立的那一刻設置強制思考關卡。只有通過六個問題，任務才能被建立。

六個問題，六個層次的自覺

Who：責任歸屬，防止重複實作

Who 問的不只是「誰來做」，更重要的是「有沒有人已經做過了」。在我們的協作模式中，Who 必須明確標記執行者和分派者兩個角色，格式如：「parsley-flutter-developer（執行者）由 rosemary-project-manager（分派者）分派」。

這個格式強制一個邊界：主線程不應自己寫程式碼，職責是設計任務、分派任務、驗收結果。如果任務標記為主線程執行但類型是程式碼實作，系統直接阻止。

執行 Who 前要先做四步檢查：搜尋現有 Domain 是否有相同功能，確認既有 Service 是否已實作，查看測試覆蓋是否涵蓋，最後才決定是重用還是新建。Domain 中已有相同功能就禁止新建，責任不明就禁止執行。這兩條規則消滅了大部分重複實作。

What：功能定義，單一職責的守門員

What 要求明確說出具體的輸入輸出、業務行為和異常處理。合格的 What 必須能一句話描述完且無法再拆分。

「書籍處理——包含驗證、儲存、查詢等」不合格。「驗證輸入字串是否符合 ISBN-10 或 ISBN-13 格式，輸入 String isbn，輸出 ValidationResult，空字串拋出 ValidationError」才是。

職責不清就禁止執行，與既有功能重疊就整合，包含多個不相關職責就拆分。

When：觸發時機，副作用要完整識別

When 要求明確說出觸發事件，不是「書籍資料需要驗證的時候」，而是「使用者完成 ISBN 條碼掃描，觸發 ISBNScannedEvent，副作用包含觸發書籍資訊查詢和更新 UI 狀態，整合到 ScanTask 聚合根的事件系統」。

副作用未識別是 When 的紅線。連鎖反應沒有提前想清楚，後來就是難以追蹤的 bug。

Where：架構位置，確保層級正確

Where 決定功能在 Clean Architecture 中的位置。不是「在需要的地方執行」，而是「Domain Layer，BookValidator 位於 Book Aggregate，由 AddBookUseCase 呼叫，呼叫路徑是 UI → UseCase → Domain → Validator」。

位置錯誤就重新定位，不能為了方便就地執行。跨層級混亂就重新架構，不妥協。

Why：動機驗證，識別逃避性開發

Why 是六個問題中最重要的，因為它直接對抗最常見的開發陷阱——逃避。

合格的 Why 必須有需求文件編號，能說明具體的使用者價值和場景。「系統需要更多驗證」不合格，它沒有需求依據，而且可能只是為了逃避更難的問題。

遇到這些語言會立即阻止：「先做簡單的」（逃避複雜問題）、「順便加個功能」（缺乏需求）、「優化一下效能」（可能在迴避功能問題）。

How：實作策略，任務類型的強制標記

How 要求明確實作策略，並強制標記任務類型，格式是 [Task Type: XXX]。六種類型：Implementation（程式碼實作，必須由執行代理人執行）、Dispatch（任務分派，主線程執行）、Review（驗收，主線程執行）、Documentation、Analysis、Planning。

這個標記讓 Who 和 How 的合規性可以被自動檢查：How 標記為 Implementation 但執行者是主線程，系統直接阻止；Dispatch 類型的任務執行者是代理人，同樣阻止。

「先建立基本功能之後再加測試」是直接違規，任何臨時解法都禁止。

Who 和 How 的聯動檢查

正確組合：Implementation 搭配執行代理人，Dispatch/Review 搭配主線程。違規組合：Implementation 搭配主線程（主線程不應寫程式碼），Dispatch 搭配代理人，缺少執行者/分派者標記。

這個機制解決了一個真實痛點：主線程在時間壓力下直接修改程式碼，繞過代理人執行的設計。有了 How 的任務類型標記和 Who 的格式要求，這種行為在任務建立階段就被攔截。

逃避語言清單

框架持續更新一份逃避語言清單，分五類：

• 品質妥協：「太複雜」「先將就」「暫時性修正」「症狀緩解」、“workaround”、“hack”、“quick fix”
• 簡化妥協：「更簡單的方法」「簡化處理」——通常意味著在迴避真正的設計問題
• 擱置問題：「架構問題先不管」「技術債務之後處理」——發現了卻不解決，最危險
• 測試妥協：「簡化測試」「基本測試即可」
• 模糊詞彙：沒有具體指標的「優化」「自動」

偵測到任何逃避語言，系統立即阻止並要求修正。

Hook 系統：讓規則有牙齒

框架的執行依賴 Hook 系統。TodoWrite 工具使用前，Hook 檢查 5W1H 完整性；任何一個 W 或 H 缺失，操作立即阻止；發現逃避語言，進入修復模式。

修復機制：阻止操作 → 明確說明缺失哪個項目 → 要求補充 → 再次驗證。

這個框架改變了什麼

最明顯的感受是對話品質變了。以前任務可能只有「實作書籍驗證功能」；現在必須帶著完整的 Who（誰來做、是否已存在）、What（具體輸入輸出）、When（何時觸發、有哪些副作用）、Where（架構層）、Why（需求來源）、How（任務類型和策略）才能被建立。

很多模糊的想法在回答六個問題的過程中就自然消失了——它們根本過不了關。

TDD 走得好好的：Phase 1 設計介面，Phase 2 寫測試規格，Phase 3 實作，Phase 4 重構評估。Ticket 系統也運作正常：建立、認領、完成、歸檔。但這兩套系統各走各的路。結果是開發者在 Phase 3 開始實作時，才發現手上的任務其實包含三件事。或者更糟：沒發現，就這樣把三件事塞進一個 Ticket 完成了。

問題根源很清楚：Ticket 設計決策沒有固定時間點，也沒有固定標準。有人在需求進來時就設計 Ticket，有人在 Phase 1 結束後，有人在開始實作前隨手建一個。技術債務藏在職責混亂的 Ticket 裡，等到 Phase 4 才浮出水面，代價已經翻了好幾倍。

解決方案不複雜，但需要紀律：把 Ticket 設計決策集中到 Phase 3a，只用一套固定標準來判斷。

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 改變時，只需要動一個 Ticket。

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

依賴獨立性檢查：拆分後的部分之間會不會產生循環依賴？有時候兩件事看起來應該分開，但 Ticket A 的實作需要 Ticket B 完成，Ticket B 又需要 Ticket A 完成——這種情況保持為同一個 Ticket 才對。

決策邏輯直接：四項全部通過就繼續執行，任何一項未通過就拆分。不確定的預設為未通過。過度拆分的代價，遠低於讓職責混亂的任務進入實作。

不確定時，選擇拆分

這條原則違反一些人的直覺：任務感覺稍微大了一點，但四大檢查又沒有明確說要拆，這時候怎麼辦？

拆。

原因是非對稱性。拆了但其實不需要拆，代價是多幾個 Ticket、多一些追蹤開銷。沒拆但其實應該拆，代價是職責混亂的實作、測試難以隔離、Phase 4 牽一髮動全身。後者的代價明顯更高。

拆分之後

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

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

一個細節：拆分出來的每個 Ticket 本身也要通過四大檢查。如果某個拆出來的 Ticket 還是不通過，繼續拆。

在實作中發現需要拆分

有時 Phase 3a 評估沒問題，但 Phase 3b 實作途中才發現任務包含多個職責——這表示 Phase 3a 有遺漏。

正確做法：停下來，回到 Phase 3a 重新評估，拆分，從拆分後的第一個 Ticket 重新開始。

這聽起來很傷，但繼續實作一個已知職責混亂的任務，只是在未來製造更大的麻煩。

積極派發子任務

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

目的是保持可追蹤性。每個被處理的問題都有對應的 Ticket，日後審查開發歷程時，能清楚看到每個決策的前因後果。

整合之後

整合後得到的不只是更整齊的任務管理。Phase 3b 的開發者拿到手的每個任務都是職責明確的，不需要在實作途中自己判斷「這個應不應該一起做」。Phase 4 的重構評估也更聚焦，每個 Ticket 邊界清晰，影響範圍好估計。

這套整合需要紀律——Phase 3a 的四大檢查不是走過場，決策如果散落在各個階段，整合就失去意義。

但兩套系統會相互強化：好的 Ticket 設計讓 TDD 執行更流暢，嚴格的 TDD 流程讓 Ticket 的職責判斷更有依據。

生命週期總覽

 1需求/問題產生
 2    |
 3    v
 4建立 Ticket (/ticket create)
 5    |
 6    v
 7Ticket 狀態: pending
 8    |
 9    v
10認領 Ticket (/ticket track claim)
11    |
12    v
13Ticket 狀態: in_progress
14    |
15    +-- 正常完成 --> /ticket track complete --> 狀態: completed
16    |
17    +-- 無法繼續 --> /ticket track release --> 狀態: blocked
18    |                                              |
19    |                                              v
20    |                                         升級到 PM 處理
21    |
22    v
23完成

這套系統的核心目標是將任務需求有邏輯地拆分拆細。任務進來後先分析，拆分成平行的子任務；子任務若仍太大，可繼續往下切分。執行時從最底層開始，完成後檢查平行任務，再往上驗收父任務，直到整個任務鏈完成。

任務拆小的好處：降低執行時的認知負擔，也讓驗收檢查更容易發現疏失。

Ticket 狀態定義

階段-標準流程對照表

每個生命週期階段都有對應的標準流程和提示，防止關鍵步驟被遺漏。

建立階段

認領階段

執行階段

完成階段

驗收後階段

任務鏈後續步驟建議

當 Ticket 完成時，系統會自動分析任務鏈狀態並建議下一步。

分析優先級

輸出範例

 1============================================================
 2[任務鏈後續步驟建議]
 3============================================================
 4
 5已完成: 0.31.0-W4-007.1
 6        [實作 track P0 功能]
 7
 8任務鏈進度: 1/3 completed
 9   Root: 0.31.0-W4-007
10
11建議下一步:
12   1. 0.31.0-W4-007.2
13      [實作 track P1 功能]
14      原因: 阻塞已解除（blockedBy 0.31.0-W4-007.1 已完成）
15      狀態: pending → 可認領

任務鏈 ID 格式

10.31.0-W3-002              # ticket-handoff 功能（根）
2├── 0.31.0-W3-002.1        # chain_analyzer 模組
3│   ├── 0.31.0-W3-002.1.1  # 問題修復
4│   └── 0.31.0-W3-002.1.2  # 測試補充
5├── 0.31.0-W3-002.2        # handoff_executor 模組
6└── 0.31.0-W3-002.3        # 文件更新

chain 欄位

根任務 0.31.0-W3-002 的 chain：

1chain:
2  root: "0.31.0-W3-002"
3  parent: null
4  depth: 0
5  sequence: [2]

子任務 0.31.0-W3-002.1.1 的 chain：

1chain:
2  root: "0.31.0-W3-002"
3  parent: "0.31.0-W3-002.1"
4  depth: 2
5  sequence: [2, 1, 1]

ID 正則表達式：^(\d+\.\d+\.\d+)-W(\d+)-(\d+(?:\.\d+)*)$

Ticket 建立流程

任務層級判斷

 1任務層級判斷
 2    |
 3    v
 4這個任務是否因為執行現有 Ticket 而產生？
 5    |
 6    +-- 是 → 來源 Ticket 是什麼？
 7    |       |
 8    |       └── 確定來源 Ticket ID → 建立該 Ticket 的子任務
 9    |           ├── 來源: 010.4 → 子任務 ID: 010.4.x
10    |           ├── 來源: 010.4.1 → 子任務 ID: 010.4.1.x
11    |           └── 來源: 010 → 子任務 ID: 010.x
12    |
13    └-- 否 → 建立新任務鏈（新的 Wx-00n）

核心判斷問題：「這個任務是在執行哪個 Ticket 時產生的？」若有明確來源，建立子任務；若無關聯，建立新任務鏈。

建立格式

 1---
 2id: {版本}-W{波次}-{序號}
 3title: {動詞} {目標}
 4type: IMP/RES/ANA/INV/DOC
 5status: pending
 6priority: P0/P1/P2
 7assignee: pending
 8created: {日期}
 9---
10
11# {Ticket ID}: {標題}
12
13## 目標
14
15{目標描述}
16
17## 驗收條件
18
19- [ ] {條件1}
20- [ ] {條件2}

Atomic Ticket 檢查

驗收條件格式要求

驗收條件必須符合 4V 原則：可驗證、可量化、可追溯、可記錄。

標準格式（表格式）：

1## Acceptance Criteria
2
3| #   | 項目       | 來源       | 確認方法   | 狀態 |
4| --- | ---------- | ---------- | ---------- | ---- |
5| 1   | {項目描述} | {來源引用} | {確認方法} | [ ]  |
6| 2   | {項目描述} | {來源引用} | {確認方法} | [ ]  |

Ticket 有效性驗證

有效 Ticket 定義

有效的 Ticket 必須滿足以下條件：

驗證時機

無效 Ticket 處理

無效 Ticket（缺少決策樹欄位）：

• 無法用於 Task 派發（被 Hook 阻止）
• 需要補充決策樹欄位才能使用
• 建議使用 /ticket create 重新建立

補充決策樹欄位

如果 Ticket 缺少決策樹欄位，可手動補充：

1. YAML 格式（在 frontmatter 中）：

   1decision_tree_path:
   2  entry_point: "第X層"
   3  decision_nodes:
   4    - layer: "X"
   5      question: "決策問題"
   6      answer: "答案"
   7      next_action: "下一步"
   8  final_decision: "最終決策"
   9  rationale: "決策理由"

2. Markdown 格式（在內容中）：

   1## 決策樹路徑
   2
   3### 進入點
   4
   5- **層級**: 第X層
   6- **觸發條件**: ...

Ticket 認領流程

認領規則

Ticket 執行流程

 1認領 Ticket
 2    |
 3    v
 4執行對應階段工作
 5    |
 6    v
 7更新工作日誌
 8    |
 9    v
10驗證驗收條件
11    |
12    +-- 全部通過 --> 完成 Ticket
13    +-- 部分通過 --> 繼續處理或升級
14    +-- 無法完成 --> 釋放 Ticket

完成檢查

Ticket 釋放流程

釋放時機

Ticket 類型說明

版本歷史

• v2.8.0 (2026-02-01): 取消驗收豁免機制，改為契約式驗收
• v2.7.0 (2026-02-01): 強化驗收代理人派發要求
• v2.6.0 (2026-01-31): 新增任務層級判斷規則
• v2.5.0 (2026-01-30): 新增階段-標準流程對照表和任務鏈後續步驟建議
• v2.4.0 (2026-01-30): 新增建議追蹤流程整合章節
• v2.3.0 (2026-01-30): 新增驗收條件格式要求章節
• v2.2.0 (2026-01-29): 新增任務鏈 ID 格式章節
• v2.1.0 (2026-01-27): 新增 Ticket 有效性驗證章節
• v2.0.0 (2026-01-23): 重構為 TDD 含 SA 前置審查流程版本