mcpField
V
verify-release

verify-release

github.com/openclawテスト・品質393.3k221 回インストール今日更新
リポジトリ

verify-release について

OpenClaw のリリースが公開、昇格され、ライブ検証済みかを確認するスキルです。リリース審査担当者向けに、ローカル状態に頼らずトラック別の最新証拠を調べ、通常のベータ版・安定版と extended-stable の要件を区別します。

主な機能

  1. 01GitHub リリースとタグの証拠を確認
  2. 02npm セレクターとパッケージ読出しを検証
  3. 03プラグイン公開インベントリを照合
  4. 04リリースワークフローと成果物を確認
  5. 05公開済み CLI の安全なスモークテスト

活用シーン

  1. 01ベータ版または安定版の公開確認
  2. 02extended-stable リリースの検証
  3. 03公開や昇格状況の調査
  4. 04リリース証拠と注意点の報告

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openclaw/openclaw --skill verify-release

インストール後、Claude Code で/verify-releaseを入力して読み込まれたか確認します。

詳細

リリースを検証

OpenClaw のリリースが完全にリリース、公開、昇格され、スモークテスト済み、またはライブ環境で検証済みかどうかを尋ねられた場合に使用します。これは検証スキルであり、公開スキルではありません。リリースの状態を変更する前に $release-openclaw-maintainer を使用してください。

ルール

  • .27 のような短いサフィックスは、現在の日付やコンテキストから具体的な CalVer バージョンを特定し、特定したバージョンを伝えてください。
  • まずトラックを特定してください。どちらのトラックでも、共通の GitHub Release エビデンス台帳を使用します。通常の beta/stable ではプラットフォームグラフも使用します。extended-stable では、正規ブランチ、npm セレクター、Gateway サーフェスを使用します。一方のトラック固有の成果物や ClawHub の成果物を、もう一方のトラックに要求しないでください。
  • ライブ状態を検証してください。ローカルのチェックアウト状態、リリースノート、過去の記憶を現在の事実として信頼しないでください。
  • チェックアウトに未コミットの変更がある場合、または分岐している場合は、スクリプトや参照用途にのみ使用してください。バージョンメタデータを確認するには、GitHub のリリース/タグから取得するか、タグの tarball を /tmp に展開してください。
  • シークレットは絶対に出力しないでください。
  • 最終回答は簡潔にまとめてください。yes/no、エビデンスの箇条書き、注意事項、クリーンアップを含めてください。

通常のベータ版/安定版チェック

これらのチェックは、通常のオーケストレーションされたリリーストラックでのみ使用してください。

  1. GitHub リリース:
    • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
    • 安定版リリースがドラフトでもプレリリースでもないことを確認します。
    • 期待される場合、リリース本文に npm、CI、プラグイン npm、ClawHub、mac/appcast の証拠へのリンクがあることを確認します。
    • 安定版 mac リリースで必要なアセットがアップロードされていることを確認します:zip、dmg、dSYM、依存関係の証拠、不変の完全検証マニフェスト、公開後の証拠、安定版メインのクローズアウトマニフェスト。
    • 各不変の証拠アセットとその .sha256 付属ファイルをダウンロードし、リリース記録を信頼する前にチェックサムを検証します。
  2. ルート npm:
    • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
    • 安定版では、latest が <VERSION> と一致している必要があります。
    • tarball、integrity、公開時刻を記録します。
    • リリースの公開後証拠に npmRegistrySignaturesVerified: true および npmProvenanceAttestationMatched: true が記録されていることを確認します。
  3. プラグイン公開セット:
    • ローカルのチェックアウトが汚れている場合は、そこからではなく GitHub から正確なタグのメタデータを取得します: https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> を /tmp/openclaw-v<VERSION>-src にダウンロードします。
    • 記録されたリリース Tooling SHA の正規の公開プランナー/収集ツールを使い、正確なタグのパッケージメタデータに基づいて、そのリリーストラックで期待される npm および ClawHub のパッケージセット全体を導出します。 生の公開フラグは数えないでください:openclaw.build.bundledDist === true は、公開フラグが設定されていても、外部公開を明示的に延期します。 延期されたパッケージ名と理由は別々に記録します。
    • 不変の公開プラン、レジストリからの読み戻し、ワークフロージョブを使い、元の公開、以前に公開されたバージョン、選択された復旧実行の間で、期待されるパッケージの識別情報、バージョン、件数を照合します。選択した復旧サブセットによって、期待されるリリースセット全体を狭めてはいけません: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate。
    • 期待される各 npm プラグインについて、バージョンが <VERSION> であり、dist-tags.latest === <VERSION> である必要があります。
  4. ClawHub:
    • Plugin ClawHub Release ワークフローの結論と公開ジョブ数を確認します。
    • ライブレジストリの証拠には OpenClaw 自体を使用します: openclaw plugins search <known-plugin> --json。
    • 隔離した HOME で、ClawHub から公式プラグインを要求された正確なリリースバージョンでインストールします: openclaw plugins install clawhub:@openclaw/matrix@<VERSION>。 matrix が期待されるセットに含まれていない場合を除き、matrix を優先します。ClawHub のバージョンは spec に記載します。--pin がサポートされるのは npm インストールのみです。
  5. リリースワークフロー:
    • リリースノートの証拠リンクについて、次の結論を確認します:Full Release Validation、OpenClaw Release Checks、OpenClaw NPM Release、Plugin NPM Release、Plugin ClawHub Release、安定版 mac アセットが必要な場合は mac の事前チェック/検証/公開。
    • 安定版では、OpenClaw Stable Main Closeout が成功し、そのマニフェストに一致するリリースタグ、最新のロールバック訓練、安定版の soak、ブロッキング対象のパフォーマンス証拠が記録されていることを確認します。
    • 関連する成功/失敗ジョブのみを要約します。リリース本文で予告されている場合を除き、通常のスキップされた任意レーンは無視します。

拡張安定版のチェック

拡張安定版には、共有リリース証跡を含む GitHub リリースがありますが、ネイティブアーティファクトや ClawHub アーティファクトはありません。ライブタグ、ワークフロー、レジストリ、来歴、イメージの状態と併せて検証してください。

  1. 識別情報: パッチ番号が 33+ の最終版 v<VERSION> で、サフィックスがなく、extended-stable/YYYY.M.33 に含まれていることを必須とします。有効な候補に限り、先端と一致する必要があります。ルートと、公開可能な公式プラグインすべてで <VERSION> が宣言されている必要があります。Git タグと、タグに一致するタイトルおよび正式な本文を持つ、公開済みでプレリリースではない GitHub リリースが必要です。isLatest=false、依存関係の証跡、不変の Full Release Validation マニフェスト、公開後の証跡、およびそれらのチェックサムを必須とします。ネイティブアーティファクトや ClawHub アーティファクトが存在しないことも必須です。
  2. ワークフローの連鎖: 成功した親リリース実行と、そのプリフライト、完全な検証、プラグインの npm、コア公開の各子実行を見つけてください。保護された release-publish/* 親と、ワークフロー SHA の来歴が検証済みの正式な release-ci/* 検証プロデューサーが必要です。検証では rerun_group=all、release_profile=stable、ブロッキング対象の soak/performance、および保存済みの試行を使用する必要があります。コア公開では、3 つすべての実行 ID を参照し、マニフェスト、ワークフロー参照、tarball ダイジェストをリリース SHA に紐付ける必要があります。
  3. レジストリ: ルート、プリフライトの corePackageTarballs の全エントリ、タグから導出された publishToNpm === true の公式プラグインすべてについて、完全一致セレクターと extended-stable セレクターが <VERSION> を返すことを必須とします。プラグインの計画、ジョブ、完全な読み戻しを比較してください。在庫を差分から推測してはなりません。
  4. 来歴: 信頼できる最新のツールを使って、node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION> を実行してください。署名、正式なブランチの来歴、公開/プリフライトのダイジェストがリリース SHA に紐付いていることを必須とします。出力とワークフローの URL を保持してください。
  5. Docker: 両方のレジストリで、デフォルト、slim、browser の各イメージ、およびアーキテクチャ別イメージとアテステーションを検証してください。これらのダイジェストに解決されるのは、extended-stable* の 3 つのエイリアスのみである必要があります。成功した OpenClaw Release Publish 親実行と、完了済みの Docker 検証が必要です。通常の経路では、その後に最終処理を行います。明示的に要求された高速経路では、先に GitHub を有効化してもかまいません。エイリアスの修復には、正確なタグを指定して current-main の Docker Channel Promotion を使い、再ビルドは行わないでください。
  6. 復旧: 再公開してはなりません。ルートセレクターには、openclaw/releases の dist-tag ワークフローで promote_extended_stable を使ってください(サフィックスのない最終パッチが 33+ の場合)。その他には、承認済みの認証情報分離ツールを使い、その後、完全な読み戻しを繰り返してください。ClawHub、ネイティブ/モバイルアプリ、ウェブサイト、プライベート dist-tag、通常の latest は必須ではありません。共有リリース証跡は必須ですが、通常版のネイティブアーティファクトや ClawHub アーティファクトは必須ではありません。

公開パッケージのスモークテスト

トラック固有の公開チェックに合格した後、OpenClaw の状態を分離した使い捨てのインストール環境/キャッシュを使用してください。

  • npm exec --yes --package openclaw@<VERSION> -- openclaw --version。
  • 公開された CLI の機能に触れる、少なくとも 1 つの無害なコマンドを実行してください。例:plugins --help または gateway --help。

予備的なリリースチェックとして、余分なローカル Gateway を起動したり、場当たり的にライブモデルのターンを実行したりしないでください。正式なリリース検証ワークフローと、上記の公開証跡を使用してください。これによって必須レーンが免除されることはありません。追加の手動ライブチェックは、明示的に要求された場合に限って実行してください。

報告すべき注意事項

  • Dist-tag に関する注意事項:安定版の latest がリリースの正式な状態です。オプションの beta がまだベータ版を指している場合は、ユーザーからベータ版の昇格検証を依頼されていない限り、安定版リリースのブロッカーではなく注意事項として報告してください。
  • トラックに関する注意事項:トラック名と、意図的に存在しないサーフェスを明記してください。通常版リリース用アーティファクトの欠落を、拡張安定版の失敗と呼んではなりません。
  • チェックアウトの相違に関する注意事項:ローカルのソース SHA がリリースタグまたは origin と異なる場合はその旨を述べ、代わりにどのライブソースを使用したかを明記してください。

コメント