deliver-spec

仕様を実行する

基本原則

相応の検証と独立した最終レビューを行い、承認済みの成果を一つ提供します。リードはアーキテクチャ、統合、提供に責任を持ち、緊密に結合した作業や順次進める作業は、原則として自ら実装します。独立性、分離、または専門的な調査によってオーバーヘッドを正当化できる場合に限り、作業を委任します。利用可能なワーカーの数だけを理由に委任してはいけません。明確なオーナーシップ、外部アクションの権限、実行予算、呼び出しごとのマージ権限を維持します。Project のキューから作業を選んではいけません。

モードの選択

アクティブな run-github-project コントローラーから検証済みのチケット引き継ぎを受けた場合は、Project コントローラーの引き継ぎを読み、以下の単独実行時の承認、マージ、タイムアウトの規則に代えて、その手順を適用します。Project コントローラーがすべての共有状態とマージ権限を保持します。 直接名前を指定した仕様のリクエストには、以下の単独実行手順を使用します。すでに Project の実行がその issue を管理している場合は、そのコントローラーに戻します。

手順

1. 新しい状態から、指定されたソース、リポジトリ、承認済みコントラクト、および既存のブランチまたは PR を確認します。再開時は、実行に移る前に PR、正確なヘッド、チェック、フィードバック、および権限を照合します。統合作業の変更では、差分を取り込む前に、インストール済みのプランナーコントラクトと保持された作業を確認するため、Evidence and review を使用します。
2. 計画を立てます。現在の to-plan 計画があれば再利用します。なければ to-plan を呼び出し（ローカルソースの場合は会話モード）、その準備状況と公開ゲートに従います。fast path の条件を満たすソースには、代わりにその手順を適用します。ready-for-agent が付いていない GitHub issue では、まず triage を使用し、承認された結果を待ちます。自分でラベルを変更してはいけません。ローカルソースではトリアージを省略できますが、ステークホルダーによる明示的な承認が必要です。承認済みのローカルソースに計画がなく、ファストパスの条件も満たさない場合は、再開に関する質問に答える場合も含め、会話モードの to-plan を最初の経路として指定します。 承認の対象は、受け入れ済みのコントラクトと、その中に明示的に記録された現在の適格性に関する許容範囲のみです。追加の試行や権限を推測してはいけません。
3. スコープと境界を一度確認します。確認済みの引き継ぎにより、隔離されたチェックアウトでスコープ内の実装、テスト、および修正を続行できます。ファイルごと、段階ごとの許可書は不要です。有効な計画、レビュー、チェックを再利用します。実行に先立って解決すべき具体的なリスクがある場合に限り、先行する独立レビューを求めます。たとえば、出力を確認する前に実験用ラベルを確定する場合などです。ツール作成など、それに依存しない作業は後回しにせず並行して進めます。必要な成果物、データ取り扱いの制限、および支出上限を守り、依頼されていない汎用インフラストラクチャは構築しません。レビュアーの能力はランタイムメタデータから確認し、能力確認だけを目的としてレビュアーを起動してはいけません。最終レビューを実施できない場合は、レビューを省略せず、そのことを納品の阻害要因として報告します。
4. 単独作業または委任作業、担当範囲、隔離、および復旧について、同梱の実装手順に従います。連続したスライスや密接に結合したスライスは、ワーカーに任せず、リードとして順番に実装します。リポジトリまたはユーザーが定めたテストポリシーに従います。実装の前に保持された作業を照合し、ルーティングのために受け入れ済みの作業をやり直してはいけません。 テスト、修正、および再利用可能な単一の納品記録には、Evidence and review に従います。ソースで非同期または永続的な実環境での適格性確認が必要な場合は、試行と再開の前に適格性確認と失敗からの復旧を適用します。通常のオフライン作業には適用しません。
5. 統合済みの候補を自己レビューし、影響を受けるローカルチェックと必須のプッシュ前チェックを実行します。その後、納品 PR ごとに独立した読み取り専用レビュアーを 1 人起用し、承認済みソース、リポジトリの標準、正確でクリーンな候補ヘッド、および検証エビデンスを渡します。書き込みを行わず、実装時のコンテキストを引き継いでいない、新しいエージェントを使用します。有効な独立レビューのカバレッジは再利用し、計画レビューや実装レビューを重複して行いません。エビデンスに基づく指摘と、ship、fix-first、または rethink の判定を求めます。明示的に適用されたプロバイダーコントラクトに従い、不足しているカバレッジを報告します。指摘を実装担当者に返し、修正後のヘッドで影響を受けるチェックを再実行し、変更された範囲と相互作用をレビューします。影響範囲を限定できない場合、または明示的な要件がある場合に限り、レビュー範囲を広げます。プッシュ前に、最終的なクリーンヘッドが総合的にカバーされていることを確認します。完了し検証済みの作業によって最終差分が空になった場合は no-change と報告します。開始時点で差分が空であっても no-change とはしません。それ以外の場合は、ドラフト PR を 1 つ作成するか既存の PR を再利用し、そのヘッドがレビュー済みヘッドと一致することを確認します。PR レビューのタイミングを適用します。適用可能な外部レビューは、検証済みのドラフト対応または許可された早期の PR 準備状況を利用し、CI の実行中に開始します。最終ヘッドのすべてのゲートに合格するまでは、納品を pending のままにします。クローズリンクは、検証済みの GitHub issue にのみ使用します。
6. CI、フィードバック、およびすべての PR 操作は shepherd が担当します。修正は実装担当者が行い、プッシュ前に、修正後のヘッドで影響を受けるチェックと焦点を絞ったレビューを再実施します。要件、カバレッジ、アーキテクチャ、および権限を維持する通常の実装修正やフィクスチャの修正は、既存の承認のもとで進め、簡潔に記録します。重大な変更では、影響を受ける作業を続ける前に、適切な決定と再計画が必要です。適格性確認の弱体化や権限の拡大は重大な変更です。この実行に対して有効な明示的権限がある場合に限り、マージします。ゲートが約 30 分間 pending のままの場合は、保留中のチェック、フィードバック、PR、およびヘッドを正確に引き継ぎ、後で再開できるようにします。

完了ゲート

最終的なヘッドが必須のチェックとレビューに合格し、指摘事項が解決済みで、そのクリーンなヘッドに適用できる証拠が揃った場合にのみ ready と報告します。 認可されたマージの読み取り確認が完了した後にのみ merged と報告します。 実装と検証が完了し、最終差分が空の場合にのみ no-change と報告します。 未完了のゲートを正確に示して pending と報告します。それ以外の場合は、必要な判断または機能を示して blocked と報告します。 pending または blocked の実行では、PR とソースへのポインターを保持します。以前のヘッドをレビュー済みの結果として報告しないでください。