實作工作分解結構（WBS）產生
目的
WBS 是「必須實作什麼」，而非工時估算。
請勿直接從 TDD 的散文描述跳躍到通用任務。
輸入必須包含已驗證的詳細設計。
需求
→ 差距分析
→ TDD
→ 設計工件
→ 已驗證的詳細設計
→ WBS 任務
→ 驗證
輸入
- 權威性需求
- 已驗證的差距分析
- 已驗證的 TDD
- 設計工件登錄
- 所有
DD_VERIFIED的詳細設計 - 詳細設計驗證報告
- 若有可用的測試設計
- 當前儲存庫
1. 任務推導
僅從已驗證的設計決策推導任務。
任務類別：
- 產出程式碼
- API/合約
- 整合
- 資料/持久化
- 設定
- 遷移/相容性
- 測試
- 建置/部署
- 文件
- 僅限於已核准設計要求的清理工作
請勿加入「有也不錯的重構」。
2. 任務粒度
一個任務應夠小，以具備：
- 一個明確的成果
- 具體的原始碼/設計錨點
- 明確的相依性
- 可驗證的完成條件
但請勿將機械性的編輯動作分割成數十個無意義的微任務。
3. 穩定 ID
使用：
WBS-001、WBS-002、...
3A. WBS ↔ 設計語意身分
追蹤性並非僅僅因為 WBS 列中包含某個現有工件 ID 就能滿足。
對於每個 WBS 任務，請識別其主要的實作交付項目，並證明參照的設計工件確實擁有該交付項目。
所需的語意鏈結：
WBS 任務標題 / 目標 / 主要交付項目
↔ 登錄工件名稱 + 責任
↔ 已驗證的 DD 所擁有的實作單元
↔ TDD 設計決策
規則：
- 參照某個工件 ID 是必要條件，但非充分條件。
- 一個型別/類別/介面僅被某個 DD 提及、匯入、參照或連結，並不證明該工件擁有該實作單元。
- 如果一個 WBS 任務的主要交付項目是某個從屬型別，則下列之一必須為真：
- 登錄/DD 明確宣告該從屬型別位於擁有該工件的範圍內，或
- 設計工件分解必須被修正，以單獨追蹤該從屬型別。
- 請勿將一個以元件/型別 A 為標題的任務，對應到一個其登錄責任為元件/型別 B 的工件，除非該工件明確擁有 A。
- 如果無法證明語意所有權，則以
WBS_BLOCKED_DESIGN_GAP停止；不要從鄰近的 TDD 散文捏造出對應關係。
在產生 WBS 之前，請建立一個內部/公開的一致性表格：
| WBS ID | 主要交付項目 | 參照的工件 ID | 登錄的責任範圍 | DD 擁有的單元 | 語意符合？ | 證據 |
|---|
所需門檻：
WBS ↔ 工件語意身分 = 100%
4. WBS 表格
| WBS ID | 設計工件 ID | 任務 | 現有原始碼錨點 / 建議位置 | 變更類型 | 相依性 | 需求 ID | TDD/DD 參照 | 驗證 | 完成條件 |
|---|
變更類型：
- 新增
- 修改
- 移除
- 設定
- 遷移
- 測試
- 文件
- 驗證
5. 相依性有向無環圖 (DAG)
從工件相依性以及程式碼/執行時期相依性推導實作順序。
建立：
| WBS ID | 依賴於 | 相依原因 | 硬/軟 |
|---|
偵測循環相依性。
請勿僅根據檔案順序發明順序。
6. 驗證對應
每個會變更程式碼的任務都需要一個驗證路徑。
對應至：
- 需要更新的現有測試
- 新的測試 ID / 觀點
- 原始碼/建置驗證
- 執行時期/整合驗證
- 僅在自動化不可行時才使用手動驗證
7. 追溯性
建立：
| 需求 ID | 差距 ID | TDD 決策 ID | 工件 ID | DD | WBS ID | 測試/驗證 ID | 覆蓋率 |
|---|
不得有任何已驗證的設計工件被孤立。
8. WBS 閘門
在 WBS_READY_FOR_VERIFICATION 之前：
[ ] 所有 DD_VERIFIED 工件都有對應的實作/驗證任務
[ ] 每個 WBS 任務都追溯到已驗證的設計
[ ] 每個 WBS 任務的主要交付項目與其參照工件之責任/擁有單元在語意上相符
[ ] 沒有任何任務依賴於僅僅被提及的 DD/TDD 符號作為工件所有權的證明
[ ] 原始碼錨點/建議位置是具體的
[ ] 相依性是明確的
[ ] 會變更程式碼的任務都有完成條件和驗證
[ ] 當需要時，已包含設定/遷移/文件/測試工作
[ ] 未加入未經核准的架構/重構
[ ] 沒有 HIGH/CRITICAL 的原始碼差距隱藏在任務內部
狀態：
- WBS_READY_FOR_VERIFICATION
- WBS_BLOCKED_DESIGN_GAP
- WBS_BLOCKED_SOURCE_GAP
重要事項
請勿在此技能中估算工時（小時/天/故事點）。 工時估算是另一個獨立的主題。