release-openclaw-maintainer

OpenClaw リリースメンテナー

通常の開発や助言を目的とした変更ではなく、リリース作業に使用してください。 現在のポリシーについては docs/reference/RELEASING.md を読んでください。プライベートな認証情報ロケーターやホスト構成を解決する前に、利用可能であれば $release-private を読み込んでください。認証情報の操作には $one-password を使用します。

操作を選択する

選択したフェーズに必要な参照のみを読んでください。

• 通常のベータ版／安定版の準備または公開：通常のリリース。準備とフェーズごとの証明の手順が記載されています。リクエストで安定版／フル版が指定されていない場合は、ベータ版を既定とします。ベータ版の承認では、後続の安定版への昇格は承認されません。
• バックポート候補の調査：候補一覧。拡張安定版の場合は、バックポートの準備も読んでください。SDK／設定の変更には、メンテナンスリスクについて明示的な警告とメンテナーの判断が必要です。
• 拡張安定版 .33+ Gateway の公開：拡張安定版の公開。拡張安定版の入力を指定して共通のパブリッシャーを使用してください。Latest ではないその GitHub Release には証拠が含まれますが、ネイティブアプリや ClawHub での公開は行いません。
• 検証の選択または証明の失敗：検証と信頼度。ワークフローの実行と不変マニフェストには $release-openclaw-ci を使用してください。
• 公開またはレジストリ昇格の中断：公開の復旧。
• ネイティブアセット：プラットフォームへの公開。macOS の操作には $release-openclaw-mac を使用してください。
• 安定版公開後の同期と、正確な SHA を指定したデプロイ引き継ぎ： main の締めくくり。
• リリースノート：$openclaw-changelog-update。承認済みの公開後ドキュメントミラー経由の手順は別途あります。初回のリリース生成では既存の形式を維持します。リリース中にドキュメントが自動で公開されることはありません。告知を依頼された場合は、Discord には $release-openclaw-announcement、X には $release-tweets を使用してください。告知は公開の条件にはならず、投稿には明示的な承認が必要です。
• 公開済みアーティファクトの検証：$verify-release。GHSA の操作には、セキュリティワークフローの明示的な承認がある場合に限り $openclaw-ghsa-maintainer を使用してください。

共通のリリース要件

選択した検証レーンはすべて成功する必要があります。Windows と macOS の Node、およびその他の通常の CI ジョブ、インストールスモーク、サバイバーレーン、update-first-hop-compat*、pack/npm の適格性確認、パッケージの整合性、Linux／Windows／macOS の Gateway チェックが対象です。これには Release Checks の Windows パッケージ版のインストール／アップグレードチェックも含まれます。キャンセルされた実行もブロック要因になります。最初に発生した失敗を保持し、復旧前にそれぞれを以下のように分類してください。安定版の公開には、安定版／フル版の証拠、ソーク、ブロッキング対象のパフォーマンスが必要です。ベータプロファイルの証拠では安定版の公開を承認できません。レーンまたはソークの免除によってこれらの要件を回避することはできません。すべてのグループの適格性確認には、Linux、Windows、macOS にわたる Gateway のインストール／アップグレードの全 9 通りの組み合わせが必要です。ID、来歴、完全な証拠、および既存の公開承認を維持してください。 失敗したテストはすべて、明示的なリードの判断、すなわち実際のリリースブロッカーかフレークとして、その根拠とともにハンドオフに記録されます。根拠とは、同じ SHA が別の場所または再実行で成功していること、リリース差分との関係がないこと、ランナーやインフラのシグネチャ、同じケースがフレークした履歴、または回帰ではない既存の製品バグ (たとえば 2026.9.6 の「Assign to…」バグ) です。実際のブロッカーとは、出荷されるバイトまたは動作における回帰、あるいは更新/インストール/公開の欠陥であり、リリースブランチで修正します。フレークは同じリリース SHA で再実行し、デフォルトでは最大 2 回の記録された再実行にとどめ、根拠を添えて main に並行修正の issue または PR を起票します。フレークのために再カット、ツール変更、新しい FRV の開始を決して行いません。赤いままのフレークは公開をブロックします。main のみの失敗およびインフラ障害 (ランナーの停止、GitHub のゴーストジョブ、ホスト型ランナーのオフロード) は、リリースにとってはフレークとして扱います。

依存関係のアドバイザリがリリースを遅らせることは決してありません。新たに公開されたアドバイザリは、再カット、ツール変更、検証の再実行の理由には決してなりません。リリースの根拠とハンドオフに記録し、公開後の通常のフォローアップとして main に依存関係の更新を起票またはキュー登録します。公開を停止するのは、既知のマルウェアの検出のみです。リリースの依存関係の根拠とリリースからディスパッチされた CI がこれを強制します。

main の CI 健全性がリリースをゲートすることは決してありません。検証と公開はリリースブランチと固定されたツールで実行されるため、赤い main は待機、再カット、一時停止の理由にはなりません。リリースが main 上のリリースツールの修正を必要とする場合 (ツールの SHA は信頼された main コミットでなければなりません)、その修正が原因ではない main の失敗がそのランディングを妨げてはなりません。クリーンな main チェックアウトでその失敗がすでに存在することを証明し、PR 本文に記録してマージします。アクティブなリリース中は、まさにその状況において、リリースツールの PR に対して管理者マージが許可されます。赤い main は引き続き修正されますが、別のレーンで並行して行われ、リリースのクリティカルパス上では決してありません。

運用目標は、検証を約 20 分で確定し、公開を 1 時間以内に収めることであり、測定された保証ではありません。ソースのみの子は成果物のプロデューサーと並行して開始し、候補のコンシューマーは候補の準備ができ次第開始します。独立して確定されたグリーンの子は、たとえその親が失敗、キャンセル、またはアクティブのままであっても、まったく同じターゲットと入力に対して再利用できます。それらの元の承認された適格性アイデンティティ (または履歴上の信頼された main ワークフロー SHA) と現在の試行を検証します。確定済みマニフェストは SDK の根拠ダイジェストと npm 公開の判断を提供しますが、SDK API の変更を承认することは決してないため、SDK レポートに変更が含まれる場合は常に plugin_sdk_api_acknowledgement を提供します。パブリッシャーは放棄された検証根拠を受け入れることができません。明示的なパブリッシャー入力が公開スコープを選択し、候補ヘルパーは必要に応じてその明示的な SDK 承認を依然として検証します。

バージョン変更および不可逆的な公開には明示的な承認が必要です。名前付きリリースのカット、公開、または完了のリクエストは、その検証済みの公開と検証を通じて継続します。アイデンティティ、チャネル、スコープ、または重大なリスクが変更されない限り、再度尋ねないでください。通常のコードに対する出荷権限はリリース権限ではありません。 名前付きリリースの準備に必要なことを実行するためのオペレーターによる明示的な承認は、必要な準備上の判断と修正を行うための継続的な権限です。候補版やツールの修正、アップグレード／移行の設計、レビュー済みのテストやセキュリティインベントリとの整合、隔離環境での検証、コミット、プッシュ、検証からの復旧まで、この権限の範囲で進めてください。判断、その根拠、選択したサポート契約を記録してください。すでに承認された作業区分が実装や検証の段階に進んだというだけで、再度確認を求めないでください。ブロッカーを解決する間も、独立して進められる作業を続けてください。この権限は、欠陥を隠すこと、成功を装うためにゲートの基準を下げること、オペレーターの状態を破壊的に変更すること、無関係な作業、または公開を許可するものではありません。「準備のみ」の依頼でも、アーティファクトやブリッジバージョンをリリースする前に、別途公開の指示が必要です。

引き継ぎテンプレートを使って、簡潔な状態記録を1つ維持してください。記録する内容は、有効な目標、バージョン／タグ／ブランチ、cut／Code／Release SHA、C/Q/Pの識別情報、実行中の親ランと試行、成功した子アーティファクト、承認済みの変更、フェーズと次のアクションです。オペレーターの最新の指示が、それ以前の指示で置き換えられた範囲に優先します。完了済みの根拠は、名前を指定した変更によって無効になるまで有効です。

通常のリリースでは、可能であればCode SHAを固定する前に完全なリリースノートを準備してください。ノートが確定している場合、Code SHAとRelease SHAは同じコミットです。成功した新規の完全な認定を1回実施すれば、両方の役割と、公開に使う正確なバイト列を満たせます。ラベルを分けるだけのために、別のコミットや実行を作成しないでください。認定後にノートを変更した場合、変更後の子孫コミットについて、完全な差分がCHANGELOG/<version>.md（正確なベータ版バージョンまたは安定版のベース）と、それに対応するレコードおよびルートインデックスだけであれば、split-changelog-release-v1を使ってプロダクトの検証結果を再利用し、新しい公開用バイト列を認定できます。それ以外のソース差分、ファイル名変更、削除があれば、Code SHAのループに戻ります。過去のルートのみのレシートでは、引き続きchangelog-only-release-v1を使用します。新しい認定ではQ=Cを固定します。認定ワークフロー全体のクロージャーは候補版に属します。独立して信頼されるP（受け入れ判定、検証、公開）は分離して維持してください。Qハーネスの修正には、新しいC/Qと新たに紐付けた根拠が必要です。Pのみの修正やインフラの修正では、候補版を維持できます。認定契約が不足している場合は、将来のmainを代用せず、意図的にバックポートしてください。

候補版を切った後は、そのベースはオペレーターの判断によって確定します。そのリリースについてPeterが明示的に要求しない限り、候補版を新しく切り直して（候補版をより新しいmainにリベースして）はいけません。確認を求めずに、マージ済みのmainコミットをリリースブランチにチェリーピックできるのは、確認済みのリリースブロッカーを修正する場合に限ります。該当するのは、固定済みの候補版で必須レーンが決定論的に失敗する場合、または更新／インストール／公開バイト列の欠陥です。チェリーピックごとに引き継ぎ記録へ明記してください。許可されないもの：便宜的なバックポート、機能のリバート、または小規模な競合解消でチェリーピックできる修正を「取り込む」ために、新しいベースを採用すること。

リリース中に行ったリリースプロセスの改善は、両方のブランチに反映してください。ワークフロー、リリーススクリプト、リリーステスト、RELEASING.md、およびリリーススキルの変更は、まずmainにマージし、その後、次の候補版またはパッチ版に向けてrelease/YYYY.M.PATCHへチェリーピック（-x）してください。このリリースに必要な認定の修正は、新しいC/Qを固定する前に反映してください。すでに認定済みの候補版のハーネスを、黙って差し替えてはいけません。ブランチにmain限定のCIインフラがない場合は、ブランチの式形式を維持し、ロジックだけを移植してください。リリースブランチ上のプロダクトコードは、上記の規則に従い、ブロッカーの修正に限ります。 リリースは、そのために開始した作業がすべて完了するまで終わりではありません。最終報告の前に、リリース中に作成されたすべての PR（gh pr list --author @me --state open と、セッションに紐づくすべての PR）を列挙し、それぞれをマージするか、理由を明記して明示的にクローズしてください。修正が main に反映されていることを確認し、リリースツールの場合はリリースブランチにも反映されていることを確認してください。また、リリース用の一時的なワークツリー、放棄されたローカルのカットブランチ、古くなった scripts/pr ワークツリーも削除してください。

公開済みのバージョンと最終タグは変更できません。ソースが完全に一致する成果物が正常に作成済みであれば、それを再利用してください。暗黙の再試行として再ビルドや再公開を行わないでください。進行中のリリースが作業キューです。便乗して main を変更したり、バックポートしたりしないでください。失敗を分類し、担当箇所を修正して、影響を受けた範囲だけを再試行し、リリース全体を繰り返すのではなく、その後に状況を再評価してください。

必須の公開証明と、強制適用される環境承認は引き続き必須です。別の対象で成功しても、必要な証拠の不足を補うことはできません。優先するのは npm と ClawHub の公開経路です。macOS、Windows、Linux、Android のネイティブ公開は並行して実行し、npm／ClawHub、GitHub リリースの最終確定、main の締め処理を妨げないようにしてください。選定対象の Windows Node、Linux／Windows／macOS Gateway、ネイティブアプリの CI 失敗は、リリース検証を妨げます。各プラットフォームのパブリッシャーは、それぞれ独自の成果物およびアップデーターの要件を維持します。保留中のプラットフォームと不足している証拠は、正確に報告してください。