リリースポリシー

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

• stable: デフォルトでは npm beta に公開され、明示的に要求された場合は npm latest に公開されるタグ付きリリース
• beta: npm beta に公開されるプレリリースタグ
• dev: main の移動し続ける先頭

​

バージョン命名

• 安定版リリースバージョン: YYYY.M.D
  • Git タグ: vYYYY.M.D
• 安定版修正リリースバージョン: YYYY.M.D-N
  • Git タグ: vYYYY.M.D-N
• Beta プレリリースバージョン: YYYY.M.D-beta.N
  • Git タグ: vYYYY.M.D-beta.N
• 月または日をゼロ埋めしない
• latest は現在昇格済みの安定版 npm リリースを意味する
• beta は現在の beta インストール対象を意味する
• 安定版および安定版修正リリースは、デフォルトでは npm beta に公開される。リリース担当者は明示的に latest を対象にすることも、検証済みの beta ビルドを後で昇格することもできる
• すべての安定版 OpenClaw リリースでは、npm パッケージと macOS アプリを一緒に出荷する。 beta リリースでは通常、まず npm/パッケージ経路を検証して公開し、 mac アプリのビルド/署名/公証は明示的に要求されない限り安定版用に予約する

​

リリース周期

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

​

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

1. 現在の main から開始する: 最新を pull し、対象コミットがプッシュ済みであることを確認し、 現在の main CI がブランチ作成に十分な程度に green であることを確認する。
2. 実際のコミット履歴から /changelog で CHANGELOG.md の先頭セクションを書き直し、 エントリをユーザー向けに保ち、コミットしてプッシュし、ブランチ作成前にもう一度 rebase/pull する。
3. src/plugins/compat/registry.ts と src/commands/doctor/shared/deprecation-compat.ts のリリース互換性レコードを確認する。期限切れの 互換性は、アップグレード経路が引き続きカバーされる場合にのみ削除する。そうでない場合は、意図的に 継続する理由を記録する。
4. 現在の main から release/YYYY.M.D を作成する。通常のリリース作業を main で直接行わない。
5. 予定しているタグに必要なすべてのバージョン箇所を bump し、その後 pnpm release:prep を実行する。これは Plugin バージョン、Plugin インベントリ、config schema、バンドル channel config メタデータ、config docs baseline、Plugin SDK exports、Plugin SDK API baseline を正しい順序で更新する。タグ付け前に生成された 差分をコミットする。その後、ローカルの決定的 preflight を実行する: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build, pnpm release:check。
6. preflight_only=true で OpenClaw NPM Release を実行する。タグが存在する前は、 validation-only preflight 用に完全な40文字のリリースブランチ SHA を使用できる。 成功した preflight_run_id を保存する。
7. リリースブランチ、タグ、または完全なコミット SHA に対して Full Release Validation で すべてのプレリリーステストを開始する。これは4つの大きなリリーステストボックスである Vitest、Docker、QA Lab、Package の単一の手動エントリポイントである。
8. 検証に失敗した場合は、リリースブランチ上で修正し、その修正を証明する最小の失敗ファイル、 レーン、workflow job、package profile、provider、または model allowlist を再実行する。 変更された表面によって以前の証拠が古くなる場合にのみ、umbrella 全体を再実行する。
9. beta の場合は vYYYY.M.D-beta.N をタグ付けし、その後一致する release/YYYY.M.D ブランチから OpenClaw Release Publish を実行する。これは pnpm plugins:sync:check を検証し、 公開可能なすべての Plugin パッケージを npm に、同じセットを ClawHub に並列で dispatch し、 Plugin npm publish が成功したらすぐに、準備済みの OpenClaw npm preflight artifact を一致する dist-tag で昇格する。OpenClaw npm publish child が成功した後、 完全に一致する CHANGELOG.md セクションから、対応する GitHub release/prerelease ページを作成または更新する。npm latest に公開された安定版リリースは GitHub latest release になる。 npm beta に維持される安定版メンテナンスリリースは GitHub latest=false で作成される。 OpenClaw npm の公開中も ClawHub 公開はまだ実行中の場合があるが、 release publish workflow は child run ID を即座に出力する。デフォルトでは、 dispatch 後に ClawHub を待たないため、OpenClaw npm の可用性は、より遅い ClawHub 承認や registry 作業によってブロックされない。ClawHub が workflow completion をブロックする必要がある場合は wait_for_clawhub=true を設定する。 ClawHub 経路は一時的な CLI dependency install 失敗を再試行し、1つの preview cell が flaky でも preview に通った Plugin を公開し、最後に期待されるすべての Plugin バージョンの registry 検証を行うため、部分的な公開は可視で再試行可能なままになる。公開後、 pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> を実行し、GitHub prerelease、npm beta dist-tags、npm integrity、 公開済みインストール経路、ClawHub の正確なバージョン、ClawHub artifacts、child workflow conclusions を1つのコマンドで検証する。 ClawHub sidecar が再試行可能な jobs でのみ失敗し、その場で再実行すべき場合は --rerun-failed-clawhub を追加する。 その後、公開された openclaw@YYYY.M.D-beta.N または openclaw@beta パッケージに対して、公開後の package acceptance を実行する。プッシュ済みまたは公開済みのプレリリースに修正が必要な場合は、 次に一致するプレリリース番号を切る。古いプレリリースを削除または書き換えない。
10. 安定版の場合は、検証済みの beta または release candidate に必要な検証証拠がある場合にのみ続行する。 安定版 npm publish も OpenClaw Release Publish を通り、 preflight_run_id 経由で成功した preflight artifact を再利用する。安定版 macOS リリース準備完了には、 package 済みの .zip、.dmg、.dSYM.zip、および main 上の更新済み appcast.xml も必要である。 非公開の macOS publish workflow は、release assets の検証後、署名済み appcast を公開 main に 自動で公開する。branch protection が直接 push をブロックする場合は、 appcast PR を開くか更新する。
11. 公開後、npm post-publish verifier、公開後 channel proof が必要な場合は任意の standalone published-npm Telegram E2E、必要な場合は dist-tag promotion を実行し、 生成された GitHub release ページを検証し、 リリース告知手順を実行する。

​

リリース preflight

• リリース前のプリフライト前に pnpm check:test-types を実行し、テスト TypeScript が高速なローカル pnpm check ゲートの外でもカバーされるようにする
• リリース前のプリフライト前に pnpm check:architecture を実行し、より広範なインポートサイクルとアーキテクチャ境界チェックが高速なローカルゲートの外でもグリーンになるようにする
• pnpm release:check の前に pnpm build && pnpm ui:build を実行し、pack 検証ステップで期待される dist/* リリース成果物と Control UI バンドルが存在するようにする
• ルートのバージョン更新後、タグ付け前に pnpm release:prep を実行する。これは、バージョン/config/API 変更後にずれやすいすべての決定的なリリース生成処理を実行する: plugin バージョン、plugin インベントリ、ベース config スキーマ、同梱 channel config メタデータ、config docs ベースライン、plugin SDK exports、plugin SDK API ベースライン。pnpm release:check はこれらのガードをチェックモードで再実行し、検出したすべての生成物のずれ失敗を 1 回のパスで報告してから、package release checks を実行する。
• リリース承認前に手動の Full Release Validation workflow を実行し、すべてのリリース前 test box を 1 つの入口から開始する。これは branch、tag、または完全な commit SHA を受け取り、手動 CI を dispatch し、install smoke、package acceptance、cross-OS package checks、QA Lab parity、Matrix、Telegram lanes のために OpenClaw Release Checks を dispatch する。stable/default 実行では、網羅的な live/E2E と Docker release-path soak は run_release_soak=true の背後に置かれる。release_profile=full は soak を強制的にオンにする。release_profile=full と rerun_group=all の場合、release checks の release-package-under-test artifact に対して package Telegram E2E も実行する。beta 公開後に release_package_spec を指定すると、release tarball を再ビルドせずに、出荷済み npm package を release checks、Package Acceptance、package Telegram E2E 全体で再利用できる。Telegram がリリース検証の残りとは異なる公開済み package を使う必要がある場合にのみ npm_telegram_package_spec を指定する。Package Acceptance が release package spec とは異なる公開済み package を使う必要がある場合は package_acceptance_package_spec を指定する。private evidence report で、Telegram E2E を強制せずに検証が公開済み npm package と一致することを証明する必要がある場合は evidence_package_spec を指定する。 例: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• リリース作業を継続しながら package candidate のサイドチャネル証拠が必要な場合は、手動の Package Acceptance workflow を実行する。openclaw@beta、openclaw@latest、または正確なリリースバージョンには source=npm を使う。現在の workflow_ref harness で信頼済みの package_ref branch/tag/SHA を pack するには source=ref を使う。必須の SHA-256 を持つ HTTPS tarball には source=url を使う。別の GitHub Actions 実行によってアップロードされた tarball には source=artifact を使う。workflow は candidate を package-under-test に解決し、その tarball に対して Docker E2E release scheduler を再利用し、telegram_mode=mock-openai または telegram_mode=live-frontier で同じ tarball に対する Telegram QA を実行できる。選択された Docker lanes に 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 一般的なプロファイル:
  • smoke: install/channel/agent、gateway network、config reload lanes
  • package: OpenWebUI や live ClawHub を含まない、artifact-native package/update/restart/plugin lanes
  • product: package profile に加えて MCP channels、cron/subagent cleanup、OpenAI web search、OpenWebUI
  • full: OpenWebUI を含む Docker release-path chunks
  • custom: focused rerun のための正確な docker_lanes 選択
• リリース候補に対する通常のフル CI カバレッジだけが必要な場合は、手動の CI workflow を直接実行する。手動 CI dispatch は changed scoping をバイパスし、Linux Node shards、bundled-plugin shards、channel contracts、Node 22 compatibility、check、check-additional、build smoke、docs checks、Python skills、Windows、macOS、Android、Control UI i18n lanes を強制する。 例: gh workflow run ci.yml --ref release/YYYY.M.D
• リリース telemetry を検証する場合は pnpm qa:otel:smoke を実行する。これはローカル OTLP/HTTP receiver を通じて QA-lab を実行し、Opik、Langfuse、またはその他の外部 collector を必要とせずに、エクスポートされた trace span 名、境界付き attributes、content/identifier redaction を検証する。
• すべてのタグ付きリリース前に pnpm release:check を実行する
• tag が存在した後、変更を伴う publish sequence のために OpenClaw Release Publish を実行する。release/YYYY.M.D から dispatch する（main から到達可能な tag を公開する場合は main から）。release tag と成功した OpenClaw npm preflight_run_id を渡し、意図的に focused repair を実行しているのでない限り、default plugin publish scope は all-publishable のままにする。この workflow は plugin npm publish、plugin ClawHub publish、OpenClaw npm publish を順序付け、外部化された plugins より前に core package が公開されないようにする。
• Release checks は別の手動 workflow で実行されるようになった: OpenClaw Release Checks
• OpenClaw Release Checks は、リリース承認前に QA Lab mock parity lane に加えて、高速な live Matrix profile と Telegram QA lane も実行する。live lanes は qa-live-shared environment を使う。Telegram は Convex CI credential leases も使う。Matrix transport、media、E2EE inventory 全体を並列で実行したい場合は、matrix_profile=all と matrix_shards=true で手動の QA-Lab - All Lanes workflow を実行する。
• Cross-OS install and upgrade runtime validation は public OpenClaw Release Checks と Full Release Validation の一部であり、これらは reusable workflow .github/workflows/openclaw-cross-os-release-checks-reusable.yml を直接呼び出す
• この分割は意図的なもの: 実際の npm release path を短く、決定的で、artifact に集中したものに保ち、遅い live checks は独自の lane に置くことで、publish を停滞させたりブロックしたりしないようにする
• secret を含む release checks は Full Release Validation 経由、または main/release workflow ref から dispatch し、workflow logic と secrets が管理された状態を保つべきである
• OpenClaw Release Checks は、解決された commit が OpenClaw branch または release tag から到達可能である限り、branch、tag、または完全な commit SHA を受け付ける
• OpenClaw NPM Release の validation-only preflight も、push 済み tag を要求せずに、現在の完全な 40 文字の workflow-branch commit SHA を受け付ける
• その SHA path は validation-only であり、実際の publish に昇格できない
• SHA mode では、workflow は package metadata check のためだけに v<package.json version> を合成する。実際の publish には引き続き実際の release tag が必要である
• どちらの workflow も実際の publish と promotion path は GitHub-hosted runners 上に保ち、変更を伴わない validation path はより大きな Blacksmith Linux runners を使える
• その workflow は OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache を OPENAI_API_KEY と ANTHROPIC_API_KEY の両方の workflow secrets を使って実行する
• npm release preflight は、別個の release checks lane を待たなくなった
• リリース候補にローカルでタグ付けする前に、RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check を実行する。この helper は、GitHub publish workflow が開始する前に承認をブロックしがちなミスを捕捉する順序で、fast release guardrails、plugin npm/ClawHub release checks、build、UI build、release:openclaw:npm:check を実行する。
• 承認前に RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts（または対応する beta/correction tag）を実行する
• npm publish 後に node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D（または対応する beta/correction version）を実行し、新しい一時 prefix で公開済み registry install path を検証する
• beta publish 後に、共有 leased Telegram credential pool を使って、公開済み npm package に対する installed-package onboarding、Telegram setup、実際の Telegram E2E を検証するため、OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live を実行する。maintainer のローカル単発実行では Convex vars を省略し、3 つの OPENCLAW_QA_TELEGRAM_* env credentials を直接渡してもよい。
• maintainer machine から完全な post-publish beta smoke を実行するには、pnpm release:beta-smoke -- --beta betaN を使う。この helper は Parallels npm update/fresh-target validation を実行し、NPM Telegram Beta E2E を dispatch し、正確な workflow run を poll し、artifact をダウンロードし、Telegram report を出力する。
• Maintainers は GitHub Actions から手動の NPM Telegram Beta E2E workflow を通じて同じ post-publish check を実行できる。これは意図的に manual-only であり、すべての merge で実行されるわけではない。
• Maintainer release automation は preflight-then-promote を使うようになった:
  • 実際の npm publish には、成功した npm preflight_run_id が必要である
  • 実際の npm publish は、成功した preflight run と同じ main または release/YYYY.M.D branch から dispatch する必要がある
  • stable npm releases はデフォルトで beta になる
  • stable npm publish は workflow input によって明示的に latest を target にできる
  • token-based npm dist-tag mutation は現在、security のために openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml にある。npm dist-tag add は引き続き NPM_TOKEN を必要とする一方、public repo は OIDC-only publish を保つためである
  • public macOS Release は validation-only である。tag が release branch 上にのみ存在し、workflow が main から dispatch される場合は、public_release_branch=release/YYYY.M.D を設定する
  • 実際の private mac publish には、成功した private mac preflight_run_id と validate_run_id が必要である
  • 実際の publish paths は、準備済み artifacts を再ビルドするのではなく promote する
• YYYY.M.D-N のような stable correction releases では、post-publish verifier は同じ temp-prefix upgrade path で YYYY.M.D から YYYY.M.D-N へのアップグレードもチェックするため、release corrections が古い global installs を 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 entrypoints と package metadata が installed registry layout に存在することもチェックする。plugin runtime payloads が欠落した release は postpublish verifier に失敗し、latest に昇格できない。
• pnpm test:install:smoke は candidate update tarball に対する npm pack unpackedSize budget も強制するため、installer e2e は release publish path の前に偶発的な 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 には、packaged .zip、.dmg、.dSYM.zip が最終的に含まれている必要がある
  • publish 後、main 上の appcast.xml は新しい stable zip を指している必要がある。private macOS publish workflow はそれを自動的に commit するか、direct push がブロックされている場合は appcast PR を開く
  • packaged app は、その release version に対する canonical Sparkle build floor 以上の non-debug bundle id、空でない Sparkle feed URL、CFBundleVersion を維持する必要がある

​

リリーステストボックス

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

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

• minimum: 最速のリリースクリティカルな OpenAI/core live と Docker パス
• stable: minimum に加えて、リリース承認用の安定プロバイダー/バックエンドカバレッジ
• full: stable に加えて、広範な助言的プロバイダー/メディアカバレッジ

# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -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.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.D-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.D-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.D

​

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-b、plugins-runtime-install-c、plugins-runtime-install-d、plugins-runtime-install-e、plugins-runtime-install-f、plugins-runtime-install-g、plugins-runtime-install-h
• 要求された場合の plugins-runtime-services チャンク内の OpenWebUI カバレッジ
• 分割されたバンドル済み Plugin インストール/アンインストールレーン bundled-plugin-install-uninstall-0 から bundled-plugin-install-uninstall-23
• リリースチェックに live スイートが含まれる場合の live/E2E プロバイダースイートと Docker live モデルカバレッジ

​

QA Lab

• agentic parity pack を使用して OpenAI 候補レーンを Opus 4.6 ベースラインと比較する mock パリティレーン
• qa-live-shared 環境を使用する高速 live Matrix QA プロファイル
• Convex CI 認証情報リースを使用する live Telegram QA レーン
• リリーステレメトリーに明示的なローカル証明が必要な場合の pnpm qa:otel:smoke

​

パッケージ

• source=npm: openclaw@beta、openclaw@latest、または正確な OpenClaw リリースバージョン
• source=ref: 信頼済みの package_ref ブランチ、タグ、または完全なコミット SHA を、選択された workflow_ref ハーネスで pack
• source=url: 必須の package_sha256 を指定して HTTPS .tgz をダウンロード
• 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 ネットワーク、config 再読み込みレーンのクイックチェック
• package: インストール/更新/再起動/Plugin パッケージ契約に加え、ライブ ClawHub skill インストール証明。これはリリースチェックのデフォルト
• product: package に MCP チャンネル、cron/サブエージェントのクリーンアップ、OpenAI web search、OpenWebUI を追加
• full: OpenWebUI を含む Docker リリースパスチャンク
• custom: 集中再実行用の正確な docker_lanes リスト

​

リリース公開自動化

1. リリースタグをチェックアウトし、そのコミット SHA を解決します。
2. タグが main または release/* から到達可能であることを検証します。
3. pnpm plugins:sync:check を実行します。
4. publish_scope=all-publishable と ref=<release-sha> で Plugin NPM Release をディスパッチします。
5. 同じ scope と SHA で Plugin ClawHub Release をディスパッチします。
6. リリースタグ、npm dist-tag、保存済みの preflight_run_id で OpenClaw NPM Release をディスパッチします。

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

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

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=latest

​

NPM ワークフロー入力

• tag: 必須のリリースタグ。例: v2026.4.2、v2026.4.2-1、v2026.4.2-beta.1。preflight_only=true の場合は、検証専用 preflight 用に現在の完全な 40 文字のワークフローブランチコミット SHA も使用できます
• preflight_only: 検証/ビルド/パッケージのみなら true、実際の公開パスなら false
• preflight_run_id: 実際の公開パスで必須。ワークフローが成功した preflight 実行から準備済み tarball を再利用するために使います
• npm_dist_tag: 公開パス用の npm ターゲットタグ。デフォルトは beta

• tag: 必須のリリースタグ。すでに存在している必要があります
• preflight_run_id: 成功した OpenClaw NPM Release preflight 実行 ID。publish_openclaw_npm=true の場合に必須
• npm_dist_tag: OpenClaw パッケージ用の npm ターゲットタグ
• plugin_publish_scope: デフォルトは all-publishable。selected は集中修復作業にのみ使用してください
• plugins: plugin_publish_scope=selected の場合の、カンマ区切りの @openclaw/* パッケージ名
• publish_openclaw_npm: デフォルトは true。ワークフローを Plugin のみの修復オーケストレーターとして使用する場合にのみ false を設定してください
• wait_for_clawhub: デフォルトは false。npm の利用可能性が ClawHub サイドカーによってブロックされないようにします。ワークフロー完了に ClawHub 完了を含める必要がある場合にのみ true を設定してください

• ref: 検証するブランチ、タグ、または完全なコミット SHA。シークレットを伴うチェックでは、解決済みコミットが OpenClaw ブランチまたはリリースタグから到達可能である必要があります。
• run_release_soak: 安定版/デフォルトのリリースチェックで、包括的なライブ/E2E、Docker リリースパス、すべての以降バージョンの upgrade-survivor soak を有効にします。release_profile=full によって強制的に有効になります。

• 安定版タグと修正タグは、beta または latest のいずれにも公開できます
• ベータプレリリースタグは、beta にのみ公開できます
• OpenClaw NPM Release では、完全なコミット SHA 入力は preflight_only=true の場合にのみ許可されます
• OpenClaw Release Checks と Full Release Validation は常に検証専用です
• 実際の公開パスは、preflight 中に使用したものと同じ npm_dist_tag を使用する必要があります。ワークフローは、公開前にそのメタデータが継続していることを検証します

​

安定版 npm リリース手順

1. preflight_only=true で OpenClaw NPM Release を実行します
   • タグが存在する前は、preflight ワークフローの検証専用ドライランに、現在の完全なワークフローブランチコミット SHA を使用できます
2. 通常の beta-first フローでは npm_dist_tag=beta を選択し、意図的に直接安定版公開を行う場合にのみ latest を選択します
3. 1 つの手動ワークフローで通常の CI に加え、ライブプロンプトキャッシュ、Docker、QA Lab、Matrix、Telegram カバレッジが必要な場合は、リリースブランチ、リリースタグ、または完全なコミット SHA で Full Release Validation を実行します
4. 意図的に決定論的な通常のテストグラフのみが必要な場合は、代わりにリリース ref で手動 CI ワークフローを実行します
5. 成功した preflight_run_id を保存します
6. 同じ tag、同じ npm_dist_tag、保存済みの preflight_run_id で OpenClaw Release Publish を実行します。これは、OpenClaw npm パッケージをプロモートする前に、外部化された Plugin を npm と ClawHub に公開します
7. リリースが beta に着地した場合は、非公開の openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml ワークフローを使用して、その安定版を beta から latest にプロモートします
8. リリースを意図的に直接 latest に公開し、beta も同じ安定版ビルドをすぐに追従させる必要がある場合は、同じ非公開ワークフローを使用して両方の dist-tag を安定版に向けるか、そのスケジュール済み自己修復同期が後で 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

​

関連

• リリースチャンネル