用途
dwf-orchestrator 是 DWF（Dev Workflow）开发工作流的统一调度入口。它负责读取状态、判断阶段、分派子技能、维护状态机骨架，但不生成阶段文档正文，也不修改项目代码。
与旧的 dev-workflow 一体化技能不同，本技能把流程编排和阶段实现解耦：编排层只持有状态机与路由表，阶段产出由 dwf-requirement、dwf-design、dwf-development、dwf-coding 完成。
主要能力
- 管理 .dwf/state.json、_meta.json、_context.md、.dwf/pending/<迭代目录名>/state.json、spec 目录骨架等状态。
- 执行首次初始化、阶段推进、拆分迭代、迭代完成、新增迭代、暂停插队、重新开始、待确认事项处理、递延提醒、恢复或 state.json 重建。
- 分派到子技能时，读取并遵守对应子技能的 SKILL.md；子技能只处理当前阶段内容，队列结构仍由本技能控制。
- 统一控制队列变更：spec 入队、出队、active/pending/paused/done 切换、拆分兄弟 spec、优先插入。
- 统一发起待确认事项：逐项确认、已确认事项回写、未确认事项记录、激活 spec 前的递延提醒。
使用方式
先读本文件，再按动作读取引用文件：
- 写入、修复或解释 .dwf/state.json、_meta.json、_context.md、.dwf/pending/<迭代目录名>/state.json、spec 目录骨架前，读取 references/state-model.md。
- 执行首次初始化、阶段推进、拆分迭代、迭代完成、新增迭代、暂停插队、重新开始、待确认事项处理、递延提醒、恢复或 state.json 重建前，读取 references/orchestration-flows.md。
- 分派到子技能时，读取并遵守对应子技能的 SKILL.md。
每次触发流程：
- 读取 .dwf/state.json。
- 若不存在：若 .dwf/specs/ 也不存在，走首次初始化；若 .dwf/specs/ 仍在，按 state.json 缺失重建流程恢复。
- 若 specs 为空：项目处于稳定态。用户提出新变更时走新增迭代。
- 若有 active spec：按其 current_step 分派子技能；若用户提出紧急变更，走暂停与优先插入。
- 若无 active 但有 paused 或 pending：先按递延项提醒流程处理 .dwf/pending/ 中的未确认状态，再用 question 让用户选择恢复 paused 或激活首个 pending。
- 若 active.current_step == "code" 且实现清单全部完成并验证通过，走迭代完成。
分派子技能后，本次 orchestrator 编排动作结束。后续阶段必须等待用户再次确认或下一次触发后，重新读取 state.json 再分派。
阶段与分派目标
| current_step | 阶段 | 子技能 |
|---|---|---|
| requirements | 需求文档待确认 | dwf-requirement |
| design | 设计稿待确认 | dwf-design |
| breakdown | 需求分析待确认 | dwf-development |
| plans | 技术方案待选择 | dwf-development |
| todos | 实现清单待确认 | dwf-development |
| code | 编码执行中或待收尾 | dwf-coding |
默认阶段顺序：requirements → design → breakdown → plans → todos → code。实际推进以当前 spec 的 affected_stages 为准。
适用场景
- 用户要启动、继续、恢复或重启 DWF 开发工作流。
- 需要编排 .dwf/state.json、specs 队列、阶段推进与迭代管理。
- 存在 .dwf/state.json，或用户要求按开发工作流推进。
限制
以下规则不可违反：
- 只编排，不实现。不生成 01-需求/、02-设计稿/、03-需求分析/、04-技术方案/、05-实现清单/ 的正文内容，不修改工作区根目录下的项目代码。唯一例外：处理待确认事项时，可把用户的明确决策回写到对应阶段文档的“待确认项/待确认事项/待解决问题”段。
- 每次调用先读 state.json。state.json 与 _meta.json 分歧时以 state.json 为准并修正 _meta.json。
- 禁止未经确认的自动推进。阶段文档整体确认和阶段间推进都必须有显式用户确认。
- 禁止跳过阶段。用户说“直接写代码”“只是小 bug”不是跳过流程的理由。
- 队列变更由本技能统一控制，必须经 question 确认后写入 state.json，并同步 _meta.json。
- 状态只写 _meta.json，不重命名 spec 目录。
- 重新开始必须二次确认并限制删除范围，默认只删除 .dwf/；确需删除根目录项目代码时须先生成逐项待删清单并逐项确认。
- 全程使用中文（除非用户明确要求其他语言）。
- 待确认事项扫描不可跳过。
- 一次触发只执行一个编排动作。允许的复合动作只有：首次初始化后分派 requirements；新增/插队 spec 经确认后激活并分派其第一个阶段；恢复经确认后激活并分派当前阶段。
- 阶段推进后必须停下，不得自动调用下一阶段子技能。
- 禁止批量生成阶段产物。
状态摘要
.dwf/state.json 是工作流权威来源。顶层维护有序 specs 队列和 completed_specs 历史；每个 spec 目录内的 _meta.json 是镜像。完整字段、示例 JSON、目录结构和台账 schema 见 references/state-model.md。
spec 队列状态：pending（排队等待执行）、active（当前正在执行，同一时刻最多一个）、paused（被高优先级 spec 中断，保留进度待恢复）、done（已完成，从 specs 移入 completed_specs）。
阶段推进要点
子技能完成当前阶段后，只有在阶段文档整体已被用户显式确认时才能推进状态：判断用户确认、读取刚确认阶段文档检查待确认段、进入待确认事项逐项确认循环、将当前阶段加入 confirmed_stages、按 affected_stages 推进 current_step、同步更新 state.json 与 _meta.json 及顶层 updated_at，然后停止本次编排。
特殊规则：跳过设计稿时把 design_skipped 设为 true 并从 affected_stages 移除 design；plans 阶段必须由 dwf-development 给出至少两个方案经 question 供用户选择并写入 selected_plan；初始化 spec 的 breakdown 确认后若需求覆盖多个页面或复杂模块，必须询问是否拆分兄弟 spec；推进到 code 并完成编码验证后进入迭代完成流程。
待确认事项处理
阶段推进前必须读取刚确认阶段文档并解析标题 ## 待确认项、## 待确认事项 或 ## 待解决问题，列表项匹配 ^-\s+。逐项用 question 让用户选择“已解决，给出答案”“跳过，留待后续迭代”“已在文档中直接修改”。用户已确认或已修改的决策回写到对应阶段文档的待确认段，不写入 .dwf/pending/；用户跳过或未确认的写入 .dwf/pending/<迭代目录名>/state.json 中对应阶段数组（含 requirements、design、breakdown、plans、todos 五个数组字段）。任意 spec 即将转为 active 前，先扫描 .dwf/pending/*/state.json 中的未确认项，用 question 提醒用户选择逐项处理、全部继续递延或只处理来自本 spec 的项。