| name | wave-execution |
| description | 基于依赖关系的波次并行执行策略，融合 GSD wave-execution 模式。 将任务按依赖图分组为有序波次，同一波次内的任务可安全并行， 增强现有 parallel-execution 技能的任务编排能力。
|
Wave Execution
用途
- 把"按列表顺序逐个执行"改成"按依赖图分波次并行执行"。
- 适合
/team-plan 拆解出多个独立任务、且部分任务间存在依赖关系的场景。
- 与
parallel-execution（Git worktree 并行）互补：wave-execution 负责"什么可以并行"，parallel-execution 负责"如何物理并行"。
核心概念
波次（Wave）
将所有任务按依赖关系分组：
- Wave 0：没有前置依赖的任务，可以最先执行
- Wave 1：仅依赖 Wave 0 产出的任务
- Wave N：仅依赖 Wave 0 ~ N-1 产出的任务
同一波次内的任务之间没有依赖关系，可以安全并行执行。
依赖图构建规则
- 显式依赖：任务 A 的输入来自任务 B 的输出（接口契约、数据模型、共享模块）。
- 文件依赖：任务 A 和任务 B 修改同一文件或同一模块。
- 测试依赖：任务 A 的测试需要任务 B 的 mock 或 fixture。
- 部署依赖：任务 A 的部署要求任务 B 先上线。
默认做法
1. 解析任务列表
从 /team-plan 的 delivery plan 中提取任务列表，每个任务需包含：
- 任务 ID
- 影响的文件/模块
- 输入依赖（其他任务的产出）
- 预计工作量
2. 构建依赖图
任务 A (API 契约定义)
↓
任务 B (后端实现) 任务 C (前端骨架)
↓ ↓
任务 D (联调) ←←←←←←←┘
↓
任务 E (E2E 测试)
3. 分配波次
- Wave 0: [A]
- Wave 1: [B, C]（B 和 C 无互相依赖，可并行）
- Wave 2: [D]（依赖 B 和 C）
- Wave 3: [E]（依赖 D）
4. 执行波次
每个波次遵循：
- 启动：并行触发本波次所有任务
- 监控：跟踪每个任务的完成状态
- 门禁：本波次所有任务完成且通过 Pre-flight Gate 后，才启动下一波次
- 异常处理：
- 某任务失败但不阻塞其他任务 → 标记失败，继续其他任务
- 某任务失败且下游依赖它 → 暂停下游波次中依赖该任务的子集
- 关键路径任务失败 → 触发 Escalation Gate
5. 产出
波次执行完成后输出：
## 波次执行报告
- 总波次数：{N}
- 并行度峰值：Wave {X} = {Y} 个并行任务
- 关键路径：{任务序列}
- 完成状态：{成功/部分成功/失败}
- 失败任务：{列表}
与现有能力的关系
| 能力 | 职责 |
|---|
wave-execution | 确定"什么可以并行"（逻辑编排层） |
parallel-execution | 确定"如何物理并行"（Git worktree / tmux 层） |
/team-plan | 产出任务列表和依赖关系 |
/team-execute | 消费波次计划，按波次驱动执行 |
触发信号
/team-plan 产出超过 5 个任务且存在可并行子集。- 用户要求"加快交付节奏"或"并行推进"。
- 多个前后端任务可以在接口契约锁定后同时启动。
配套约束
- 依赖必须显式：不允许"应该没有依赖"的默认假设，必须逐任务确认。
- 冲突检测：同一波次内的任务如果修改同一文件，自动升级为顺序执行或拆分更细粒度。
- 回退到顺序：当并行执行引入额外协调成本（频繁 merge conflict、上下文切换过多）时，主动建议回退到顺序执行。
