schedule

调度

读取 .noodle/mise.json，写入 .noodle/orders-next.json。 循环会将 orders-next.json 原子提升为 orders.json——切勿直接写入 orders.json。 使用 noodle schema mise 和 noodle schema orders 作为架构的事实来源。

全程自主运行。切勿要求用户选择或暂停等待确认。

一次只处理一个计划

这是调度的首要规则。选择优先级最高且仍有未完成阶段的计划，并安排该计划的所有阶段。不要把工作分散到多个计划中——端到端完成一个计划才能产出可交付的结果；每个计划各推进一个阶段，则什么可用的成果也产不出来。如果当前计划受阻，应保持空闲（生成空 orders），而不是切换到其他计划。例外：共享基础设施的订单可以与计划的各阶段并行执行。

订单模型

输出格式为 {orders: [...]}，其中每个订单都是由多个阶段组成的流水线，按顺序执行。将相关工作分组到同一订单的不同阶段中，而不是拆成多个订单。

阶段

每个阶段都有一个 do 字段（任务键，必须与已注册的任务类型匹配），并且在订单内逐个执行。当前阶段完成后，循环会推进到下一阶段。

典型的订单流水线：执行，然后质检，再然后复盘——全部作为同一订单中的不同阶段。

任务类型

从 mise 中读取 task_types，了解所有可调度的任务类型及其 schedule 提示。任何已注册的任务类型都可以作为订单中的一个阶段。使用每个阶段的 do 字段将其绑定到一种任务类型。

执行任务

在 mise 中为 backlog 数组中的任务安排执行。使用 backlog 条目的 ID（作为字符串）作为订单 id。

Backlog 条目始终包含 id 和 title。其他字段由适配器定义，可能各不相同。默认适配器（todos.md）提供：status、section、tags、estimate 和 plan。自定义适配器可能包含任意字段——请将未知字段视为有用的上下文。

共享基础设施： 当多个计划依赖共同的基础设施（共享类型、实用工具、基础包）时，请在计划的各阶段之前，提出一个独立的基础设施订单。使用描述性 slug ID（例如，"infra-shared-types"）。如果基础设施工作量较大，请通过适配器创建一个 backlog 条目（noodle adapter run backlog add），然后使用该条目的 ID 作为订单 ID。

带计划的条目： 当 backlog 条目包含 plan 字段（相对路径，例如 brain/plans/29-foo/overview.md）时，请阅读计划概述和阶段文件，了解工作内容。为每个尚未完成的阶段（每个未勾选的 - [ ] 条目）安排一个阶段，并将这些阶段加入一个订单。将计划路径填入 order.plan。在每个阶段使用 extra_prompt 注入计划上下文：阶段概要及跨阶段依赖。

并行安排阶段： 阅读计划以识别阶段之间的依赖关系。依赖先前阶段产出（共享类型、API、架构）的阶段必须按顺序安排。涉及代码库中独立区域（不同的包、互不相关的功能、文档与代码）的阶段可以作为同一订单中的并行阶段。拿不准时，按顺序安排更稳妥——但不要将不存在实际依赖的工作串行化。

不带计划的条目： 安排任务前评估其复杂度。如果条目简单（关注单一事项、范围明确、改动较小），请使用 backlog 条目的标题和描述作为提示词，安排为简单的执行任务。如果条目复杂（涉及多个文件、跨领域、范围模糊，或你希望先看到架构草图再编码），请安排一个先规划的订单：先安排一个仅包含 prompt 的阶段（不含 do），调用 /plan；随后安排一个 adversarial-review 阶段。不要安排 quality 或 reflect 阶段——规划产出是设计文档，而非代码。先规划的阶段不得使用 "do": "execute"——execute 技能会指示 Agent 实现代码，这与 plan 技能的“规划后停止”指令相冲突。plan 技能会将分阶段计划写入 brain/plans/；在下一轮安排任务时，该条目将包含 plan 字段，此时便可使用标准的 execute → quality → reflect 流程正常安排。

独立订单： 订单可以使用任意 ID——无需对应 backlog 条目。独立订单完成时，backlog done 适配器调用不会执行任何操作（没有匹配的条目可标记为完成）。共享基础设施、维护任务或服务于多个 backlog 条目的跨领域工作，可使用独立订单。

没有可安排的任务： 如果没有可操作的 backlog 条目（全部被阻塞、进行中、已完成等），仍须将 orders-next.json 写为包含空订单数组的内容（{"orders":[]}）。这会向循环表明已运行安排流程但未找到任务，从而防止循环热重启。

后续阶段和独立阶段

每种任务类型的 schedule 字段说明了何时以及如何安排该任务——作为订单中的后续阶段、作为独立订单，或两者皆可。请从 mise 中的 task_types 读取这些提示，并据此组合订单。

最近事件

mise 简报中包含一个 recent_events 数组——这是自上次安排运行以来由循环发出的生命周期事件。这些是安排决策的上下文，而非命令。完整的事件类型目录（内部和外部）请参阅 references/events.md。

使用事件安排任务

事件是上下文，不是命令。决定安排哪些任务时，应结合待办列表状态和会话历史进行考虑：

• 在 stage.failed 或 order.failed 之后——考虑是否需要安排一个调试订单，或者是否应采用不同方法重试该事项。
• 在 order.completed 之后——考虑后续工作（复盘、此前受阻的相关事项）。
• 在 merge.conflict 之后——受影响的订单可能需要人工处理；避免立即重新安排该订单。
• 在 ci.failed 等外部事件之后——如果看起来值得处理，可考虑安排调查或修复订单。
• 在 registry.rebuilt 之后——可能有新的任务类型可用；查看 task_types，寻找安排任务的机会。

不要对每个事件都机械地作出反应。要运用判断：长流水线中单个阶段失败很正常；同一订单连续失败三次则可能说明存在更深层的问题。

安排任务的启发式原则

• 最低成本模式：优先选择能够处理该任务且成本最低的提供方／模型。
• 明确说明理由：每个订单都必须指出其安排依据的原则或规则。
• 为失败设定时间限制：如果某事项在 recent_history 中失败了 2 次或更多次，请取消安排或拆分该事项。

模型路由

模型选择请参阅 references/model-routing.md。

运行时路由

始终在所有阶段设置 "runtime": "process"。sprites 运行时仍在开发中，目前不应使用。为已安排的阶段始终包含 "runtime"，以明确指定分派路由。

输出

将有效的 JSON 写入 .noodle/orders-next.json，并符合 noodle schema orders。

订单 JSON 示例和 extra_prompt 字段用法请参阅 references/examples.md。

原则

• [[cost-aware-delegation]]
• [[foundational-thinking]]
• [[subtract-before-you-add]]
• [[never-block-on-the-human]]
• [[guard-the-context-window]]