OpenClaw リリースメンテナー は何をしますか？
リリース操作用であり、通常の開発やアドバイザリの変更には使用しません。
現在のポリシーについては docs/reference/RELEASING.md を参照してください。プライベートな認証情報の場所やホストトポロジを解決する前に、$release-private が利用可能な場合は読み込んでください。認証情報の操作には $one-password を使用します。
ロールの選択
- リリースオーナー (デフォルト): 「このリリースを管理」は、準備から検証、振り返り、終了まで、1つのリリースを所有します。短いプロンプトであっても、オーナーライフサイクル から始めてください。
- リリースマネージャー / オーケストレーター: 複数のリリースオーナーを調整し、キックオフや引き継ぎの概要を作成し、ホットフィックスの機会をルーティングします。マネージャーモード から始めてください。このロールは、オーナーのリリースブランチや公開状態の第二の作成者にはなりません。
このスキルは一般的なプロセスを所有します。初期プロンプトは、コピーされたランブックではなく、リリース固有の意図、権限、および状態を伝達します。引き継ぎは、別のリリースを開始するのではなく、現在のエビデンスを使用してその意図を再開します。
操作の選択
選択したフェーズに必要な参照のみを読み取ってください。
- 通常のベータ/安定版の準備または公開: 通常リリース。これにより、準備とフェーズ固有の証明がルーティングされます。リクエストで安定版/フルが指定されていない場合、デフォルトでベータになります。ベータの承認は、後日の安定版へのプロモーションを許可しません。
- バックポートの発見と移植: 候補インベントリとワーカー概要。延長安定版の場合は、バックポート準備 も参照してください。SDK/設定の変更には、目に見えるメンテナンスリスクの警告とメンテナーによる決定が必要です。
- 延長安定版
.33+Gateway 公開: 延長安定版公開。延長安定版の入力と共有パブリッシャーを使用します。その非 Latest GitHub Release は、ネイティブアプリや ClawHub の公開なしにエビデンスを伝達します。 - 検証の選択または失敗した証明: 検証と信頼性。ワークフローの実行とイミュータブルなマニフェストには
$release-openclaw-ciを使用します。 - 中断された公開またはレジストリプロモーション: 公開リカバリ。
- ネイティブアセット: プラットフォーム公開。macOS 操作には
$release-openclaw-macを使用します。 - 安定版公開後の同期と正確な SHA デプロイメントの引き継ぎ: メインクローズアウト。
- リリースの振り返りと共有イシューレジャー (すべてのトラック、および任意の引き継ぎスナップショット): 振り返り。
- リリースノート:
$openclaw-changelog-update。これには、別途承認された公開後のドキュメントミラールートが含まれます。初期リリース生成は既存の形式を維持します。ドキュメントの公開はリリース中に自動的には実行されません。リクエストされたアナウンス: Discord 用$release-openclaw-announcement、X 用$release-tweets。アナウンスが公開をゲートすることは決してなく、明示的な投稿承認が必要です。 - 公開されたアーティファクトの検証:
$verify-release。GHSA 操作: 明示的なセキュリティワークフロー承認がある場合のみ$openclaw-ghsa-maintainer。
ホットフィックスレジャーの管理
バックポートの発見、選択、および結果 (Tideclaw が所有するリリースを含む) には、共有ホットフィックスレジャー を優先してください。候補を再利用し、メイン/兄弟リリースからの発見を追加し、各リリースの評価を更新します。アクセスできない場合は、ローカルのエビデンスを保持し、後で同期します。これは推奨される記録管理であり、別のリリースゲートではありません。
共有リリース境界
FRV は、固定された P のチェックイン済みリリースツールポリシー の下で 成功 で終了する必要があります。テストをスキップしたり C/Q を変更したりせずに、正確に失敗したライブプロバイダーまたは Telegram のリーブのみが免除される場合があります。その他すべての必須レーンは成功する必要があります: Windows および macOS Node およびその他の通常の CI ジョブ、インストールスモーク、サバイバーレーン、update-first-hop-compat*、pack/npm 資格、パッケージ整合性、Linux/Windows/macOS Gateway チェック (Release Checks での Windows パッケージインストール/アップグレードチェックを含む)。キャンセルされた実行もブロックされます。最初の失敗を保存し、以下のようにそれぞれを分類してからリカバリしてください。安定版の公開には、安定版/フルのエビデンス、ソーク、およびブロッキングパフォーマンスが必要です。ベータプロファイルのエビデンスは安定版の公開を承認できません。これらのハードゲート、ソーク、またはパフォーマンスは免除できません。Linux、Windows、macOS 間の 9 つの Gateway インストール/アップグレードの組み合わせすべてが、全グループ資格に必要です。ID、来歴、完全なエビデンス、および既存の公開承認を保持してください。
失敗した各テストには、明示的なリード決定、実際のリリースブロッカーまたはフレークがあり、そのエビデンスとともに引き継ぎに記録されます: 同じ SHA が他の場所または再実行で合格している、リリースデルタとの関連性がない、ランナーまたはインフラの署名、同じケースがフレークした履歴、または回帰ではない既存の製品バグ (例: 2026.9.6 の「Assign to…」バグ)。実際のブロッカーとは、出荷されたバイトまたは動作の回帰、または更新/インストール/公開の欠陥です。リリースブランチで修正してください。同じリリース SHA でフレークを再実行する場合、デフォルトで最大 2 回の記録された再実行とし、エビデンスとともに main に並行修正のイシューまたは PR を提出してください。フレークのためにカットし直さないでください。意図的なツールコードの免除には、新しい固定 P の下での FRV 検証が必要であり、パブリッシャーによるオーバーライドは許可されません。免除されていないフレークが赤のままの場合、公開をブロックします。メインのみの失敗およびインフラストラクチャの失敗 (ランナーの停止、GitHub のゴーストジョブ、ホステッドランナーのオフロード) は、リリースのフレークとしてカウントされます。
依存関係アドバイザリはリリースを遅延させることはありません。新たに公開されたアドバイザリは、カットし直し、ツールの変更、または検証の再実行の理由にはなりません。リリースのエビデンスと引き継ぎに記録し、公開後、通常のフォローアップとして main に依存関係のバンプを提出またはキューに入れてください。既知のマルウェアの検出のみが公開を停止します。リリース依存関係のエビデンスとリリースディスパッチ CI がこれを強制します。
メインの CI の健全性がリリースをゲートすることは決してありません。検証と公開はリリースブランチと固定されたツールから実行されるため、赤い main は待機、カットし直し、または一時停止の理由にはなりません。リリースが main にリリースツールの修正を必要とする場合 (ツール SHA は信頼できる main コミットである必要がある)、修正が引き起こさない main の失敗はそのランディングを妨げてはなりません。クリーンな main チェックアウトで、その失敗がすでにそこに存在することを証明し、PR 本文に記録し、マージしてください。アクティブなリリース中は、まさにその状況でのリリースツール PR に対して管理者マージが許可されます。赤い main はそれでも修正され、リリースのクリティカルパス上ではなく、別のレーンによって並行して行われます。
FRV ウォールタイムループ に従ってください。リモート検証を迅速に開始し、診断結果が排出されるにつれて障害を修復し、サイクル間のダウンタイムを最小限に抑えます。次の実行に影響を与える既知の非フレーク修正をすべて、障害を意図的に持ち越すのではなく含めてください。有用なローカルチェックをリモート検証と重複させてください。これはスケジューリングをガイドするものであり、新しいゲートではありません。
運用目標は、検証を確定し、公開を約 1 時間以内に完了することであり、測定された保証ではありません。ソースのみの子は、アーティファクトプロデューサーと同時に開始されます。候補コンシューマーは、候補の準備ができ次第すぐに開始されます。独立して確定された緑の子は、親が失敗、キャンセル、またはアクティブな状態であっても、同じ正確なターゲットと入力に対して再利用できます。元の認められた資格 ID (または過去の信頼できるメインワークフロー SHA) と現在の試行を検証してください。確定されたマニフェストは、SDK エビデンスダイジェストと npm 公開決定を提供します。SDK API の変更を認識しないため、SDK レポートに変更が含まれている場合は常に plugin_sdk_api_acknowledgement を提供してください。パブリッシャーは成功した FRV のみを受け入れ、免除を許可できません。明示的なパブリッシャー入力が公開範囲を選択します。候補ヘルパーは、必要に応じて明示的な SDK 承認を依然として検証します。
リリース管理リクエストには、オーナーライフサイクルの権限デフォルト を使用してください。ベータには、保留されていない限り検証済み公開が含まれます。安定版と延長安定版には公開承認が必要です。明示的な準備のみのリクエストは、決して公開を許可しません。名前付きリリースを公開または完了するようにという明示的な指示は、その検証済み公開と検証を通じて実行されます。ID、チャネル、範囲、または重大なリスクが変更されない限り、再度尋ねないでください。バージョンを変更する前に解決して記録してください。指定されていないバージョンは、ライフサイクルの承認ルールに従います。通常のコードに対する出荷権限は、リリース権限ではありません。
名前付きリリースを準備するために必要なことは何でも行うようにとのオペレーターの明示的な承認は、必要な準備の決定と修復に対する恒久的な権限です。候補およびツールの修正、アップグレード/移行の設計、レビューされたテストまたはセキュリティインベントリの調整、分離された証明、コミット、プッシュ、および検証リカバリを通じてそれを実行してください。決定、そのエビデンス、および選択されたサポート契約を記録してください。すでに承認されたクラスの作業が実装または検証のステップに達したという理由だけで、再度尋ねないでください。ブロッカーの解決中に独立した作業を続けてください。この権限は、欠陥の隠蔽、成功を偽るためのゲートの低下、オペレーター状態への破壊的な変更、無関係な作業、または公開を許可しません。準備のみのリクエストには、アーティファクトまたはブリッジバージョンをリリースする前に、別途公開の指示が必要です。
引き継ぎテンプレート を使用して、1 つのコンパクトな状態レコードを保持してください。効果的な目標、バージョン/タグ/ブランチ、カット/コード/リリース SHA、C/Q/P ID、アクティブな親の実行と試行、成功した子アーティファクト、承認された変更、フェーズ、および次のアクション。最新のオペレーターの指示は、以前の範囲を置き換えます。完了したエビデンスは、名前付きの変更によって無効にされない限り、完全なままです。
通常のリリースでは、可能な場合は コード SHA をフリーズする前に完全なノートを準備してください。それらのノートが最終版である場合、コード SHA とリリース SHA は同じコミットです。1 回の成功したフル新規資格で、両方の役割とその正確な公開バイトを提供できます。ラベルを分離するためだけに別のコミットや実行を作成しないでください。資格後にノートが変更された場合、完全なデルタに CHANGELOG/<version>.md (正確なベータバージョンまたは安定ベース) とそのエントリのみ、そのマッチングレコード、およびルートインデックスが含まれる子孫は、split-changelog-release-v1 を使用して新しい公開バイトを資格しながら製品証明を再利用できます。その他のソースデルタ、名前変更、または削除は、コード SHA ループに戻ります。過去のルートのみのレシートは changelog-only-release-v1 を保持します。新しいテスト資格は Q=C を固定します。候補のテストワークフロークロージャは候補に属します。独立して信頼できる P (入場、集約決定、検証者、およびパブリッシャー) は別にしておいてください。Q ハーネスの修復には、新しい C/Q と新たにバインドされたエビデンスが必要です。P のみまたはインフラストラクチャの修復は、候補を保持できます。不足している資格契約には、将来のメインへのフォールバックではなく、意図的なバックポートが必要です。
一度候補がカットされると、そのベースはオペレーターの決定です。Peter がそのリリースで明示的に要求しない限り、決してカットし直さないでください (新しい main に候補を再ベースする)。要求なしに、確認されたリリースブロッカー (必須レーンがフリーズされた候補で決定的に失敗している、または更新/インストール/公開バイトの欠陥) を修正するためだけに、すでにマージされた main コミットをリリースブランチにチェリーピックしてください。各チェリーピックを引き継ぎレコードに名前を付けてください。許可されないもの: 日和見的なバックポート、機能のリバート、または小さな競合解決できれいにチェリーピックされる修正を「ピックアップ」するために取られる新しいベース。オペレーターが明示的に承認した追加は、オーナー受け入れ手順 に従います。変更された範囲を記録し、新しい候補を再資格し、無効にされた証明を黙って再利用しないでください。マネージャーの機会通知は、その承認ではありません。
リリース中に行われたリリースプロセスの改善は、両方のブランチにランディングします。ワークフロー、リリーススクリプト、リリーステスト、RELEASING.md、およびリリーススキルの変更は、最初に main にマージされ、次の候補またはパッチのために release/YYYY.M.PATCH にチェリーピック (-x) されます。このリリースに必要な資格修復は、新しい C/Q をフリーズする前にランディングする必要があります。すでに資格された候補のハーネスを黙って交換しないでください。ブランチに main のみの CI インフラストラクチャがない場合、ブランチの表現形式を維持し、ロジックのみを移植してください。リリースブランチ上の製品コードは、上記のルールに従ってブロッカーのみです。
リリースのために開かれたすべての修復 PR を、最終報告書の前に解決してください。以下で説明する振り返り PR は、未解決の修復ではなく、必須のオープンクローズアウト成果物です。リリース中に作成されたすべての PR をリストしてください (gh pr list --author @me --state open に加えて、そのリリースのスコープに関連する PR)。