リリースポリシー

• stable: 既存の昇格済みリリースチャネル。独立した CLI/チャネルのマイルストーンが到達するまでは、引き続き npm latest 経由で解決されます
• beta: npm beta に公開されるプレリリースタグ
• dev: main の移動する先頭

​

バージョン命名

• 月次 npm extended-stable リリースバージョン: YYYY.M.PATCH、PATCH >= 33、git タグ vYYYY.M.PATCH
• 日次/通常の最終リリースバージョン: YYYY.M.PATCH、PATCH < 33、git タグ vYYYY.M.PATCH
• 通常のフォールバック修正リリースバージョン: YYYY.M.PATCH-N、git タグ vYYYY.M.PATCH-N
• Beta プレリリースバージョン: YYYY.M.PATCH-beta.N、git タグ vYYYY.M.PATCH-beta.N
• Alpha プレリリースバージョン: YYYY.M.PATCH-alpha.N、git タグ vYYYY.M.PATCH-alpha.N
• 月またはパッチをゼロ埋めしない
• PATCH はカレンダー日ではなく、月次リリーストレインの連番です。通常の最終リリースと beta リリースは現在のトレインを進めます。alpha のみのタグは beta/通常のパッチ番号を消費も進行もしないため、beta または通常のトレインを選ぶときは、より高いパッチ番号を持つレガシーな alpha のみのタグを無視してください。
• Alpha/nightly ビルドは次の未リリースのパッチトレインを使用し、繰り返しビルドでは alpha.N のみを増やします。そのパッチに beta が付いたら、新しい alpha ビルドは次のパッチに移ります。
• npm バージョンは不変です。公開済みタグを削除、再公開、再利用してはいけません。代わりに次のプレリリース番号または次の月次パッチを切ってください。
• latest は引き続き現在の通常/日次 npm ラインに従います。beta は現在の beta インストール先です
• extended-stable は、パッチ 33 から始まる、サポート対象の直近月 npm パッケージを意味します。パッチ 34 以降はその月次ライン上のメンテナンスリリースです
• 通常の最終リリースと通常の修正リリースは、デフォルトで npm beta に公開されます。リリース担当者は明示的に latest を対象にすることも、後から検証済みの beta ビルドを昇格することもできます
• 専用の月次 extended-stable パスは、コア npm パッケージと、npm 公開可能なすべての公式 Plugin を同一の正確なバージョンで公開します。Plugin を ClawHub に公開したり、macOS または Windows アーティファクト、GitHub Release、プライベートリポジトリ dist-tag、Docker イメージ、モバイルアーティファクト、Web サイトのダウンロードを公開したりはしません。
• 通常の最終リリースごとに、npm パッケージ、macOS アプリ、署名済み Windows Hub インストーラーを一緒に出荷します。Beta リリースでは通常、まず npm/package パスを検証して公開し、ネイティブアプリのビルド/署名/公証/昇格は、明示的に要求されない限り通常の最終リリース用に予約します。

​

リリース周期

• リリースは beta 優先で進みます。stable は最新 beta が検証された後にのみ追従します
• メンテナーは通常、現在の main から作成した release/YYYY.M.PATCH ブランチからリリースを切ります。これにより、リリース検証と修正が main 上の新規開発をブロックしません
• beta タグが push または公開済みで修正が必要な場合、メンテナーは古いタグを削除または再作成するのではなく、次の -beta.N タグを切ります
• 詳細なリリース手順、承認、認証情報、復旧メモはメンテナー専用です

​

月次 npm 専用 extended-stable 公開

gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=true \
  -f npm_dist_tag=extended-stable

gh workflow run full-release-validation.yml \
  --ref extended-stable/YYYY.M.33 \
  -f ref=extended-stable/YYYY.M.33 \
  -f release_profile=stable

RELEASE_SHA="$(git rev-parse HEAD)"
gh workflow run plugin-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f publish_scope=all-publishable \
  -f ref="$RELEASE_SHA" \
  -f npm_dist_tag=extended-stable

gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=false \
  -f npm_dist_tag=extended-stable \
  -f preflight_run_id=<npm-preflight-run-id> \
  -f full_release_validation_run_id=<full-validation-run-id> \
  -f plugin_npm_run_id=<plugin-npm-run-id>

npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"
npm view openclaw@extended-stable version --userconfig "$(mktemp)"

​

通常リリース担当者チェックリスト

1. 現在の main から開始します。最新を pull し、対象コミットが push 済みであることを確認し、ブランチ元として十分に main CI が green であることを確認します。
2. 最後に到達可能なリリースタグ以降にマージされた PR とすべての直接コミットから、CHANGELOG.md の先頭セクションを生成します。エントリはユーザー向けにし、重複する PR/直接コミットのエントリを重複排除し、コミット、push、ブランチ作成前にもう一度 rebase/pull します。
3. src/plugins/compat/registry.ts と src/commands/doctor/shared/deprecation-compat.ts のリリース互換性記録をレビューします。期限切れの互換性は、アップグレードパスが引き続きカバーされている場合にのみ削除するか、意図的に保持する理由を記録します。
4. 現在の main から release/YYYY.M.PATCH を作成します。通常のリリース作業を main 上で直接行わないでください。
5. タグに必要なすべてのバージョン位置を上げてから、pnpm release:prep を実行します。これは順番に、Plugin バージョン、npm shrinkwrap、Plugin インベントリ、ベース設定スキーマ、バンドル済みチャネル設定メタデータ、設定ドキュメントベースライン、Plugin SDK エクスポート、Plugin SDK API ベースラインを更新します。タグ付け前に生成された差分をコミットし、その後でローカルの決定的プレフライトを実行します: pnpm check:test-types、pnpm check:architecture、pnpm build && pnpm ui:build、pnpm release:check。
6. preflight_only=true で OpenClaw NPM Release を実行します。タグが存在する前は、検証専用プレフライトに完全な 40 文字のリリースブランチ SHA を使用できます。プレフライトは、正確にチェックアウトされた依存グラフの依存リリース証拠を生成し、npm プレフライトアーティファクトに保存します。成功した preflight_run_id を保存します。
7. リリースブランチ、タグ、または完全なコミット SHA に対して Full Release Validation で全プレリリーステストを開始します。これは 4 つの大きなリリーステストボックス、Vitest、Docker、QA Lab、Package に対する単一の手動エントリポイントです。full_release_validation_run_id を保存します。これは OpenClaw NPM Release と OpenClaw Release Publish の両方で必須入力です。
8. 検証が失敗した場合は、リリースブランチ上で修正し、修正を証明する最小の失敗ファイル、レーン、ワークフロージョブ、パッケージプロファイル、プロバイダー、またはモデル allowlist を再実行します。変更サーフェスにより以前の証拠が古くなる場合にのみ、完全な統合ワークフローを再実行します。
9. タグ付き beta 候補の場合は、一致する release/YYYY.M.PATCH ブランチから pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N を実行します。stable の場合は、必要な Windows ソースリリースも渡します: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z。このヘルパーは、ローカルの生成済みリリースチェックを実行し、Full Release Validation と npm プレフライト証拠をディスパッチまたは検証し、正確な準備済み tarball に対する Parallels fresh/update 証拠と Telegram パッケージ証拠を実行し、Plugin npm と ClawHub の計画を記録し、証拠バンドルが green になった後にのみ正確な OpenClaw Release Publish コマンドを出力します。 OpenClaw Release Publish は、選択された、または公開可能なすべての Plugin パッケージを npm に、同じセットを ClawHub に並列でディスパッチし、Plugin の npm publish が成功すると、準備済みの OpenClaw npm プレフライトアーティファクトを一致する dist-tag で昇格します。OpenClaw npm publish の子ワークフローが成功した後、一致する完全な CHANGELOG.md セクションから、対応する GitHub release/prerelease ページを作成または更新します。npm latest に公開された安定版リリースは GitHub の latest release になり、npm beta に保持された安定版メンテナンスリリースは GitHub latest=false で作成されます。このワークフローは、リリース後のインシデント対応のために、プレフライト依存関係エビデンス、完全検証マニフェスト、postpublish レジストリ検証エビデンスも GitHub release にアップロードします。子 run ID を即座に出力し、ワークフロートークンで承認できる release environment gate を自動承認し、失敗した子ジョブをログ末尾付きで要約し、OpenClaw npm publish が成功し次第 GitHub release と依存関係エビデンスを完了し、OpenClaw npm が公開される場合は必ず ClawHub を待機し、その後 pnpm release:verify-beta を実行して、GitHub release、npm パッケージ、選択された Plugin npm パッケージ、選択された ClawHub パッケージ、子ワークフロー run ID、任意の NPM Telegram run ID の postpublish エビデンスをアップロードします。ClawHub パスは一時的な CLI 依存関係インストール失敗をリトライし、1 つの preview セルが不安定でも preview を通過した Plugin を公開し、期待されるすべての Plugin バージョンについてレジストリ検証で終了するため、部分的な公開は可視かつリトライ可能なままになります。 次に、公開された openclaw@YYYY.M.PATCH-beta.N または openclaw@beta パッケージに対して post-publish package acceptance を実行します。push 済みまたは公開済みの prerelease に修正が必要な場合は、次の一致する prerelease 番号を切ります。古いものを削除したり書き換えたりしてはいけません。
10. 安定版では、検証済みの beta または release candidate に必要な検証エビデンスが揃ってから続行します。安定版 npm publish も OpenClaw Release Publish を通り、成功したプレフライトアーティファクトを preflight_run_id で再利用します。安定版 macOS release readiness には、パッケージ化された .zip、.dmg、.dSYM.zip、および更新済みの appcast.xml が main 上にあることも必要です。macOS publish ワークフローは、release asset の検証後に署名済み appcast を public main に自動公開します。branch protection が直接 push をブロックする場合は、appcast PR を開くか更新します。安定版 Windows Hub readiness には、OpenClaw GitHub release 上の署名済み OpenClawCompanion-Setup-x64.exe、OpenClawCompanion-Setup-arm64.exe、OpenClawCompanion-SHA256SUMS.txt asset が必要です。正確な署名済み openclaw/openclaw-windows-node release tag を windows_node_tag として渡し、その candidate 承認済み installer digest map を windows_node_installer_digests として渡します。OpenClaw Release Publish は release draft を保持し、Windows Node Release をディスパッチし、公開前に 3 つすべての asset を検証します。
11. 公開後、npm post-publish verifier、post-publish channel proof が必要な場合は任意の standalone published-npm Telegram E2E、必要に応じた dist-tag promotion を実行し、生成された GitHub release ページを検証し、release announcement 手順を実行してから、安定版リリースを完了と呼ぶ前に Stable main closeout を完了します。

​

Stable main closeout

1. 最新の新鮮な main から開始します。それに対して release/YYYY.M.PATCH を監査し、main に存在しない実際の修正を forward-port します。release 専用の互換性、テスト、検証アダプターを新しい main に盲目的に merge してはいけません。
2. main を、推測上の次の train ではなく、出荷済みの安定版バージョンに設定します。root version 変更後に pnpm release:prep を実行し、その後 pnpm deps:shrinkwrap:generate を実行します。
3. main 上の CHANGELOG.md の ## YYYY.M.PATCH セクションを、tag 付き release branch と完全に一致させます。mac release が公開した場合は、安定版 appcast.xml の更新を含めます。
4. operator がその release train を明示的に開始するまで、YYYY.M.PATCH+1、beta バージョン、または空の将来 changelog セクションを main に追加してはいけません。
5. pnpm release:generated:check、pnpm deps:shrinkwrap:check、OPENCLAW_TESTBOX=1 pnpm check:changed を実行します。push してから、安定版リリースを完了と呼ぶ前に、origin/main が出荷済みバージョンと changelog を含んでいることを検証します。
6. private rollback drill のたびに、repository variables RELEASE_ROLLBACK_DRILL_ID と RELEASE_ROLLBACK_DRILL_DATE を最新に保ちます。

​

Release preflight

• release preflight の前に pnpm check:test-types を実行し、テスト TypeScript が高速なローカル pnpm check gate の外でもカバーされるようにします。
• release preflight の前に pnpm check:architecture を実行し、より広範な import cycle と architecture boundary check が高速なローカル gate の外でも green になるようにします。
• pnpm release:check の前に pnpm build && pnpm ui:build を実行し、期待される dist/* release artifact と Control UI bundle が pack validation step に存在するようにします。
• root version bump 後、tag 付け前に pnpm release:prep を実行します。これは、version/config/API 変更後にずれやすいすべての決定的な release generator を実行します。Plugin version、npm shrinkwrap、Plugin inventory、base config schema、bundled channel config metadata、config docs baseline、Plugin SDK exports、Plugin SDK API baseline です。pnpm release:check はそれらの guard を check mode で再実行し、さらに Plugin SDK surface budget check を加え、package release check を実行する前に、生成物の drift failure を 1 回でまとめて報告します。
• Plugin version sync は、publishable な @openclaw/ai runtime package、official Plugin package version、既存の openclaw.compat.pluginApi floor を、デフォルトで OpenClaw release version に更新します。そのフィールドは単なる package version のコピーではなく、Plugin SDK/runtime API floor として扱ってください。古い OpenClaw host との互換性を意図的に維持する Plugin-only release では、floor をサポート対象の最古 host API のままにし、その選択を Plugin release proof に記録します。
• release approval の前に手動の Full Release Validation ワークフローを実行し、すべての pre-release test box を 1 つの entrypoint から開始します。branch、tag、または完全な commit SHA を受け取り、手動 CI をディスパッチし、install smoke、package acceptance、cross-OS package check、QA Lab parity、Matrix、Telegram lane のために OpenClaw Release Checks をディスパッチします。安定版と full run には、常に網羅的な live/E2E と Docker release-path soak が含まれます。run_release_soak=true は、明示的な beta soak のために保持されています。Package Acceptance は candidate validation 中に canonical package Telegram E2E を提供し、2 つ目の同時 live poller を避けます。 beta を公開した後、release_package_spec を指定すると、release tarball を再ビルドせずに、出荷済み npm パッケージを release check、Package Acceptance、package Telegram E2E 全体で再利用できます。Telegram が他の release validation とは異なる公開済みパッケージを使うべき場合にのみ、npm_telegram_package_spec を指定します。Package Acceptance が release package spec とは異なる公開済みパッケージを使うべき場合は、package_acceptance_package_spec を指定します。Telegram E2E を強制せずに、release evidence report が validation と公開済み npm パッケージの一致を証明すべき場合は、evidence_package_spec を指定します。
  gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH
  
• release 作業を続けながら package candidate の side-channel proof が必要な場合は、手動の Package Acceptance ワークフローを実行します。openclaw@beta、openclaw@latest、または正確な release version には source=npm を使用します。現在の workflow_ref harness で信頼済みの package_ref branch/tag/SHA を pack するには source=ref を使用します。必須の SHA-256 と厳格な public URL policy を伴う public HTTPS tarball には source=url を使用します。必須の trusted_source_id と SHA-256 を使う named trusted-source policy には source=trusted-url を使用します。別の GitHub Actions run によってアップロードされた tarball には source=artifact を使用します。 ワークフローは candidate を package-under-test に解決し、その tarball に対して Docker E2E release scheduler を再利用し、telegram_mode=mock-openai または telegram_mode=live-frontier で同じ tarball に対して Telegram QA を実行できます。選択された Docker lane に published-upgrade-survivor が含まれる場合、package artifact が candidate になり、published_upgrade_survivor_baseline が公開済み baseline を選択します。update-restart-auth は candidate package を installed CLI と package-under-test の両方として使用するため、candidate update command の managed restart path を実行します。 例:
  gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai
  
  一般的な profile:
  • smoke: install/channel/agent、Gateway network、config reload lane
  • package: OpenWebUI または live ClawHub なしの artifact-native package/update/restart/plugin lane
  • product: package profile に加えて MCP channel、cron/subagent cleanup、OpenAI web search、OpenWebUI
  • full: OpenWebUI 付き Docker release-path chunk
  • custom: focused rerun のための正確な docker_lanes selection
• release candidate に対して決定的な通常 CI coverage だけが必要な場合は、手動の CI ワークフローを直接実行します。手動 CI dispatch は changed scoping を迂回し、Linux Node shard、bundled-plugin shard、Plugin and channel contract shard、Node 22 compatibility、check-*、check-additional-*、built-artifact smoke check、docs check、Python Skills、Windows、macOS、Control UI i18n lane を強制します。standalone manual CI run は、include_android=true でディスパッチされた場合にのみ Android を実行します。Full Release Validation はその CI child にその input を渡します。
  gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
  
• リリーステレメトリを検証するときは pnpm qa:otel:smoke を実行します。これは local OTLP/HTTP レシーバーを通じて QA-lab を実行し、Opik、Langfuse、または別の外部コレクターを必要とせずに、トレース、メトリック、ログのエクスポートに加えて、境界付きのトレース属性とコンテンツ/識別子のリダクションを検証します。
• コレクター互換性を検証するときは pnpm qa:otel:collector-smoke を実行します。これは同じ QA-lab OTLP エクスポートを、local レシーバーのアサーションの前に実際の OpenTelemetry Collector Docker コンテナ経由でルーティングします。
• 保護された Prometheus スクレイピングを検証するときは pnpm qa:prometheus:smoke を実行します。これは QA-lab を実行し、未認証のスクレイプを拒否し、リリース上重要なメトリックファミリーにプロンプト内容、生の識別子、認証トークン、ローカルパスが含まれないことを検証します。
• ソースチェックアウトの OpenTelemetry と Prometheus の smoke レーンを連続で実行するには pnpm qa:observability:smoke を実行します。
• すべてのタグ付きリリースの前に pnpm release:check を実行します。
• OpenClaw NPM Release プリフライトは npm tarball をパックする前に依存関係リリース証跡を生成します。npm アドバイザリ脆弱性ゲートはリリースをブロックします。推移的マニフェストリスク、依存関係の所有権/インストール面、依存関係変更レポートはリリース証跡のみです。依存関係変更レポートは、リリース候補と以前の到達可能なリリースタグを比較します。プリフライトは依存関係証跡を openclaw-release-dependency-evidence-<tag> としてアップロードし、準備済み npm プリフライトアーティファクト内の dependency-evidence/ にも埋め込みます。実際の公開パスはそのプリフライトアーティファクトを再利用し、同じ証跡を openclaw-<version>-dependency-evidence.zip として GitHub リリースに添付します。
• タグが存在した後の変更を伴う公開シーケンスには OpenClaw Release Publish を実行します。release/YYYY.M.PATCH（または main から到達可能なタグを公開する場合は main）からディスパッチし、リリースタグ、成功した OpenClaw npm preflight_run_id、成功した full_release_validation_run_id を渡し、意図的に集中的な修復を実行している場合を除き、デフォルトの Plugin 公開スコープ all-publishable を維持します。このワークフローは Plugin npm publish、Plugin ClawHub publish、OpenClaw npm publish を直列化し、外部化された Plugin より前に core package が公開されないようにします。
• Stable の OpenClaw Release Publish には、一致する non-prerelease の openclaw/openclaw-windows-node リリースが存在した後の正確な windows_node_tag と、候補として承認済みの windows_node_installer_digests マップが必要です。公開の子をディスパッチする前に、ソースリリースが公開済みであり、non-prerelease であり、必要な x64/ARM64 インストーラーを含み、承認済みマップと引き続き一致することを検証します。その後、OpenClaw リリースがまだドラフトの間に、固定されたインストーラーダイジェストマップを変更せずに渡して Windows Node Release をディスパッチします。子ワークフローは、その正確なタグから署名済み Windows Hub インストーラーをダウンロードし、固定ダイジェストと照合し、Windows runner 上で Authenticode 署名が期待される OpenClaw Foundation 署名者を使用していることを検証し、SHA-256 マニフェストを書き込み、インストーラーとマニフェストを canonical OpenClaw GitHub リリースにアップロードした後、昇格済みアセットを再ダウンロードしてマニフェストの包含関係とハッシュを検証します。親は公開前に現在の x64、ARM64、checksum アセット契約を検証します。直接リカバリは、期待される契約アセットを固定されたソースバイトで置き換える前に、予期しない OpenClawCompanion-* アセット名を拒否します。 Windows Node Release を手動でディスパッチするのはリカバリ時のみにし、常に正確なタグを渡し、latest は決して使わず、承認済みソースリリースの明示的な expected_installer_digests JSON マップも渡します。Webサイトのダウンロードリンクは、現在の stable リリースの正確な OpenClaw リリースアセット URL を指すべきです。または、GitHub の latest リダイレクトが同じリリースを指すことを検証した後に限り releases/latest/download/... を使用します。companion repo のリリースページだけにリンクしないでください。
• リリースチェックは現在、別の手動ワークフロー OpenClaw Release Checks で実行されます。これはリリース承認前に、QA Lab mock parity レーンに加えて、高速な live Matrix profile と Telegram QA レーンも実行します。live レーンは qa-live-shared 環境を使用し、Telegram は Convex CI credential lease も使用します。Matrix transport、media、E2EE inventory 全体を並列で確認したい場合は、手動の QA-Lab - All Lanes ワークフローを matrix_profile=all および matrix_shards=true で実行します。
• Cross-OS のインストールおよびアップグレードランタイム検証は、public な OpenClaw Release Checks と Full Release Validation の一部であり、これらは reusable workflow .github/workflows/openclaw-cross-os-release-checks-reusable.yml を直接呼び出します。この分割は意図的です。実際の npm リリースパスは短く、決定的で、アーティファクト中心に保ち、遅い live checks は独自のレーンに置くことで、publish を停止またはブロックしないようにします。
• secret を含むリリースチェックは、ワークフローのロジックと secret が管理された状態を保つよう、Full Release Validation 経由、または main/release workflow ref からディスパッチする必要があります。
• OpenClaw Release Checks は、解決されたコミットが OpenClaw ブランチまたはリリースタグから到達可能である限り、ブランチ、タグ、または完全なコミット SHA を受け入れます。
• OpenClaw NPM Release の validation-only プリフライトは、push 済みタグを要求せずに、現在の完全な 40 文字の workflow-branch commit SHA も受け入れます。この SHA パスは validation-only であり、実際の publish に昇格できません。SHA モードでは、ワークフローは package metadata check のためだけに v<package.json version> を合成します。実際の publish には引き続き実際のリリースタグが必要です。
• どちらのワークフローも、実際の publish と promotion パスは GitHub-hosted runner 上に保ち、変更を伴わない validation パスはより大きな Blacksmith Linux runner を使用できます。
• そのワークフローは、OPENAI_API_KEY と ANTHROPIC_API_KEY の両方の workflow secret を使用して OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache を実行します。
• npm リリースプリフライトは、別個の release checks レーンを待たなくなりました。
• ローカルでリリース候補にタグ付けする前に、RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check を実行します。このヘルパーは、高速なリリースガードレール、Plugin npm/ClawHub リリースチェック、build、UI build、release:openclaw:npm:check を、GitHub publish ワークフローの開始前に一般的な承認ブロック要因を検出できる順序で実行します。
• 承認前に RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts（または対応する prerelease/correction タグ）を実行します。
• npm publish の後、node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH（または対応する beta/correction version）を実行し、新しい temp prefix で公開済み registry install path を検証します。
• beta publish の後、OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live を実行し、共有の leased Telegram credential pool を使用して、公開済み npm package に対する installed-package オンボーディング、Telegram setup、実際の Telegram E2E を検証します。メンテナーのローカル one-off では Convex 変数を省略し、3 つの OPENCLAW_QA_TELEGRAM_* env credentials を直接渡してもかまいません。
• メンテナーのマシンから full post-publish beta smoke を実行するには、pnpm release:beta-smoke -- --beta betaN を使用します。このヘルパーは Parallels npm update/fresh-target validation を実行し、NPM Telegram Beta E2E をディスパッチし、正確な workflow run をポーリングし、アーティファクトをダウンロードし、Telegram report を出力します。
• メンテナーは、手動の NPM Telegram Beta E2E ワークフローを通じて、GitHub Actions から同じ post-publish check を実行できます。これは意図的に manual-only であり、すべての merge で実行されるわけではありません。
• メンテナーのリリース自動化は preflight-then-promote を使用します。
  • 実際の npm publish は、成功した npm preflight_run_id に合格する必要があります。
  • 実際の publish は、成功した preflight run と同じ main または release/YYYY.M.PATCH ブランチからディスパッチする必要があります（alpha prerelease では Tideclaw alpha ブランチが許可されます）。
  • Stable npm releases はデフォルトで beta になります。stable npm publish は workflow input により明示的に latest を対象にできます。
  • token-based npm dist-tag mutation は openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml にあります。これは、source repo が OIDC-only publish を維持する一方で、npm dist-tag add には引き続き NPM_TOKEN が必要なためです。
  • Public な macOS Release は validation-only です。タグが release branch のみに存在するが、ワークフローが main からディスパッチされる場合は、public_release_branch=release/YYYY.M.PATCH を設定します。
  • 実際の macOS publish は、成功した macOS preflight_run_id と validate_run_id に合格する必要があります。
  • 実際の publish paths は、再度 rebuild するのではなく、準備済みアーティファクトを promote します。
• YYYY.M.PATCH-N のような stable correction release では、post-publish verifier は同じ temp-prefix upgrade path で YYYY.M.PATCH から YYYY.M.PATCH-N へのアップグレードもチェックするため、release correction が古い global install を base stable payload のまま静かに残すことはできません。
• npm release preflight は、tarball に dist/control-ui/index.html と空でない dist/control-ui/assets/ payload の両方が含まれていない限り fail closed するため、空の browser dashboard を再び出荷しません。
• Post-publish verification は、公開済み Plugin entrypoint と package metadata が installed registry layout に存在することもチェックします。Plugin runtime payload が欠落したまま出荷されたリリースは postpublish verifier に失敗し、latest に昇格できません。
• pnpm test:install:smoke は candidate update tarball に対する npm pack unpackedSize budget も強制するため、installer e2e は release publish path の前に accidental pack bloat を検出できます。
• リリース作業で CI planning、extension timing manifests、または extension test matrices に触れた場合、承認前に .github/workflows/plugin-prerelease.yml から planner-owned の plugin-prerelease-extension-shard matrix outputs を再生成してレビューし、release notes が古い CI layout を説明しないようにします。
• Stable macOS release readiness には updater surfaces も含まれます。GitHub release には最終的に package 済みの .zip、.dmg、.dSYM.zip が含まれている必要があります。main 上の appcast.xml は publish 後に新しい stable zip を指す必要があります（macOS publish workflow が自動的に commit するか、direct push がブロックされた場合は appcast PR を開きます）。packaged app は non-debug bundle id、空でない Sparkle feed URL、その release version の canonical Sparkle build floor 以上の CFBundleVersion を維持する必要があります。

​

リリーステストボックス

pnpm ci:full-release --sha <full-sha>

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable \
  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N

• minimum: 最速のリリースクリティカルな OpenAI/core live と Docker パス
• stable: minimum に、リリース承認用の stable provider/backend 網羅を追加
• full: stable に、広範な advisory provider/media 網羅を追加

# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f npm_telegram_provider_mode=mock-openai

​

Vitest

• ディスパッチされた CI 実行 URL を示す Full Release Validation サマリー
• 正確な対象 SHA で green になった CI 実行
• リグレッション調査時の CI ジョブからの失敗または遅いシャード名
• 実行にパフォーマンス分析が必要な場合の .artifacts/vitest-shard-timings.json などの Vitest タイミングアーティファクト

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

​

Docker

• 遅い Bun グローバルインストールスモークを有効にした完全なインストールスモーク
• 対象 SHA ごとのルート Dockerfile スモークイメージ準備/再利用。QR、root/gateway、installer/Bun スモークジョブは別々の install-smoke シャードとして実行
• リポジトリ E2E レーン
• リリースパス Docker チャンク: core、package-update-openai、package-update-anthropic、package-update-core、plugins-runtime-plugins、plugins-runtime-services、plugins-runtime-install-a から plugins-runtime-install-h
• 要求された場合の plugins-runtime-services チャンク内の OpenWebUI 網羅
• 分割されたバンドル Plugin インストール/アンインストールレーン bundled-plugin-install-uninstall-0 から bundled-plugin-install-uninstall-23
• リリースチェックに live suites が含まれる場合の live/E2E provider suites と Docker live model 網羅

​

QA Lab

• agentic parity pack を使用し、OpenAI 候補レーンを anthropic/claude-opus-4-8 ベースラインと比較する mock parity レーン
• qa-live-shared 環境を使用する高速 live Matrix QA プロファイル
• Convex CI credential lease を使用する live Telegram QA レーン
• リリース telemetry に明示的なローカル証明が必要な場合の pnpm qa:otel:smoke、pnpm qa:otel:collector-smoke、pnpm qa:prometheus:smoke、または pnpm qa:observability:smoke

​

パッケージ

• source=npm: openclaw@beta、openclaw@latest、または正確な OpenClaw リリースバージョン
• source=ref: 選択した workflow_ref ハーネスで、信頼済みの package_ref ブランチ、タグ、または完全なコミット SHA を pack
• source=url: 必須の package_sha256 を指定して公開 HTTPS .tgz をダウンロード。URL 認証情報、デフォルト以外の HTTPS ポート、private/internal/special-use ホスト名または解決済みアドレス、安全でないリダイレクトは拒否されます
• source=trusted-url: .github/package-trusted-sources.json の名前付きポリシーから、必須の package_sha256 と trusted_source_id を指定して HTTPS .tgz をダウンロード。source=url に入力レベルのプライベートネットワークバイパスを追加する代わりに、maintainer 所有のエンタープライズミラーやプライベートパッケージリポジトリにこれを使用します
• source=artifact: 別の GitHub Actions 実行によってアップロードされた .tgz を再利用

gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f published_upgrade_survivor_baseline=openclaw@2026.4.26

• smoke: 簡易パッケージインストール/チャネル/エージェント、Gateway ネットワーク、設定リロードレーン
• package: インストール/更新/再起動/plugin パッケージ契約に加え、ライブ ClawHub skill インストール証明。これはリリースチェックのデフォルトです
• product: package に加え、MCP チャネル、cron/サブエージェントクリーンアップ、OpenAI web search、OpenWebUI
• full: OpenWebUI を含む Docker リリースパスのチャンク
• custom: 集中的な再実行のための正確な docker_lanes リスト

​

通常のリリース公開自動化

1. リリースタグをチェックアウトし、そのコミット SHA を解決します。
2. タグが main または release/* から到達可能であることを検証します（alpha プレリリースの場合は Tideclaw alpha ブランチでも可）。
3. pnpm plugins:sync:check を実行します。
4. publish_scope=all-publishable と ref=<release-sha> で Plugin NPM Release をディスパッチします。
5. 同じスコープと SHA で Plugin ClawHub Release をディスパッチします。
6. 保存済みの full_release_validation_run_id を検証した後、リリースタグ、npm dist-tag、保存済みの preflight_run_id で OpenClaw NPM Release をディスパッチします。
7. 安定版リリースでは、GitHub release をドラフトとして作成または更新し、明示的な windows_node_tag と候補承認済みの windows_node_installer_digests で Windows Node Release をディスパッチし、正規のインストーラー/チェックサムアセットを検証してからドラフトを公開します。

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f npm_dist_tag=latest

​

NPM ワークフロー入力

• tag: 必須のリリースタグ。例: v2026.4.2、v2026.4.2-1、v2026.4.2-beta.1、v2026.4.2-alpha.1。preflight_only=true の場合、検証専用プリフライト用に、現在の完全な 40 文字のワークフローブランチコミット SHA も使用できます
• preflight_only: 検証/ビルド/パッケージのみなら true、実際の公開パスなら false
• preflight_run_id: 既存の成功したプリフライト実行 ID。実際の公開パスでは必須で、ワークフローが再ビルドではなく準備済み tarball を再利用できるようにします
• full_release_validation_run_id: このタグ/SHA に対する成功した Full Release Validation 実行 ID。実際の公開では必須です。ベータ公開は警告付きでプリフライトのみで進められますが、安定版/latest プロモーションでは引き続き必要です。
• release_publish_run_id: 承認済みの OpenClaw Release Publish 実行 ID。このワークフローがその親からディスパッチされる場合（bot-actor の実公開呼び出し）に必須です
• plugin_npm_run_id: 成功した exact-head Plugin NPM Release 実行 ID。実際の extended-stable コア公開では必須です
• npm_dist_tag: 公開パスの npm ターゲットタグ。alpha、beta、latest、extended-stable を受け付け、デフォルトは beta です。最終パッチ 33 以降は extended-stable を使用する必要があります。デフォルトでは、extended-stable はそれより前のパッチを拒否し、非最終タグは常に拒否します。
• bypass_extended_stable_guard: テスト専用の boolean。デフォルトは false。npm_dist_tag=extended-stable と併用すると、リリース ID、アーティファクト、承認、読み戻しチェックを維持したまま、月次 extended-stable 適格性をバイパスします。

• tag: 必須のリリースタグ。すでに存在している必要があります
• preflight_run_id: 成功した OpenClaw NPM Release プリフライト実行 ID。publish_openclaw_npm=true の場合は必須です
• full_release_validation_run_id: 成功した Full Release Validation 実行 ID。publish_openclaw_npm=true の場合は必須です
• windows_node_tag: 正確な非プレリリースの openclaw/openclaw-windows-node リリースタグ。安定版 OpenClaw 公開では必須です
• windows_node_installer_digests: 現在の Windows インストーラー名から固定された sha256: ダイジェストへの、候補承認済みのコンパクト JSON マップ。安定版 OpenClaw 公開では必須です
• npm_telegram_run_id: 最終リリース証拠に含める任意の成功した NPM Telegram Beta E2E 実行 ID
• npm_dist_tag: OpenClaw パッケージの npm ターゲットタグ。alpha、beta、latest のいずれか
• plugin_publish_scope: デフォルトは all-publishable。selected は、publish_openclaw_npm=false を指定した集中的な plugin のみの修復作業にだけ使用します
• plugins: plugin_publish_scope=selected のときの、カンマ区切りの @openclaw/* パッケージ名
• publish_openclaw_npm: デフォルトは true。ワークフローを plugin のみの修復オーケストレーターとして使用する場合にだけ false を設定します
• release_profile: リリース証拠サマリーに使用されるリリースカバレッジプロファイル。デフォルトは from-validation で、検証マニフェストから読み取ります。beta、stable、full で上書きできます
• wait_for_clawhub: デフォルトは false で、npm の可用性が ClawHub サイドカーによってブロックされないようにします。ワークフロー完了に ClawHub 完了を含める必要がある場合にだけ true を設定します

• ref: 検証するブランチ、タグ、または完全なコミット SHA。シークレットを伴うチェックでは、解決済みコミットが OpenClaw ブランチまたはリリースタグから到達可能である必要があります。
• run_release_soak: ベータリリースチェック向けに、網羅的なライブ/E2E、Docker リリースパス、all-since upgrade-survivor soak を有効にします。release_profile=stable と release_profile=full によって強制的に有効になります。

• パッチ 33 未満の通常の最終版と修正版は、beta または latest のどちらにも公開できます。パッチ 33 以上の最終版は extended-stable に公開する必要があり、その境界での修正サフィックス付きバージョンは拒否されます。
• ベータプレリリースタグは beta のみに公開できます。アルファプレリリースタグは alpha のみに公開できます
• OpenClaw NPM Release では、完全なコミット SHA 入力は preflight_only=true の場合にのみ許可されます
• OpenClaw Release Checks と Full Release Validation は常に検証専用です
• 実際の公開パスでは、プリフライト時に使用したものと同じ npm_dist_tag を使用する必要があります。このワークフローは、公開前にそのメタデータの検証を続行します

​

通常の beta/latest 安定版リリース手順

1. OpenClaw NPM Release を preflight_only=true で実行します。タグが存在する前は、プリフライトワークフローの検証専用ドライランとして、現在の完全なワークフローブランチコミット SHA を使用できます。
2. 通常のベータ先行フローでは npm_dist_tag=beta を選択し、意図的に安定版を直接公開したい場合のみ latest を選択します。
3. 1 つの手動ワークフローから通常の CI に加えてライブプロンプトキャッシュ、Docker、QA Lab、Matrix、Telegram のカバレッジが必要な場合は、リリースブランチ、リリースタグ、または完全なコミット SHA で Full Release Validation を実行します。意図的に決定論的な通常のテストグラフのみが必要な場合は、代わりにリリース ref で手動の CI ワークフローを実行します。
4. 署名済みの x64 および ARM64 インストーラーを出荷する、正確な非プレリリースの openclaw/openclaw-windows-node リリースタグを選択します。それを windows_node_tag として保存し、検証済みのダイジェストマップを windows_node_installer_digests として保存します。リリース候補ヘルパーは両方を記録し、生成する公開コマンドに含めます。
5. 成功した preflight_run_id と full_release_validation_run_id を保存します。
6. 同じ tag、同じ npm_dist_tag、選択した windows_node_tag、保存した windows_node_installer_digests、保存した preflight_run_id、保存した full_release_validation_run_id を指定して OpenClaw Release Publish を実行します。OpenClaw npm パッケージを昇格する前に、外部化された plugins を npm と ClawHub に公開します。
7. リリースが beta に反映された場合は、openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml ワークフローを使用して、その安定版を beta から latest に昇格します。
8. リリースを意図的に直接 latest に公開し、beta も同じ安定版ビルドにすぐ追従させる必要がある場合は、同じリリースワークフローを使用して両方の dist-tags がその安定版を指すようにするか、スケジュールされた自己修復同期によって後で beta が移動するのを待ちます。

​

公開リファレンス

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

​

関連

• リリースチャネル