用途
Orchestrator 是一个 Spec-Driven Development（SDD）路由器。当用户说“构建 X”“实现 X”“添加功能 X”而没有指定阶段时，或询问“我们该如何构建 X？”“下一步是什么？”时，它负责判断该变更应获得多少流程投入，并引导加载相应的阶段技能。它本身不持有任何阶段内容，而是围绕三个单一归属文件运作：references/size-tiers.md（定义 T0-T3 层级及对应流程路径）、references/lanes.md（唯一存放模型名称的地方，指定构建和评审所用模型）、references/coding-principles.md（代码编写原则、T0/T1 计划格式、不可达场景定义以及每个任务简报携带的 builder 块）。
主要能力
- 层级选择（Step 0）：始终先阅读 references/size-tiers.md，选择 T0 / T1 / T2 / T3，并用一行话向用户说明理由。T0/T1 还需附上假设行和 step → verify 检查计划。层级决定后续运行表格中的哪些行、多少评审者以及循环允许的评审轮数。工作变大或风险变高时层级可升，但绝不静默降级。
- 阶段路由：根据当前状态决定加载哪个阶段技能，包括 grill（硬化计划）、spec（规格回合、澄清、计划回合、可选工单回合）、test-evals（为计划中的测试用例编写 RED 测试并运行至失败）、build（实现代码，按层级进行逐任务评审、最终集成评审和收敛循环）、review-commit（两轴通过 → R1 → 预算内确认轮 → 提交/部署门禁）。
- 两条执行路径：Path A——子代理驱动（默认，T2/T3），grill → spec → test-evals → build → review-commit，每个任务由新的实现者子代理完成并逐任务评审；Path B——单一 CLI 代理（T1，或 size-tiers.md 规则 7 下的 T2 绿地项目），spec（规格和计划回合）→ test-evals → builder lane CLI → review-commit，规格喂给一份自包含实现简报，由 review-commit 的循环作为质量门禁。
- 路由规则：层级优先，始终执行 Step 0；计划模糊则 grill；无规格且为 T2/T3 则 spec 规格回合，T1 则在计划头部放 3-6 条验收标准；有规格无计划则 spec 计划回合；需要并行单元则 spec 工单回合（可选）；有计划无测试则 test-evals；测试 RED 未构建则 build；所有任务完成则收敛循环（受层级上限约束）；需要评审差异则 review-commit；定期架构检查使用 improve-codebase-architecture（技能外）；用户说“直接构建”则视为 T0 或 T1，跳过 grill 和规格回合并说明，评审步骤仍按层级执行。
- 测试归属：计划命名每个测试用例（行为、接缝、期望值及其来源）；test-evals 编写这些测试并运行至 RED；build 实现者使其 GREEN 且不重写测试；实现者仅为计划遗漏的行为添加测试（构建中发现的缺陷），遵循 TDD 并在报告中列出。
使用方式
快速开始：Step 0 选择并说明层级；计划模糊则 grill；spec 规格回合 → .hermes/specs/（T2/T3），如有标记则澄清；spec 计划回合 → .hermes/plans/（工单可选）；test-evals → 计划的测试用例的 RED 测试；build → 按层级逐任务评审 → 最终评审 → 收敛；review-commit → Step A → R1 → 预算内确认轮 → 门禁。每次只加载一个阶段技能，以节省上下文。
适用场景
适用于用户提出构建/实现/添加功能而未指定阶段、询问如何推进或下一步是什么、需要决定变更应获得多少流程投入的场景。不适用于用户已指定阶段（如“为 X 写规格”“评审这个差异”），此时应直接加载对应阶段技能。
限制
Orchestrator 本身不包含阶段内容，仅做路由；层级和评审规则由 references/size-tiers.md 等文件定义，模型名称仅在 references/lanes.md 中维护；任何实际部署无论层级都需要三评审者门禁。外部技能指针（kanban-orchestrator、improve-codebase-architecture、doubt-driven-development、review-lessons）属于技能外内容。