schedule

スケジュール

.noodle/mise.json を読み込み、.noodle/orders-next.json に書き込みます。 ループは orders-next.json を orders.json にアトミックに昇格させます。orders.json に直接書き込まないでください。 スキーマの信頼できる情報源として、noodle schema mise と noodle schema orders を使用します。

完全に自律して動作してください。ユーザーに選択を求めたり、確認のために処理を一時停止したりしないでください。

一度に 1 つの計画

これはスケジュール設定における最優先ルールです。残りのフェーズがある計画のうち、優先度が最も高いものを選び、そのすべてをスケジュールに設定してください。複数の計画に作業を分散させないでください。1 つの計画を最初から最後まで完了すれば、出荷可能な成果が得られますが、複数の計画をそれぞれ 1 フェーズずつ進めても、使えるものは何もできません。現在の計画がブロックされている場合は、別の計画に切り替えず、空のオーダーで待機してください。例外として、共有インフラのオーダーは計画の各フェーズと並行して実行できます。

オーダーモデル

出力は {orders: [...]} です。各オーダーは、順番に実行されるステージのパイプラインです。関連する作業は別々のオーダーに分けず、1 つのオーダー内のステージにまとめてください。

ステージ

各ステージには do フィールド（タスクキー。登録済みのタスクタイプと一致する必要があります）があり、オーダー内で 1 つずつ実行されます。現在のステージが完了すると、ループは次のステージに進みます。

一般的なオーダーパイプラインは、実行、品質確認、振り返りの順に、それぞれ 1 つのオーダー内のステージとして実行します。

タスクタイプ

mise から task_types を読み込み、スケジュール可能なタスクタイプとその schedule ヒントをすべて確認してください。登録済みのタスクタイプはどれも、オーダー内のステージとして使用できます。各ステージで do を使い、タスクタイプを指定してください。

タスクを実行する

mise の backlog 配列から実行タスクをスケジュールします。順序 id には、バックログ項目の ID を文字列として使用します。

バックログ項目には必ず id と title があります。その他のフィールドはアダプターによって定義され、異なる場合があります。デフォルトのアダプター（todos.md）では、status、section、tags、estimate、plan が提供されます。カスタムアダプターには任意のフィールドが含まれる場合があります。不明なフィールドも有用なコンテキストとして扱ってください。

共有インフラストラクチャ： 複数の計画が共通のインフラストラクチャ（共有型、ユーティリティ、ベースパッケージ）に依存する場合は、計画の各フェーズより前に、独立したインフラストラクチャの順序を提案します。インフラストラクチャ作業の規模が大きい場合は、アダプターを使ってバックログ項目を作成し（noodle adapter run backlog add）、その項目の ID を順序 ID として使用します。

計画がある項目： バックログ項目に plan フィールド（brain/plans/29-foo/overview.md のような相対パス）がある場合は、計画の概要とフェーズファイルを読み、作業内容を把握します。未完了の各フェーズ（未チェックの - [ ] 項目）ごとにステージを設けて、1 つの順序をスケジュールします。order.plan には計画のパスを入力します。計画のコンテキストを注入するため、各ステージの extra_prompt にフェーズの概要と、フェーズ間の依存関係を設定します。

フェーズの並列化： 計画を読み、フェーズ間の依存関係を特定します。先行フェーズの成果物（共有型、API、スキーマ）に依存するフェーズは、順次実行するステージにします。コードベース内の独立した領域（別々のパッケージ、無関係な機能、ドキュメントとコードなど）を扱うフェーズは、同じ順序内の並列ステージにできます。判断に迷う場合は、順次実行するほうが安全です。ただし、実際の依存関係がない作業まで直列化しないでください。

計画がない項目： スケジュールする前に、複雑さを評価します。項目が単純（関心事が 1 つ、範囲が明確、小規模な変更）であれば、バックログ項目のタイトルと説明をプロンプトとして、単純な実行タスクをスケジュールします。項目が複雑（複数ファイルにまたがる、横断的、範囲が曖昧、またはコーディング前にアーキテクチャの概要を確認したい）であれば、計画優先の順序をスケジュールします。まず /plan を呼び出す prompt のみのステージ（do は指定しません）を設け、続いて adversarial-review ステージを設けて計画を検証します。品質確認や振り返りのステージは設けません。計画の成果物はコードではなく設計ドキュメントだからです。計画優先ステージで "do": "execute" を使用してはいけません。execute スキルはエージェントに実装を指示するため、計画スキルの「計画後に停止する」という指示と矛盾します。計画スキルは brain/plans/ にフェーズ分けされた計画を作成します。次のスケジュール実行サイクルでは、項目に plan フィールドが追加されているため、標準の execute → quality → reflect パイプラインで通常どおりスケジュールできます。

独立した順序： 順序には任意の ID を設定できます。バックログ項目と対応している必要はありません。独立した順序が完了した際の backlog done アダプター呼び出しは、完了済みにする項目が一致しないため、何も行いません。複数のバックログ項目に役立つ共有インフラストラクチャ、保守作業、横断的な作業には、独立した順序を使用します。

スケジュールする項目がない場合： 実行可能なバックログ項目がない場合（すべてブロック中、進行中、完了済みなど）でも、空の orders 配列（{"orders":[]}）を含む orders-next.json を書き込みます。これにより、スケジュール処理は実行されたものの対象が見つからなかったことをループに通知し、ホットループによる再起動を防ぎます。

フォローアップステージと独立したステージ

各タスクタイプの schedule フィールドには、そのタスクをいつ、どのようにスケジュールするかが記されています。順序内のフォローアップステージとして、独立した順序として、またはその両方としてスケジュールする方法です。mise の task_types からこれらのヒントを読み取り、それに従って順序を構成します。

最近のイベント

mise の概要には recent_events 配列が含まれます。これは、前回のスケジュール実行以降にループが発行したライフサイクルイベントです。これらはスケジュールの判断に用いるコンテキストであり、コマンドではありません。内部イベントと外部イベントを含むイベントタイプの一覧は、references/events.md を参照してください。

スケジュール設定におけるイベントの活用

イベントはコンテキストであり、コマンドではありません。何をスケジュールするか判断する際は、バックログの状態やセッション履歴と併せて検討してください。

• stage.failed または order.failed の後 — 失敗に対処するデバッグ用オーダーが必要か、または別のアプローチで項目を再試行すべきかを検討します。
• order.completed の後 — 後続作業（振り返り、ブロックされていた関連項目）を検討します。
• merge.conflict の後 — 該当するオーダーには手動での対応が必要な場合があります。すぐに再スケジュールするのは避けてください。
• ci.failed などの外部イベントの後 — 対応が必要と思われる場合は、調査または修正のオーダーをスケジュールすることを検討します。
• registry.rebuilt の後 — 新しいタスクタイプが利用可能になっている可能性があります。スケジュールの機会がないか、task_types を確認してください。

すべてのイベントに機械的に反応しないでください。状況に応じて判断します。長いパイプラインでステージが1つ失敗するのは通常のことですが、同じオーダーが3回連続で失敗する場合は、より根本的な問題があることを示しています。

スケジュール設定のヒューリスティクス

• 最も低コストのモード：タスクを処理できるプロバイダー／モデルのうち、最もコストの低いものを優先します。
• 明確な根拠：すべてのオーダーに、その配置の根拠となった原則またはルールを明記します。
• 失敗に時間制限を設ける：recent_history で項目が2回以上失敗している場合は、スケジュールから外すか、分割します。

モデルのルーティング

モデルの選択については、references/model-routing.md を参照してください。

ランタイムのルーティング

すべてのステージで、常に "runtime": "process" を設定します。sprites ランタイムはまだ開発中のため、現時点では使用しないでください。ディスパッチ先を明示するため、スケジュールするステージには常に "runtime" を含めてください。

出力

noodle schema orders に一致する有効な JSON を .noodle/orders-next.json に書き込みます。

オーダーの JSON の例と extra_prompt フィールドの使い方については、references/examples.md を参照してください。

原則

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