プラン

1つのpull requestを超える規模の作業に対して段階的に納品し、実装前に承認ステップを設けます。

1つのプランは、タスクを段階にまとめた順序付けられたセットです。コードを記述する前にプランを承認します。

特定の順序で複数の変更が必要な場合や、全体像を把握した上で実装を決定したい場合に利用します。

ライフサイクル

計画立案は独立したステージであり、即座に変換されるわけではありません。

承認と同時に実行することも、承認後に開始することも可能です。

プランがほぼ完成している場合、修正を施せばアーキテクトがコードベースに関して得た知見を活かし、フィードバックを反映できます。リセットするとそれらの情報が失われ、一からやり直すことになります。

全体のアプローチが誤っている場合はリセットし、アプローチは正しいが詳細が不十分な場合は修正しましょう。修正の方がはるかにコストが低く、却下されたプランの内容は無駄にならず、次回の試みの入力として活用できます。

実行中のプランは一時停止、再開、キャンセルが可能で、各段階の進捗を確認できます。また、プランをクローンすることもでき、これはうまく機能した構造を繰り返し利用するための実用的な方法です。例えば、別のサービスへの移行処理などに適用できます。

完了したプランはアーカイブされ、アクティブなビューを整理できます。

プランのタスクごとに個別のpull requestが作成されるわけではありません。各タスクは独自のブランチで作業し、共有されたレーン分岐；作業が条件を満たすと、その分岐はベースブランチに対する単一のプルリクエストとして昇格されます。

task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘

そのため、途中段階のものを個別に承認するのではなく、変更全体が確認できる状態で一度だけ機能をレビューできます。

クロスプロジェクトプランは例外です：レーンとは異なるプロジェクトに属するタスクは別途昇格されるため、リポジトリごとに1つのpull requestが生成されます。pull requestは2つのリポジトリにまたがることはできません。

フェーズは順序付けのためのものであり、並列実行のためのものではありません。キャパシティに余裕があればフェーズ内のタスクは並列に実行可能ですが、次のフェーズは現在のフェーズが完了するまで待機します。

並列実行可能なタスクが10件あり、エージェントスロットが1つしかない場合でも、タスクは順番に実行されます。構造自体がキャパシティを生み出すわけではありません — 詳細はこちらを参照してください。キャパシティとエージェントスロット.

選択によって決定します。段階的作業プランまたは実行可能なタスクが1つルーティングステップにおいて、ご依頼内容を分析して代わりに判断するものは存在しません。

判定基準はレビュー可能性です。同僚が一度で読み終えられる長さのpull requestがタスクであり、複数の順序付けられた変更が必要な場合はプランとなります。

規模が非常に大きな作業においてタスク単位で推測して進めると、よりリスクの高い誤りを招きます。途中で作業が行き詰まり、無駄な手間が生じる可能性があるからです。一方、プラン単位で推測して進めると、本来不要な承認ステップが余計に発生します。

プランには、出力物が次の段階に進む前に満たすべき条件を定めるデリバリーゲートを設定できます。詳細はこちらをご覧ください：品質ゲート.