antigravity-maintainer-batch-release

Antigravity メンテナーバッチリリース

使用するタイミング

AAS メンテナーによる一括対応、PR の修正と一括マージ、ランタイム／カタログのリリース、インストール済みメンテナースキルとの整合性確認、公開デプロイの検証に使用します。通常のコントリビューターにメンテナー権限は必要ありません。

運用手順

1. 未コミットの作業を保持してください。分離された current-main チェックアウトを使用してください。そのベースにある正確な AGENTS.md、.github/MAINTENANCE.md、package.json、およびメンテナンス契約を確認してください。必須ツールはそのベースに存在していなければなりません。他のチェックアウトから廃止済みの手順を持ち込まないでください。
2. ソース PR のバッチでは、PR 番号をすべて一覧にし、内容の分析やレビューを始める前に、クリーンな current main 上で npm run maintenance:cycle -- start を開始し、サイクル全体に従ってください。ランナーはリリースを行わずにソースメンテナンスを測定します。リリース準備の前に完了させてください。リリースのみのタスク、または PR のない一括処理では、--prs none を指定して明示的に空のサイクルを開始し、準備の前に検証してください。許可された範囲全体をトリアージしてください。ソース PR を修正し、コンポーネント計画を実行し、追跡対象の skills/<skill-id>/** サブツリー全体をレビューし、関連するアドバイザリを調査してください。意味的なレビューをヒューリスティックなスコアで代用しないでください。
3. maintenance:cycle merge を使用してください。これは merge:batch に処理を委譲します。ソースサイクルが適用されない場合は、npm run merge:batch を直接実行してください。どちらも唯一のマージ権限を共有しています。同じマージに対して両方を実行しないでください。厳格な保護対象 main と管理者による適用を維持してください。安全な分析はレビュー前に実施できますが、マージには最新のチェックと、実際の Tessl レビューまたは正確な HEAD に対するメンテナーの証明が必要です。非公開の署名済みレシートは、内容とコンテキストのレビューに変更がない場合に再利用できます。機密変更に対する所有者限定の制限と、保護対象ベースのフォーク台帳の制限を維持してください。
4. ガイド付き受付を使用してすべてのブロッカーを収集し、その後、非公開の外部 --state-dir を指定して再開してください。各ブロッカーは一度だけ記録してください。同等の確認を2回行っても進展がない場合は、独立した作業を続行してください。毎回 PR の状態と保護設定を再取得してください。ブロックされた PR があっても独立した PR の処理を続け、失敗を報告してください。サイクルのリファレンスに記載された決定的な失敗コードと、回数に上限のある読み取り再試行に従ってください。結果が不明な書き込みを繰り返したり、アクティブな状態ロックを奪ったり、古い CI 証拠を再利用したりしないでください。PR のメタデータを書き換えたり、ベースのずれを自動的に再試行したり、GitHub の自動マージを使用したりしないでください。
5. 通常のソースマージで生成されるのは、一時的な検証状態のみです。追跡対象の配布スナップショットと貢献者クレジットは、保護されたリリース PR で更新します。通常の正規同期 PR は必要ありません。リリースを伴わない依存関係の修正が明示的に要求された場合は、信頼されたベースに対する所有者限定の契約で検証された、既存の通常のロックファイルの複製のみ同期できます。それ以外の生成対象パスはすべてリリース管理下に置かれます。
6. 許可された公開を試みる前に、クリーンでコミット済みの、検証済み main の子孫上（診断用トピックブランチを含む）で release:rehearse -- X.Y.Z --state-dir /absolute/private/completed-cycle を実行してください。これはプッシュ、タグ付け、公開、ソース／サイクル状態の変更を行わず、破棄可能なクローン内で共有ローカル候補パイプラインを実行します。詳細はローカルリハーサル契約を参照してください。リハーサルに合格しても公開が許可されるわけではありません。契約にある非公開の --candidate-dir レシート／昇格フローを使用して、テスト済みコミットを保持し、正確なソースとツールチェーンが引き続き最新である場合にローカル準備の繰り返しを避けてください。許可されたら、release:prepare と release:publish を使用してください。準備ではローカルのリリースコミットを作成し、その正確な封印済みツリーをパックして、候補に対してテストスイート全体を実行します。合格した場合にのみプッシュします。診断目的の事前チェックで同じテストスイートを重複実行しないでください。準備済みのリリース PR は保護設定を通してマージしてください。タグを作成または再利用し、不変の候補を待ってから公開し、正確な npm バイト列を検証してください。GitHub Release は npm の成功後にのみ作成してください。その後 Pages は、変更されていない同じテスト済みバイト列を使用します。リリース済みコミットが保護対象の祖先として維持されていれば、main は先に進んでもかまいません。
7. 互換性のあるカタログのみの公開には、独立したカタログワークフローと不変のリビジョン／SRI を使用してください。オフライン動作、ロールバック、エージェントによる選択を維持してください。カタログデータの更新だけを目的に、ランタイムのバージョンを上げたり再公開したりしないでください。
8. ソースバッチは、他のソースサイクル作業をすべて終えた後、正確な main CI／CodeQL に対して maintenance:cycle verify を実行して完了してください。公開を行わない場合は、そこで終了してください。公開配布スナップショットは意図的に直近のリリース時点のままです。リリースの場合は、実際の公開バイト列と稼働中のサーフェスを含む、契約に定められた完全リリース整合性ゲートを完了してください。個人用 MCP 設定とセッションの再読み込みは、別々に報告してください。導入済みのメンテナー用スキルは、無関係な導入内容を維持しながら、採用済みの正規ソースから更新してください。 ユーザーが npm への公開を禁止したうえで GitHub リリースを明示的に要求した場合、release:publish -- X.Y.Z --skip-npm は同じリリース承認チェックと候補チェックを実行し、タグを作成または検証したうえで、npm をスキップし、npm を利用できないことを明記したリリースノートを付けて GitHub Release を作成します。明示的に選択されたこのターゲットを、release:verify -- --version X.Y.Z --target github-site で検証してください。GitHub／サイトでの完了は npm を含む配布全体とは異なります。対象外の npm とローカルホストが合格と報告されることはありません。適用されるすべての公開整合性ゲートは引き続き必須です。npm への公開失敗から、このモードを推測してはなりません。後から通常の公開を行う場合も、明示的な承認が必要です。

例

マージせず、安全な分析を準備します：

npm run merge:batch -- --prs 123,124 --prepare-only

実際にセマンティックレビューを行った後、証跡を保存してマージします：

npm run merge:batch -- --prs 123,124 --state-dir /absolute/private/state --reviewed-head FULL_40_CHARACTER_SHA --reviewer maintainer --review-evidence 'Complete bundle, provenance, safety and limitations reviewed'

実際の ID、パス、完全な不変の SHA を使用してください。状態ディレクトリはあらかじめ存在し、所有者が限定され、モードが 0700 に設定されており、ソースのチェックアウト外にある必要があります。

検証

正確なチェック、リリース証明、カタログ互換性、タイミング測定方法については、コンポーネント検証とメンテナンス契約をお読みください。必須チェックは引き続き pr-policy、pr-evidence、source-validation、artifact-preview です。不明な変更、共有変更、ポリシー変更には完全な検証を実施します。コンポーネントガイドで定義されているとおり、CI では、必要な前提条件の成功後に限り、完全なプランの未シャーディング・スクリプトスイート全体と、分離された Web カバレッジ／ビルドのみを並行実行できます。順序が定められたすべての結果は引き続き必須です。Blob でフィルターされたチェックアウトでは、完全な履歴を保持し、必要なバイトをオンデマンドで取得します。ピン留めされた Turborepo は、既存の無料 GitHub キャッシュ枠を通じて、Web のカバレッジ／型チェック／コンパイルの完全な結果を再利用できます。現在のコミットのメタデータ、プリレンダリング、最終検証、完全なリポジトリのスクリプトスイートは、新たに実行する必要があります。キャッシュされた CI ジョブでは、同一の正確な Node パッチバージョンをピン留めし、永続キャッシュのスコープには安定したユーザーランド／ツールチェーンの ID を使用してください。クラウドのカーネルを ID に使用してはなりません。入力、出力の整合性チェック、キャッシュの信頼性、診断用の HIT／MISS レシートについては、コンポーネントガイドに従ってください。有料の CI やリモートキャッシュは有効化されません。完全な未シャーディング・スクリプトスイートでは、レビュー済みの分離された 6 グループを 2 ワーカーで実行した後、残りの全グループを順番に実行できます。失敗時は実行中の子プロセスをすべて終了させ、安全側に停止します。コンポーネントガイドに従い、完全なインベントリダイジェストを保持してください。

制限事項

このスキルによって、追加の公開権限やメッセージ送信権限が付与されることはありません。Tessl を利用できない場合は、レビュー合格ではなく manual-review-required とします。Jev、SkillSpector、タイミングレポートは参考情報です。main への直接プッシュ、管理者によるバイパス、可変のアーティファクト ID、PR が制御するレビューレシート、ネイティブクライアントの再読み込みを示す捏造した証明を使用してはなりません。ローカルでの計測だけでは、サイクル全体の改善は立証できません。

SkillSpector のトリアージではスキャナーの解釈を、ランタイムの変更ではCore のプレビュー受け入れを参照してください。

カタログ、Pages、旧式のリダイレクトの変更については、公開サーフェスの検証に従ってください。

CSV のセキュリティ受付では、過去の重複や生成された重複と、現在の正規データにおける欠陥を区別してください。トリアージを簡略化する目的で、スキルの Markdown や外部セットアップを実行してはなりません。調査資料には、内包するネストされたスキルツリーを含める必要があります。実行可能なドキュメント例には、レビュー済みのテスト用フィクスチャと、不活性なソース比較を使用してください。リリース前に、各指摘の処置とその証拠を記録してください。

リリースタグを作成する前に、バンドルされたアプリケーションやテンプレートを含む、正規の npm ロックファイルをすべて洗い出して監査してください。ルートと Web の監査がクリーンでも、ネストされた依存関係は対象になりません。ソースのマージ後とタグ付けの直前に、稼働中のセキュリティアラートを再確認してください。新たに作成されたアラートは、公開前の新たな作業として扱ってください。

必須のリリースサイクルバリア

記録されたバッチに未解決の PR がある状態で、リリースを進めてはなりません。バッチ内のすべての PR は、保護された main にマージするか、オーナーが理由を記載したコメントをクローズ前に投稿し、そのコメントを PR の正確なヘッドに紐づけたうえで、マージせずにクローズする必要があります。ポリシー上のブロッカーは完了を意味せず、マージ保護を回避したり、公開を可能にする目的だけで有効なコントリビューションをクローズしたりする根拠にはなりません。

npm run maintenance:cycle -- close --state-dir /absolute/private/state --prs 123 --expected-head FULL_40_CHARACTER_SHA --reason 'Substantive reason, including the replacement PR when applicable' を使用してください。 このコマンドはクローズ前に必要なコメントを投稿します。不確実な書き込みが発生した場合は、再試行せずに停止します。記録のない単純なクローズは、検証を満たしません。マージ済みの PR には、既存の保護されたマージ手順を使用してください。

npm run release:prepare -- X.Y.Z --state-dir /absolute/private/state の実行前に、現在の main の正確な状態で maintenance:cycle verify を正常に完了してください。サイクルの証拠が揃っていない場合、準備処理はブランチの作成やバージョンの変更を行う前に失敗します。リリース PR には data/release-cycle.json が含まれます。公開処理と npm ワークフローは、ライブの PR 状態、クローズコメント、保護された main の系譜、および検証済みソースコミットに対する CI／CodeQL の成功をそれぞれ再読み込みして確認します。再オープンされた PR、証拠の欠如、またはチェックの失敗がある場合、公開はブロックされます。準備前に main が更新された場合は、再検証してください。ブロッカーを隠すために記録された対象範囲を縮小してはなりません。

ソース PR のバッチがない、本当にリリースのみのタスクの場合は、--prs none を指定してサイクルを明示的に開始し、検証してください。暗黙にサイクルを省略する回避策はサポートされていません。元のバッチ一覧には、承認された対象範囲内のすべての PR を含める必要があります。

コントリビューターの準備状況

作成者の証拠、初期修正、制限付きバンドルについては、コントリビューションの受付に従ってください。既存のコントリビューター向け事前チェックと Actions の概要を再利用してください。これらは承認やマージを許可するものではありません。セマンティックレビューの前に、内容に踏み込んだ、作成者が対応可能な修正を依頼し、実際のタスクテストと、構造・ソース・プロトコルのチェックを区別して、正確な HEAD に対するレビューを維持してください。保守コストの低減を主張する前に、実際の外部 PR の結果を測定してください。

PR の証拠を確認する際は、テンプレートのコメントを、表示されている断片を連結せずに解析してください。未完了のコメントは作成者の証拠ではありません。このパーサーは、信頼できないレポート出力のエスケープ処理とは分離してください。

正規のスキルツリー PR の必須受付は、保護されたベースブランチの pr-policy と現在の本文に対するマージチェックによって適用されます。記入済みの 3 つの証拠セクションを必須とし、範囲を限定した簡潔な結果と、未実行のテストについての説明を受け入れ、作成者が対応可能な修正を返してください。オーナーの保証やキャッシュされたセマンティックレシートで、この要件を免除しないでください。説明文やドラフトのずれがあれば、マージの試行を中止してください。ドラフトはフィードバックを受けられる状態のままにしてください。新たに取り込む外部の内容には、ライセンスの出所とルートの LICENSE を保持し、無関係な既存部分のクリーンアップを強制しないでください。バンドルされたコントリビューション受付ガイドに記載された受付の詳細に従ってください。

トリアージの前に maintenance:doctor を使用し、各ステージの間に maintenance:cycle next を使用してください。独立して許可された作業は継続し、完全な検証の前に修正を完了し、次にマージするものだけを調整して、最後に予定されているソース PR にリリースノートを含めてください。認証済み候補の昇格、キャッシュされたリリースのウェブチェック、明示的な GitHub／サイト検証ターゲットについては、保守契約に従ってください。

範囲を限定した maintenance:cycle run を使って、すでに許可された決定論的な継続処理を唯一のマージ権限を通じて実行してください。正確な HEAD に対する実際のレビューは引き続き必須です。明示的な --allow-align true は、PR ごとに観測済み HEAD を 1 回更新することを許可します。不確実な書き込みを再試行したり、レビューを捏造したりしないでください。メタデータの受付、早期の PR 準備状況、ランタイム優先の候補スケジューリング、範囲を限定した永続的なインストールについては、契約を確認してください。すべてのチェックを維持し、実際のサイクルを測定してください。

承認待ちのフォーク CI については、コーディネーターはチェックを待つ前に、同じ保護されたマージゲートに処理を委任します。実行を直接承認することはありません。正確な HEAD に基づくスケジューリングと失敗の境界については、サイクルのリファレンスを参照してください。