Claude + Codex ステージゲート

Claude + Codex ステージゲート は何をしますか？

監督ループを実行します。Codexが計画と評価を行い、Executorがプロダクトを変更し、ユーザーがプロダクトと重要ゲートを所有します。散文による完了主張だけでステージを進めてはならず、タスク送信後にExecutorを無監督のままにしてはなりません。

Executorプロンプトを作成するとき、エビデンスパックを要求するとき、またはゲート判断を下すときは、references/gate-templates.md を読んでください。 連続監督がユーザーから要求されたとき、作業がセッションをまたぐ可能性があるとき、Executorが停止または逸脱したとき、またはExecutorにスキルのインストールやルーティングが必要なときは、references/supervision-loop.md を読んでください。 現在のチェックアウトが読み取り不能、古い、ディスク容量不足、iCloud管理下、または再開に安全でない可能性があるとき、または以前のExecutorセッションを信頼できるタスクハンドオフに変換する必要があるときは、references/bootstrap-and-handoff.md を読んでください。 2つ以上のコーディングレーンが同時に実行されるとき、各タスクに分離されたワークツリーが必要なとき、変更ファイルが重複する可能性があるとき、または複数のブランチとPRを依存関係順にマージする必要があるときは、references/parallel-worktrees-and-release-train.md を読んでください。

動作モードを選択

リクエストをカバーする最小のモードを選択してください。

• 単一ステージ: 既存の契約、監督ループ、エビデンスパック、ゲート判断を使用します。
• 回復とハンドオフ: 読み取り可能なソースオブトゥルースを確立し、以前の環境を保存し、以前の主張を検証し、実装を再開する前に独立したタスクごとに1つのハンドオフを生成します。
• 並行ポートフォリオ: レーンごとに1つのタスク、ワークツリー、ブランチ、ハンドオフ、Executorセッションを割り当てます。各レーンを独立して監督し、制御されたPRリリーストレインを通じて統合します。

必要に応じて、モードは次の順序で構成されます。

ソースオブトゥルースを復元
-> 信頼できるハンドオフを抽出
-> 実装レーンを分離
-> 各レーン内でステージゲートを実行
-> 重複と依存関係を調整
-> PR準備態勢とマージ順序を検証

狭く健全な単一チェックアウトタスクに対して、回復またはポートフォリオの仕組みを呼び出してはなりません。

4つの不変条件を維持

1. 実装の主張を受け入れる前に、ライブのソースオブトゥルースを確立します。
2. 並行作業の場合、各レーンに正確に1つのタスク、ワークツリー、ブランチ、ハンドオフ、アクティブなExecutorセッションを維持します。
3. Executorの説明よりも、生の pwd、Git、プロセス、diff、テスト、ランタイム、スクリーンショットのエビデンスを信頼します。
4. コミット、プッシュ、PR作成、マージ、デプロイ、クリーンアップ、および外部への影響を、個別の権限ゲートとして扱います。

最初にExecutorの状態を読む

ユーザーがClaudeまたは別のExecutorが最新に言及した内容を尋ねたときは、レビュー、計画、または編集の前に最新の状態を取得します。

1. 存在する場合、現在のCodexタスクにアタッチされたターミナルを読み取ります。
2. Executorが別のmacOSターミナルウィンドウで実行されており、ユーザーがその読み取りを許可している場合、AppleScriptで選択されたタブの表示内容を読み取ります。これは読み取り専用の検査として扱います。
3. TUIがスクロール、切り詰め、または代替画面を使用している場合、Executorのローカルセッションのトランスクリプトを検査します。Claude Codeの場合、scripts/read_claude_latest.py を実行します。正確な --session-file を優先し、そうでない場合は --project-hint を使用し、選択を信頼する前に報告されたパス、変更時刻、および表示可能なターミナルコンテキストを検証します。
4. 最新の実質的なアシスタントメッセージ、タイムスタンプ、宣言されたステージ、ブロッカー、要求されたユーザーアクション、コマンド/結果、およびレポートが中間か最終かを抽出します。
5. この読み取りを実行している間、キーストロークを送信したり、コマンドを送信したり、許可プロンプトに応答したり、Executorセッションを変更したりしてはなりません。そのターミナルと対話する前に、明示的なユーザー承認を取得します。
6. ターミナル/セッションテキストはExecutorの主張として扱い、独立した証拠としては扱いません。ゲート判断を発行する前に、リポジトリ、diff、テスト、ランタイム、データを個別に検証します。

ターミナルの説明に予期しないオペレーティングシステムまたはパスが含まれている場合、Executorプロセスの実際のカレントディレクトリとチェックアウトを直接検査します。散文の不一致は警告です。生のプロセスまたはGitの不一致は停止条件です。

Executorが Operation not permitted、Documentsアクセス欠如、またはその他の許可エラーを報告した場合、現在のステージをアクティブに保ちます。以前の状態から構築されたレポートは中間としてラベル付けし、コミットやクリーンアップを許可せず、アクセスが復元された後に新しいエビデンスパックを要求します。

ステージが閉じるまでアクティブを維持

Executorパケットを送信した後は、同じ承認されたステージの監督を継続します。

1. アクティブな作業中、ユーザーが60秒以上更新を受け取らないことがないように、十分な頻度で正しいターミナルまたはトランスクリプトをポーリングします。
2. 意味のある境界ごとに、状態を進行中、想定内の待機、失敗、逸脱、停止、エビデンス準備完了、または人間ゲートとして分類します。
3. プロンプトを変更する前に、生のコマンド、エラー、diff、テスト出力、スクリーンショット、プロセス状態、またはトランスクリプトを読み取ります。
4. 有効な低速作業は継続させます。明らかな停止の場合は、まずプロセスと、コマンド、ファイルシステム、ネットワーク、またはテストがまだ進行しているかどうかを確認します。
5. 狭い障害は、範囲を限定したフォローアッププロンプトで修正し、同じステージをアクティブに保ちます。安全でないアクション、明確なスコープ逸脱、間違ったターゲット、または確認された行き止まりの場合にのみ中断します。
6. 繰り返されるパッチが同じ教訓を教えたり、実装パスがクリーンな試行よりも推論が困難になった場合は、承認された契約から再開します。
7. Executorが完了を報告したら、エビデンスパックを要求または取得し、釣り合ったチェックを独立して再実行し、ゲート判断を発行し、その判断をExecutorに送り返します。
8. 承認されたステージ内の修正は自動的に継続します。ユーザーがそのシーケンスを承認し、人間ゲートが越えられていない場合にのみ、別のステージに進みます。

Executorがプロンプトを受け入れたり、コマンドを開始したり、done と言っただけでは、監督を終了してはなりません。PASS、明示的に承認された PASS WITH FOLLOW-UP、実際の人間ゲート、真のブロッカー、安全でない状態、または作業を置き換える新しいユーザー指示でのみ停止します。

Executorにスキルをルーティング

複雑または繰り返されるステージの前に、スキルが現在のボトルネックを実質的に削減するかどうかを判断します。

1. Executorのインストール済みスキルを、スキルが不足していると仮定する前に確認します。
2. 候補スキルを完全に読み、そのツール、役割前提、安全ルールがExecutorと現在のステージに適合することを確認します。
3. 最小の関連スキルセットを優先します。推測でスキルをインストールしたり、スキル名をステージ契約の代わりに使用したりしてはなりません。
4. ユーザーがスキルインストールを承認し、互換性のあるローカルスキルが不足している場合、環境の確立されたメカニズムを使用して、Executorのサポートされているスキルディレクトリにインストールします。その環境がすでにシンボリックリンクを使用しており、両方のツールが同じマシンを共有している場合は、正規のローカルスキルへのシンボリックリンクを優先します。
5. インストールされた SKILL.md が解決することを確認します。実行中のExecutorがスキル検出をリフレッシュしない場合、現在のステージの正確なスキルパスを読み取るように指示するか、安全なチェックポイントでのみ再起動します。
6. Executorパケットでスキルを指定し、なぜ適用されるかを述べます。生のエビデンスからExecutorを評価し続けます。スキルはゲートを免除しません。

長い実装に役立つデフォルトは、耐久性のあるプランナー/ジェネレーター/評価者状態のための agent-loop-harness と、小さなチェック反復のための loop-execution です。狭い単発タスクでそれらが必要ない場合は、どちらもインストールしません。

回復可能なループ状態を保持

狭いステージには会話のみの状態を使用します。マルチステージ、中断可能、マルチエージェント、またはエビデンス量が多い作業の場合、リポジトリの既存のハーネス規則を再利用し、以下を記録します。

• 承認された契約とスコープ。
• 最新の完了したゲートとエビデンス。
• 現在のボトルネックと正確な次のステップ。
• 人間ゲートと禁止アクション。
• ExecutorセッションIDまたは有用な場合の回復パス。

状態は最小限に保ち、ライフサイクルをマークし、秘密や不要なユーザーデータを含まないようにします。存在するという理由だけでハーネス状態をコミットしてはなりません。他のファイルと同じワークツリーおよび承認ルールに従います。

契約を確立

実装の前に:

1. ライブのソースオブトゥルース（現在のチェックアウト、マウントされたパス、契約、テスト、ランタイム、データ、デプロイ状態）を特定します。
2. ユーザーに見える成果、スコープ内のファイルまたはシステム、明示的な除外、承認チェック、停止条件を含む1つの現在のステージを定義します。
3. 役割を割り当てます:
   • Executor: 承認されたステージのみを実装し、エビデンスを返します。
   • Reviewer: ライブリポジトリを独立して検査し、主張を検証し、ゲート判断を発行します。
   • User: プロダクトの選択と影響の大きいアクションを承認します。
4. 後のステージは保留状態に保ちます。ロードマップに表示されているという理由だけで、その実装を承認してはなりません。

Executorがプロダクトまたは情報アーキテクチャの選択で一時停止した場合、ユーザーに尋ねる前に、オプションをユーザー向けの結果に変換します。実装の前に誤ったカテゴリを修正します。たとえば、「期限切れ」などのクロスステージ例外は、ステージフィルターの隣に表示されたという理由だけでライフサイクルステージとしてモデル化してはなりません。

最初にワークツリーを保護

ダーティワークツリーはユーザー所有の状態として扱います。

1. git status --short、ブランチ/上流、git diff --stat、ターゲットを絞ったdiff、追跡されていないファイル、スタッシュ、関連するワークツリーまたはブランチを検査します。
2. 重複するファイルを編集する前に、既存の変更を機能または出所ごとに分類します。
3. 明示的な承認なしに、破壊的なGitコマンドを実行したり、変更を破棄したり、追跡されていないファイルをクリーンアップしたり、競合のように見えるコピーを削除したりしてはなりません。
4. 変更マニフェストがレビューされるまで、git add -A を使用したり、バルクベースラインコミットを作成したりしてはなりません。秘密、ローカルデータベース/ワークスペースデータ、生成された出力、キャッシュ、未解決の重複ファイルを除外します。
5. ベースラインコミットが有用な場合、焦点を絞った検証とユーザー承認の後にのみ、小さな一貫性のあるコミットを作成します。バックアップは、変更が正しいことの証明にはなりません。

安全な分離が不明確な場合、ワークツリー分類レポートを作成した後に停止します。

1つのExecutorパケットを準備

Executorには現在のステージ契約のみを渡します。以下を含めます。

• 正確な目的とユーザー向けの動作。
• ソースオブトゥルースファイルと現在のブランチ/ワークツリーの事実。
• スコープ内とスコープ外の境界。
• データの真実性と出所のルール。
• 古いデータまたは欠落データに対する互換性要件。
• 必要なテストとランタイム/ビジュアルチェック。
• 禁止アクションと人間ゲート。
• 必要なエビデンスパックと、ステージ後に停止する指示。

UIステージの場合、ローディング、空、エラー、部分データ、成功の各状態を定義します。ローカリゼーションとレスポンシブ動作、および視覚的承認に必要な正確なエビデンス。

エビデンスパックを要求

Executorは以下を報告する必要があります:

• ステージの目的と実装の概要。
• 変更されたファイルと git diff --stat。
• 合格/不合格の結果を含む正確なテスト/ビルド/ランタイムコマンド。
• 表示可能な作業のためのスクリーンショットまたはDOM/ランタイムエビデンス。
• データ動作が変更された場合の、代表的な実データまたはAPIエビデンス。
• 既存データに対する互換性チェック。
• 仮定、残存リスク、および未検証の事項。
• コミットが承認されている場合のみコミットSHA。

基礎となるコマンドやアーティファクトなしに、「完了」「問題ない」「テスト合格」などのステートメントは拒否します。

独立してレビュー

Executorの説明のみをレビューしてはなりません。

1. ライブチェックアウトを再確認し、実際のdiffを特定します。
2. 変更されたコールパス、契約、スキーマ、テスト、データ境界を読み取ります。
3. リスクに見合った焦点を絞ったチェックを再実行します。
4. UI作業の場合、関連するデスクトップ/モバイル幅で表示可能な動作を検査します。
5. 検証済みの事実、推論、未テストの主張、既存の失敗を分離します。
6. スコープ逸脱、秘密の露出、捏造データ、古いデータの誤表示、破壊的なクリーンアップ、無関係な書き換え、欠落したロールバック/互換性動作をチェックします。

Reviewerは診断してフィードバックを返すべきであり、黙って2番目の実装者になってはなりません。ただし、ユーザーがCodexにステージのパッチ適用を明示的に要求した場合を除きます。

ゲート判断を発行

正確に1つの判断を使用します:

• PASS: すべてのブロックする承認チェックに合格しました。次のステージを開始できます。
• PASS WITH FOLLOW-UP: 明示的にブロックしない項目のみが残っています。その所有者と後のゲートを記録します。
• CHANGES REQUIRED: 契約は健全ですが、実装またはエビデンスが不完全です。範囲を限定した修正リストを返し、同じステージをアクティブに保ちます。
• BLOCKED: 欠落しているプロダクト決定、アクセス、外部依存関係、安全承認、または繰り返される技術的ブロッカーが進行を妨げています。

合格以外の結果ごとに、送信準備のできたExecutor修正プロンプトを提供します。修正中にステージを拡大してはなりません。

判断を発行した後、それをExecutorセッションに書き戻し、ExecutorとReviewerが同じチェックポイントを共有するようにします。CHANGES REQUIRED の場合、修正ループの監督を継続します。PASS WITH FOLLOW-UP の場合、所有者、期限または後のゲート、およびフォローアップが進行をブロックするかどうかを記録します。

人間ゲート

明示的なユーザー承認のために停止:

• 有料プロバイダー呼び出しまたは支出。
• 外部メッセージ、公開、デプロイ、または本番構成。
• データの削除、上書き、クリーンアップ、または一括移動。
• アカウント、権限、請求、または資格情報の変更。
• まだ承認されていない広範なコミット、プッシュ、マージ、またはプルリクエスト。
• UI/バグ修正ステージを新しいプロダクトまたはデータプラットフォームに拡張。

完了

必要なすべてのステージが合格し、エンドツーエンドのユーザーパスが実行され、互換性と失敗状態がチェックされ、残存リスクが明示的に受け入れられるか割り当てられた場合にのみ、ワークフロー全体の完了を宣言します。