openclaw-release-maintainer

OpenClaw リリースメンテナー

リリースおよび公開時のワークフローには、このスキルを使用してください。通常の開発変更と GHSA 固有のアドバイザリ作業には、このスキルを使用しないでください。

リリース時のガードレールを遵守する

• オペレーターの明示的な承認なしに、バージョン番号を変更しないでください。
• npm の公開やリリースの手順を実行する前に、許可を求めてください。
• このスキルだけで、通常のリリースフローを最初から最後まで進められるようにしてください。
• 認証情報、復旧手順、mac の署名／公証に関する詳細には、メンテナー向けの非公開リリースドキュメントを使用し、公開ポリシーには docs/reference/RELEASING.md を使用してください。
• コアの openclaw の公開は手動の workflow_dispatch で行います。タグを作成またはプッシュしただけでは公開されません。
• 通常のリリース作業は、main から切り出したブランチで行い、main で直接作業しないでください。ブランチ名には release/YYYY.M.D を使用してください。
• オペレーターが「安定版／完全版」と明示せずにリリースを依頼した場合は、デフォルトでベータ版のみとしてください。オペレーターが完全版リリースまたはベータ版から安定版までの自動リリースを明示的に依頼した場合に限り、ベータ版から安定版へ進めてください。
• リリースブランチを作成する前に、最新の main をプルし、現在の main の CI が成功していることを確認してください。そのコミットからブランチを作成し、リリース検証中も main で通常の開発を続けられるようにしてください。
• リリースブランチを作成する前に、変更のあるファイルをまとまりごとにコミットしてプッシュし、プル／リベースしてから、main で /changelog を実行してください。リリースブランチの作成直前に、その変更履歴の書き換えをコミット、プッシュ、プルしてください。
• リリース計画中は、ブランチ作成前と最終公開前に、src/plugins/compat/registry.ts と src/commands/doctor/shared/deprecation-compat.ts の両方を確認してください。removeAfter の日付がリリース日以前の、非推奨または削除予定の互換性レコードごとに、安全であれば互換性経路を削除して関連テストを検証するか、削除が妨げられている理由を記録し、期限切れの互換性経路をリリースする前にメンテナーの明示的な承認を得てください。
• 非推奨のランタイム／設定との互換性を削除する際も、サポート対象のアップグレード経路で引き続き必要となる doctor の移行、修復、ヒントは維持してください。メンテナーが修復不要と確認するまで、doctor 側の互換性は src/commands/doctor/shared/deprecation-compat.ts で追跡し続けてください。
• リリース計画中に、互換性の代替案に関する文言を再検証してください。プラグインの所有権、外部化、設定の範囲によって推奨される代替案は変わることがあるため、古い代替案の注記をリリースノートにそのまま転記しないでください。
• 対応する npm パッケージが公開された後は、ベータタグを削除または書き換えないでください。プッシュ済みのベータタグが npm 公開前の事前チェックに失敗した場合は、タグとプレリリースを削除して、修正済みのコミットで作り直し、npm のプレリリースバージョンが連続するようにしてください。公開済みのベータ版に修正が必要な場合は、リリースブランチに修正をコミットし、次の -beta.N にバージョンを上げてください。
• ベータ版のリリースでは、まず高速なローカル事前チェックを実行し、npm の beta にベータ版を公開してから、公開パッケージを対象とした高負荷のテスト項目（インストール／更新／Docker／Parallels／NPM Telegram）を実行してください。失敗があった場合は、リリースブランチで修正し、コミット／プッシュ／プルしてベータ番号を上げ、再度実行してください。安定版／latest への昇格前に、高負荷のテスト項目一式を少なくとも一度は実行してください。それ以降のベータ版では、変更の影響があったテスト項目のみ再実行してください。ただし、修正がリリース全般、インストール／更新、プラグイン、Docker、Parallels、または実環境での QA に広く影響する場合は、テスト項目一式を再実行してください。各ベータ版の公開後に、リリースブランチの作成後に入った重要な修正がないか、現在の main を一度確認し、重要かつリスクの低い修正のみをバックポートしてください。オペレーターは自律的なベータ版の試行を最大 4 回まで許可できます。ベータ版の試行に 4 回失敗したら、作業を停止して報告してください。
• バージョン／タグの準備前に /changelog を使用し、変更履歴の先頭セクションを重複のない状態に整理して、ユーザーへの影響順に並べてください。
• ベータ版専用の CHANGELOG.md 見出しは作成しないでください。ベータ版のリリースには安定版のベースバージョンのセクションを使用します。たとえば、v2026.4.20-beta.1 のリリースノートには ## 2026.4.20 を使用してください。
• ベータ版または安定版のリリースが公開されたら、Peter の .profile にあるボットトークンを使用して、Discord で可能な限り告知してください。告知に失敗しても、リリースを妨げたりロールバックしたりしないでください。
• X での告知を依頼された場合は、~/Projects/bird/bird を使用し、以下のリリース告知ポストのスタイルに従ってください。

リリースチャンネルの命名を統一する

• stable：タグ付きリリースのみ。デフォルトでは npm beta に公開されます。運用担当者は明示的に npm latest を指定するか、後から昇格できます
• beta：vYYYY.M.D-beta.N のようなプレリリースタグで、npm の dist-tag は beta です
• -beta.N を優先してください。新たに -1 または -2 のベータサフィックスを付けないでください
• dev：main の最新コミットです
• ベータ版の Git タグを使用する場合は、通常のバージョンが消費されたりブロックされたりしないよう、対応するベータ版のバージョンサフィックスを付けて npm に公開してください

バージョンとリリースファイルを一貫して管理する

• バージョンの記載箇所は次のとおりです：
  • package.json
  • apps/android/app/build.gradle.kts
  • apps/ios/Sources/Info.plist
  • apps/ios/Tests/Info.plist
  • apps/macos/Sources/OpenClaw/Resources/Info.plist
  • docs/install/updating.md
  • Peekaboo の Xcode プロジェクトおよび plist のバージョンフィールド
• リリースタグを作成する前に、上記すべてのバージョンの記載箇所を、そのタグに含まれるバージョンと一致させてください。
• vYYYY.M.D-N のようなフォールバック修正タグの場合も、リポジトリ内のバージョンの記載箇所は YYYY.M.D のままにしてください。
• 「バージョンをすべての箇所で更新する」とは、appcast.xml を除く上記すべてのバージョンの記載箇所を指します。
• リリース署名と公証の認証情報は、リポジトリ外の非公開メンテナー向けドキュメントに保管されています。
• OpenClaw のすべての安定版リリースでは、npm パッケージと macOS アプリを同時に公開します。 ベータ版リリースでは通常、まず npm／パッケージのアーティファクトを公開し、運用担当者が macOS ベータ版の検証を求めない限り、mac アプリのビルド、署名、公証は省略します。
• npm の事前チェックに合格したら、時間のかかる macOS の署名／公証処理で npm の公開を遅らせないでください。mac の検証／公開は並行して続け、npm の公開は成功した npm の事前チェックから開始し、その後、公開済み npm のインストール／更新、Docker、Parallels の検証を開始してください。その間も mac のアーティファクト作成を続けます。
• ベータ版を公開した後は、必要に応じてリモート／手動のリリース検証を並行して進めてください。ただし、システム負荷のノイズが発生する場合は、同じホストにローカルの Docker、Parallels、QA-Lab の作業を集中させないでください。失敗や修正の後には選択的に再実行して構いませんが、安定版／latest への昇格前に、Docker、Parallels、QA-Lab のそれぞれが少なくとも一度は合格したことを示す証跡を保持してください。
• タグ付きコミットとの差分が mac のパッケージ作成、署名、ワークフロー、または検証のみを目的としたリリース機構である場合は、リリースブランチにわずかな変更を加えた状態から mac のパッケージをビルドしても構いません。安定版の npm パッケージまたは GitHub タグの公開後に、mac のパッケージ作成でリリースブランチ限定の修正が必要になった場合は、ワークフローのソースを変更するだけのために vYYYY.M.D-N の修正タグを作成しないでください。元の tag=vYYYY.M.D に対して、source_ref=release/YYYY.M.D および public_release_branch=release/YYYY.M.D を指定して非公開の mac ワークフローをディスパッチしてください。プロベナンスチェックではソースの SHA がタグから派生していることを証明し、検証と事前チェックでは同じソースを使用する必要があります。vYYYY.M.D-N の修正タグは、新しい npm パッケージ／リリース ID の公開が必要な緊急ホットフィックス用に限り、通常の mac のみのパッケージ復旧には使用しないでください。
• 本番環境の Sparkle フィードは https://raw.githubusercontent.com/openclaw/openclaw/main/appcast.xml にあり、正式な公開ファイルは openclaw リポジトリの main ブランチにある appcast.xml です。
• 共有の本番 Sparkle フィードは安定版専用です。ベータ版の mac リリースでは GitHub のプレリリースにアセットをアップロードしても構いませんが、別のベータ版フィードがない限り、共有の appcast.xml を置き換えてはいけません。
• vYYYY.M.D-N のようなフォールバック修正タグの場合、リポジトリ内のバージョンは YYYY.M.D のままですが、既存のインストール済みアプリが新しいバージョンと認識するよう、mac リリースでは元のリリースより厳密に大きい数値の APP_BUILD／Sparkle ビルド番号を使用する必要があります。

変更履歴に基づくリリースノートの作成

• リリースブランチの作成やタグ付けを行う前に、既存の記載だけを頼りにせず、コミット履歴に基づいて対象の CHANGELOG.md セクションを書き直してください。最後に到達可能なリリースタグ以降のコミットを確認し、記載漏れのあるユーザー向けの変更を追加し、重複する項目を整理して、各セクションをユーザーにとって重要な順に並べてください。
• 変更履歴の項目はユーザー向けの内容とし、社内向けのリリース作業メモにはしないでください。
• GitHub のリリースとプレリリースの本文には、抜粋や要点ではなく、該当する CHANGELOG.md のバージョンセクション全体を使用してください。リリースの作成時または編集時は、## YYYY.M.D から次のレベル 2 の見出しの直前までを抜き出し、そのブロック全体をリリースノートとして使用してください。
• リリースノートを準備する際は、src/plugins/compat/registry.ts と src/commands/doctor/shared/deprecation-compat.ts を確認し、リリース日から7日以内に warningStarts または removeAfter を迎える互換性レコードを調べてください。該当するレコードがある場合は、互換性コード、対象日、置き換え先、およびそのレコードの docsPath へのリンクを含む「Upcoming deprecations」の注記をリリースノートに追加してください。より具体的な非推奨化ページがない場合は、/plugins/compatibility へのリンクを使用してください。
• ベータ版の GitHub プレリリースを伴う mac リリースを行う場合：
  • リリースコミットから vYYYY.M.D-beta.N のタグを付ける
  • openclaw YYYY.M.D-beta.N というタイトルでプレリリースを作成する
  • ベータ専用の見出しではなく、安定版のベースとなる CHANGELOG.md バージョンセクション（## YYYY.M.D）のリリースノートを使用する
  • 少なくとも zip と dSYM zip を添付し、利用可能であれば dmg も添付する
• CHANGELOG.md の上位バージョン項目は、影響度順に並べてください。
  • ### Changes を最初にする
  • ### Fixes は重複を整理し、ユーザー向けの修正を最初にする

リリース告知ツイートを書く

OpenClaw アカウントの既存のリリース投稿スタイルを使います。

• 形式：OpenClaw YYYY.M.D 🦞 または 🦞 OpenClaw YYYY.M.D is live、空行、 絵文字で始まる箇条書きを3～4個、空行、 短い決め台詞を1つ、その後にリリース リンクを記載します。
• ベータ版の場合：OpenClaw YYYY.M.D-beta.N 🦞 または OpenClaw YYYY.M.D beta N is live とし、ベータ版であることを明確に示し、安定版に昇格したかのような表現は避けます。
• ユーザーから見える機能を最初に取り上げ、次に重要な連携、最後に信頼性・セキュリティ・インストールの修正を紹介します。「修正多数」は、読みやすい箇条書き1つにまとめます。
• 下書きを作成する前に、変更履歴の該当セクションを最後まで読みます。リリースが明確にそれらを主題としている場合を除き、カバレッジ、CI、検証、内部的なリリース手順から書き始めないでください。Peter は、具体的にユーザーの役に立つ内容、つまり機能、連携、ワークフローの改善、実用的な信頼性向上の修正を好みます。
• トーン：情報密度が高く、少し茶目っ気があり、自信に満ちていて、企業的ではないものにします。冗談は1つで十分です。人を見下したり、ユーザーを侮辱したり、確認されていないことを約束したりしないでください。
• Peter は、しっくりくるなら、淡々として簡潔なタグラインを好みます。よい例：Big release, tiny release notes... kidding. 冗談は短くし、ツイートの中心は機能の箇条書きにします。決め台詞を二段落目にしたり、無理に笑いを取ったりしないでください。
• 長さ：リリース告知ツイートは、URLを1つ載せる余裕を残しつつ、常に280文字未満にします。投稿前に最終版の文字数を確認します。
• リンク／メディア：最初のリリース告知ツイートの末尾に、GitHub のリリースまたは変更履歴へのリンクを含めます。
• スレッドでの続きの投稿：スレッドにする場合、最初のリリース告知ツイートは簡潔な公開告知にし、その後の返信では機能を1つずつ取り上げて説明します。スレッドの文脈から明らかな場合、続きの返信で「VERSION で新登場」やバージョン番号を繰り返さないでください。
• Peter が好むスレッドの進め方：まず汎用的な告知ツイートに合意してから、続きのツイートを1つずつ作成します。next と言われたら、次の続きの投稿だけを提示またはコピーします。求められない限り、スレッド全体を再掲しないでください。
• 続きの投稿には、それぞれの機能に対応するドキュメントのURLを必ず含めます。明確さのためにラベルが必要な場合を除き、Docs: <url> よりURLのみを記載する形式を優先します。続きの投稿は簡潔にし、生の文字数で160～220文字程度を目安にします。280文字未満が厳守上限です。URLを含めると文字数を超える場合は、URLを削るのではなく、まず文章を短くしてください。
• 診断、軌跡／エクスポート、プロバイダーの設定、モデルのコマンド、その他セットアップに関する機能は、最初のリリース告知ツイートに詰め込むのではなく、続きの投稿で説明することを優先します。
• ホットフィックス／修正告知：率直に、責任ある姿勢で伝えます。何が漏れたのか、何を修正したのか、新しいバージョンを明記します。障害に関する投稿では冗談を避けてください。

応用する例：

OpenClaw 2026.4.20-beta.1 🦞

🐳 Docker install/update smoke
🖥️ Parallels upgrade checks
🔧 Package verification tightened

Beta first. Stable after the gauntlet.
<release link>

OpenClaw 2026.4.20 🦞

🚀 Faster install + update
🐳 Docker + Parallels verified
🍎 macOS signed + notarized
🔧 Channel/plugin fixes

Good boring release. Best kind.
<release link>

Packaging issue in 2026.4.20-beta.1.

2026.4.20-beta.2 fixes install/update verification. No tag rewrites; beta moves
forward.

Upgrade with the beta channel.
<release link>

公開前の検証を実行する

タグ付けまたは公開の前に、次を実行します。

pnpm check:architecture
pnpm build
pnpm ui:build
pnpm qa:otel:smoke
pnpm release:check
pnpm test:install:smoke

• リリース検証でテレメトリーのカバレッジが必要な場合は、pnpm qa:otel:smoke を使用します。 ローカルの OTLP/HTTP トレースレシーバーを起動し、QA-lab の otel-trace-smoke を実行して、外部の Opik または Langfuse の認証情報を使わずに スパン名とコンテンツ／識別子の秘匿化を確認します。

root 以外のスモークパスの場合：

  OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke

npm で公開した後、次を実行します。

node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>

• 新しい一時プレフィックスで、公開済みレジストリからのインストールパスを検証します。
• YYYY.M.D-N のような安定版の修正リリースでは、YYYY.M.D から YYYY.M.D-N への アップグレードパスも検証します。これにより、修正版の公開後に既存のグローバルインストールが 古いベース安定版のペイロードを使い続ける事態を防ぎます。
• インストールのスモークテストもパックサイズの上限チェックとして扱います。pnpm test:install:smoke は、npm が過大な unpackedSize を報告した場合に候補アップデートの tarball を 不合格にするようになりました。これにより、リリース時の e2e で、低メモリー環境での インストールや起動に支障をきたすおそれのあるパッケージ肥大化を見逃しません。
• インストールのスモークテストでは、npm のグローバルインストールを直接検証するカバレッジを有効にしておきます。 npm install -g <candidate> による新規インストールと、npm によるアップデートインストールを検証します。 ドキュメントで pnpm を推奨していても、多くのユーザーが npm でインストールするためです。
• 動画生成がリリース対象に含まれる場合は、動画プロバイダーの範囲を絞ったスモークテストとして pnpm test:live:media video を使用します。デフォルトの動画スモークテストでは fal をスキップし、 各プロバイダーで「ロブスターを一秒間表示する」というプロンプトによるテキストから動画への変換を 一回試行します。また、各プロバイダーの処理時間は OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS （デフォルトは 180000）で制限されます。
• FAL 固有の検証が必要な場合に限り、pnpm test:live:media video --video-providers fal を 実行します。キューの待ち時間によって、リリースにかかる時間が長くなる可能性があります。
• 時間のかかる画像から動画への変換レーンと動画から動画への変換レーンを意図的に検証する場合に限り、 OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1 を設定します。

リリースに関連するすべてのビルドを確認する

• タグを作成する前に、必ず OpenClaw npm リリースパスを検証してください。
• ライブリリース検証の前に Peter のプロファイルを source して、シークレットを出力せずに OpenAI と Anthropic の認証情報を利用できるようにします: set -a; source "$HOME/.profile"; set +a。
• このトレインの Parallels 検証およびローカルでのライブモデル QA は、OPENAI_API_KEY と ANTHROPIC_API_KEY の両方を使用する必要があります。.profile を source した後にどちらかが欠けている場合は、それらのローカル長時間レーンを開始する前に停止し、欠けているキーを報告してください。
• 認証情報を用いたライブチャネル QA は、ローカルの代替手段ではなく、GitHub Actions ワークフロー QA-Lab - All Lanes (.github/workflows/qa-live-telegram-convex.yml) です。Actions からリリースタグに対してディスパッチし、npm のプリフライト/パブリッシュ準備の前に合格するのを待ってください。SHA を使用するのは、ワークフローのシークレットを伴う信頼ゲート (main の祖先またはオープン PR のヘッド) を満たす場合のみにしてください。これは qa-live-shared 環境を使用して、QA Lab モックパリティゲートに加えてライブ Matrix およびライブ Telegram レーンを実行します。Telegram は Convex CI 認証情報リースを使用します。
• デフォルトのリリースチェック:
  • pnpm check
  • pnpm check:test-types
  • pnpm check:architecture
  • pnpm build
  • pnpm ui:build
  • pnpm release:check
  • OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke
• npm 前のベータテスト完全ロスター:
  • 上記のデフォルトのリリースチェック
  • すべての Docker テスト: pnpm test:docker:all、およびオペレーターが「すべての docker テスト」と言った場合に集約に含まれないスタンドアロンの Docker ライブレーン: pnpm test:docker:live-acp-bind、pnpm test:docker:live-cli-backend、および pnpm test:docker:live-codex-harness
  • すべての Parallels インストール/更新テスト: pnpm test:parallels:npm-update -- --json、および openclaw-parallels-smoke から必要に応じた個別の再実行レーン
  • すべての QA リリース検証: GitHub Actions > QA-Lab - All Lanes をリリースタグに対してディスパッチし、成功を必須とします。これが、認証情報を用いたライブ Matrix/Telegram チャネルカバレッジのリリースゲートです。SHA を使用するのは、ワークフローの信頼ゲートを満たす場合のみにしてください。ローカルの OpenAI/Anthropic スイートまたはリポジトリに基づくキャラクター評価は、オペレーターが追加のモデルカバレッジを求めた場合、または障害をローカルでデバッグする必要がある場合にのみ実行してください。
• パブリッシュ後のベータ検証ロスター:
  • node --import tsx scripts/openclaw-npm-postpublish-verify.ts <beta-version>
  • パブリッシュされたベータチャネルに対するインストール/更新スモーク
  • パブリッシュされたベータパッケージを実行する Docker インストール/更新カバレッジ
  • パブリッシュされた npm の Telegram プルーフ: main から Actions > NPM Telegram Beta E2E を package_spec=openclaw@<beta-version> および provider_mode=mock-openai でディスパッチし、成功を必須とします。このワークフローはメンテナーがディスパッチするもので、意図的に npm-release 承認ゲートを持ちません。qa-live-shared は共有 QA シークレットを提供するだけです。これは、インストール済みパッケージのオンボーディング、Telegram セットアップ、およびパブリッシュされた npm パッケージに対する実際の Telegram E2E のデフォルトのボタンパスです。 フォールバックまたはデバッグパスとしてのみ、一致する OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC と Convex CI 環境を指定してローカルの pnpm test:docker:npm-telegram-live レーンを使用してください。
  • OpenAI と Anthropic の両方のプロバイダーキーを利用可能な状態での Parallels パブリッシュ済みベータのインストール/更新カバレッジ
  • Parallels のインストール/更新プルーフは、オペレーターがハーネスのみの分離チェックを明示的にスコープしない限り、プラグインインストールを有効に保つ必要があります。バンドルされたプラグインインストールを無効にするレーンは、プラグイン/依存関係のリリース証拠として有効ではありません。
  • 完全な npm 前ロスターの後に修正が触れた領域に対してのみ、対象を絞った QA 再実行を行います。ただし、オペレーターが完全な QA ロスターを再度要求した場合を除きます。修正がライブチャネル QA、認証情報の配線、Matrix、Telegram、または QA ハーネスに触れる場合は、Actions > QA-Lab - All Lanes を再実行してください。
• npm パッケージだけでなく、リリースが触れるすべてのリリース関連ビルドサーフェスを確認してください。
• ベータ形式の完全な e2e バッテリーでは、トップレベルの長時間レーンを無期限に実行させるのではなく、上限をハードキャップしてください。ホストの timeout --foreground/gtimeout --foreground の上限を次のように使用します:
  • OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke には 45m
  • pnpm test:docker:all には 90m
  • スタンドアロンの Docker ライブレーンにはそれぞれ 60m
  • 明示的に要求された場合のローカル完全 QA ライブ OpenAI + Anthropic ロスターには 180m。デフォルトのリリースチャネル QA ゲートは Actions > QA-Lab - All Lanes です
  • openclaw-parallels-smoke スキルからの Parallels の上限 レーンが上限に達した場合は、停止して影響を受けるレーンを検査/修正してから続行してください。同じプロセスを待ち続けないでください。
• 実際の npm インストール/更新フェーズは 5 分に上限が設定されています。リリース e2e で npm install -g、インストーラーパッケージのインストール、または openclaw update に 300 秒以上かかる場合は、その実行を健全な進捗として扱うのをやめ、インストーラー/アップデーターまたはハーネスをデバッグしてください。
• VM レーンの前にホストのビルド/パッケージ変更を直列化してください。Parallels の npm pack レーンを開始する前に、pnpm build、pnpm ui:build、pnpm release:check、インストールスモーク、およびすべての Docker/パッケージ準備レーンを完了させてください。そうしないと、VM の pack 準備中に dist が消えて偽の失敗を引き起こす可能性があります。
• すべてのリリースで openclaw/openclaw の公開検証ワークフローと openclaw/releases-private の実際の mac プリフライトを実行することで、プリフライトに mac リリース準備を含めてください。
• main 上の appcast.xml の更新を、オプションのフォローアップではなく、mac リリース準備の一部として扱ってください。
• ワークフローは引き続きタグベースです。エージェントは、パブリッシュ実行が開始される前にプリフライト実行が正常に完了することを確認する責任があります。
• プリフライト後の修正は、新しいコミットを意味します。タグと対応する GitHub リリースを削除して修正コミットから再作成し、パブリッシュ前にプリフライトを最初から再実行してください。 例外: 対応する npm パッケージがすでにパブリッシュされているベータタグは、決して削除または再作成しないでください。代わりに次のベータ番号にインクリメントしてください。プッシュされたタグ/プレリリースのみが存在し、npm パブリッシュが行われていない場合は、その同じベータタグを修正コミットで再作成してください。
• 安定版 mac リリースでは、公開リリースアセットをアップロードする前に署名済みの appcast.xml を生成して、アップデーターのフィードがパブリッシュされたバイナリより遅れることがないようにしてください。
• タグ間で安定版の appcast 生成実行を直列化して、2 つのリリースが同じ古いシードから置換用の appcast.xml ファイルを生成しないようにしてください。
• 安定版リリースでは、主に最新ベータのより広範なリリースワークフローの信頼性に依存してください。一致する非ベータビルドを npm の latest に昇格させる場合は、時間制限付きの軽量な検証パスを優先してください: パブリッシュ後の npm 検証、Docker インストール/更新スモーク、macOS のみの Parallels インストール/更新スモーク、および必要な QA シグナル。ベータの証拠が古い場合、安定版ビルドがベータと大きく異なる場合、またはオペレーターが完全な再テストを明示的に要求した場合を除き、完全な Docker/Parallels マトリックスを再実行しないでください。
• 必要なビルド、パッケージング手順、またはリリースワークフローが赤い場合は、リリースの準備ができたと言わないでください。

適切な認証フローを使用する

• OpenClaw の公開には、GitHub の信頼されたパブリッシングを使用します。
• beta から latest への安定版 npm プロモーションには、非公開の openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml ワークフローを使用します。npm dist-tag の管理には NPM_TOKEN が必要ですが、 公開 npm リリースワークフローは OIDC のみを使用するためです。
• ローカルの 1Password フォールバックよりも、非公開ワークフローのトークン経路を 修正してください。望ましい構成は、粒度の細かい npm トークンを非公開リポジトリの NPM_TOKEN シークレットとして保存し、自動化用に読み書き権限と 2FA バイパスを openclaw パッケージに限定することです。
• NPM_TOKEN がない、または古くなっているために非公開の dist-tag ワークフローで プロモーションできない場合は、ローカルの tmux ＋ 1Password フォールバックを 使用します。
  • 対話型の npm login と OTP のプロンプトを確認・復旧できるように、tmux セッションを開始するか、既存のセッションを再利用します。
  • 絶対ルール：リリース作業中にメインのエージェントシェルで op を直接実行 しないでください。1Password CLI を使う場合は、プロンプトやアラートをその セッション内に隔離して確認できるよう、必ず tmux セッション内で実行します。
  • npm の認証情報と OTP には、1Password アイテム op://Private/Npmjs を使用します。 パスワード、トークン、OTP をトランスクリプトに出力しないでください。tmux バッファー、tmux コマンドに限定した環境変数、または log_user 0 を指定した expect を通じて渡します。
  • その tmux セッション内で npm login --auth-type=legacy を実行して npm に 再認証し、npm whoami が steipete を返すことを確認します。
  • 新しい OTP を使用してプロモーションします。 npm dist-tag add [email protected] latest --otp "$OTP"。
  • たとえば、キャッシュを迂回したレジストリ読み取りで確認します。 npm view openclaw dist-tags --json --prefer-online --cache /tmp/openclaw-npm-cache-verify-$$ および npm view openclaw@latest version dist.tarball --json --prefer-online。
• 直接安定版を公開する場合も、運用担当者が両方のタグをすぐに揃えたいときは、 その非公開 dist-tag ワークフローを使用して、すでに公開済みの latest バージョンを beta の参照先にできます。
• 公開の実行は、workflow_dispatch を使って手動で開始する必要があります。
• npm ワークフローと非公開 mac 公開ワークフローは、preflight_only=true を指定して、 公開リリースアセットをアップロードせずに検証、ビルド、パッケージ化の各手順を 実行できます。
• 実際の npm 公開では、公開ジョブが再ビルドせずに準備済みの tarball を プロモーションできるよう、事前に成功した npm preflight の実行 ID が必要です。
• 実際の非公開 mac 公開では、公開ジョブが再ビルドや再 notarize を行わずに準備済みの アーティファクトをプロモーションできるよう、事前に成功した非公開 mac preflight の 実行 ID が必要です。
• 非公開 mac ワークフローは、ブランチで安全に実行できるワークフローのスモークテスト用に smoke_test_only=true も受け付けます。このテストではアドホック署名を使用し、 notarize と共有 appcast の生成をスキップします。リリース準備が整っていることの証明には なりません。
• npm ワークフローの preflight_only=true は、公開後に既存のタグを検証する場合にも 適切です。npm バージョンがすでに公開済みでも、ビルドチェックは実行し続ける必要が あります。
• npm の検証のみを行う preflight は、マージ前のワークフロー変更のテスト時に通常の ブランチから実行してもかまいません。リリースチェックと実際の公開には、 main または release/YYYY.M.D のみを使用します。
• openclaw/openclaw の .github/workflows/macos-release.yml は、現在、公開用の 検証のみを行う引き継ぎワークフローです。タグとリリースの状態を検証し、運用担当者に 非公開リポジトリを案内します。リリース検証に必要な JS 出力は引き続き再ビルドしますが、 macOS アーティファクトの署名、notarize、公開は行いません。
• openclaw/releases-private/.github/workflows/openclaw-macos-validate.yml は、 swift test に必須の非公開 mac 検証レーンです。実際の安定版 mac 公開を開始する前に、 必ず成功させてください。
• 実際の mac preflight と実際の mac 公開には、どちらも openclaw/releases-private/.github/workflows/openclaw-macos-publish.yml を使用します。
• 非公開 mac 検証レーンは、GitHub の標準 macOS ランナーで実行されます。
• 非公開 mac preflight の経路は、GitHub の xlarge macOS ランナーで実行されます。 ビルド、署名、notarize、パッケージ化の処理は CPU 負荷が高いため、SwiftPM キャッシュを 使用します。
• 非公開 mac preflight は、notarize 済みのビルドアーティファクトを公開 GitHub リリース アセットとしてではなく、ワークフローアーティファクトとしてアップロードします。
• 非公開スモークテストの実行では、アドホック署名済み・notarize なしのビルド アーティファクトをワークフローアーティファクトとしてアップロードし、安定版の appcast.xml 生成を意図的にスキップします。
• 安定版リリースでは、実際の公開を開始する前に、npm preflight、公開 mac 検証、 非公開 mac 検証、非公開 mac preflight のすべてが成功している必要があります。 ベータ版リリースでは、mac ベータ検証が明示的に要求されていない限り、npm preflight と、選択した Docker、インストール／更新、Parallels、リリースチェックの各レーンで 十分です。
• 実際の公開は、main または release/YYYY.M.D ブランチから実行できます。 リリースブランチから実行する場合、タグはそのリリースブランチに含まれている必要があり、 実際の公開では同じブランチからの成功済み preflight を再利用する必要があります。
• リリースワークフローはタグベースのままにします。ワークフローレベルで SHA を固定する のではなく、記載されているリリース手順に従ってください。
• 公開を続行するには、npm-release 環境が @openclaw/openclaw-release-managers に よって承認されている必要があります。
• mac の公開では、 openclaw/releases-private/.github/workflows/openclaw-macos-publish.yml を使用して、 非公開 mac preflight のアーティファクト準備と、実際の公開におけるアーティファクトの プロモーションを行います。
• 非公開リポジトリの mac-release 環境に OPENCLAW_PUBLIC_REPO_RELEASE_TOKEN が ある場合、実際の非公開 mac 公開では、パッケージ化された .zip、.dmg、 .dSYM.zip アセットが openclaw/openclaw の既存の GitHub リリースに自動で アップロードされます。
• 安定版リリースでは、エージェントは成功した非公開 mac ワークフローから署名済みの macos-appcast-<tag> アーティファクトもダウンロードし、その後 main の appcast.xml を更新する必要があります。
• ベータ版 mac リリースでは、別個のベータ版 Sparkle フィードがない限り、共有の本番用 appcast.xml を更新しないでください。
• 非公開リポジトリは専用の mac-release 環境を対象とします。GitHub のプランがまだ そこで必須レビュアーをサポートしていない場合、環境だけで承認境界が確保されると 想定しないでください。それらの設定を有効にできるまでは、非公開リポジトリへの アクセス制御と CODEOWNERS に依拠してください。
• OpenClaw パッケージの公開経路では、NPM_TOKEN とプラグインの OTP フローを 使用しないでください。パッケージの公開には信頼されたパブリッシングを使用します。
• NPM_TOKEN は、明示的に npm の dist-tag を管理する場合にのみ使用してください。 npm dist-tag add は信頼されたパブリッシングに対応していないためです。
• @openclaw/* プラグインの公開には、メンテナー専用の別フローを使用します。
• npm ですでに公開されているプラグインのみ公開してください。バンドル済みで ディスクツリーにのみ存在するプラグインは、公開しないままにします。

Fallback local mac publish

• CI/CD による macOS 公開が利用できない、または正常に動作しない場合に備えて、従来のローカル macOS 公開ワークフローをフォールバックとして利用できる状態にしておきます。
• Peter が使用する既存のメンテナーワークフローを維持します。ローカル署名、notary、Sparkle の認証情報を設定済みの実機 Mac で実行します。
• ローカルでの手順は、非公開のメンテナー向け macOS 手順書に従います。アプリのビルド、署名、公証、パッケージ化には scripts/package-mac-dist.sh を使用し、GitHub リリースのアセットを手動でアップロードした後、scripts/make_appcast.sh を実行して appcast.xml を main にコミットします。
• scripts/package-mac-dist.sh は、バンドルされたアプリのバンドル ID がデバッグ用になっている、Sparkle フィード URL が空である、または CFBundleVersion が該当する短縮バージョンの正規 Sparkle ビルド下限を下回っている場合、リリースビルドを失敗させるようになりました。修正用タグでは、より大きな値を明示的に APP_BUILD に設定します。
• scripts/make_appcast.sh は、まず PATH 内の generate_appcast を使用し、次に apps/macos/.build 内の SwiftPM Sparkle ツールの出力にフォールバックします。
• 安定版タグの場合、ローカルフォールバックによって共有の本番用 appcast.xml を更新することがあります。
• ベータ版タグの場合も、ローカルフォールバックで macOS 用アセットを公開しますが、別個のベータフィードがない限り、共有の本番用 appcast.xml は更新してはいけません。
• ローカルワークフローはフォールバックとしてのみ扱います。CI/CD 公開ワークフローが正常に動作している場合は、そちらを優先してください。
• 安定版 macOS 公開の後、リリース完了とする前に、以下のすべてを確認してください。
  • GitHub リリースに .zip、.dmg、.dSYM.zip の各アセットがある
  • main 上の appcast.xml が新しい安定版 zip を参照している
  • パッケージ化されたアプリが、想定される短縮バージョンと、正規 Sparkle ビルド下限以上の数値 CFBundleVersion を報告している

リリース手順を実行する

1. オペレーターがリリースを明示的に希望していることを確認します。
2. 正確な対象バージョンと Git タグを決定します。
3. 変更のあるファイルを一貫性のあるグループに分けてコミットし、プッシュして、プル／リベースし、ワークツリーがクリーンであることを確認します。
4. 最新の main をプルし、現在の main の CI がグリーンであることを確認します。
5. main で安定版のベースとなる対象バージョンに対して /changelog を実行し、変更されたチェンジログを直ちにコミットして、プッシュし、プル／リベースします。ベータリリースでは、チェンジログの見出しを ## YYYY.M.D-beta.N ではなく ## YYYY.M.D にします。
6. チェンジログ変更後の main のコミットから release/YYYY.M.D を作成します。
7. 作成前に、すべてのリポジトリ内バージョン表記をベータタグに一致させます。
8. リリースブランチでリリース準備の変更をコミットし、ブランチをプッシュします。
9. npm の事前チェックや公開の前に、リリースブランチから高速なローカルベータ事前チェックを実行します。オペレーターからベータ公開前に実行するよう依頼されない限り、高コストな Docker、Parallels、公開済みパッケージのインストール／更新のテストはベータ公開後に行います。
10. ベータリリースでは、ベータの範囲またはリリースを妨げる問題への対応として特に必要でない限り、mac アプリのビルド／署名／公証を省略します。安定版リリースでは、mac アプリ、署名、公証、appcast の一連の処理を含めます。
11. 対象の npm バージョンがすでに公開されていないことを確認します。
12. リリースブランチから Git タグを作成し、プッシュします。
13. 対応する GitHub リリースを作成するか、更新します。
14. Actions > QA-Lab - All Lanes をリリースタグに対して実行し、モックのパリティ、ライブ Matrix、ライブ Telegram の認証済みチャンネルの各レーンが成功するまで待ちます。
15. リリースブランチから .github/workflows/openclaw-npm-release.yml を preflight_only=true で実行し、意図した npm_dist_tag（デフォルトは beta、意図的に安定版を直接公開する場合のみ latest）を選択します。成功するまで待ちます。その実行 ID を保存します。実際の公開では、準備済みの npm tarball を再利用するためにこの ID が必要です。
16. 安定版リリースでは、openclaw/openclaw で .github/workflows/macos-release.yml を実行し、一般公開向けの検証のみの実行が成功するまで待ちます。
17. 安定版リリースでは、openclaw/releases-private/.github/workflows/openclaw-macos-validate.yml を同じタグで実行し、非公開 mac 検証レーンが成功するまで待ちます。
18. 安定版リリースでは、openclaw/releases-private/.github/workflows/openclaw-macos-publish.yml を preflight_only=true で実行し、成功するまで待ちます。その実行 ID を保存します。実際の公開では、公証済み mac アーティファクトを再利用するためにこの ID が必要です。
19. 事前チェックまたは検証が失敗した場合は、新しいコミットで問題を修正し、タグと対応する GitHub リリースを削除して、修正済みコミットから再作成し、続行する前に関連するすべての事前チェックを最初からやり直します。コミットが変わった後に、古い事前チェック結果を再利用してはいけません。プッシュ済みまたは公開済みのベータタグについては、削除して再作成せず、次のベータタグに上げます。npm でベータ版が公開されていない事前チェックのみの失敗の場合は、プレリリース番号を飛ばさず、修正済みコミットから同じベータタグとプレリリースを削除して再作成します。
20. 実際の公開では、同じブランチから同じタグを指定して .github/workflows/openclaw-npm-release.yml を実行します。npm_dist_tag（デフォルトは beta、意図的に安定版を直接公開する場合のみ latest）を選択し、事前チェックの実行時と同じ値にして、成功した npm の preflight_run_id を渡します。
21. @openclaw/openclaw-release-managers による npm-release の承認を待ちます。
22. 公開後の検証を実行します。 node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>
23. 公開済みベータ版の検証項目を実行します。まず現在の main を調べ、リリースブランチの分岐後に取り込まれた重大な修正を確認します。高コストなレーンを開始する前に、重要かつリスクの低い修正のみをバックポートします。公開済みパッケージを変更する必要がある修正なら、次のベータに上げます。ベータパッケージの公開後にいずれかのレーンが失敗した場合は、修正して、コミット／プッシュ／プルし、次のベータタグに上げて、該当するベータ検証をやり直します。ベータが公開されたら、安全に並行できるリモート／手動の検証項目を開始しますが、ローカルの Docker と Parallels の負荷は制御してください。安定版／latest への昇格前に、高コストな検証項目がすべて少なくとも一度は成功していることを確認します。検証項目には、正確な公開済みベータパッケージを対象とする手動の Actions > NPM Telegram Beta E2E ワークフローが含まれます。タグ／パッケージがマシンから外に出る前に npm 前のレーンが失敗した場合は、同じベータ試行を修正して再実行します。オペレーターが承認したベータ試行回数の上限まで繰り返します。通常は 4 回です。
24. Peter の .profile にあるボットトークンを使用して、Discord でベータ／安定版リリースを可能な範囲で告知します。
25. オペレーターがベータのみを依頼した場合は、ベータ検証と告知の後で終了します。
26. 安定版リリースが beta に公開され、対応するベータ版ですでに完全な信頼性確認に合格している場合は、軽量な安定版昇格検証項目を実行します。公開済み npm の公開後検証、Docker のインストール／更新スモークテスト、macOS のみを対象とする Parallels のインストール／更新スモークテスト、および必要な QA シグナルです。その後、非公開の openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml ワークフローを実行して、その安定版の beta から latest への昇格を行い、latest がそのバージョンを指していることを確認します。
27. 安定版リリースが latest に直接公開され、beta も同じバージョンにする必要がある場合は、同じ非公開の dist-tag ワークフローを実行して beta を安定版のバージョンに設定し、latest と beta の両方がそのバージョンを指していることを確認します。
28. 安定版リリースでは、成功した非公開 mac の preflight_run_id を指定して、実際の公開のために openclaw/releases-private/.github/workflows/openclaw-macos-publish.yml を実行し、成功するまで待ちます。
29. 成功した非公開 mac の実行によって、.zip、.dmg、.dSYM.zip のアーティファクトが openclaw/openclaw の既存の GitHub リリースにアップロードされたことを確認します。
30. 安定版リリースでは、成功した非公開 mac の実行から macos-appcast-<tag> をダウンロードし、main の appcast.xml を更新して、フィードを検証します。安定版の公開が成功した後、リリースブランチの変更を main にマージするか、チェリーピックします。
31. ベータリリースでは、明示的に依頼された場合にのみ mac アセットを公開します。共用の本番用 appcast.xml アーティファクトは想定せず、別個のベータ用フィードがない限り、共用の本番用フィードを更新しないでください。
32. 公開後に npm と添付されたリリースアーティファクトを検証します。

GHSA アドバイザリの作業

• GHSA アドバイザリの調査、パッチ適用／公開のフロー、プライベートフォークの検証、GHSA API 固有の公開チェックには、openclaw-ghsa-maintainer を使用します。