execute-ticket

チケットの実行

担当範囲：意味上のベースライン確立から実装、的を絞った簡素化、レビューの分離ゲート、QA の調整、検証の引き継ぎまで、チケット単位の品質ループを担います。

フォルダーからチケットを選ぶこと、レガシー Markdown を解析すること、実行台帳を更新すること、チケットファイルを移動すること、コミット、プッシュ、PR の作成または編集、マージ、ワークツリーのクリーンアップは行いません。

呼び出し元から渡される正規化済みの チケットエンベロープを受け取ります。検証のセマンティクスと出力レコードは verification-auditが担当します。

デフォルトのスキルのみのレーンでは、スキルのみの契約を読み込みます。 入力にランナーは不要です。完全なレコードが必要な場合を除き、引き継ぎは簡潔なメモです。

入力

以下を必須とします。

• 正規化済みエンベロープとチケット本文
• リポジトリ／ワークツリーのパスと許可されたファイル範囲
• ソースと現在の CandidateRef
• 受け入れ基準と明示的な互換性要件
• 品質再試行の上限と、すでに開いているチケット対象のゲート

古い CandidateRef と、未解決の実装開始時 HITL ゲートは拒否します。人間のみが実施できる検証ゲートは開いたままでもかまいませんが、最終的な判定は制限されます。

移植可能な構成

委任権限がない場合は、各ステージを順番にインラインで実行します。これがデフォルトであり、AgentTool は不要です。個別のワーカーを選ぶ前に、運用上のデフォルトを適用し、ユーザーが要求した範囲と確認された分離状態を記録します。

品質ループ

1. 意味上のベースラインを確立するために必要なコード、テスト、仕様、現行ドキュメントのみを確認します。ライブラリ、SDK、CLI、API、クラウドの動作については、リポジトリの要件に従って最新の一次ドキュメントを取得します。
2. 受け入れ基準を、観測可能なテストと不変条件に変換します。コードの動作を変更する場合は、指定されたテストファーストの流れに従います。RED を再現し、GREEN を実装してから、セマンティクスを変えずにリファクタリングします。
3. チケットの範囲だけを実装します。無関係なユーザー変更を保持し、互換性が明示されていない限り、互換性シムを追加しません。
4. チェックを実行する前に、検証の受け入れ判定と試行ごとのコストを適用します。納品されたパッケージ／アーティファクトのグラフを検証し、因果関係のあるチェックと必須チェックを選択し、これまでのすべての試行と今回の試行で残っている予算を保持します。候補が変更されたからといって、完了済みのスイートを自動的に再実行しないでください。受け入れが認められた対象チェックを実行します。合格時は、貼り付けたアーティファクトの代わりにマニフェストとコンテンツアドレス指定された参照を残し、各リーフで宣言された正規化バイトの取り込み上限と出力上限を適用します。残りの範囲を捨てずに、budget-exhausted の部分結果から処理を続けます。GREEN の後にのみ、code-simplification を通じて対象を絞ったクリーンアップを呼び出します。編集後は、影響を受けるチェックを再実行します。
5. 候補の差分と CandidateRef を凍結します。読み取り専用の code-review を呼び出します。別コンテキストによる分離が確認された場合に限り、独立したレビューと説明します。レビュー中は編集しません。
6. ブロッカーとなる指摘があった場合は候補を変更し、以前のレビュー／QA／監査の証拠を無効化して、該当するステージから再試行します。設定された再試行上限で停止します。
7. qa-test-plan を通じて QA 計画の作成を呼び出します。ドリフト後は検証の受け入れ判定を再確認し、古い証拠は元の識別情報のまま保持し、付け替えません。実行するのは、許可され、実行可能なチェックだけです。観測結果を正確に分類し、シミュレーションによる証拠を実稼働の証拠として扱いません。
8. スキルのみのレーンが簡潔なメモで終了する場合を除き、呼び出し元から渡された正規化済みチケット ID、チケットエンベロープのアーティファクト参照、完全な凍結済み CandidateRef、レビュー結果、QA 計画／結果、ゲート、プロバイダーレコード、要求された操作を verification-audit に渡します。正規版の検証レコードと主張の上限を出力するのは、これだけです。

引き継ぎ

以下を含む構造化された結果を返してください。

• チケット ID、Ticket Envelope アーティファクト参照、CandidateRef；
• 変更したパスと受け入れ基準のステータス；
• 実行したコマンド、確認された結果、保持されているすべての試行／シャード、試行ごとの消費量、不明なコスト、現在の試行で残っている予算、フルスイートを再実行した理由；
• レビューで見つかった問題と再試行回数；
• QA 計画と実行済みの証拠参照；
• 各リーフの正規化された実行モード、分離、並列フラグ、権限参照；
• 検証済みの Verification Record、または検証エラーの正確な内容；
• 未解決の人手、認証情報、プロバイダー、またはライブ環境に関するゲート。

この引き継ぎで、done、PR-open、integrated、または本番環境への準備が完了したと主張しないでください。 正規の検証による集約で、主張できる範囲が制限されます。デリバリー状態には、Autopilot レーンにおけるスケジューラーの受領記録、または skills-only において別途承認された呼び出し元によるデリバリーとプロバイダーの読み戻しが必要です。実装が完了したというだけでは、いずれも推定できません。