OpenClaw Parallels Smoke

OpenClaw Parallels Smoke は何をしますか？

このスキルは、Parallels ゲストワークフローおよびスモーク結果の解釈に使用します。通常のリポジトリ作業では読み込まないでください。

グローバルルール

• Parallels はデフォルトで公開後の信頼性検証（postpublish-confidence coverage）であり、限定ベータ公開フェーズの前提条件ではありません。正確に公開された1つのパッケージバージョンに対して実行し、そのパッケージを承認した Validation SHA と Tooling SHA の実行タプルを記録します。Validation SHA は Code SHA または Release SHA にマッピングされます。これは3番目のリリース ID ではありません。
• 公開後の Parallels レーンが失敗しても、ベータ版が遡って公開解除されることはありません。失敗は、製品、ハーネス/ツール/来歴、インフラ/資格情報、ラッパーのいずれかに分類します。製品欠陥と確認された場合のみ、次のベータ版に影響します。
• 独立したゲストファミリーごとに1つのコーディネーターと1つのレーンを使用します。1回失敗したファミリーは診断して1回再試行した後、再評価します。集約マトリックスを自動的に再起動しないでください。
• プロビジョニングする前に、既存の VM とスナップショットを一覧表示します。事前設定された pristine スナップショットが要求されたベースラインと一致する場合、そのスナップショットに切り替え、ユーザー、ツール、ベース設定を再利用します。「新しい」実行のために新しい VM を作成したり、macOS を再インストールしたり、ゲストベースラインを再構築したりしないでください。
• 「新規」とは、最も近い既存の pristine スナップショットを復元することを意味し、新しいスナップショットを作成することではありません。ユーザーが明示的に要求した場合、または適切なベースラインが存在しない場合を除き、アドホックスナップショットを作成しないでください。元のスナップショットを復元し、アドホック実行後はゲストを停止状態にしておきます。
• スナップショットを復元する前に、その状態を検査します。pristine poweron スナップショットには、事前設定されたログインセッションが含まれている場合があります。通常はそのスナップショットに切り替え、Parallels がそのセッションを再開できるようにします。実行が意図的に保存されたセッションを破棄してログインウィンドウから起動する必要がある場合を除き、テストエントリで --skip-resume を渡さないでください。--skip-resume は、復元されたソースゲストを停止状態にしておく必要がある最終クリーンアップにのみ許容されます。
• スモーク実行でのゲートウェイ検証は、チェック対象の安定バージョンがまだサポートしていない場合を除き、openclaw gateway status --deep --require-rpc を使用します。
• 安定版 2026.3.12 のアップグレード前診断では、通常の gateway status --deep フォールバックが必要になる場合があります。
• その安定版のアップグレード前レーンでの precheck=latest-ref-fail は、自動的にリグレッションと見なさず、ベースラインとして扱います。
• 機械可読なサマリーを得るために --json を渡します。
• フェーズごとのログは、デフォルトで .artifacts/parallels/openclaw-parallels-* の下に保存されます。実行で別のアーティファクトボリュームが必要な場合は、OPENCLAW_PARALLELS_ARTIFACT_ROOT でオーバーライドします。
• 同じ fresh ワークスペースまたはセッションでローカルエージェントとゲートウェイエージェントのターンを並列実行しないでください。
• すべてのトップレベル Parallels レーンにホストの timeout --foreground（または利用可能なバイナリが gtimeout --foreground の場合それ）を設定し、インストール、スナップショット切り替え、prlctl exec 転送がスタックして残りのテスト時間を消費しないようにします。デフォルト：
  • macOS: 75m
  • Linux: 75m
  • Windows: 90m
  • 集約 npm-update ラッパー: 150m レーンが制限に達した場合は、そこで停止し、最新の /tmp/openclaw-parallels-* 実行ディレクトリとフェーズログを検査して、影響を受ける最小のレーンを修正または再実行します。制限に達したレーンを待ち続けないでください。
• 実際の OpenClaw npm install/update フェーズは、レーン全体の制限よりも厳格なシグナルです。インストールフェーズは通常7分以内に完了し、アップデートフェーズは通常5分以内に意味のある進捗を示す必要があります。install-main、install-latest、install-baseline、install-baseline-package という名前のフェーズが420秒を超えた場合、または update-dev / 同じゲストの openclaw update という名前のフェーズが300秒を超えて新しいマーカーがない場合は、そのフェーズログとゲストプロセス状態から診断を開始します。現在の Windows アップデートフェーズは、doctor --fix がバンドルされたプラグインランタイム依存関係をインストールする可能性があるため、約10〜15分経過しても成功する場合があります。ログが本当に古くなっていない限り、スクリプトのハードキャップは20分近くに保ちます。
• 完全な OS マトリックスの場合、ホスト容量が許せば、独立したゲストファミリーレーンを並列実行することを推奨します：
  • timeout --foreground 75m pnpm test:parallels:macos -- --json
  • timeout --foreground 90m pnpm test:parallels:windows -- --json
  • timeout --foreground 75m pnpm test:parallels:linux -- --json 各レーンを独自のシェル/セッションで実行し、それぞれの実行ディレクトリを追跡します。マトリックスを開始する前に、必要なホストビルド/パッケージゲートを完了させます。現在の main の tgz パッケージングが必要な場合、スモークスクリプトは pnpm build、inventory/staging、npm pack を通じて共有パッケージロックを保持します。そのロックがないか壊れている場合は、同時 dist 変更を避けるためにマトリックスを直列化します。
• 同じゲストファミリーに対して複数のスモークレーンを同時に実行しないでください。Tahoe レーンはホスト HTTP ポートを共有し、Windows/Linux レーンは2つのジョブが同じ VM に同時にアクセスすると、スナップショットの復元/起動状態で衝突する可能性があります。
• 集約 pnpm test:parallels:npm-update ラッパーを個別の macOS/Windows/Linux スモークレーンと並列実行しないでください。同じゲストファミリーとスナップショットにアクセスします。
• Parallels レーンを開始する際、無関係なホストコマンドが dist を再ビルド、クリーン、または再ステージングする可能性がある間は開始しないでください（pnpm build、pnpm ui:build、pnpm release:check、pnpm test:install:smoke、npm pack/install smoke、またはパッケージ/ビルド準備を実行する Docker レーンなど）。最初に関係のないビルド/パッケージゲートを実行し、それらが終了するのを待ってから、VM マトリックスを開始します。同時 dist 変更により、ホストの npm pack がファイル欠落で失敗し、VM サイクル全体が無駄になる可能性があります。
• マトリックスの実行または最適化中、レーンごとの経過時間と /tmp/openclaw-parallels-* ログからの最も遅いフェーズを記録します。そのタイミングを、スモークの順序、タイムアウト、またはヘルパーの動作を変更する前に使用します。
• ホストビルドが追跡対象の生成ファイルを変更する場合、VM 時間を費やす前に停止します。生成されたアーティファクトを個別にコミットするか、ジェネレーターのドリフトを修正してから、影響を受ける最小のレーンを再実行します。
• main がアクティブなマルチエージェント作業中に動いている場合、長時間の Parallels スイートには1つのコミットに固定されたデタッチドワークツリーを推奨します。スモークスクリプトは現在、ライブの git rev-parse HEAD の代わりにパッケージ化された tgz コミットを検証しますが、ピン留めされたワークツリーは再実行中にノイズの多い再ビルド/バージョンドリフトを依然として回避します。
• openclaw update --channel dev レーンの場合、ゲストはローカルワークツリーではなく GitHub の main をクローンすることに注意してください。ローカル修正が存在するが、再実行がクローンされた dev チェックアウト内でまだ失敗する場合、ブランチがプッシュされるまでその修正の反証として扱わないでください。
• prlctl exec の場合、VM 名を --current-user の前に渡します（prlctl exec "$VM" --current-user ...）。逆の順序では渡さないでください。
• ワークフローがサイトインストーラー/npm リリースの代わりにリポジトリチェックアウトから OpenClaw をインストールする場合、最後に実際のゲスト CLI シムをインストールし、新しいゲストシェルで検証します。リポジトリ内の pnpm openclaw ... は、ハンドオフのパリティには十分ではありません。
• macOS ゲストでは、ユーザーグローバルインストールと安定した PATH 可視シムを推奨します：
  • NPM_CONFIG_PREFIX="$HOME/.npm-global" npm install -g . でインストールします
  • ~/.local/bin/openclaw が存在するか、~/.npm-global/bin が PATH 上にあることを確認します
  • 真新しいゲストシェルで which openclaw と openclaw --version を使用して検証します

npm install then update

• 推奨エントリポイント: pnpm test:parallels:npm-update
• macOS のみの公開リリース更新確認には、以下を使用します：
  • timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@<old-version> --update-target <target-version-or-tag> --json これにより、同じゲストの openclaw update --tag ... カバレッジが維持され、Windows/Linux レーンを開始せずに共有 macOS current-user/sudo フォールバックが使用されます。
• 必要なカバレッジ: すべてのリリース/アップデート回帰実行には、両方のレーンを含める必要があります：
  • fresh スナップショット -> 要求されたパッケージ/ベースラインをインストール -> スモーク
  • 同じゲストベースライン -> ゲストにインストールされた openclaw update ... コマンドを実行 -> 再度スモーク
• アップデートレーンは OpenClaw の内部アップデータを実行する必要があります。直接の npm install -g <tgz-or-spec> またはハーネス側のパッケージ交換をアップデートフローカバレッジとしてカウントしないでください。これらはインストールスモークのみです。
• 公開ターゲットの場合、最初に古いベースラインパッケージをインストールし（例: [email protected]）、次にインストールされたゲスト CLI を意図したチャネル/タグで実行し（例: openclaw update --channel beta --yes --json）、コマンド後に openclaw --version、openclaw update status --json、ゲートウェイ RPC、エージェントターンを検証します。
• 未公開ターゲットの場合、ホスト上で候補をパッケージ化し、.tgz をハーネス HTTP サーバーで提供し、ゲストアップデータをその提供されたパッケージに向けます。openclaw update --tag http://<host-ip>:<port>/openclaw-<version>.tgz --yes --json を推奨します。チャネル永続性も重要な場合は、--channel <stable|beta> を渡し、ゲストアップデート環境で OPENCLAW_UPDATE_PACKAGE_SPEC を同じ提供 URL に設定します。テスト対象のコマンドは依然として openclaw update であり、直接 npm ではありません。
• 未公開のローカル修正検証では、古いベースラインアップデータコードが依然として最初のホップを制御することを忘れないでください。新しいアップデータコードにのみ存在する修正は、その既に実行中の古いプロセスを変更できません。提供された候補は、ベースラインホストと互換性のあるパッケージ/プラグインメタデータを維持するか、ベースライン自体にアップデータ修正を含める必要があります。
• ベータ/安定版検証では、実行の直前にタグを解決します（npm view openclaw@beta version dist.tarball または npm view openclaw@latest ...）。タグは長時間の VM マトリックスが既に実行中に移動する可能性があります。目的のプレリリースが以前のレジストリ 404/タグラグチェック後に表示された場合は、マトリックスを再起動します。
• 設定されたシークレットワークフローを使用して、OpenAI/Anthropic レーンに必要なプロバイダーキーのみを注入します。シークレットや環境ダンプを出力しないでください。プロバイダーシークレットはゲスト exec 環境を介して渡します。
• 同じゲストのアップデート検証では、エージェントターンの前にデフォルトモデルを明示的に openai/gpt-5.4 に設定し、新しい明示的な --session-id を使用して、古いセッションモデル状態がチェックに漏れ込まないようにします。
• 集約 npm-update ラッパーは、fresh レーンとアップデートレーンの両方の前に、parallels-linux-smoke.sh と同じ Ubuntu フォールバックポリシーで Linux VM を解決する必要があります。正確なデフォルト VM がない場合は、メジャーバージョン >= 24 の Ubuntu ゲストを許容可能と見なし、新しい poweroff スナップショットを持つ最新バージョンの Ubuntu ゲストを優先します。ピーターの現在のホストでは、Ubuntu 26.04 を使用します。
• macOS の同じゲストアップデートチェックでは、npm アップグレード後、gateway status / agent の前にゲートウェイを再起動します。そうしないと、launchd が、古いプロセスが終了し、新しいプロセスがまだ RPC 対応になっていないときに、ロードされたサービスを報告する可能性があります。
• npm-update 集約の macOS アップデートレッグは、ゲストアップデートスクリプトを root として書き込み、デスクトップユーザーとして実行します。prlctl exec "$MACOS_VM" --current-user ... が認証できない場合は、通常の root prlctl exec と sudo -u <desktop-user> /usr/bin/env HOME=/Users/<desktop-user> USER=<desktop-user> LOGNAME=<desktop-user> PATH=/opt/homebrew/bin:/opt/homebrew/opt/node/bin:/usr/bin:/bin:/usr/sbin:/sbin ... を介して再試行します。これは Parallels 転送フォールバックです。アップデート後も openclaw --version、ゲートウェイ RPC、エージェントターンを検証します。
• Windows の同じゲストアップデートチェックでは、npm アップグレード後、gateway status / agent の前にゲートウェイを再起動します。そうしないと、インプレースグローバル npm アップデートにより、実行中のサービス内に古いハッシュ化された dist/* モジュールインポートが残る可能性があります。
• これらの Windows 同じゲストアップデートチェックでは、1回の非ゼロの openclaw gateway restart を決定的な失敗として扱わないでください。現在のログイン項目の再起動は、バックグラウンドサービスが再度観測可能になる前に失敗を報告する可能性があります。その後、より長い RPC 対応待機を実行し、準備が戻らない場合にのみ回復ステップとして gateway start を使用します。
• その Windows 再起動後、固定スリープ後の1回の gateway status --deep --require-rpc 呼び出しを信頼しないでください。約30秒間 RPC 準備プローブを再試行し、各試行をログに記録します。現在のゲストは、新しい RPC エンドポイントがまだ起動している間にポート 18789 をバインドしたままにすることができます。
• Windows 同じゲストアップデートチェックでは、1つの長時間稼働する prlctl exec ... powershell -EncodedCommand ... 転送よりも、done-file/log-drain PowerShell ランナーパターンを優先します。ゲストは正常に終了しても、外側の prlctl exec がまだハングすることがあります。
• Windows 同じゲストアップデートヘルパーは、tgz ダウンロードや npm install -g などの長いステップの前にステージマーカーをログに書き込む必要があります。これにより、健全だが静かなインストール中に外側の進捗モニターが waiting for first log line で停止しないようにします。
• Linux 同じゲストアップデート検証では、HOME=/root もエクスポートし、prlctl exec ... /usr/bin/env を介して OPENAI_API_KEY を渡し、openclaw agent --local を使用する必要があります。新しい Linux ベースラインは、永続化されたゲートウェイ資格情報に依存しません。
• npm-update ラッパーは、ネストされたログファイルからレーンごとの進捗を出力するようになりました。レーンがまだスタックしているように見える場合は、外側のラッパーがハングしたと想定する前に、runDir 内のネストされたログ（macos-fresh.log、windows-fresh.log、linux-fresh.log、macos-update.log、windows-update.log、linux-update.log）を調査します。
• 各実行は summary.json と summary.md の両方を書き込みます。まずマークダウンを読んで迅速な人間によるトリアージを行い、次に JSON/タイミングを自動化に使用します。
• タグが公開された後の完全なベータ検証には、1つのコマンドを推奨します：
  • timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json これにより、beta3 が最新の *-beta.3 バージョンに解決され、同じゲストの latest->that-version アップデートカバレッジが実行され、選択された同じ OS マトリックス上でその公開ターゲットの fresh インストールスモークが実行されます。--platform macos|windows|linux を使用して再実行を絞り込みます。
• エージェントターンを含むベータ4 npm 検証の場合、既知の正常な形状は次のとおりです：
  • gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai/gpt-5.4 --json 特定のプレリリース番号を検証する場合は、openclaw@beta よりも明示的な beta4 エイリアスを優先します。npm タグは移動する可能性があります。
• ラッパーがレーンに失敗した場合、最初に自動ダンプされたテールを読み、次に完全なネストされたログファイルを読みます。