release-openclaw-plugin-testing

OpenClaw プレリリースプラグインテスト

このスキルは、ユーザーがプラグインリリースの確信度、プラグインライフサイクルスイープ、パッケージアーティファクトのプラグイン証明、または「リリース前に他に何をテストすべきか？」と尋ねたときに使用します。このスキルは openclaw-testing を補完します。最も安価な安全なランナーを選択するときや、失敗したレーンをデバッグするときも、そのスキルを使用してください。

目標

ソーステストとしてだけでなく、製品表面としてプラグインシステムを証明します：

• バンドルプラグインライフサイクル：インストール、検査、有効化、無効化、アンインストール
• クリーンな HOME からのパッケージアーティファクトの動作
• doctor/fix/config の検証と冪等性
• 設定の検出と設定ラウンドトリップ
• status/log の可視性と診断
• プラグインメタデータスナップショットを使用したゲートウェイ起動/ブートストラップ
• 実際の外部プラグインとの公開SDK互換性
• 安全な資格情報が存在する場合のみ、ライブプロバイダ/チャネルプローブ

最初のチェック

OpenClaw リポジトリルートから：

pnpm docs:list
git status --short --branch
pnpm changed:lanes --json

依存関係の所有権とローカルまたはリモートの証明の選択については、openclaw-testing に従ってください。

ランナーの選択

次の順序を優先します：

1. GitHub Package Acceptance：インストール可能なパッケージの製品証明用。
2. 現在の専用Linuxワーカー：必要な依存関係と機能がある場合の、信頼できるソース/パッケージ/Docker 証明用。
3. ci-build-artifacts-testbox.yml Testbox：Docker/パッケージレーンにシードされた dist、dist-runtime、およびパッケージキャッシュが必要な場合。
4. ci-check-testbox.yml Testbox：ソースチェック、ターゲットを絞った Vitest、パッケージ境界チェック、または焦点を絞った Docker レーン用。
5. ワークステーションのターゲットコマンドのみ：小規模なフォーマット/静的/ユニットプローブ用。

古いスパースワークツリーからの長期のパッケージ Docker 実行は避けてください。Testbox の同期が数百のファイル変更を報告したり、パッケージ入力を削除し始めた場合は、停止して現在の main から新しいボックスをウォームアップするか、Package Acceptance に切り替えてください。

既存のベースライン

新しいカバレッジを考案する前に、以下を実行または検証します：

OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm run test:extensions:package-boundary:canary
pnpm run test:extensions:package-boundary:compile
pnpm test:docker:plugins
OPENCLAW_PLUGINS_E2E_CLAWHUB=0 pnpm test:docker:plugins
pnpm test:docker:plugin-update

完全なバンドルインストール/アンインストールの証明のために、パッケージスイープをシャーディングします：

OPENCLAW_BUNDLED_PLUGIN_SWEEP_TOTAL=8 \
OPENCLAW_BUNDLED_PLUGIN_SWEEP_INDEX=<0-7> \
pnpm test:docker:bundled-plugin-install-uninstall

この例では、選択したパッケージのプラグインインベントリをシャード 0-7 に分割します。プライベートQAプラグインは、パッケージに明示的に含まれていない限り、ソースモードのみです。

確信度マトリックス

プレリリース承認にはこのマトリックスを使用します。合格/不合格、実行URL/Testbox ID、パッケージSHA/バージョン、スキップされたライブの理由を記録します。

表面	証明	推奨ランナー
パッケージアーティファクト	Package Acceptance suite_profile=package またはカスタムレーン	GitHub Actions
バンドルライフサイクル	シャーディングされた test:docker:bundled-plugin-install-uninstall	Testbox またはリリース Docker
外部プラグイン	test:docker:plugins および plugins-offline	Testbox/package acceptance
更新no-op	test:docker:plugin-update	Testbox/package acceptance
Doctor/fix	シードされた不良config + doctor --fix --non-interactive	新しい Docker/Testbox ハーネス
設定ラウンドトリップ	config set/get、inspect、doctor、reload、diff hash	新しい Docker/Testbox ハーネス
ゲートウェイブートストラップ	クリーンな HOME、プラグイングループ有効/無効、ステータス JSON	新しい Docker/Testbox ハーネス
SDK互換性	SDKサブパスを使用したディレクトリ、tgz、および file: 外部プラグイン	test:docker:plugins に新しいスモークを追加
ライブ風	存在する環境のみの編集済みプロバイダ/チャネルプローブ	Testbox ライブレーン

パッケージ承認計画

完全リリース検証は、Q=C と正確な公開tarballを使用した最終候補の資格認定を所有します。診断または公開後の確信度にはスタンドアロンの Package Acceptance を使用しますが、候補資格認定の代替としては使用しないでください：

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=<branch-or-sha> \
  -f suite_profile=custom \
  -f docker_lanes='plugins-offline plugin-update doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
  -f telegram_mode=mock-openai

公開されたベータ版の証明には source=npm -f package_spec=openclaw@beta を使用します。これらのスタンドアロンの診断/確信度実行は、信頼できる現在のハーネスコードを使用する場合があります。候補資格認定は、代わりに凍結された候補のハーネスを保持する必要があります。

拡張安定版の共有公開には、Q=C で候補所有の release-ci/* ハーネスからの完全な正確なターゲット完全リリース検証が必要であり、信頼できるP admission と公開ツールは別にする必要があります。直接の canonical-branch または main プロデューサーは保護された発行者を満たしません。Package Acceptance は公開後のセレクタースモークです：

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@extended-stable \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

解決されたバージョンを記録します。それでもタグの all-publishable インベントリ内のすべてのパッケージとセレクターを検証します。1回のスモークはレジストリの読み返しではありません。

プラグイン npm アーティファクト資格認定

公開候補の場合、完全リリース検証がプラグイン npm アーティファクトの資格認定を所有します。ディスパッチ時に公開選択を指定します。すべてのグループの親は、正確なリリースSHAに対してアーティファクトのみのモードで plugin-npm-release.yml を呼び出し、tarballの読み返しが成功することを必要とし、不変の集約記述子を publicationArtifacts.pluginNpm に記録します。リリース準備と公開は、プラグインを再パッケージ化する代わりに、その正確な記述子を採用する必要があります。

定期的な公開候補の外部にある、焦点を絞った診断または選択されたプラグインの修復にのみ、スタンドアロンの信頼できるワークフロープリフライトを使用します：

release_sha="$(git rev-parse origin/release/2026.7.1)"
gh workflow run plugin-npm-release.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f preflight_only=true \
  -f publish_scope=selected \
  -f plugins=@openclaw/meta-provider \
  -f ref="${release_sha}" \
  -f npm_dist_tag=default

release_publish_run_id を渡さないでください。ワークフローが verify_plugin_npm_preflight を正常に完了することを要求します。実行URL、ワークフローSHA、およびソースSHAを記録します。ワークフローは最初に、npm-pack.json、preflight-manifest.json、およびtarballを含むステージング/読み返しアーティファクト plugin-npm-package-source-<source-sha>-<extension-id> を作成します。次に、tarballと plugin-publication-manifest.json を含む最終的なコンシューマーアーティファクト plugin-npm-package-<extension-id>-<version>-<route>-<run-id>-<attempt> をアップロードします。

最終的なアーティファクト名とダイジェストを別々に記録します。マニフェストは openclaw.plugin-publication-artifact/v1 を使用し、ターゲットSHA、パッケージマニフェストハッシュ、公開ルートとポリシー、tarballハッシュとインベントリを記録します。このスタンドアロンの証明は検証のみです。公開を許可またはステージングするものではなく、完全リリース検証のマニフェストにバインドされた記述子を置き換えることはできません。アーティファクトのインベントリは、ソースツリーではなく、セキュリティとパッケージコンテンツの境界です。ソースのみのフィクスチャは無関係です。出荷されたランタイムとスキルアセットの外部にあるパッケージ所有のテストおよびフィクスチャパスは、資格認定に失敗します。出荷されたランタイムはセキュリティスキャンされたままです。バンドルされた node_modules は、プラグインソースポリシーではなく、依存関係の証拠とともに残ります。別の trusted_publisher_preflight=true OIDC チェックには、保護された release-publish/<tooling-sha12>-<epoch> ディスパッチタグが必要であり、npm-publish で実行されます。実際の公開にはそのツーリングタグも必要です。直接の人間によるディスパッチは、公開前に npm-release 承認ジョブを待ちます。既に公開されたバージョンの場合、npm の dist.integrity と dist.shasum が検証されたtarballと一致することを要求します。欠落しているか、証明可能なほど古いdist-tagのみを修復可能として扱います。新しいまたは比較不能なセレクターはブロッカーです。

新しい Testbox ハーネス計画

さらなる確信度が必要な場合は、1つのパッケージtarballとシャーディングされたプラグインリストを使用する plugin-lifecycle-matrix Docker レーンを追加または実行します。プラグインごとに：

1. クリーンな HOME で開始します。
2. plugins list --json をキャプチャします。
3. plugins install <id> を実行します。
4. plugins inspect <id> --json を実行します。
5. plugins disable <id> を実行し、無効化された可視性をアサートします。
6. plugins enable <id> を実行します。ただし、config が必要なプラグインでconfigがない場合は除きます。
7. plugins registry --refresh を実行します。
8. doctor --non-interactive を実行します。
9. plugins uninstall <id> --force を実行します。
10. プラグインの plugins.entries 値が正確に { enabled: false } であること、およびその allow/deny エントリ、インストールレコード、管理ディレクトリ、バンドルされたランタイムロードパスがなくなっていることをアサートします。過去のターゲットには、既存のハーネスのソース修飾されたアンインストール期待値を使用します。
11. 診断に level: "error" が含まれず、出力が秘密のような値を編集していることをアサートします。

memory-lancedb は特別に扱います。config が必要です。最初に、config を埋め込まずにインストールしても有効にならないことをアサートし、次に設定済みのケースを実行します。

Doctor/Fix マトリックス

不良状態をシードし、doctor --fix --non-interactive がそれらを修復することを要求し、その後 doctor を再度実行して冪等性を要求します：

• 古い plugins.allow
• 古い plugins.entries
• 欠落しているチャネルプラグインに対する古いチャネル設定
• 無効な plugins.entries.<id>.config
• plugins.load.paths 内のパッケージ化されたバンドルパス
• レガシー plugins.installs
• ランタイム依存関係をステージングしてはならない無効化されたチャネル/プラグイン設定
• 変更されないままにしておく必要があるルート所有のグローバルパッケージツリー

ゲートウェイブートストラップマトリックス

パッケージ化された OpenClaw を Docker でクリーンな状態で起動します：

• プロバイダプラグイン有効、資格情報なし：警告ありで準備完了、クラッシュなし
• チャネルプラグイン設定無効：ランタイム依存関係がステージングされていない
• 起動アクティベーションプラグイン有効：準備完了、ステータスに反映
• 無効な単一プラグイン設定：不良プラグインはスキップ/隔離され、他のプラグインはそのまま

アサート：

• ゲートウェイが準備完了に達する
• openclaw status --json にプラグイン診断が含まれる
• openclaw plugins inspect --all --json が解析可能である
• パッケージツリーが変更されていない
• ログに生のトークンが含まれていない

設定ラウンドトリップ代表

徹底的な設定ラウンドトリップには、すべてのプラグインではなく、代表的なプラグインファミリを使用します：

• プロバイダ：openai、anthropic、mistral、openrouter
• チャネル：telegram、discord、slack、whatsapp
• メモリ：memory-lancedb
• 機能/ランタイム：browser、acpx、tokenjuice

各代表について：

1. 可能な場合はCLIを介して設定を書き込みます。
2. config get またはJSONを介して読み戻します。
3. plugins inspect を実行します。
4. doctor --non-interactive を実行します。
5. 該当する場合は、ゲートウェイの設定リロードをトリガーします。
6. no-opコマンドの前後で設定ハッシュを比較します。

外部 SDK スモーク

パッケージ Docker レーンで、小さな外部プラグインを作成し、以下からインストールします：

• ローカルディレクトリ
• .tgz
• file: npm スペック

CJS および ESM の形状、さらに焦点を絞った openclaw/plugin-sdk/* サブパスをインポートする少なくとも1つのプラグインをカバーします。plugins inspect がそのツール、ゲートウェイメソッド、CLIコマンド、またはサービスを認識することをアサートします。

ライブ風プローブルール

ライブ風の作業の前に、Testbox で許可された環境変数をソースし、編集された可用性マトリックスを生成します：存在/不在のみ、値は絶対に含めません。

存在する資格情報に対してのみプローブを実行します。ユーザーに見えるメッセージを送信するよりも、認証/カタログ/ステータスプローブを優先します。プローブが外部ユーザー、チャネル、またはワークスペースに接触する可能性がある場合は、停止してユーザーに確認します。

レポート

次の形式でレポートします：

package/ref:
tbx ids / run urls:
matrix:
  bundled lifecycle:
  package acceptance:
  doctor/fix:
  gateway bootstrap:
  config round-trip:
  sdk external:
  live-ish:
failures:
skips:
next highest-value gap:

障害が製品の動作ではなく Testbox の同期/環境の損傷である場合は、そのことを明確に述べ、クリーンな再実行または現在の main との比較で証明します。