openclaw-pre-release-plugin-testing

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

ユーザーから、プラグインリリースの信頼性、プラグインのライフサイクル全体の検証、パッケージ成果物でのプラグインの動作確認、または「リリース前にほかに何をテストすべきですか？」と尋ねられた場合に、このスキルを使用します。openclaw-testing を補完するもので、最も低コストで安全なランナーを選ぶ場合や、失敗したレーンのデバッグには、そちらのスキルも使用してください。

目標

プラグインシステムをソースコードのテストだけでなく、製品の機能として検証します。

• 同梱プラグインのライフサイクル：インストール、確認、有効化、無効化、アンインストール
• クリーンな HOME でのパッケージ成果物の動作
• doctor／fix／設定の検証と冪等性
• 設定の検出と設定のラウンドトリップ
• ステータス／ログの可視性と診断
• プラグインのメタデータスナップショットを伴うゲートウェイの起動／ブートストラップ
• 実際の外部プラグインに対する公開 SDK の互換性
• 安全な認証情報がある場合に限った、ライブに近いプロバイダー／チャネルのプローブ

最初の確認事項

OpenClaw リポジトリのルートで実行します。

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

.codex/worktrees 内の Codex ワークツリーでは、node_modules をメインの OpenClaw チェックアウトへのシンボリックリンクにする必要があります。そこで pnpm install を実行しないでください。広範な検証やパッケージ関連の検証には、Blacksmith Testbox または GitHub Actions を使用してください。

ランナーの選択

次の順で優先してください。

1. インストール可能なパッケージの製品検証には、GitHub Package Acceptance。
2. Docker／パッケージのレーンで dist、dist-runtime、パッケージキャッシュの事前準備が必要な場合は、ci-build-artifacts-testbox.yml Testbox。
3. ソースチェック、対象を絞った Vitest、パッケージ境界チェック、または対象を絞った Docker レーンには、ci-check-testbox.yml Testbox。
4. 小規模なフォーマット／静的解析／ユニットテストのプローブに限り、ローカルで対象を絞ったコマンド。

古い疎なワークツリーから、時間のかかるパッケージ 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
pnpm test:docker:bundled-channel-deps:fast

同梱プラグインのインストール／アンインストールを完全に検証するには、パッケージ化されたテストを複数のシャードに分けて実行します。

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

現在想定されているパッケージ対象範囲：8 個のシャード 0-7 にわたる、公開されている同梱プラグイン 116 個。プライベート QA プラグインは、パッケージに明示的に含まれていない限り、ソースモードのみが対象です。

信頼性マトリックス

リリース前の承認には、このマトリックスを使用してください。合格／不合格、実行 URL／Testbox ID、パッケージの SHA／バージョン、およびライブテストをスキップした理由を記録します。

対象	検証	推奨ランナー
パッケージ成果物	Package Acceptance の suite_profile=package またはカスタムレーン	GitHub Actions
同梱プラグインのライフサイクル	8 シャードの test:docker:bundled-plugin-install-uninstall	Testbox またはリリース用 Docker
外部プラグイン	test:docker:plugins および plugins-offline	Testbox／Package Acceptance
更新のノーオペレーション	test:docker:plugin-update	Testbox／Package Acceptance
チャネルのランタイム依存関係	test:docker:bundled-channel-deps:fast と主要チャネル	Testbox／Package Acceptance
Doctor／fix	不正な設定を事前に用意し、doctor --fix --non-interactive を実行	新しい Docker／Testbox ハーネス
設定のラウンドトリップ	config set/get、確認、doctor、再読み込み、差分ハッシュ	新しい Docker／Testbox ハーネス
ゲートウェイのブートストラップ	クリーンな HOME、有効／無効のプラグイングループ、ステータス JSON	新しい Docker／Testbox ハーネス
SDK 互換性	SDK のサブパスを使用する、ディレクトリ、tgz、file: の外部プラグイン	test:docker:plugins と新しいスモークテスト
ライブに近いテスト	環境変数が設定されている場合に限り、プロバイダー／チャネルのプローブを秘匿化して実行	Testbox のライブレーン

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 bundled-channel-deps-compat 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 を使用してください。リリースプロセスで別途指定されていない限り、workflow_ref は信頼できる現在のハーネスコードのままにしてください。

新しい 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> を実行します。ただし、設定がなく、設定必須のプラグインは除きます。
7. plugins registry --refresh を実行します。
8. doctor --non-interactive を実行します。
9. plugins uninstall <id> --force を実行します。
10. 設定エントリ、allow／deny の残存項目、インストール記録、管理対象ディレクトリ、バンドルされた dist/extensions/... の読み込みパスが残っていないことを確認します。
11. 診断結果に level: "error" が含まれず、出力内のシークレットらしき値がマスキングされていることを確認します。

memory-lancedb は設定必須のため、特別扱いを維持します。まず、埋め込み設定なしではインストールによって有効化されないことを確認し、その後、設定済みのケースを実行します。

Doctor／修正マトリックス

不正な状態を用意し、doctor --fix --non-interactive で修復されることを確認した後、もう一度 doctor を実行して冪等性を確認します。

• 古い plugins.allow
• 古い plugins.entries
• プラグインが見つからないチャンネルの古い設定
• 無効な plugins.entries.<id>.config
• plugins.load.paths にあるパッケージ同梱のバンドルパス
• レガシーな plugins.installs
• ランタイム依存関係をステージングしてはならない、無効化されたチャンネル／プラグインの設定
• 変更されてはならない、root 所有のグローバルパッケージツリー

Gateway ブートストラップマトリックス

クリーンな状態の Docker で、パッケージ版 OpenClaw を起動します。

• プロバイダープラグインが有効で、認証情報がない場合：警告を表示しながら準備完了となり、クラッシュしない
• チャンネルプラグインが設定済みで無効な場合：ランタイム依存関係がステージングされない
• 起動時アクティベーションプラグインが有効な場合：準備完了となり、ステータスに反映される
• 単一のプラグイン設定が無効な場合：そのプラグインはスキップまたは隔離され、ほかのプラグインは維持される

次の点を確認します。

• ゲートウェイが準備完了状態になる
• 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. 何も変更しないコマンドの前後で設定ハッシュを比較します。

外部 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 との比較によって裏付けます。