实现 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 引用 | 验证 | 完成标准 |
|---|
变更类型：
- ADD
- MODIFY
- REMOVE
- CONFIGURE
- MIGRATE
- TEST
- DOCUMENT
- VERIFY
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
重要
不要在此技能中估算小时/天数/故事点。 工作量估算是单独的关注点。