handle-tickets

チケットを処理する

既存の実装準備が整ったチケットのチケットオーケストレーターとして、このスキルを実行します。既に存在するトラッカーのチケット、またはチケットを既に参照している PRD からのみ開始してください。

各フェーズの手順は、参照先のスキルが担当します。チケットコーディネーターは、ワーカーの作業範囲、フェーズの境界、順序、再試行、チケットの完了を担当します。チケットに保持されたスコープガードが、レビュー担当ワーカーから返された指摘の妥当性、デリバリースコープ、処置を判断します。

利用可能な場合は、実装とコーディネーターが担当する修正に、設定済みのworkerサブエージェントを使用してください。 複雑なバグや重要なバグには、diagnosing-bugsを使用してください。

コマンドチェーン

• チケットオーケストレーターは、ユーザーとやり取りする唯一の役割であり、対話形式の質問を行える唯一の役割です。チケットごとの進行はコンダクターに委任します。コンダクターとワーカーのすべての起動プロンプトでは、対話形式で質問するのではなく、対象を絞った質問やブロッカーを親に返すようエージェントに指示します。オーケストレーターはユーザーに質問し、回答を受け取った後、チケットに記録されているコンダクターを再開します。ランタイムがコンダクターの下にワーカーをネストできない場合、オーケストレーターがコンダクターの役割を担い、そのコンダクターのワーカーを直接の子として保持します。コードレビューのワーカーが許可されたリーフを起動できない場合、コンダクターがそのフェーズの調整を引き継ぎ、Standards と Spec のリーフを直接起動します。明確なリーフパケットが2つあればレビュー完了とし、指摘事項はすべてまとめて Scope Guard に提出し、2つの軸で1回の判定を行います。チケットに新しいコンダクター引き継ぎが記録された時点で完了です。

• オーケストレーターは、PR Cleanup まで各チケットに割り当てるアクティブなワークツリーとブランチをそれぞれ1つに限定し、同時に稼働するチケットコンダクターも最大1人にして、そのタスク ID を記録します。コンダクターはそのチケットに割り当てるScope Guardを1つに限定し、タスク ID を直ちにオーケストレーターに記録して、納品全体を通じてそのタスクを再開します。チケットを割り当てる前に、オーケストレーターは記録済みのコンダクターを確認します。稼働中のコンダクターはrunningのまま、他の対象チケットのスケジュールを続けます。必要な入力が揃って一時停止中のコンダクターを再開し、コンダクターが割り当てられていない対象チケットにのみ、新しいコンダクターを割り当てます。コンダクターを交代する場合は、アクティブな割り当て、Scope Guard のタスク ID、アクティブなワーカーと報告済みの子タスク ID、現在の実装パケットのパス、現在のレビュー パケットのパス、および現在失敗しているチェックの継続参照を引き継ぎます。割り当ての交代にはユーザーの明示的な承認が必要です。以前のブランチに紐づくオープンな PR を閉じ、そのブランチに紐づく証拠を無効化し、交代後の割り当てと PR 計画を一括で記録して、Prepare the Worktreeから再開します。PR に依存するフェーズに入る前に交代後の PR URL を記録し、Merge Lane がある場合はそれを再紐づけします。

• ワークツリーのパスは、リポジトリに規約があればそれに従います。規約がない場合、オーケストレーターは各ワークツリーをメインのワークツリーの隣に<repository-name>-ticket-<ticket-id>として配置します。

• 各コンダクターは、チケット、そのワークツリー、そのブランチ、ワーカーの実行順序、およびチケットが以下の完了ルールを満たすまでの納品品質を管理します。

• コンダクターは、実行中のワーカーの作業を重複して行いません。Head に紐づくワーカーの実行中は、後続フェーズ向けの読み取り専用コンテキストを準備できますが、ブランチの編集と Head に紐づくフェーズの移行は、チェックポイントに従って順番に行います。

• PR の準備状況は、以下のPR Review Activationに従います。

• チケットのコミットは、作成または引き継ぎ後すぐに割り当てられたブランチへプッシュして、PR を最新の状態に保ちます。ホスト型レビューでは、codex-pr-reviewの定義どおりにexpectedHeadRefOidとstatusFreshAfterを取得し、引き継ぎます。

• 実装、修正、分析、コードレビュー、ローカル Codex、PR、最終スコープ、および Scope Guard の各ワーカーはコンダクターに報告します。各実装／修正ワーカーは、ブランチの編集、チェック、プッシュを含む、コンダクターから割り当てられたアクションを1つ担当します。PR ワーカーはcodex-pr-reviewの処理を担当し、ホスト型の修正ごとに新しい修正ワーカーを起動します。Scope Guard は指摘事項の判定を担当します。コードレビューのワーカーは Standards と Spec のリーフを起動し、PR ワーカーはcodex-pr-reviewで定義された修正ワーカーを起動します。

• Scope Guard 以外の保存済みタスクを再開できない場合は、まずランタイムを通じてその結果とステータスを復旧し、有効な終端ハンドオフを受け入れます。元のタスクとすべての子孫タスクが終端状態にあると確認でき、ランタイムが対応している場合は元のタスクがクローズまたは解放された後にのみ、代替タスクを開始します。それ以外の場合は、対象を絞ったランタイムブロッカーを返します。代替タスクには、現在のWorker Contextと、入手できる場合は最新のハンドオフを渡し、新しいタスク ID を記録します。

• Scope Guard に記録されたタスク ID は、継続性を保つための要件です。Scope Guard タスクを利用できない場合は、最新のハンドオフと現在の Head を含む、対象を絞ったランタイムブロッカーを返します。同じタスクが再び利用可能になった時点で、納品を再開できます。

• 起動側の役割は、起動のたびに、待機する前に、タスク ID、依頼者、役割、チケット、フェーズ、および Head を保持コンテキストに記録します。調整役は必須のハンドオフフッターに子タスク ID を含めます。コンダクターは各直接ワーカーの情報もオーケストレーターに記録します。アクティブなタスクの割り当てを消去できるのは、終端ハンドオフを受け取った後、または交代を記録した後のみです。

• すべてのコンダクターおよびワーカーの起動プロンプトまたは再開プロンプトは、次の正確なフッターで終わります。

  Skills allowed: <workflow skill names or none>
  Delegation allowed: <none or exact delegated roles>
  

  委任の許可を持たないフェーズワーカーには、次のように指示します。このレーンを直接完了してください。task を呼び出したり、エージェントを起動したりしないでください。Skills allowed に記載されたワークフロースキルだけを読み込んでください。エビデンス、質問、ブロッカーを親に返してください。 実装／修正ワーカーには、Skills allowed: implement, tdd と、指揮役が許可した名前付きの診断スキルがあればそれも渡し、Delegation allowed: none とします。Scope Guard には、完全な判断基準として Review Decision Flow、Review Finding Validation、Delivery Scope、Review Finding Disposition を渡し、Skills allowed: none、Delegation allowed: none とします。コードレビュー担当ワーカーには Skills allowed: code-review を渡し、その Standards と Spec のリーフへの委任を許可します。上記の直接リーフへのフォールバックでは、そのフェーズの指揮役に Skills allowed: code-review と Delegation allowed: Standards reviewer, Spec reviewer を渡します。ローカルの Codex ワーカーには Skills allowed: codex-local-review を渡し、PR ワーカーには Skills allowed: codex-pr-review と、そこで定義されている修正担当への委任許可を渡します。最終スコープワーカーには Skills allowed: none を渡します。委任されていない子孫を通じて得たエビデンスは、許可された役割が直接再確認するまで、フェーズのエビデンスとして扱いません。

• レビューとデリバリーのエビデンスは、検証対象の正確なブランチ HEAD に紐付けられます。後続の実装コミットがある場合、既存のフェーズがその差し替えを明示的に担うのでない限り、以前の HEAD に対するエビデンスは無効になります。ホスト上のレビュー修正は codex-pr-review の範囲内で行い、規定されたスコープ修正は Check Final Scope Fit に従い、機械的な統合更新にはその Delivery checkpoint を引き継がせることができます。以前の HEAD で得たエビデンスを、現行のものとして報告してはいけません。

• すべての役割の引き継ぎは、次の完全一致のフッターで終わる必要があります。

  Skills loaded: <none or verified skill provenance>
  Children spawned: <none or direct child task IDs and roles>
  

  各コーディネーターは、直接の子タスク ID と役割を列挙します。各リーフまたは修正担当は Children spawned: none と記載します。親は引き継ぎを受け入れる前に、受領内容が役割に与えられた許可と一致することを確認します。記載の欠落、不一致、または許可されていない項目がある場合、許可された役割が直接再確認するまで、そのエビデンスは無効になります。読み込んだ各スキルの来歴には、その名前と解決済みのベースパスに加え、利用可能な場合は一致する標準ロックの source、skillPath、skillFolderHash を含めます。別のマニフェストを作成せずに、検証済みの来歴を集約してください。 委任許可と Children spawned の受領記録は、現在の起動または再開に適用されます。

チケットの完了

チケットが完了となるのは、PR がマージ可能な状態になるか、対象を絞ったブロッカーが以下の Human Decision Boundary に達した場合のみです。マージ可能な状態とは、すべての fix-now の指摘が解決済みで、investigate または blocked の指摘が残っておらず、ローカルの Codex レビューループと修正ループが通過し、関連するチェックに合格し、codex-pr-review による PR の検証が済み、最終スコープ適合性を確認済みで、PR を問題なくマージできる状態を指します。フォローアップは完了を妨げません。codex-pr-review が成功しなかった場合は、いずれの結果でも継続用パケットを保持します。PR 本文の Codex ステータスが reviewing の間に限り、ウォッチャーのタイムアウトは、対象を絞ったブロッカーにならず、再開可能な状態を保ちます。人間によるレビューが必要な場合、サイレントスタート時に Codex が unavailable／disabled／stuck となった場合、および GitHub またはアクセスに関する障害は、対象を絞ったブロッカーです。

デフォルトでは merge-ready で停止してください。このワークフローだけを根拠に、PR のマージや自動マージの有効化が許可されていると判断してはいけません。

Human Decision Boundary

要件の情報源と根拠に基づいて安全なスコープ内の次のアクションを決定できる間は、デリバリーを自律的に進めます。Human Decision Boundary が存在するのは、必須のプロダクト動作、契約、スコープ、または責任の所在をそれらから決定できない場合、必要な承認、アクセス、レビュー、またはマージのアクションが不足している場合、あるいは先に進むと承認済みの決定を必ず変更することになる場合に限られます。複雑さ、差分の大きさ、複数領域にまたがる作業、失敗の繰り返し、コード、テスト、または対象を絞った実験で解決できる技術的不確実性は、この境界を越える理由にはなりません。問題が解決するか、境界が実証されるまで、自律的に調査、計画、実装、検証を行います。対象を絞った質問では、不足している情報を正確に示し、リポジトリからその情報を得られない理由を説明します。

PR Comment Policy

ワークフローの結果コメントは、完了した根拠と決定の追記専用記録です。ワークフローは、以下で定義する完了フェーズの時点でコメントを追加します。参照されるスキルは、それぞれの運用上の制御コメントとレビューのスレッドへの返信を引き続き担当します。後から不正確だと判明した完了記録には、その記録へのリンクを含む簡潔な訂正を追加します。

Code Review フェーズのサイクルでは、指摘の検証と対応方針の決定後に、確定したコメントを1件追加します。その結果のコミットが、修正が行われたことを示す記録になります。それ以外のフェーズコメントには、完了したレビュー結果、外部アクションが必要なブロッカー、確定した統合結果、またはデリバリーのチェックポイントを記録します。

すでに正規の参照先がある内容を複製する代わりに、参照情報としてソースの URL、リポジトリ内のパス、コミット SHA、以前のコメント URL を使用します。後続のコメントから直前のコメントにリンクし、新しいエージェントが必要に応じて決定の履歴をたどれるようにします。

各 ## Code review コメントは、1つの Head に対する現在の決定差分です。Head、Fixed point、サイクル、先行コメントの URL、該当する場合は修正コミット、以前の訂正を現在の Head で検証した簡潔な参照情報、そして現在の Head で初めて決定されたか、決定が変更された現在の指摘を含めます。現在の各指摘には、ID と有効性を記載します。却下した指摘には、反証となる根拠を簡潔に記載します。それ以外の各指摘には、デリバリー要件、対応方針、簡潔な根拠、該当する訂正またはフォローアップの優先度を記載します。結果では、現在の fix-now、follow-up、investigate、blocked の各 ID を分類します。指摘がないサイクルでは、Current findings: none と Outcome: PASS を記録します。先行コメントの連鎖に、それ以前に訂正、却下された決定、および変更されていない決定が引き継がれます。

チェックポイントは、後続の遷移を許可する、現在の Head に紐づいた結果記録です。継続パケットは再開可能な状態を記録するものであり、検証の根拠ではありません。

Worker Context

Worker のプロンプトには、ソースコンテンツをコピーするのではなく、Gather Context で見つけた参照情報を記載します。チケットの URL、worktree、ブランチ、固定ポイント、現在の Head を渡し、PR が作成されたら PR の URL も追加します。プロジェクトのドメイン文書の利用ルールを含むリポジトリの指示に従い、各フェーズに関連するドメインコンテキストと決定事項を参照するよう、各 Worker に伝えます。作業を実質的に規定し、かつそれらの情報源からすでに見つけられない場合に限り、別の直接 URL またはパスを追加します。修正 Worker には、Scope Guard が確定した fix-now の処置を永続的な成果記録を通じて渡します。利用できる場合は永続的な URL またはパスを使い、永続的な参照が存在しない場合にのみソースコンテンツを含めます。

レビューを更新する場合は、直前のコードレビューコメントの URL と、その間に行われた修正コミットを、両方の継続レビュー担当者に渡します。各レビュー担当者には、以前の修正を検証し、未解決の investigate または blocked の指摘事項をすべて現在の Head で再確認し、現在の固定ポイントから Head までの変更全体をレビューして、それらの指摘事項に加え、変更された現在の Head の証拠によって新たに見つかった、または再発した現在の該当指摘事項をコードレビュー Worker に返すよう伝えます。その Worker は、前のレビューにリンクした現在の証拠参照と、以前の修正を簡潔に検証した要約を含む総合レビュー用パケットを作成します。以前に完了した処置はコンテキストであり、要件の情報源ではありません。ただし、新しい現在の Head の証拠によって妥当性またはDelivery Scopeが変わった場合は、該当する処置を再度検討します。これには、リグレッション、不完全な修正、新たに適用される要件が含まれます。

PR Review Activation

チケットごとの PR には、最初のホスト環境への移行から最終的なスコープ適合確認まで、記録済みの PR Worker タスク ID が 1 つあります。codex-pr-review のターミナルハンドオフで 1 回の実行は完了しますが、そのタスクの所有権は解除されません。記録済みのタスクが利用可能であれば再開します。それ以外の場合は、Command Chain に記載された保存済みタスクの復旧・置換ルールに従い、以前のタスクとその子孫タスクが終了状態になった後に限り、置換タスクを 1 つだけアトミックに記録します。

• Local state: PR はドラフトです。ローカルのブランチ変更フェーズと Head に紐づくフェーズは実行できます。PR Worker は、ウォッチャーやホスト環境のフィードバックに関する副作用を発生させません。
• Hosted state: PR はレビュー可能な状態です。記録済みの PR Worker が、ホスト環境のフィードバックを扱う唯一の担当です。PR Worker は、観測した各フィードバック項目を直ちにパケット化します。コンダクターが Scope Guard の判断を取得した後、修正またはフェーズ移行の前に、PR Worker が必要なリアクションと返信を行います。ウォッチャーの実行や副作用の発生前には毎回、記録済みのタスク ID、isDraft: false、およびローカル、リモート、PR の Head が一致していることを必須とします。
• Local -> Hosted: コンダクターは Head を検証し、PR がドラフトの状態で、記録済みの PR Worker を再開するか起動します。Worker は Head を再検証し、鮮度の境界を記録して PR をレビュー可能な状態にし、現在の未リアクションのフィードバックを処理してから、ウォッチャーを起動します。
• Hosted -> Local: PR Worker は現在のフィードバックへの対応を完了し、Head を検証して PR をドラフトに戻し、Head が変更されていないことと isDraft: true を確認して、その証明を返します。この証明を受け取る前に、ローカル Worker やブランチを変更する Worker を起動してはなりません。
• Ready recovery: 記録済みの PR Worker がない状態で、すでにレビュー可能な PR に対するローカル作業を再開する場合は、変更されていない Head 上で PR Worker を 1 つだけ起動して記録し、現在のホスト環境のフィードバックを処理させてから、ローカル作業の前に Hosted -> Local を完了します。
• 最終的なスコープ適合確認は Hosted state で実施します。スコープ適合確認の間も PR Worker のタスク ID を保持します。スコープ適合確認の PASS を記録する前に、変更されていない Head 上でその Worker を再開し、ホスト環境のステータスを最終確認して、範囲を限定した台帳のクローズを行います。

レビュー判定フロー

各チケットには、検証済みの割り当てから PR クリーンアップまたは納品の中止まで、1つのスコープガードが維持されます。初期コンテキストには、権威あるスコープの情報源、ワークツリー、ブランチ、固定ポイント、現在の Head が含まれます。スコープガードは判定を行わずに、Scope Guard ready、そのベースライン、および必須の役割引き継ぎフッターを返します。固定ポイントが変更された場合、次の指摘判定の前にベースラインを更新します。

フェーズワーカーがレビューの問題なし、指摘、または要求された証拠を報告する前に、オーケストレーターはワークツリーから読み取り可能で、意図した差分の外にある、チケット専用の一意な一時パスを割り当てます。ワーカーは、Phase、レビュー対象の完全な Head、Outcome: clear | findings | evidence、およびレポートを含むレビューパケットをアトミックに書き込み、その後に ## Packet complete を記述します。evidence パケットでは、更新する指摘 ID を明記します。引き継ぎでは、これらのフィールド、パケットのパス、および必須の役割引き継ぎフッターを返します。オーケストレーターはパケットのパスを検証して記録します。パケットに基づく公開またはスコープガードへの提出の前に、さらにスコープガードの判定を公開する前に、オーケストレーターは利用可能なローカル、リモート、PR の各 Head を改めて解決し、それぞれがパケットの Head と一致することを確認します。一致しない場合、パケットは無効となり、そのフェーズを再実施します。clear の場合はフェーズで定められた問題なしの経路に進み、findings と evidence の場合は関連するパケット参照を添えてスコープガードを再開します。

スコープガードはレビュー指摘の検証、納品スコープ、レビュー指摘の処置を適用し、レビューのフェーズ、Head、Decision: clear | fixes-required | investigate | blocked、現在の指摘判定、次のオーケストレーターの移行先を返します。オーケストレーターはこれらのフィールドを含む、Head に紐づいた永続的な記録を公開し、その URL を後続の引き継ぎ用に保持してから、フェーズで定められている場合は指定の結果形式を、それ以外の場合は ## Review decision を使用して移行先に進みます。この判定が出るまで、レビューをきっかけとする修正を開始してはいけません。investigate の場合は分析ワーカーを割り当て、その証拠パケットを同じスコープガードに戻します。レビューパケットは判定の再開が可能な間は利用できる状態に保ち、PR クリーンアップまたは納品の中止時に削除します。

必須チェックが失敗したままで、診断によってチケットに起因する指摘が見つからない場合、またはスコープガードが修正を許可しない場合、オーケストレーターは待機に入る直前に、失敗したコマンド、現在の Head とベースの比較、証拠、外部の担当者、再開条件を含む、永続的な失敗チェック継続記録をオーケストレーターに記録し、チケットは running のままとします。人間の判断が必要な境界に達した場合は、代わりに blocked を使用します。指摘なしの判定によって、失敗したチェックを合格扱いにしてはいけません。

オーケストレーターループ

1. コンテキストの収集

各チケットの本文と関連コメントを読み、リンク先の仕様や決定事項を確認してから、リポジトリの指示、ベースブランチ、外部アクションの制限を読みます。プロジェクトのドメイン文書の利用ルールに従って、コンテキストマップ、用語集、決定事項を特定します。存在する資料を調査し、チケットの準備状況とキューの判断に関連する内容を読みます。

すべてのチケットが ready-for-agent またはリポジトリで相当する状態に設定されているか、除外されているか、具体的な質問とともにブロックされていれば完了です。

2. キューの作成

準備状況、依存関係、競合の可能性、並列化の機会を分類します。

実装可能な各チケットが、1人のオーケストレーター、ワークツリー、ブランチ、PR 計画に対応付けられていれば完了です。

3. オーケストレーターのスケジュール設定

独立したチケットを並列で割り当て、依存関係のあるチケットや競合するチケットは、明示された前提条件が満たされるまでキューに入れます。 オープンな PR に必須のマージ順序がある場合は、以下のマージレーンを使用します。

すべてのチケットが実行中、理由を添えてキューに登録済み、除外済み、またはブロック済みであれば完了です。

4. ハンドオフを照合する

各コンダクターから必要なハンドオフが返されたことを確認します。

すべてのチケットが「チケット完了」のルールを満たすか、対象外となるか、明示的なマージ前提条件の後ろで待機状態になったら完了です。

5. マージの判断を返す

PR、ブランチ、チェック、レビュー結果、ブロッカー、および必要な人間による対応を報告します。

チケットオーケストレーターが PR のマージを確認したら、マージ確認後のフォローアップを実行します。

• PR Cleanup を実行します。
• 新たにブロックが解除されたチケットのデリバリーを再開します。
• そのチケットの Merge Lane をマージ候補 1 件分進めます。
• マージされた PR に依存するチケットを開始する前に、以下を行います。
  1. デフォルトブランチを最新のリモートコミットに更新します。
  2. 更新したデフォルトブランチにマージが含まれていることを確認します。
  3. 更新したデフォルトブランチから、依存チケットのブランチとワークツリーを作成します。

マージの判断が返され、現在の Orchestrator Loop の反復で必要なすべてのマージ確認後のフォローアップが完了したら完了です。

Merge Lane

オープン PR に必要なマージ順序がある場合、オーケストレーターは並行するチケットデリバリーと並行して、順序付きチェーンごとに 1 つの直列 マージレーンを実行します。各レーンにはアクティブなマージ候補が 1 つあります。独立したレーンと、順序が指定されていないマージ候補は並行して進められます。アクティブなマージ候補の後ろで待機する、マージ可能な状態の PR は Delivery チェックポイントで待機したまま、他のチケットの実装と修正はそれぞれのコンダクターを通じて続行されます。

Delivery チェックポイントは、正常にデリバリーされた PR を待機状態にするための、Merge Lane 専用のチェックポイントです。Head: <full SHA> を記録し、ホスト上のレビュー入力、チェック、ホスト上の検証、および該当するスコープ適合の結果を関連付けます。記録された Head がブランチの Head と一致する場合に最新の状態であり、最新のクリーンなマージ可能性がなければマージ可能な状態とはなりません。オーケストレーターはその両方を確認し、デリバリーを続行するか、アクティブなマージ候補を準備するか、統合リフレッシュを実施するかをコンダクターに指示します。

待機中の PR は、アクティブなマージ候補になった時点で評価されます。最新の Delivery チェックポイントとクリーンなマージ可能性があれば、マージ可能な状態が維持されます。マージの競合が発生するか、リポジトリの要件としてベースの更新が必要になった場合は、統合リフレッシュを開始します。コンダクターは、統合と競合の調整を行う新しい実装／修正ワーカーを起動する前に Hosted -> Local を完了し、その後、次のフェーズを選択する前に結果を分類します。

• 機械的な統合リフレッシュでは、祖先関係と競合のない統合のみを変更します。統合をプッシュした後、自動的に開始されたチェックを待つ前に、引き継いだ Delivery checkpoint を使用して Local -> Hosted を実施し、ホスト上の検証が正常に完了したら、引き続き適用可能なスコープ適合の結果を関連付けてチェックポイントを更新します。
• 実質的な統合リフレッシュでは、意味的な競合の選択、またはブランチ上で作成されたコード、テスト、ドキュメントの変更が必要です。統合されたベースの完全な SHA を新しい固定点として記録し、引き継いだチェックポイントを無効にして、Code Review から再開し、その後 Local Codex、hosted Codex、最終的なスコープ適合の順に進みます。

以前マージ可能だった PR が統合リフレッシュに入った場合は、その分類を行い、完了した結果を ## Integration refresh として記録します。そこには Head、以前のチェックポイントの Head、新しいベース、理由、Classification: mechanical integration refresh | substantive integration refresh、無効化されたチェックポイント、および次に必要なフェーズを含めます。後続フェーズの完了結果は、以下で定義する通常のコメントを通じて記録します。

アクティブなマージ候補がマージされるか、マージ順序が明示的に変更された後、マージレーンは次へ進みます。特定のブロッカーがある場合は、他のレーンとチケットデリバリーを続けたまま、アクティブなマージ候補でレーンを一時停止します。レーンが進むと、オーケストレーターは次のマージ候補を 1 つだけ選択し、その最新のマージ可能性を評価します。

Ticket Conductor Loop

割り当てられた各チケットについて、以下を行います。

1. 作業ツリーを準備する

チケットに現在割り当てられている作業ツリーとブランチのみを、宣言されたベースから作成するか、正しいことを確認します。 明示的に承認された割り当ての置き換え後は、記録済みの置き換え先を使用する前に、以前の割り当てを終了します。

git status --short の結果が把握され、ブランチにチケットで意図された作業のみが含まれている状態になれば完了です。

確認済みの割り当てと、Review Decision Flow で必須とされるスコープ情報源を使って、チケットに記録された Scope Guard を開始するか再開します。タスク ID と Scope Guard ready の引き継ぎがオーケストレーターに記録されれば完了です。

2. 実装する

実装担当者を起動する前に、チケットとリンク先の仕様書だけで実装に必要なコンテキストが十分かどうかを判断します。具体的な未回答の設計、担当範囲、互換性、または検証に関する質問が実装に重大なリスクをもたらす場合、指揮担当者は割り当てられた作業ツリーから読み取り可能な、チケット専用の一意な一時パスを割り当てます。利用可能な場合はリポジトリ内の無視対象のスクラッチ領域または一時領域を使い、そうでない場合はリポジトリ外の共有パスを使ってから、そのパスを 1 人の直接分析担当者に渡します。分析担当者は意図された差分を変更せず、implementation handoff packet をそのパスにアトミックに書き込み、## Packet complete で締めくくってパスを返します。指揮担当者はファイルが読み取り可能で完了マーカーがあることを確認し、その後すぐにオーケストレーターへパスを記録します。既存の成果物で質問に答えられる場合は、この分析を省略します。

パケットの長さに制限はありません。参照先の要件情報源にすでに記録されているものを除き、根本原因、選択した設計、誤りを防ぐために却下した方向性、不変条件、スコープ、担当範囲、互換性、検証、未解決の質問、運用状態など、実装に関係する事実をすべて保持します。生の調査ログや繰り返し記載される情報は除外し、既存の Issue、仕様書、ADR、コミット、差分、ファイル、URL を参照します。機密情報は伏せます。

重大なリスクをもたらす質問が未解決のままなら、指揮担当者は読み取り専用の調査を続けるか、同じ直接分析担当者を再開してパケットを更新します。技術的な不確実性は実装の許可にはなりません。Human Decision Boundary に達した場合に限り、対象を絞ったブロッカーを返します。それ以外の場合は、作業コンテキストとしてパケットのパスを実装／修正担当者に渡します。元のチケットとリンクされた承認済みの仕様書や決定事項は引き続き要件情報源であり、固定点、差分、パケットはレビュー対象の証拠またはコンテキストです。レビュー担当者が必要とする承認済みの設計またはスコープに関する決定は、レビュー前にチケットまたは仕様書へ反映します。再利用する前にパケットの存在を確認し、パケットに記録された実装関連の事実に変更があれば、常にアトミックに更新します。パケットが存在しない場合は再生成し、置き換えるパスは古いファイルを削除する前に必ずオーケストレーターへ記録します。PR Cleanup 時、またはデリバリーを断念する際にパケットを削除します。

implement、Worker Context で必要とされる参照情報、存在する場合は実装パケットのパス、検証の期待事項を指定し、新しい実装／修正担当者を起動します。各実装／修正担当者は割り当てられたアクションを 1 つだけ実行し、引き継ぎ後に終了します。引き継ぎを待つ前に、タスク ID をすぐに記録します。 このワークフローでは、専任の新しい Code Review が、実装後のレビュー手順として implement を満たします。実装／修正担当者には、実装、検証、コミット、プッシュを行い、実装の引き継ぎを返すよう伝えます。後続の指揮担当者による修正依頼は、検証、コミット、プッシュの後に返答します。 担当者から実装コミットが返されたら、Refs #123 のような終了扱いにならないチケット参照を含むドラフト PR が存在することを確認します。 その結果の Head に対して Code Review に進みます。

実装コミットがプッシュされ、PR の URL が記録され、チェック、受け入れを裏付ける証拠、前提条件、ブロッカーが返されるか、証拠を添えた対象を絞った実装ブロッカーが返されれば完了です。

3. コードレビュー

コンダクターはレビュー用パケットを割り当て、実装の Head でコードレビューワーカーを起動するか、再開します。そのワーカーは code-review を実行し、Standards と Spec の各レビュワータスク ID を記録して、参照情報のみのレビュー用パケットの引き継ぎを返します。

Spec レビューでは、チケット本文、関連する正式なチケットコメント、リンクされた承認済み仕様書と決定事項、およびすべての受け入れ基準を仕様の情報源として使用します。条件に該当する指摘には、立証されていない要件も含め、文章で報告してください。

差分で追加または強化されたドキュメントは、チケットの要件情報源に照らしてレビューする実装として扱います。チケットの要件を超える限定的な約束は避けてください。 コードレビューワーカーは、実装の Head で両方のレビュワーを起動します。両方のレビュワーから結果が返るまで、その Head を変更せず、その後ワーカーにレビュー用パケット内で生の指摘を不変条件ごとにグループ化させます。 以下の証拠要件は、code-review のレビュワー向け報告の長さに関するガイダンスに優先します。両方のレビュワーに、すべての指摘について、レビュー対象の完全な Head SHA、要件の情報源、差分内の変更箇所または原因に至る経路、具体的なトリガー、観測された動作と必要な動作、確認した反証材料、対象を絞った検証、および必要最小限の修正を報告するよう伝えてください。 指摘については、Review Decision Flow に従い、永続的な記録として PR Comment Policy で定義された「現在の決定差分」を使用してください。パケットの結果が clear の場合、コンダクターはクリーンサイクル用の形式をそのまま公開します。

両方の保持されたレビュワーが同じ最新の Head について報告し、指摘がないか、または Scope Guard がすべての指摘に対する決定を返すことのできるレビュー用パケットが完成した時点で完了です。

レビュー指摘の検証

レビュー報告には編集指示ではなく、指摘事項が含まれます。Scope Guard は各指摘事項を自律的に検証します。現在の HEAD の証拠によって次のすべてが立証された場合に限り、指摘事項を confirmed とします。

• 要件の根拠： 必要な動作は、元のチケット、関連する信頼性の高いチケットコメント、リンクされた承認済み仕様または決定、変更前から存在し適用されるリポジトリ標準、または変更対象コードに適用される変更前から存在する重要なコード上の契約に基づいています。レビュー対象の差分で変更されたドキュメントと実装パケットは、審査対象の証拠です。
• 関連性： 差分によって不具合が導入されたのか、必要な動作が欠落したのか、または変更された実行経路がその不具合に依存するようになったのかを特定します。変更箇所、または因果関係を示す完全な経路を引用してください。その因果経路を示せない具体的な不具合は、このチケットに隣接する問題であり、対象範囲内の修正を正当化できません。
• トリガー： 焦点を絞った再現手順、失敗するテスト、到達可能な実行経路、または直接的な静的証明によって、現在の動作を実証します。関連するガード、呼び出し元、テスト、反証となる証拠を確認してください。単に想定上の回避経路やアーキテクチャ上の好みだけでは不十分です。
• 期待される結果： 要件の根拠によって必要な結果を決定し、焦点を絞ったチェックによって修正後の動作と現在の動作を区別できることを確認します。

証拠によって指摘事項が否定される場合、または古くなっている、裏付けのない約束に基づいている、到達不能な動作である、重複している、あるいは単なる好みに基づいていると示された場合は、rejected とします。否定する証拠によって指摘事項の検証は完了し、対応要件や処置は割り当てられません。指摘事項が依然としてもっともらしいものの、上記の証明のいずれかを欠く場合は、unresolved とし、不足している証拠を正確に記録します。Delivery Scope と Review Finding Disposition によって、これを follow-up、investigate、または blocked のいずれにするかを決定します。

指摘事項は、破られたと主張する不変条件ごとにまとめます。以前修正した問題群に新たな構文、入力、または競合状態の変種が見つかった場合、以前の修正で不変条件が確立されていなかった可能性を示す証拠となります。根本原因を再調査し、要件の根拠に基づいて最小限かつ十分な修正を特定し、サポート対象の入力クラス全体で必要な不変条件を検証してください。その問題群に対して次の修正を行う前に、根本原因に関する証拠パケットを1つ完成させ、同じ Scope Guard に戻してください。フェーズの担当者から要件を満たす証拠パケットを再利用し、そうでない場合は根本原因の証拠を直接調査する担当者を1人割り当てます。

レビュー対象の HEAD が古い場合、必要な証拠が欠けている場合、または許可されていない子孫プロセスが指摘事項に関与した場合は、必要な再確立の証拠を指揮担当者に戻します。指揮担当者は権限のある直接担当者を割り当て、完成した証拠パケットを受け取って Scope Guard を再開します。有効性、対応要件、処置はそれぞれ別個に扱います。

提供範囲

confirmed または unresolved の各指摘事項について、Required for this delivery: yes | no | unknown を記録します。Review Finding Validation では、利用可能な要件の根拠、関連性と因果関係、トリガーの証拠、期待される結果がすでに確立されています。指摘事項を未解決のままにすると受け入れ基準、要求されたアプリケーションの動作、または変更された経路でサポートされる動作に違反し、その修正が承認済みチケットを実装する最小限で一貫性のある対応の一部となる場合は、yes とします。判断する前に、関連するアプリケーションフロー、呼び出し元、テスト、ドメインのドキュメント、固定点での動作を確認してください。

指摘事項を解決しなくても、アプリケーションがチケットの要件を満たし、適用される既存の動作を維持できる場合は、no とします。証拠が不足しており、チケットの受け入れまたは変更された経路でサポートされる動作の維持を確認できない場合は、unknown とします。

yes の指摘事項を未解決のままにすることは、スコープの漏れです。個別の承認なく no の指摘事項を実装することは、スコープの逸脱です。

レビュー指摘の処置

処置を決定する前に、レビュー指摘の妥当性確認とデリバリー範囲を適用します。すべての指摘に、次の項目を記録します。

• Validity: confirmed | rejected | unresolved

却下されていない指摘には、次の項目も記録します。

• Required for this delivery: yes | no | unknown
• Disposition: fix-now | follow-up | investigate | blocked

証拠を処置に対応付けます。

• confirmed + yes -> fix-now、または人間の判断境界で blocked。
• unresolved + yes -> investigate、または人間の判断境界で blocked。
• confirmed + no -> follow-up。
• unresolved + no -> follow-up。
• confirmed + unknown -> investigate、または人間の判断境界で blocked。
• unresolved + unknown -> investigate、または人間の判断境界で blocked。

follow-up には、Priority: high | medium | low、期待される価値、証拠、これを対応せずにデリバリーを進められる理由、および次のアクションを記録します。investigate の処置は、エージェントによる証拠収集が続く間、フェーズの完了を妨げます。

スコープガードは、確定済みの fix-now の判断内容を返します。指揮役はその内容を永続的な結果記録に掲載し、その URL を実装／修正ワーカーに送ります。最終引き継ぎではフォローアップを保持します。フォローアップの実装やトラッカーチケットとしての公開には、別途承認が必要です。重大度は処置内の緊急度を示すものであり、妥当性、デリバリー要件、または処置を左右するものではありません。 未解決の判断が修正の正しさに影響する可能性がある場合を除き、ブロッカーを返す前に、独立して対応できる fix-now の指摘を適用します。残りの指摘は、指摘内容、証拠、不足している具体的な入力、推奨事項、および独立してデリバリーを続行できるかどうかを含む、1 つの質問にまとめます。

4. コードレビューの修正

コードレビューフェーズのサイクルは、2 軸のレポート 1 件、指摘の妥当性確認と処置の完全なセット 1 件、および最大 1 回のレビュー修正バッチで構成されます。レポートにはレビュー指摘の処置を適用します。

コードレビューパケットの Outcome: clear を確認したら、ローカル Codex レビュー／修正へ進みます。指摘を含むパケットの場合は、レビュー判断フローに従います。fixes-required の判断が出たら、新しい実装／修正ワーカーを起動し、永続的な結果記録を渡して、集約チェック、コミット、プッシュを含む、焦点を絞ったレビュー修正バッチを 1 回実施します。その後、コードレビューワーカーに戻り、更新後の Head を再レビューします。フォローアップは最終引き継ぎまで保持し、その後にコードを変更した場合は集約チェックを再実行します。

集約チェックに失敗した場合、指揮役は診断をワーカーに割り当て、そのワーカーがレビューを完了したパケットを作成します。チケットが原因の指摘は、修正前にレビュー判断フローに従って処理します。チケットに関係のない明確な診断では、そこで定義されている永続的な失敗チェックの継続記録を残します。修正コミットの後は、必ずコードレビューを再実施します。チェックに合格するか、人間の判断境界に達するまで続けます。

各指摘について最新の head に対する妥当性が記録され、却下されていない指摘すべてにデリバリー要件と処置が記録されており、ブロッカーが返されているか、fix-now、investigate、blocked の指摘が残っておらず、コミットされたレビュー修正が焦点を絞ったチェックと集約チェックに合格していれば、完了です。フォローアップは最終引き継ぎのために記録に残します。

5. ローカル Codex のレビュー／修正

conductor はレビュー用パケットを割り当て、Worker Context で必要とされる参照情報を渡して、新しい codex-local-review ワーカーを起動します。そのパケットを Review Decision Flow に従って処理します。fixes-required の判定では、焦点を絞ったレビュー修正を 1 件、チェック、コミット、プッシュとともに行う新しい実装／修正ワーカーを起動し、その後、変更後の Head を新しいローカルレビュアーにレビューさせます。保留中のブロッカーはすべてそのレビューに引き継ぎ、返却または解消する前に、現在の Head に対する判定を必須とします。 ローカルレビューの入力はディスパッチ時点で固定されます。ワーカーはピン留めされた fixed-point から Head までの差分を直接レビューします。GitHub のフィードバックによってレビュー用パケットを拡張したり、完了を遅らせたり、Local Codex を更新したりすることはできません。ディスパッチ前に Local state を必須とします。 ローカルレビューで問題がない場合、conductor は集約チェックを行う新しい実装／修正ワーカーを起動します。チェックが失敗した場合、レビュー用パケットを完成させるワーカーが原因を診断します。修正に着手する前に、チケットに起因する指摘は Review Decision Flow に従って処理し、その後、新しいローカルレビューを行います。チケットに起因しない診断で問題がない場合は、そこで定義された永続的な失敗チェックの継続を記録します。チェックに合格するか、Human Decision Boundary に達するまで続けます。 ローカル Codex の実行が成功した後、conductor はローカル、リモート、PR の各 Head が一致していることを確認し、## Local Codex review の後に PASS と Head: <full SHA> を記録します。同じ Head に対する最新のこの実行結果が、現在の ローカル Codex チェックポイント です。

fix-now、investigate、blocked の指摘が残っておらず、集約チェックに合格し、現在のローカル Codex チェックポイントが存在する場合、または対象となるブロッカーが証拠とともに返却された場合に完了とします。最終引き継ぎ用にフォローアップ事項を保持します。

6. Ready PR と Codex PR Review の実行

ホステッドレビュー入力 は、現在のローカル Codex チェックポイント、または機械的な統合の更新の場合は、引き継いだ更新前の Delivery チェックポイントのいずれかです。

conductor はローカルの HEAD がリモートの完全な head SHA と一致することを確認し、その後、ホステッドレビュー入力を使って Local -> Hosted を実行します。expectedHeadRefOid と statusFreshAfter は codex-pr-review の定義どおりに引き継ぎます。

この呼び出し元に対して、PR ワーカーはマージコンフリクトを conductor に返し、次の遷移として integration refresh を指定します。conductor が新しい実装／修正ワーカーを起動して競合を解消し、更新が機械的か実質的かを分類する前に、Hosted -> Local を完了します。順序付けられた PR は Merge Lane に従います。それ以外の PR では、機械的な更新は現在の Head のチェックポイントを得るため Local Codex Review/Fix に戻り、実質的な更新は統合後のベースを fixed point として記録して Code Review に戻ります。その後、conductor は結果として得られたホステッドレビューの開始地点から PR ワーカーを再開します。 Head を変更したりローカルレビューを更新したりする可能性がある統合の更新、スコープの修正、その他の遷移を行う前に、Hosted -> Local を完了します。最終的なスコープ適合性の確認中は、検証の成功後も Hosted state を維持します。 ウォッチャーの承認は、新しいPR本文への THUMBS_UP も含め、Review Ledger Closureが完了するまでは暫定的なものです。PRワーカーは、修正作業に入る前に、現在のHeadでホストされたすべての指摘事項をレビューパケットに記録します。コンダクターは、そのパケットをReview Decision Flowに送って判断を確定し、公開された判断を添えて同じPRワーカーを再開します。判断のHeadは、承認された修正によって、そのワークフローが管理する訂正後のHeadが置き換えとして記録されるまで、期待されるアクションHeadです。リアクション、返信、修正の実行、またはクローズの前には毎回、PRワーカーがローカル、リモート、PRのHeadが期待されるアクションHeadと一致することをその都度確認します。不一致の場合、副作用を発生させず、ホストされたレビューを更新します。承認された修正の後、未解決の investigate または blocked の指摘事項があれば、台帳をクローズする前に、Review Decision Flowを通じて訂正後のHeadでそれぞれ再確認します。各判断の直後に、PRワーカーは処置内容と簡潔な根拠を返信し、確認済みの指摘事項または未解決のフォローアップには THUMBS_UP、却下された指摘事項には THUMBS_DOWN を付けます。また、以降のレビューまたは修正作業に進む前に、却下の理由をすべて説明します。後の判断で有効性が覆った場合は、以前のリアクションを削除し、訂正を投稿してから置き換えのリアクションを付けます。Required for this delivery: yes | unknown が付いたホスト上の未解決の指摘事項は investigate または blocked のままにします。no の場合はフォローアップとして残し、返信に不足している証拠と、それでもデリバリーを続行できる理由を記録します。fix-now のスレッドは、訂正を検証した返信で解決するまで開いたままにします。このワークフローでは、PRワーカーは承認されたすべての修正を新しいフィクサーに委任し、起動できるフィクサーがいない場合は、対象を絞った実行時ブロッカーを返します。フィクサーが、指摘事項の有効性、範囲、または訂正内容を変える証拠を得た場合、修正不要であることを示す証拠も含め、PRワーカーはその証拠をパケットとして返し、修正、リアクション、返信、またはクローズの前に新たなScope Guardの判断を受けます。それ以外の場合は、フィクサーの実行、検証、プッシュ、リアクション、返信、台帳のクローズについて、codex-pr-review に従います。ホスト上のフォローアップはコンダクターへの引き継ぎ用に保持します。

ホストレビューの入力と、その結果のHeadを使って、呼び出し元の遷移先を選択します。

• Local Codex checkpoint / normal entry：上記の通常のPR準備手順を実行します。
• Local Codex checkpoint / hosted review fix that is not a scope correction changes Head：修正と、それに続くホスト検証を codex-pr-review 内で完結させます。
• Local Codex checkpoint / scope correction changes Head：ホスト検証を再開する前に、Local Codex Review/Fixに戻ります。
• Returned Local Codex / Head changed：通常のPR準備手順でこのフェーズに再び入り、codex-pr-review の要件に従ってホストレビューの入力を更新します。
• Returned Local Codex / Head unchanged：変更されていない expectedHeadRefOid に対し、より新しいローカルCodexチェックポイントを使って Local -> Hosted を実行します。レビューの唯一のトリガーはready状態への再有効化なので、チェックポイント更新のための @codex review リクエストは承認しません。
• Carried Delivery checkpoint / no hosted review fix changes implementation：統合の更新を機械的に行い、引き続き適用されるスコープ適合の結果にリンクしてDeliveryチェックポイントを更新します。
• Carried Delivery checkpoint / a hosted review fix changes implementation：実質的な統合更新として分類し、修正済みの固定点を統合後のベースの完全なSHAに再バインドし、引き継いだチェックポイントを無効にして、Code Reviewに戻ります。その後、Local Codex、ホストレビュー、スコープ適合の順に進めてから、新しいDeliveryチェックポイントを記録します。

ホストレビューの修正後に集約チェックが失敗した場合は、完成済みのレビューパケットをPRワーカーに返します。チケットに起因する指摘事項はReview Decision Flowに送り、その後、承認された修正について codex-pr-review に従い、変更後のHeadでホスト検証を再開します。チケットに起因しないことが明確な診断の場合は、そこで定義されている永続的な失敗チェックの継続情報を記録します。チェックに合格するか、Human Decision Boundaryに達するまで続行します。 継続パケットでPR本文のステータスに変更がなく、reviewingと報告された場合は、永続化された継続参照と必須のウェイク条件を付けて、チケットとその指揮役をrunningのまま維持します。次のウェイクシグナルまたは予定された検査時に、同じ指揮役とPRワーカーを再開し、codex-pr-reviewの範囲を限定した状態確認を行います。オーケストレーターは継続を最終的な引き継ぎとして扱わず、後任の指揮役を割り当てません。これ以外の、成功しなかったすべての最終結果は、継続参照を付けて対象を限定したブロッカーとして返します。PRワーカーが最終Headに対する台帳クローズ済みの検証を返し、ホスト型レビューの修正後にそのHeadで関連する集約チェックに合格し、さらに、すべてのスコープ修正の後、ホスト型検証の再開前に新たなローカルCodexチェックポイントが実施された時点で完了です。または、対象を限定したブロッカーがHuman Decision Boundaryに到達した時点で完了です。

7. 最終的なスコープ適合性を確認する

codex-pr-review が PR を検証した後、conductor はレビュー用パケットを割り当て、Worker Contextで必要とされる参照情報を添えて、新しい最終スコープ確認ワーカーを起動します。PR の差分全体を確認し、レビュー対象の Head に対する参照情報のみを含む完了済みパケットを、Outcome: clear | findings とともに返すよう指示します。 差分が、要求された結果を実現する最小限の一貫した実装かどうかを確認します。 変更されたファイルやテスト以外の LOC は証拠として扱い、しきい値としては扱いません。 無関係な責務、推測に基づくアーキテクチャ、受け入れ基準で求められていない過剰な約束を指摘します。 差分に Required for this delivery: no の項目が実装されているという確認済みの指摘はスコープクリープです。これを削除することは Required for this delivery: yes であり、処置は fix-now です。

Outcome: clear の場合は、PASS を準備します。指摘がある場合は、Review Decision Flowに従い、## Scope fit を永続的な記録として使用します。Scope Guard の判断が clear の場合も PASS を準備します。それ以外の判断では FAIL を記録し、次の遷移を示します。いずれかの PASS を記録する前に、PR Review Activationで求められている最終的なホスト側ステータス確認と、範囲を限定した台帳のクローズを完了し、PR ワーカーにレビュー対象の Head が変更されていないことを報告させます。クローズの修正が発生した場合、スコープ適合性パケットは無効になり、必要なローカルおよびホスト側のフェーズを経て、新たにスコープ適合性レビューを行います。その後、## Scope fit、PASS、Head: <full SHA> を記録します。

要件の参照元によってスコープ修正が必要と判断された場合：

1. Scope Guard は、すべてのスコープ適合性に関する指摘に対してReview Finding Dispositionを適用します。修正を許可するのは fixes-required のみです。conductor は、結果が既知で小規模かつ局所的で、元に戻せる修正をprescribed scope correctionに分類します。それ以外の修正では、diagnosing-bugs ワーカーが根本原因、影響を受ける責務、最小限の一貫した修正、および重点的な検証を証拠パケットに記録します。conductor はそのパケットをReview Decision Flowに戻し、判断結果が引き続き fixes-required の場合にのみ次に進みます。
2. 変更されていない Head を対象に Hosted -> Local を完了します。ホスト側のフィードバックによって Head が変更された場合は、スコープ適合性パケットと判断を無効にし、必要なホスト側の検証を完了してから、修正を検討する前に新しいスコープ適合性レビューを行います。
3. conductor は、最新の永続的な Scope Guard の判断と修正分類を引き継いだ、新しい実装／修正ワーカーを起動して、必要な動作を維持しながらスコープ修正を適用します。
4. そのワーカーに関連するチェックを再実行させ、コミットしてプッシュさせた後、修正後の完全な head SHA を記録します。
5. 新たなローカルレビューのため、Local Codex Review/Fix に戻ります。
6. Ready PR and Run Codex PR Review を通じてホスト側の検証を実行します。
7. Check Final Scope Fit に戻ります。

最終結果が成功した後、Merge Lane で Delivery checkpoint が必要な場合は、ブランチの最新の更新後に記録します。

Codex の検証を妨げる特定済みのブロッカーがある場合は、スコープ適合性レビューの前にこのフェーズを終了し、そのブロッカーを返します。

現在の Head に対するスコープ適合性の結果が PASS となるか、スコープ修正がHuman Decision Boundaryに到達した時点で完了です。

チケットコーディネーターへの引き継ぎ

コーディネーターへの引き継ぎには、次の内容が含まれます。

• Outcome: merge-ready | blocked | queued
• チケット、PR、ワークツリー、ブランチ、および現在の Head
• 保持されている Scope Guard のタスク ID と、最新の head に紐付けられた引き継ぎ
• フェーズまたはレビューの担当が再開可能な間、記録されたコードレビューまたは PR ワーカーのタスク ID
• 検出事項に関する判断が再開可能な間、現在のレビューパケットのパス
• 現在のレビュー、チェック、ローカル Codex、ホスト型 Codex、およびスコープ適合性のエビデンスへのリンク
• 各チケットの基準について、実装と検証を引用した簡潔な文章による Acceptance evidence
• 現在の未解決の検出事項を follow-up、investigate、blocked に分類した一覧。該当する優先度、エビデンス、次のアクション、担当者を含めます
• デリバリーがブロック中または再開可能な場合に限り、実装パケットのパス
• 外部からの再開通知が再開可能な間、現在失敗しているチェックの継続参照
• ホスト型レビューがブロック中または再開可能な間、永続的な継続参照、再開条件、expectedHeadRefOid、statusFreshAfter
• 次のワークフローアクションと担当者

完了済みおよび却下された検出事項は、リンク先の結果記録に残します。コーディネーターへの引き継ぎには、それらの永続的な参照を記載します。必須の役割引き継ぎフッターには、検証済みのスキルの出所情報と子タスク ID を記載します。

PR のクリーンアップ

マージが確認された PR ごとに、マージを記録し、関連するチケットを更新します。PR の完了によってチケットが完了する場合はチケットをクローズし、関連するレビューのスレッドを解決して、クリーンアップした内容を報告します。一部のみ完了したチケット、ブロック中のチケット、未マージのチケットは、エビデンスと次のアクションを添えてそのまま維持します。 PR のクリーンアップ時またはデリバリーの断念時には、保持されている Scope Guard、記録された再開可能なすべてのワーカー、およびその子孫が終了状態にあることを示す最終引き継ぎ、またはランタイムによる確認を取得します。ランタイムが対応している場合は、それらを終了または解放してから、アクティブな割り当てをクリアし、ワークツリーのリソースを削除します。終了状態を確認できない場合は、それらのリソースと割り当てを維持し、対象を絞ったランタイムブロッカーを返します。

リポジトリのクリーンアップ

この実行で処理した PRD のすべてのチケットがクローズされ、作業が完了したら、チケットオーケストレーターはその PRD を完了としてマークします。その後、handle-tickets の開始元のワークツリーをデフォルトブランチに切り替え、最新のリモートコミットに更新します。また、必要に応じて、既存のロックファイルを変更せずにローカルの依存関係を同期します。