Dev 是一个端到端开发工作流编排器，覆盖从需求到交付的完整功能实现周期。
┌─────────────────────────────────────────────────────────────────┐
│ Dev 工作流 (7步) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Step 0 Step 1 Step 2 Step 3 │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │选择│ → │需求│ → │分析│ → │计划│ │
│ │后端│ │澄清│ │调研│ │制定│ │
│ └───┘ └───┘ └───┘ └───┘ │
│ │ │
│ ▼ (需用户确认) │
│ Step 6 Step 5 Step 4 ┌───┐ │
│ ┌───┐ ┌───┐ ┌───┐ │执行│ │
│ │总结│ ← │验证│ ← │并行│ ← │DAG │ │
│ │报告│ │覆盖率│ │执行│ │调度│ │
│ └───┘ └───┘ └───┘ └───┘ │
│ code-dispatcher --parallel │
│ │
│ 硬性规则：所有代码变更必须通过 code-dispatcher 执行 │
│ 覆盖率要求: >= 90% │
│ 失败重试: 最多2轮 │
│ │
└─────────────────────────────────────────────────────────────────┘
整个工作流围绕两个核心目标展开：把需求吃透，把后端选择权交给用户。
很多 AI 编码工具的失败根源是一样的——需求还没理解清楚就动手。所以 Step 1 强制做 2-3 轮需求澄清，不允许跳过。同时，用户比系统更清楚当前任务适合哪个模型，所以 Step 0 让用户自己决定参与执行的后端组合，而不是系统硬分配。
有了这两个锚点，剩下的步骤自然按"谁来决策"划分：Step 0-1 是人说了算（选后端、定需求），Step 2-3 是 AI 干活人来审（code-dispatcher 做代码调研，用户审开发计划），Step 4-6 全自动跑（并行调度、覆盖率验证、出总结报告）。人工介入点压到最少，但关键决策不跳过。
主对话（Claude）只负责规划和协调，绝不直接改文件。实际执行全部交给 code-dispatcher。Worker agent 的定位很明确："execution backend, not the planning layer"——接到任务就跑到底，不中途停下来问问题。
这样做的好处是多层的：三个后端的超时、退出码、日志、进程管理全在 dispatcher 层统一处理；每次执行返回 SESSION_ID，后续可以 resume 复用同一个对话上下文；出了问题有结构化日志能定位到具体任务。规划和执行隔离，两边都不会互相干扰。
路由逻辑是按各后端的实际表现定的，不是按理论能力：
| 任务类型 | 后端 | 理由 |
|---|---|---|
default |
codex | 干活最细致，复杂逻辑和大规模重构交给它 |
ui |
claude | 组件、布局、样式、交互交给 claude |
quick-fix |
claude | 小修小补要快，claude 响应速度合适 |
docs |
claude | codex 写文档人机味太重，claude 文风自然得多 |
每种类型都有自己的 fallback 链，且只在用户允许的后端集合内选择：default 走 codex → claude，ui、quick-fix 和 docs 走 claude → codex。
任务之间天然是有依赖的——先分析才能设计，设计完了才能实现。但同层级内没有依赖的任务完全可以同时跑。DAG 拓扑分层正好解决这个矛盾：层内并行缩短总耗时，层间保序保证正确性。依赖失败时下游自动跳过，不做无用功。
这个数字不是自定义的，是跟着行业惯例走。常见测试实践会把覆盖率分成几个区间：60% 是及格线，75% 值得表扬，90% 是标杆，同时警告超过 90% 边际收益急剧下降。再往前追溯，80% 这个数字来自帕累托原则（80/20 法则）在测试领域的泛化引用，90% 是它的上浮版本，被大型工程团队的实践共同采用。SonarQube、JaCoCo、Codecov 等工具链也把 90% 作为推荐默认值，进一步固化了这个标准。
本质上，90% 是"核心路径全覆盖"和"边界场景测试成本过高"之间的平衡点。
快速失败原则的应用。1 轮可能只是偶发问题，多试一次合理；3 轮以上就该停下来让人看了。2 轮是自动重试和人工介入之间的分界线。
超过 2 轮通常说明任务拆分、需求边界或验证方式需要重新判断，不应继续自动重试。
该格式和 dispatcher 的 stdin 输入一致：---TASK--- 标记任务边界，---CONTENT--- 后面的内容原样交给后端。任务内容可以包含代码、Markdown、JSON/YAML 或 shell 片段，不需要额外转义。
并发调度用的是 Go channel-based worker pool，code-dispatcher 项目的选型。通过 ~/.code-dispatcher/.env 中的 CODE_DISPATCHER_MAX_PARALLEL_WORKERS 控制并发上限（最大100），防止后端 API 被打爆。信号量模式是 Go 里处理这类问题的标准做法。
SESSION_ID 机制的核心目的经常被误解。它不是为了处理超时或中断——那些是副作用。真正的目的是复用对话上下文。一个长任务可能分多轮人机交互，resume 让后续指令在同一个对话里继续，不用从零开始、不丢上下文。