OpenClaw QA テスト

OpenClaw QA テスト は何をしますか？

このスキルは qa-lab / qa-channel の作業に使用します。リポジトリローカルの QA のみです。

最初に読むもの

• docs/concepts/qa-e2e-automation.md
• docs/help/testing.md
• docs/channels/qa-channel.md
• qa/README.md
• qa/scenarios/index.yaml
• extensions/qa-lab/src/suite.ts
• extensions/qa-lab/src/character-eval.ts

モデルポリシー

• 通常のライブスイート実行は、QA Lab のソースおよび認証認識デフォルトに依存します。
• デフォルトで --model、--alt-model、--fast を渡さないでください。--fast を省略しても fast が無効になるわけではありません。fast の動作はソースが所有します。
• シナリオ固有の実行の場合、完全な execution.summary が信頼できる情報源であり、他のフラグが必要な場合も含めて、一般的なデフォルトガイダンスよりも優先されます。execution.config.requiredProvider または requiredModel が必要な場合にのみ、明示的なプロバイダー/モデルピンを追加してください。

デフォルトワークフロー

1. シナリオパックと現在のスイート実装を読み込みます。
2. レーンを決定します：
   • mock/dev：mock-openai
   • 本番検証：live-frontier
3. 通常のライブスイートの場合は、次を使用します：

pnpm openclaw qa suite \
  --provider-mode live-frontier \
  --output-dir .artifacts/qa-e2e/run-all-live-frontier-<tag>

4. 出力を監視します：
   • サマリー：.artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-summary.json
   • レポート：.artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-report.md
5. ユーザーがライブ UI を監視したい場合は、現在の openclaw-qa リッスンポートを見つけて http://127.0.0.1:<port> を報告します。
6. シナリオが失敗した場合、製品またはハーネスの根本原因を修正し、その後レーン全体を再実行します。

OTEL スモークテスト

ローカルの QA-lab OpenTelemetry 検証には、次を使用します：

pnpm qa:otel:smoke

これにより、ローカルの OTLP/HTTP トレースレシーバーが起動し、otel-trace-smoke シナリオが qa-channel を通じて実行され、出力された protobuf スパンがデコードされ、エクスポートされたトレース名とプライバシー契約が検証されます。Opik、Langfuse、または外部コレクターの認証情報は必要ありません。

QA 認証情報と 1Password

• このリポジトリでの QA シークレット検索には、tmux 内でのみ op を使用してください。
• tmux 内での簡単な認証確認：

op account list

• 承認された 1Password アイテムとフィールド参照を解決します：
  • OPENCLAW_QA_CONVEX_SITE_URL
  • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER（メンテナー @role 用）
  • OPENCLAW_QA_CONVEX_SECRET_CI（CI ロール用）
• 必要な参照が欠落しているか古い場合は、現在のアイテムとフィールド参照をメンテナー/オペレーターに問い合わせてください。チャットでシークレット値を尋ねたり、ログや証明アーティファクトにコピーしたりしないでください。
• npm Telegram Docker レーンには Convex 認証情報のリースが必要です。リースは、Telegram E2E userbot によって定義された Test Server SUT ボット、QA-user 認可、テストグループメタデータを提供します。ダイレクトな Telegram トークン変数は、必要な Convex 設定を置き換えません。
• 承認されたサイト URL とロール固有のシークレットを、承認されたシークレットソースからコマンドの環境にロードします。Docker 実行の前に、サイト URL と一致するロールシークレットが必要です。
• メンテナー設定がロードされた状態で、次を実行します：

OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex \
OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=maintainer \
OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE=mock-openai \
OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC="openclaw@beta" \
pnpm test:docker:npm-telegram-live

• scripts/e2e/npm-telegram-live-runner.ts は OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE を読み取ります。OPENCLAW_QA_PROVIDER_MODE ではありません。
• 承認されたホスト型証明の場合、既存の手動レーンが有効な Convex CI 設定を持つ qa-live-shared 環境を持っている場合に使用します。ディスパッチは認証情報をプロビジョニングしたり、認証情報拒否を回避したりしません。

ghx workflow run "NPM Telegram Beta E2E" --repo openclaw/openclaw --ref main \
  -f [email protected] \
  -f [email protected] \
  -f provider_mode=mock-openai

• ディスパッチ URL から正確な実行 ID をポーリングします。gh run view --json artifacts はサポートされていません。次のコマンドでアーティファクトを一覧表示します：

gh api repos/openclaw/openclaw/actions/runs/<run-id>/artifacts

WhatsApp ライブ認証情報

Convex kind=whatsapp 認証情報を設定または交換するときに使用します。

• WhatsApp QA 認証情報は、オペレーター所有のライブアカウントとして扱い、生成されたフィクスチャとしては扱いません。
• 専用の WhatsApp 対応テスト番号を 2 つ使用します。1 つはドライバーアカウント、もう 1 つは SUT アカウントです。共有プール内の個人番号や個人の OpenClaw WhatsApp アカウントは使用しないでください。
• 各アカウントを WhatsApp または WhatsApp Business で手動で登録してリンクし、Web 認証のみをリポジトリ外の隔離されたローカル認証ディレクトリに保存します。
• グループカバレッジの場合、両方の QA アカウントを含む専用テストグループを作成し、その JID を groupJid として保存します。それ以外の場合、グループメンションゲーティングシナリオはデフォルトでスキップされ、明示的に要求された場合に失敗する必要があります。
• 2 つの Baileys 認証ディレクトリを base64 .tgz ペイロードフィールドにパッケージ化し、新しいアクティブな Convex 認証情報行を追加します。その場で認証情報を上書きするのではなく、新しい行を追加して古い/壊れた行を無効にすることを推奨します。
• 期待されるペイロードフィールド：driverPhoneE164、sutPhoneE164、driverAuthArchiveBase64、sutAuthArchiveBase64、およびオプションの groupJid。
• 認証情報マテリアルをリポジトリ、ログ、PR、スクリーンショットから遠ざけてください。オペレーターが明示的にローカルデバッグを要求しない限り、電話番号を編集してください。
• 次を使用して検証します：pnpm openclaw qa whatsapp --credential-source convex --credential-role maintainer --provider-mode mock-openai し、アーティファクトパスと編集された合格/不合格サマリーを保存します。
• WhatsApp がリンクされた Web セッションを期限切れまたは無効にした場合は、ローカルで再リンクし、新しい認証アーカイブをパッケージ化し、新しい Convex 行を追加してから、古い行を無効にします。

キャラクター評価

スタイル/ペルソナ/雰囲気チェックのために qa character-eval を複数のライブモデルで使用します。

pnpm openclaw qa character-eval \
  --output-dir .artifacts/qa-e2e/character-eval-<tag>

• ローカルの QA ゲートウェイ子プロセスを実行します。Docker は使用しません。
• パッケージ化された pnpm build は、設計上 QA Lab + qa-channel を省略します（ソースチェックアウトのみ）。ビルド済みディストリビューションから openclaw qa/qa-channel を実行するには、OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build でビルドするか（dist/plugin-sdk/qa-lab.js、qa-runtime.js、dist/extensions/{qa-lab,qa-channel} を出力）、pnpm dev で実行します。
• モデルフラグがない場合、キャラクター評価は現在のソース定義の候補、判定、思考、高速デフォルトを使用します。
• 対応するインベントリを明示的に置き換える場合にのみ、--model provider/model,thinking=<level>[,fast|,no-fast|,fast=<bool>] または --judge-model ... を繰り返します。
• 別の --model-thinking を使用した新しい例を追加しないでください。そのフラグはレガシー互換性のためだけに維持してください。
• レポートには、判定ランキング、実行統計、期間、完全なトランスクリプトが含まれます。生の判定応答は含めないでください。期間はベンチマークのコンテキストであり、評価シグナルではありません。
• 候補と判定の同時実行数はデフォルトで 16 です。ローカルゲートウェイまたはプロバイダーの制限により、より穏やかなレーンが必要な場合は、--concurrency <n> と --judge-concurrency <n> を使用してオーバーライドします。
• シナリオソースは qa/scenarios/ 以下の YAML のみです。index.yaml とシナリオごとの *.yaml ファイルを、トップレベルの title、scenario、オプションの flow とともに使用します。フェンスで囲まれた qa-scenario / qa-flow Markdown ファイルを追加しないでください。
• 独立したキャラクター/ペルソナ評価の場合、シナリオフローでペルソナを SOUL.md に書き込み、IDENTITY.md を空白にします。通常の OpenClaw ID とキャラクターを意図的に組み合わせてテストする場合にのみ SOUL.md + IDENTITY.md を使用します。
• プロンプトは自然でタスク指向に保ちます。候補モデルは SOUL.md を通じてキャラクター設定を受け取り、その後、チャット、ワークスペースヘルプ、小さなファイルタスクなどの通常のユーターンを受け取る必要があります。「どのように反応しますか？」と質問したり、モデルに評価中であることを伝えたりしないでください。
• 小さなワークスペースアーティファクトの作成や編集など、少なくとも 1 つの実際のタスクを推奨します。これにより、トランスクリプトが純粋なロールプレイではなく、通常のツール使用下でのキャラクターをキャプチャします。

Codex CLI モデルレーン

QA がモデルバックエンドとして Codex を実行する必要があるときはいつでも、codex-cli/<codex-model> の形のモデル参照を使用します。

例：

pnpm openclaw qa suite \
  --provider-mode live-frontier \
  --model codex-cli/<codex-model> \
  --alt-model codex-cli/<codex-model> \
  --scenario <scenario-id> \
  --output-dir .artifacts/qa-e2e/codex-<tag>

pnpm openclaw qa manual \
  --model codex-cli/<codex-model> \
  --message "Reply exactly: CODEX_OK"

• 具体的な Codex モデル名はユーザー/設定入力として扱います。ソース、ドキュメント例、シナリオにハードコードしないでください。
• ライブ QA は CODEX_HOME を保持するため、Codex CLI の認証/設定が機能し、HOME と OPENCLAW_HOME はサンドボックス化されたままです。
• モック QA は CODEX_HOME を消去する必要があります。
• Codex が毎ターンにフォールバック/認証テキストを返す場合、シナリオアサーションを変更する前に、まず CODEX_HOME、関連するシークレットバックアップ認証、およびゲートウェイ子ログを確認してください。
• モデル比較の場合、codex-cli/<codex-model> を qa character-eval の別の候補として含めます。レポートはそれを不透明なモデル名としてラベル付けする必要があります。

リポジトリの事実

• シードシナリオは qa/scenarios/index.yaml と qa/scenarios/<theme>/*.yaml にあります。
• メインのライブランナー：extensions/qa-lab/src/suite.ts
• QA ラボサーバー：extensions/qa-lab/src/lab-server.ts
• 子ゲートウェイハーネス：extensions/qa-lab/src/gateway-child.ts
• シンセティックチャネル：extensions/qa-channel/

「完了」の状態

• 要求されたレーンのフルスイートがグリーンであること。
• ユーザーが取得するもの：
  • 該当する場合の監視 URL
  • 合格/不合格の数
  • アーティファクトパス
  • 修正内容に関する簡潔なメモ

一般的な失敗パターン

• ライブタイムアウトが短すぎる：
  • extensions/qa-lab/src/suite.ts でライブ待機時間を広げる
• 検出がリポジトリファイルを見つけられない：
  • シードされたワークスペース内の repo/... にプロンプトを向ける
• サブエージェントの証明がもろすぎる：
  • 一時的な子セッションリストよりも、安定した最終応答証拠を優先する
• ハーネスの「再ビルド」遅延：
  • ダーティツリーは実行前のビルドをトリガーする可能性があります。ポートが表示される前にそれを想定してください

シナリオを追加する場合

• qa/scenarios/ の下にシナリオ YAML を追加または更新します。.md シナリオファイルやフェンスで囲まれた YAML ブロックを追加しないでください。
• qa/scenarios/index.yaml のキックオフ期待値を調整してください。
• extensions/qa-lab/src/suite.ts に実行可能なカバレッジを追加します。
• モックのみのチェックよりもエンドツーエンドのアサーションを優先します。
• 出力を .artifacts/qa-e2e/ の下に保存します。