| name | full-execution-plan |
| description | Use when the user says "执行计划", "execution plan", "wave编排", "任务拆分", "交付计划", "sprint 规划", or has finished code-architecture.md and needs to split the work into executable waves. Produces execution-plan.md. Step 6 of 6. Not for code architecture design (Step 5). Not for writing code itself — this plans the execution sequence, it does not execute it. |
核心目标
将代码架构（Step 5）拆分为多个 Wave，每个 Wave 粒度约为一个 subagent 可高度专注完成的开发单元。
- Wave 拆分 — 每个功能/垂直切片 = 一个 Wave
- 依赖推导 — 从 Step 5 类方法时序图推导 Wave 间依赖（时序已到方法级，依赖可梳理）
- 串并行编排 — 明确哪些可并行、哪些必须串行
- 最终列表 — 共多少 Wave、串行还是并行
关键优势： Step 5 时序图已细化到类方法级，Wave 依赖关系能直接从时序图读出。
执行流程
按 ../full-shared/references/loop-skeleton.md（共享参考目录）的 6 步循环执行。（loop-method.md 的方法论仅 clarity 首次 read，本阶段无需 read。）
Step 1（交互+初稿）— Grilling 遍历 Wave 依赖树：
[状态追踪] 开始时调 design_status start_phase execution 标记阶段开始（会校验 code-arch 已 completed）。
有 design_status tool 优先用 tool：design_status(action: start_phase, phase: execution)；无 tool（Claude Code/Cursor/shell）用 CLI：design-status start-phase execution。CLI 完整用法见 loop-skeleton.md「CLI 完整用法」。
[按 loop-skeleton Step 1.0] grilling 前先获取已确认决策：
[复杂度档位] 先读 _progress.md 的 complexity_tier：L1 档跳过 context-builder（主 agent 直读 decisions.md + 必问决策点引用的上游章节）；L2/L3 派 context-builder。追踪/审查/重建帧的降级见 loop-skeleton「复杂度自评与降级档位·三档执行矩阵」。本阶段上游较多，派 context-builder subagent（fresh）读 {topic_dir}/decisions.md（本 topic 已确认决策）+ 相关长期文档（NFR.md/ADR/ARCHITECTURE.md）+ 上游 .md，输出「阶段工作摘要」（不可推翻决策清单 + 设计树入口 + 接口契约）注入主 agent context。grilling 不得重新确认已 confirmed 决策；每个 D 类决策拍板后按 Step 1.2 即时 append decisions.md。
提问从宽： Wave 编排、依赖推导、串并行多为技术推导，agent 自决为主。仅当出现"是否需要 Prefactor Wave""哪些 P3 真延后""并行组是否真不冲突"等只有用户能判断的点时才 ask_user。
Wave 编排（根：从时序图推导）
├── Wave 0: Prefactor → 是否有让后续更易的前置重构？
├── Wave 1: 首个垂直切片（P0/P1）
│ ├── 切穿哪些层？→ schema→API→逻辑→测试 全切
│ ├── blocked_by？→ Wave 0 or 无
│ └── subagent 配置 → 注入哪些上下文/读取哪些文件
├── Wave 2-N: 后续切片 → 并行还是串行？（看时序图依赖+文件冲突）
├── Wave N+1: 验收 Wave → blocked_by 所有功能 Wave，必须最后
│ └── 职责：读测试验收清单全量→跑测试→全 PASS 才算实现完成（闭环闸门）
└── P3 延后项 → 标注「后续迭代」+ 理由
遍历纪律：先走 Prefactor Wave（如有）和 P0 Wave——它们是后续 Wave 的依赖根。
从 code-architecture.md §4 时序图推导：功能 B 调用功能 A → Wave(B) blocked_by Wave(A)；同文件被多时序修改→必须串行。
编排末端强制加 Wave N+1「验收 Wave」（blocked_by 所有功能 Wave），它不做功能开发，只读测试验收清单全量→跑测试→全 PASS 才算实现完成（设计→实现的闭环闸门）。
[MANDATORY] ④性能混沌类缓解项编排（接收 nfr 路由契约）： 从④回灌表筛 验收方式=性能混沌 的缓解项，编排为独立 perf/chaos Wave 或 pre-prod gate（不混入功能 Wave——性能/混沌测试需独立负载·故障注入环境，与功能测试不同层）。该 Wave blocked_by 相关功能 Wave。无性能混沌类缓解项则跳过并注明。
按 references/vertical-slice.md 垂直切片原则（不水平切片，每 Wave 切穿所有层可独立验证）。
[MANDATORY] 定稿必须含「测试验收清单」章节——把⑤test-matrix 全量用例（来源 A 功能 + 来源 B NFR）按归属 Wave 列全，作为实现期的 Definition of Done。
初稿用 references/deliverable-template.md。
Step 1 末尾 — 机器结构检查前置（零成本提速）： 初稿写完后，主 agent 调 cw(action=clarify) / cw(action=detail) 触发 CW gate 的机器检查（CW gate 自动跳过 6c 总闸门检查——consistency-final.md 该文件 Step 6c 才产出，未到 6c 前必缺失），FAIL 当场修低级硬伤（验收清单缺用例/末尾验收 Wave 缺 blocked_by），不必等 Step 6。
与 Step 6 审查的分工：此处只杀机器可证的结构硬伤；Step 6 才是质量门（含红队反过度编排）。两者不替代——Step 6 审查前 CW gate 的机器检查 FAIL 仍硬阻断。
Step 2（追踪）— 2 组并行 fresh-context subagent（认知帧内聚，用 wait:false 同消息派发，见 loop-skeleton「subagent 派发工程规范」）：
为何拆 2 组（不拆 4）：3 个结构视角（切片独立性/依赖闭合/并行安全）同属"Wave 图结构审计"认知域，fresh context 已消除对话偏误，同域内一个 subagent 顺序切换帧的帧内偏误很低，拆 4 = 4x IO 换不来等量盲区消除（过度并行）。测试/实现闭环跨读⑤test-matrix↔⑥清单，是不同认知帧，独立成组。
组 A 机器化降级空间：Wave 编排机器化（CW gate 机器检查 + 结构检查）后，结构三视角（切片独立性/依赖闭合/并行安全）可退化为机器自检。当机器检查已覆盖这三项时，Step 2 只派组 B（测试闭环，1 个 subagent）即可，从 2 组并行降为单组——CW gate 的结构检查替代组 A，省一个 subagent。机器检查未覆盖前维持 2 组。
本阶段是机器化降级的范本：其他 full 阶段（①-⑤）已参照本模式在各自 Step 2 标注「机器化降级空间」，说明各自的 CW gate 机器检查覆盖了哪些机器可判视角、subagent 只保留哪些语义盲区工作。
| 组（认知帧） | 视角 | 主读 |
|---|
| 组 A：编排结构审计 | 切片独立性 + 依赖闭合 + 并行安全 | Wave 定义 + ⑤§4 时序图 + blocked_by + 文件影响集 + 并行组 |
| 组 B：测试闭环审计 | 测试闭环 + 实现闭环 | ⑤test-matrix ↔ ⑥测试验收清单 |
组 A 详细检查：每 Wave 可独立验证？非水平切片？/ Wave 依赖从时序图完整推导？/ 同并行组真不改同一文件？
组 B 详细检查：每 Wave 标注覆盖的⑤test-matrix 用例 ID（含来源 B NFR 用例），并集=全部？每个时序图 alt/else 异常分支落在某 Wave 覆盖里？/「测试验收清单」用例 ID 集合 = ⑤test-matrix 全量？末尾验收 Wave blocked_by 所有功能 Wave？每个功能 Wave 覆盖的用例 ID 都在清单出现？清单的「测试执行层」列与⑤§6 来源 B「强制层级」一致？
产出：组 A 写 tracing-round-{N}-structure.md，组 B 写 tracing-round-{N}-testclosure.md。轻量项目（单 Wave）可降级为单 agent。
Step 3-4 — gap 分流(F/K/D) → 收敛复核。 按 loop-skeleton.md。
Step 5（定稿+HTML）— 按 references/deliverable-template.md 定稿 execution-plan.md；派 fresh subagent 渲染 execution-plan.html（机制见 loop-skeleton.md Step 5b）（主角图：Wave 依赖 DAG 图，标注并行组）。
Step 6（审查）— 派 2 组并行 fresh-context 审查 subagent（对齐组 ‖ 红队组，按 ../full-shared/references/review-agent.md 规范 + loop-skeleton「subagent 派发工程规范」用 wait:false 同消息派发）。两组都经 CW gate 的机器检查（FAIL 硬阻断），再各跑认知帧：对齐组 5 维（内部一致性/上游对齐/可执行性/完整性/可视化）写 changes/review-execution.md，红队组 1 维（必要性/比例性，反过度设计）写 changes/review-execution-redteam.md。两组 APPROVED 后进 Step 6b 反哺检查（回扫①-⑤上游），再进 Step 6c。轻量项目可降级单组（review_mode: single，见 loop-skeleton Step 6 降级条款）。
Step 6c（全文档一致性终检）— 仅⑥阶段：编码前的总闸门。 派独立 fresh-context subagent，读取①-⑥全部 .md + CONTEXT.md + ⑤骨架代码，按 6 维做跨文档一致性审计（详见 references/consistency-check.md）。产出 changes/consistency-final.md（verdict: CONSISTENT / INCONSISTENT）。INCONSISTENT → 矛盾当 gap 回相应阶段 Step 3。CONSISTENT 才允许交接编码。
Phase Loop 机制
- 收敛失败 → 回 Step 1 调整 Wave 编排
- 依赖推导不出 → 回 Step 5 补充时序图细节
- 审查 CHANGES_REQUESTED → 审查意见当 gap 回 Step 3
- 一致性终检 INCONSISTENT → 矛盾当 gap 回相应阶段 Step 3（用例链断回⑤/⑥，决策被推翻回②/③ Step 6b 反哺流程，NFR 没落地回⑤/⑥，骨架漂移回⑤）
- 反哺触发上游修订（详见 loop-skeleton.md Step 6b）→ 上游 .md 更新后，本阶段可能需重新对齐 → 回 Step 2 重追踪
- Stagnation（连续 3 轮 gap 不降）→ 强制收敛
Self-Check
[MANDATORY] 禁止在未完成 loop-skeleton 全流程（含 Step 6 审查 APPROVED + Step 6c 一致性终检 CONSISTENT）时声称完成。
本地目录覆盖规则
- 主目录：
.xyz-harness/（项目根）
- 子目录：
${yyyy-MM-dd}-${主题简短标题}
- 路径：
.xyz-harness/${主题}/execution-plan.md + .html
- 不同主题不同子目录，禁止混放。 单次写入超 1000 字优先拆分子文档。
下游衔接
设计工作流全部完成并通过独立审查 + 一致性终检。 审查 APPROVED 且一致性终检 CONSISTENT 后向用户交接：
[状态追踪] 交接前调 design_status complete_phase execution 收尾——自动校验 execution-plan.md + verdict:pass + review APPROVED + consistency CONSISTENT，过了才标 completed（全流程完成）。
有 tool 优先用 tool：design_status(action: complete_phase, phase: execution)；无 tool 用 CLI：design-status complete-phase execution。
✅ ⑥执行计划 已完成并通过独立审查 + 全文档一致性终检。
产出：execution-plan.md + execution-plan.html（含「测试验收清单」）
审查报告：changes/review-execution.md（verdict: APPROVED）
一致性终检：changes/consistency-final.md（verdict: CONSISTENT）
🎉 设计工作流（6 步 + 骨架验证 + 一致性终检）全部完成！
下一步：编码实现
⚠️ 编码完成的定义 = 测试验收清单全绿（末尾验收 Wave 不绿 = 未完成）
⚠️ 编码全绿后须 /coding-closeout 收尾——把稳定结论沉淀进长期文档（ARCHITECTURE/PRODUCT/NFR/ADR/TEST-STRATEGY），否则随 topic 归档流失。
编码完成 ≠ 真正 Done；编码完成 + 沉淀归档 = Done（闭合设计→实施→沉淀管道）。
方式 A（推荐）：接入 coding-workflow — 启动 Phase 流程（Phase-test gate 以测试验收清单为验收基线）
方式 B：手动执行 — 每个 Wave 派一个 fresh subagent；末尾验收 Wave 最后跑
偏离通道：编码中发现用例设计错误/不可行，走 [DEVIATED] 登记（原因+用户确认），不可静默跳过
是否现在开始编码？
用户确认后才开始编码。
标记说明
| 标记 | 含义 | 修改约束 |
|---|
| [MANDATORY] | 流程强制要求 | 必须严格遵守 |
