ticket-autopilot

チケット自動操縦

担当範囲：フォルダーのスケジューリング、実行状態、ワークツリー／ブランチ／PR のオーケストレーション、プロバイダーの正規化、ガード付きの最終処理です。チケットの実装、レビュー、QA 計画、申告は行いません。

正規のチケットエンベロープはバージョン 1です。検証成果物と申告のルールについては、verification-auditを参照してください。

ポータブルな構成

invoke = 1 つのスキルをインラインで実行すること。compose = 所有権を維持しながら、スキルを順番に実行すること。 delegate = 別のホストワーカーを使用すること。independent = 別個のコンテキストとして確認されていること。parallel = 委任を並行して実行すること。 チケットのデフォルト実行では、スキルを順番にインラインで構成し、AgentTool の呼び出しをゼロにする必要があります。 別個のワーカーを使用する場合は、運用上のデフォルトを適用し、要求された範囲と確認された隔離状態を記録してください。

AFK 契約

• チケット単位のゲートが未解決でも、準備完了済みの無関係な AFK 作業は続行します。
• 直列化された 1 件のチケット変更を行うフォルダー実行ごとに、隔離されたワークツリーを 1 つ作成し、ブランチと PR をそれぞれ 1 つ作成します。
• 単一親のチェーンのみを積み重ねます。複数親の結合は、すべての親が統合されるまで待機します。
• プロバイダーの MERGED は必要条件ですが、十分条件ではありません。再帰的なルート配信ベースを導出し、最新の状態をフェッチしてから、integrated にする前に完全一致するヘッド、または明示的なマージオブジェクトの祖先関係を永続化します。
• 認証情報、プロバイダー機能、ライブの証拠、承認、マージ権限を決して捏造しません。
• 手動マージには完全一致するヘッドについての明示的な決定が必要です。自律マージには、アクターと証拠に紐づく実行許可が必要です。AFK、アクセス権、沈黙は、いずれも許可を与えません。
• CandidateRef v2 は、セマンティックツリー／ダイジェスト／バージョンを紐づけます。別個のバージョン管理されたレコードが、プロバイダー／PR／ベース／ヘッド／ブランチの系譜を紐づけます。
• セマンティックなドリフトはすべての証拠を無効にします。系譜のみのドリフトでは証拠は維持されますが、使い捨てのマージ許可はクリアされます。
• 設定された品質再試行回数の上限に達したチケットは停止し、その他の準備完了済みチケットは進めます。

公開 CLI

新しい実行では、品質とインタラクション／ツール／時間の制限を含む台帳スキーマ 4 を使用します。インタラクション数のデフォルトは 10 で、qa-execute と verify 用にそれぞれ 1 つずつ確保します。制限が未設定の場合は unavailable と報告します。合計値が無効な場合は、作成前に失敗します。

ディレクトリのインポート時、またはプライベートな GitHub のブートストラップ時は、インベントリ作成または公開の前にブートストラップ手順を読み込みます。ブートストラップ権限は、実行やマージの権限を付与しません。

ワークツリーの採用、中止、クリーンアップ、収集時は、ワークツリー手順を読み込みます。適格性は削除権限ではありません。

永続的な統合後にインストール済みスキルを更新するときは、ローカル Pi 同期を読み込みます。別途アクター／証拠の設定を要求し、/reload が引き続き必要であることを報告します。

PR のマージ、マージ権限の付与／取り消し、リポジトリ権限の移行、または変更された PR ベース／ヘッドの調整を行う前に、マージおよび調整の手順を読み込みます。

リポジトリ全体を対象とする「merge all」、「merge everything」、または「mergia tutto」の肯定的な指示があった場合は、repository-autonomous-merge-status を確認します。存在しない場合は、人間のアクターと永続化された肯定的なメッセージを指定して --scope current-and-future-runs を付与します。完全一致する有効な許可を維持し、取り消し済み、レガシー形式、不正形式、または矛盾する状態の場合はフェイルクローズします。その後、merge-all --repo <repository> を呼び出します。呼び出し元に PR ヘッドを指定させたり、1 つの PR のみに絞ったりしてはいけません。質問、引用、否定、曖昧な主体の指定は、何の許可も与えません。マージ権限によって他のゲートが解除されたり、競合内容、公開、クリーンアップ、wiki、または Pi が許可されたりすることはありません。

最終的に追跡されるツリーを投影する場合、または完全一致するソースモードのゲートを復旧する場合は、処理を行う前に最終ツリー手順を読み込みます。新しい実行では、デフォルトで --final-tree-mode enabled を使用します。投影は統合でも権限でもありません。 resume <run-id> --events <file.json> は {"schema": 1, "events": [...]} を読み込みます。leaf-result-template <run-id> は、現在のレビュー、QA の計画／実行、または検証ステージ用に、事前入力された leaf-result イベントを出力します。各スキーマ 3 の結果は、正確な CandidateRef、フェーズ、リソース、正規化された execution に紐付けられます。QA／検証では、スキーマ 1 の quality スコープ、コンテンツアドレス方式の証跡、上限も追加されます。部分的な引き継ぎは、同じ CandidateRef の場合にのみ再開できます。意味上のドリフトがある場合は、新しい有界エポックを開始し、追記専用の履歴には累計値を保持します。同じ候補の再試行は現在のエポック内に留まります。leaf コンテキストの唯一の経路は leaf-result です。handoff スキルは人間のセッションを橋渡しするものであり、leaf コンテキストの経路ではありません。result: "gated" を持つ stage イベントと Kernel.record_stage(..., reason=...) は、変更前に空白以外の文字を含む文字列 reason を必要とします。前後の空白は削除され、残った原因は生成された代替テキストを使わず、そのまま永続化されます。ゲートされていない結果には理由は不要です。ゲートの理由や詳細には、認証情報や非公開のペイロードを絶対に含めないでください。

環境ステージのブロッカーや、新たな人間の判断に関する不確実性については、ゲートの準備状況と既存の権限を読み込んでください。原因が解消された後に限り、有効な既存スコープを再利用してください。準備状況のラベルだけでは何の権限も付与されません。 未開始の後続作業に対する post-merge-verification ゲートでは、マージ済みソースの検証を読み込んでください。先行作業を再開したり、稼働中のゲートを回避したりせずに、新しいソースの品質を確認します。

レガシー実行の移行／廃止、その台帳の圧縮、またはレガシーの誤った予算枯渇状態の修復を行う場合は、レガシー復旧手順を読み込んでください。履歴を手作業で編集したり、実際の枯渇状態を回避したりしてはいけません。

デリバリーでは、バージョン管理された PR 本文の引き継ぎに従ってください。render-required は explain-pr に振り分け、pr-open では、プロバイダーによって検証された本文／ヘッドの読み戻しを必須とします。

verification-checkpoint は、期待されるツリー、正規化された入力、絶対パスの verification-audit ルートを受け取り、検証器／リデューサーを使用します。チェックポイントモジュールが担うのは、シリアライズ、ハッシュ、フェーズインデックス、再開です。証跡クラス、ゲート、権限、主張は担いません。inspect_verification_checkpoints はアダプターを介さず、信頼できるプレフィックスを読み込みます。キャッシュキーは CandidateRef、leaf コントラクト、スコープ、成果物、コマンド、環境に紐付けられます。完全一致するキャッシュがあればやり取りは不要です。エントリーがない、または破損している場合は再実行し、チェーンが部分的な場合は再開します。

execute-ticket を唯一回避できるのは docs-only-adopt です。v1 リクエストは Ticket Envelope、ダイジェスト、CandidateRef、パス、スコープに紐付けられます。対象となるのは、ステージ済みの通常ファイル docs/**/*.md のみです。チケット、エージェント、生成物、設定、コード、スクリプト、混在パス、シンボリックリンク、サブモジュール、曖昧さ、ドリフトがある場合は standard-path-required が必要です。コンテンツアドレス方式のパッチ／種類／Markdown／グラフ／リンクのチェックでは、leaf とのやり取りは行いません。上限は implementation-complete で、保護されたデリバリー／正確なヘッドのマージ前に再確認されます。

チケットが永続的に統合された場合、または wiki のデリバリーを再試行する必要がある場合は、wiki デリバリー手順を読み込んでください。正確なヘッドに対して、個別に wiki-sync-v1 を実行します。失敗は別途記録し、チケットの検証やマージ権限を引き継いではいけません。

ランナーの欠陥に関する issue を公開または照合する場合は、issue 公開手順を読み込んでください。実行やマージの許可ではなく、別個の権限を必須とします。

TICKET_AUTOPILOT_ROOT はスキルの絶対パスであり、リポジトリの作業ディレクトリではありません。TICKET_AUTOPILOT_PYTHON は、ここで実行可能な Python 3.10 以降を指します。Linux／macOS では python3、Windows では python または py -3 を使用してください。Windows では python3 が Microsoft Store のスタブであることがよくあります。コマンドの一覧は次のとおりです。

"$TICKET_AUTOPILOT_PYTHON" -B "$TICKET_AUTOPILOT_ROOT/scripts/ticket-autopilot.py" --help

コマンドは prepare-zero-to-autopilot、zero-to-autopilot、zero-to-autopilot-status、bootstrap-private-github、sync-local-pi、grant-repository-autonomous-merge、revoke-repository-autonomous-merge、repository-autonomous-merge-status、grant-repository-autonomous-reconciliation、revoke-repository-autonomous-reconciliation、repository-autonomous-reconciliation-status、migrate-repository-authority、merge-all、plan、run、worktree-owner-adopt、worktree-gc-plan、worktree-gc-apply、worktree-sweep、resume、status、post-merge-verify、wiki-delivery-retry-status、retry-wiki-delivery、pause、unpause、grant-autonomous-merge、grant-completion-projection、runner-defect-issue-grant、runner-defect-issue-revoke、runner-defect-issue-status、runner-defect-issue-escalate、approve、abort、cleanup、ticket-hold、ticket-cancel、ticket-reopen-request、ticket-reopen、migrate-run-lifecycle、compact-run-ledger、ticket-parse、ticket-emit、ticket-list、artifact-audit、migrateです。<command> --help を使用してください。ticket-list はプロバイダー不要の読み取り専用スキーマ 2 で、処理方針、ライフサイクル、準備状況／原因、不正形式／重複チケット、依存関係の不足、循環を報告します。artifact-audit はプロバイダー不要の読み取り専用スキーマ 1 で、エラー、レガシー警告、未参照の候補、移行作業を分類し、アーティファクトを書き換えることはありません。

pause は実行単位です。保留／キャンセルには、識別情報、理由、永続的な権限が必要です。再開はリクエスト→人による approve→適用の順で行います。対象となる合格済みゲートのみを消費し、候補からマージまでの状態を無効化します。承認は永続的な人間の権限であり、呼び出し元の認証ではありません。プロバイダー／Git／配信の境界では、一時停止、処理方針、ソースパス、ダイジェストを再確認します。手動で範囲外から操作した場合、TOCTOU が発生する可能性は残ります。

スケジューラーフロー

1. ベースがクリーンなリポジトリ内のチケット、または完全に無視対象となっているリポジトリ内のチケットのみ受け付けます。スナップショット／ワークツリーを作成する前に、pre-QA coherence に従い、--base <branch>（既定値は main）をフェッチし、その識別情報を永続化して、ローカルブランチは変更しないでください。フェッチしたコミットから正規コンテンツを Git 共通状態の下にスナップショットし、モード／ダイジェストを紐付けます。再開時に呼び出し元のファイルを再解析することはありません。無視対象の完了コンテンツは PR の対象外とします。ただし、別途許可された、ダイジェストが正確に一致する候補限定の正規 done/ 投影は例外です。ソースの所有権と最終処理は引き続き外部にあります。
2. 正規 CLI を使って解析し、未対応のスキーマ、重複する ID、依存関係の不足、循環を拒否します。移行は明示的に行い、フォールバックはしません。
3. 実行可能なチケット群を決定論的に算出します。保留中／キャンセル済みのチケットはスケジュール対象外とし、連鎖的な変更は行わずに子孫チケットをブロックします。HITL ゲートがあっても、無関係な AFK チケットは停止しません。
4. 実行可能なチケットを 1 つ選び、正規化されたエンベロープ、ソース成果物の参照、本文、CandidateRef、再試行上限、スコープを指定して execute-ticket を呼び出します。ただし、検証済みの明示的な docs-only-adopt が適用される場合を除きます。ドキュメントのみの適格性を推測してはいけません。直列化された変更と状態遷移を先に完了させてください。
5. 実装と簡素化の完了を受け取り、その後、確立済みの完全なサイクルを維持するか、または厳密に有効化された追跡対象の適格性がある場合に限り、最終品質確認の前に I → D を永続化して適用します。各 review → qa-plan → qa-execute → verify の変更には、実効的なデリバリー対象とアクティブな最終 CandidateRef を対象とした、新しい pre-QA coherence が必要です。コミット済み HEAD については、正確に記録されたリネージも含みます。その後、通常どおり最終処理を行います。不完全、インポート済み、古い、または整合性のない引き継ぎは拒否し、申告された上限を解釈し直してはいけません。
6. 品質確認に合格した後、チケットが所有するファイルのみを凍結、コミット、プッシュし、PR 本文の引き継ぎ手順に従います。ゲート失敗を記録します。プロバイダーの本文／HEAD 検証後に限り、pr-open を記録します。
7. pr-open は integrated とは別に記録します。通常の承認では、即時に実行可能で再開可能な merge critical path v1 に従います。自律実行が明示的に許可されている場合は、変更を試みるたびに新しい適格性を再確認し、PR ごとのプロンプトなしで同じ厳密な HEAD パスを再利用します。すべての統合の入口では、プロバイダーからの読み戻しとデリバリーリネージを新しいターミナル SHA／ツリーに紐付け、正確な HEAD の祖先であること、または明示的なプロバイダーのマージコミットであることを証明する必要があります。外部読み戻しは別個のプロヴェナンスを保持し、マージ変更を許可できません。プロバイダーが別の単一コミット HEAD をすでにマージしている場合、記録された遷移、観測された遷移、プロバイダー統合の生の遷移がすべて空でなく、バイト単位で一致するときに限り、integrate はそれを採用できます。2 つ目の親が観測された HEAD、またはそれとは異なる同一ベース・同一ツリーの単一親統合コピーである、2 親マージのみを受け付けます。ターミナル証明の前に、バージョン付きトポロジー証明書を永続化して読み戻します。スキーマ 1 の 2 親証明書は、書き換えずに再生します。パッチ ID、パスのみの等価性、プロバイダーラベル、最終ツリーの類似性だけでは不十分です。複数コミット、一般的なスカッシュ、キューによる書き換え、パス／ブロブ／モード／親の差異は失敗となります。
8. 冪等な単一の delivery でガード付きプッシュを行い、pr-open／ゲート済みの状態へ読み戻し、統合後にのみ完了します。
9. 親チケットがターミナル状態で統合された後、または記録済み PR のベースが進んだ後、reconcile は Git のツリー／HEAD を算出し、ツリーが等しい場合にのみ証拠を保持し、置き換えられた試行をアーカイブして、進行中の対象をプッシュ前に更新します。親のない状態でのベースの進行にはデリバリーリネージを使用し、依存関係の祖先を捏造しません。 意味的なドリフトは、新しい制限付きエポックで再検証します。プロバイダーによる変更後の更新は拒否してください。
10. agent-skills チケットが永続的に統合され、別のアクターおよび証拠に紐付いたローカル設定が存在する場合にのみ、その正確な HEAD に対して sync-local-pi を実行します。ローカル同期の失敗は、統合を書き換えずに確認できる状態にします。権限を推測したり、アクティブな Pi セッションが再読み込みされたと主張したりしてはいけません。

コンポーネントの境界

• execute-ticket：実装とチケット内の品質確認ループを担当します。コミット、プッシュ、PR、実行状態の変更は行いません。
• code-simplification、code-review、qa-test-plan、verification-audit は、execute-ticket 内で組み合わせる末端ワーカーであり、フォルダースケジューラーから直接呼び出すものではありません。
• explain-pr：検証済みの引き継ぎ後、最終処理で使う決定論的なPR本文のレンダリングを行います。

スケジューラーによる変更は直列化してください。チケットの CandidateRef に影響するアクティブな変更は、最大で一つにしてください。また、フォルダーのファイナライザーは、冪等性ガードを通じて必ず一度だけ呼び出してください。

ワークフローファミリーをリリースする際は、scripts/forward_test.py --output <artifact.json> を実行してください。シナリオのプロンプトを実行せずに生の状態で確認するには、--list を使用します。レポートはローカルのユニットテスト／統合テストのエビデンスとしてのみ扱ってください。実環境で観測されていないプロバイダーや環境の挙動については、レポートに記録された制限が引き続き主張の条件となります。

最終レポート

status スキーマ 2 には、正確なヘッドを含む、信頼できるライフサイクル、成果、準備状況、ゲート、進捗、予算／合計、CandidateRef の無効化、ターゲット ID、QA 前の整合性、ソース／デリバリーの状態、権限が公開されます。 繰り返しの読み取りは純粋な投影であり、ハートビートを追記したり、予算を消費したりしません。open_gates は順序付きの ID を保持します。open_gate_records は同じ順序で {"schema": 1, "records": [...]} を追加します。ディープコピーされたレコードには、gate_id、ticket_id（実行オーナーの場合は null）、category、scope、kind、state、reason、既存の details が含まれます。閉じたゲートは省略されます。履歴にあるスキーマ 4 の汎用的な理由は、そのまま記載されます。バックフィル、履歴の書き換え、承認は推測されません。

各チケットを、準備完了、進行中、ゲートにより停止、レビュー上限到達、PR オープン、統合済み、または失敗として報告してください。PR のリンクと観測されたヘッド SHA、エビデンスの上限、未解決の人間／プロバイダーゲート、次にブロックされていない作業範囲を含めてください。完了状況を誇張しないでください。