openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
c7aca71a8a
docs/docs/de/help/testing.md
openclaw-docs-i18n[bot] c7aca71a8a chore(i18n): refresh de translations
2026-05-05 01:52:08 +00:00

68 KiB
Raw Blame History

read_when summary title x-i18n
Tests lokal oder in CI ausführen
Regressionstests für Modell-/Provider-Fehler hinzufügen
Debugging von Gateway- und Agentenverhalten
Test-Kit: Unit-/E2E-/Live-Test-Suites, Docker-Runner und was jeder Test abdeckt Testen
generated_at model provider source_hash source_path workflow
2026-05-05T01:47:32Z gpt-5.5 openai 8d051bf6a01f6caf7755ad1d7107f21ae2d440b55a65bb7f18ee4a81f5f0e3b2 help/testing.md 16

OpenClaw hat drei Vitest-Suites (Unit/Integration, e2e, Live) und eine kleine Gruppe von Docker-Runnern. Dieses Dokument ist ein Leitfaden dazu, wie wir testen:

  • Was jede Suite abdeckt (und was sie bewusst nicht abdeckt).
  • Welche Befehle Sie für gängige Workflows ausführen (lokal, vor dem Push, Debugging).
  • Wie Live-Tests Anmeldedaten erkennen und Modelle/Provider auswählen.
  • Wie Sie Regressionen für reale Modell-/Provider-Probleme hinzufügen.
**Der QA-Stack (qa-lab, qa-channel, Live-Transport-Lanes)** ist separat dokumentiert:
  • QA-Überblick — Architektur, Befehlsoberfläche, Szenarioerstellung.
  • Matrix-QA — Referenz für pnpm openclaw qa matrix.
  • QA-Kanal — das synthetische Transport-Plugin, das von repo-gestützten Szenarien verwendet wird.

Diese Seite behandelt das Ausführen der regulären Test-Suites und Docker-/Parallels-Runner. Der folgende Abschnitt zu QA-spezifischen Runnern (QA-spezifische Runner) listet die konkreten qa-Aufrufe auf und verweist zurück auf die obigen Referenzen.

Schnellstart

An den meisten Tagen:

  • Vollständiges Gate (vor dem Push erwartet): pnpm build && pnpm check && pnpm check:test-types && pnpm test
  • Schnellerer lokaler Lauf der vollständigen Suite auf einem leistungsstarken Rechner: pnpm test:max
  • Direkter Vitest-Watch-Loop: pnpm test:watch
  • Direktes Datei-Targeting routet jetzt auch Plugin-/Channel-Pfade: pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts
  • Bevorzugen Sie zuerst gezielte Läufe, wenn Sie an einem einzelnen Fehler iterieren.
  • Docker-gestützte QA-Site: pnpm qa:lab:up
  • Linux-VM-gestützte QA-Lane: pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

Wenn Sie Tests ändern oder zusätzliche Sicherheit möchten:

  • Coverage-Gate: pnpm test:coverage
  • E2E-Suite: pnpm test:e2e

Beim Debuggen realer Provider/Modelle (erfordert echte Anmeldedaten):

  • Live-Suite (Modelle + Gateway-Tool-/Bildprüfungen): pnpm test:live
  • Eine Live-Datei unauffällig gezielt ausführen: pnpm test:live -- src/agents/models.profiles.live.test.ts
  • Laufzeit-Performance-Berichte: dispatchen Sie OpenClaw Performance mit live_gpt54=true für einen echten openai/gpt-5.4-Agent-Turn oder deep_profile=true für Kova-CPU-/Heap-/Trace-Artefakte. Tägliche geplante Läufe veröffentlichen Artefakte für Mock-Provider-, Deep-Profile- und GPT-5.4-Lanes in openclaw/clawgrit-reports, wenn CLAWGRIT_REPORTS_TOKEN konfiguriert ist. Der Mock-Provider-Bericht enthält außerdem Zahlen zu Gateway-Boot auf Source-Ebene, Speicher, Plugin-Druck, wiederholtem Fake-Model-Hello-Loop und CLI-Start.
  • Docker-Live-Modell-Sweep: pnpm test:docker:live-models
    • Jedes ausgewählte Modell führt jetzt einen Text-Turn plus eine kleine dateileseartige Prüfung aus. Modelle, deren Metadaten image-Eingaben ausweisen, führen außerdem einen kleinen Bild-Turn aus. Deaktivieren Sie die zusätzlichen Prüfungen mit OPENCLAW_LIVE_MODEL_FILE_PROBE=0 oder OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0, wenn Sie Provider-Fehler isolieren.
    • CI-Abdeckung: Tägliche OpenClaw Scheduled Live And E2E Checks und manuelle OpenClaw Release Checks rufen beide den wiederverwendbaren Live-/E2E-Workflow mit include_live_suites: true auf; dieser enthält separate Docker-Live-Modell- Matrix-Jobs, nach Provider geshardet.
    • Für fokussierte CI-Wiederholungen dispatchen Sie OpenClaw Live And E2E Checks (Reusable) mit include_live_suites: true und live_models_only: true.
    • Fügen Sie neue besonders aussagekräftige Provider-Secrets zu scripts/ci-hydrate-live-auth.sh sowie zu .github/workflows/openclaw-live-and-e2e-checks-reusable.yml und seinen geplanten/Release-Aufrufern hinzu.
  • Native Codex-Bound-Chat-Smoke: pnpm test:docker:live-codex-bind
    • Führt eine Docker-Live-Lane gegen den Codex-App-Server-Pfad aus, bindet eine synthetische Slack-DM mit /codex bind, übt /codex fast und /codex permissions aus und verifiziert dann, dass eine einfache Antwort und ein Bildanhang über die native Plugin-Bindung statt über ACP geroutet werden.
  • Codex-App-Server-Harness-Smoke: pnpm test:docker:live-codex-harness
    • Führt Gateway-Agent-Turns durch das Plugin-eigene Codex-App-Server-Harness aus, verifiziert /codex status und /codex models und übt standardmäßig Bild-, Cron-MCP-, Sub-Agent- und Guardian-Prüfungen aus. Deaktivieren Sie die Sub-Agent-Prüfung mit OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0, wenn Sie andere Codex- App-Server-Fehler isolieren. Für eine fokussierte Sub-Agent-Prüfung deaktivieren Sie die anderen Prüfungen: OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness. Dies beendet den Lauf nach der Sub-Agent-Prüfung, sofern OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0 nicht gesetzt ist.
  • Crestodian-Rettungsbefehl-Smoke: pnpm test:live:crestodian-rescue-channel
    • Optionale zusätzliche Sicherheitsprüfung für die Message-Channel-Oberfläche des Rettungsbefehls. Sie übt /crestodian status aus, reiht eine persistente Modelländerung ein, antwortet mit /crestodian yes und verifiziert den Audit-/Config-Schreibpfad.
  • Crestodian-Planner-Docker-Smoke: pnpm test:docker:crestodian-planner
    • Führt Crestodian in einem configlosen Container mit einer Fake-Claude-CLI auf PATH aus und verifiziert, dass der Fuzzy-Planner-Fallback in einen auditierten typisierten Config-Schreibvorgang übersetzt wird.
  • Crestodian-Erstlauf-Docker-Smoke: pnpm test:docker:crestodian-first-run
    • Startet aus einem leeren OpenClaw-State-Verzeichnis, routet bloßes openclaw an Crestodian, wendet Setup-/Modell-/Agent-/Discord-Plugin- und SecretRef-Schreibvorgänge an, validiert die Config und verifiziert Audit-Einträge. Derselbe Ring-0-Setup-Pfad wird auch in QA Lab durch pnpm openclaw qa suite --scenario crestodian-ring-zero-setup abgedeckt.
  • Moonshot-/Kimi-Kosten-Smoke: Wenn MOONSHOT_API_KEY gesetzt ist, führen Sie openclaw models list --provider moonshot --json aus, und führen Sie dann einen isolierten openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json gegen moonshot/kimi-k2.6 aus. Verifizieren Sie, dass das JSON Moonshot/K2.6 meldet und das Assistententranskript normalisierte usage.cost speichert.
Wenn Sie nur einen fehlschlagenden Fall benötigen, bevorzugen Sie das Eingrenzen von Live-Tests über die unten beschriebenen Allowlist-Umgebungsvariablen.

QA-spezifische Runner

Diese Befehle stehen neben den Haupt-Test-Suites, wenn Sie QA-Lab-Realismus benötigen:

CI führt QA Lab in dedizierten Workflows aus. Agentic-Parität ist unter QA-Lab - All Lanes und Release-Validierung verschachtelt, nicht in einem eigenständigen PR-Workflow. Breite Validierung sollte Full Release Validation mit rerun_group=qa-parity oder die QA-Gruppe der Release-Checks verwenden. Stabile/standardmäßige Release- Checks halten erschöpfenden Live-/Docker-Soak hinter run_release_soak=true; das full-Profil erzwingt Soak. QA-Lab - All Lanes läuft nächtlich auf main und per manuellem Dispatch mit der Mock-Parity-Lane, der Live- Matrix-Lane, der Convex-verwalteten Live-Telegram-Lane und der Convex-verwalteten Live-Discord- Lane als parallele Jobs. Geplante QA- und Release-Checks übergeben Matrix explizit --profile fast, während der Standardwert der Matrix-CLI und der manuellen Workflow-Eingabe all bleibt; manueller Dispatch kann all in transport, media, e2ee-smoke, e2ee-deep und e2ee-cli-Jobs sharden. OpenClaw Release Checks führt vor der Release-Freigabe Parität plus die schnellen Matrix- und Telegram-Lanes aus und verwendet mock-openai/gpt-5.5 für Release-Transport-Checks, damit sie deterministisch bleiben und den normalen Provider-Plugin-Start vermeiden. Diese Live-Transport- Gateways deaktivieren die Speichersuche; Speicherverhalten bleibt durch die QA-Parity- Suites abgedeckt.

Full-Release-Live-Media-Shards verwenden ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04, das bereits ffmpeg und ffprobe enthält. Docker-Live-Modell-/Backend-Shards verwenden das gemeinsam genutzte ghcr.io/openclaw/openclaw-live-test:<sha>-Image, das einmal pro ausgewähltem Commit gebaut wird, und ziehen es dann mit OPENCLAW_SKIP_DOCKER_BUILD=1, statt es in jedem Shard neu zu bauen.

  • pnpm openclaw qa suite
    • Führt repo-gestützte QA-Szenarien direkt auf dem Host aus.
    • Führt mehrere ausgewählte Szenarien standardmäßig parallel mit isolierten Gateway-Workern aus. qa-channel verwendet standardmäßig Parallelität 4 (begrenzt durch die Anzahl der ausgewählten Szenarien). Verwenden Sie --concurrency <count>, um die Worker-Anzahl anzupassen, oder --concurrency 1 für die ältere serielle Lane.
    • Beendet sich mit einem Exit-Code ungleich null, wenn ein Szenario fehlschlägt. Verwenden Sie --allow-failures, wenn Sie Artefakte ohne fehlschlagenden Exit-Code wünschen.
    • Unterstützt die Provider-Modi live-frontier, mock-openai und aimock. aimock startet einen lokalen AIMock-gestützten Provider-Server für experimentelle Fixture- und Protocol-Mock-Abdeckung, ohne die szenariobewusste mock-openai-Lane zu ersetzen.
  • pnpm test:plugins:kitchen-sink-live
    • Führt den Live-OpenAI-Kitchen-Sink-Plugin-Prüflauf über QA Lab aus. Er installiert das externe Kitchen-Sink-Paket, verifiziert das Inventar der Plugin-SDK-Oberfläche, prüft /healthz und /readyz, zeichnet Gateway-CPU/RSS- Nachweise auf, führt einen Live-OpenAI-Turn aus und prüft adversariale Diagnosen. Erfordert Live-OpenAI-Authentifizierung wie OPENAI_API_KEY. In hydrierten Testbox- Sitzungen lädt er automatisch das Testbox-Live-Auth-Profil, wenn der openclaw-testbox-env-Helper vorhanden ist.
  • pnpm test:gateway:cpu-scenarios
    • Führt den Gateway-Startup-Benchmark plus ein kleines Mock-QA-Lab-Szenariopaket aus (channel-chat-baseline, memory-failure-fallback, gateway-restart-inflight-run) und schreibt eine kombinierte CPU-Beobachtungs- Zusammenfassung unter .artifacts/gateway-cpu-scenarios/.
    • Markiert standardmäßig nur anhaltend heiße CPU-Beobachtungen (--cpu-core-warn plus --hot-wall-warn-ms), sodass kurze Startup-Spitzen als Metriken aufgezeichnet werden, ohne wie die minutenlange Gateway-Peg-Regression zu wirken.
    • Verwendet gebaute dist-Artefakte; führen Sie zuerst einen Build aus, wenn der Checkout noch keine frische Runtime-Ausgabe hat.
  • pnpm openclaw qa suite --runner multipass
    • Führt dieselbe QA-Suite in einer wegwerfbaren Multipass-Linux-VM aus.
    • Behält dasselbe Verhalten zur Szenarioauswahl wie qa suite auf dem Host bei.
    • Verwendet dieselben Flags für Provider-/Modellauswahl wie qa suite.
    • Live-Durchläufe leiten die unterstützten QA-Auth-Eingaben weiter, die für den Gast praktikabel sind: env-basierte Provider-Schlüssel, den Pfad zur QA-Live-Provider-Konfiguration und CODEX_HOME, wenn vorhanden.
    • Ausgabeverzeichnisse müssen unter dem Repo-Root bleiben, damit der Gast über den gemounteten Workspace zurückschreiben kann.
    • Schreibt den normalen QA-Bericht und die Zusammenfassung plus Multipass-Logs unter .artifacts/qa-e2e/....
  • pnpm qa:lab:up
    • Startet die Docker-gestützte QA-Website für operatorartige QA-Arbeit.
  • pnpm test:docker:npm-onboard-channel-agent
    • Baut aus dem aktuellen Checkout einen npm-Tarball, installiert ihn global in Docker, führt nicht interaktives Onboarding mit OpenAI-API-Schlüssel aus, konfiguriert standardmäßig Telegram, verifiziert, dass die paketierte Plugin-Runtime ohne Startup- Dependency-Reparatur lädt, führt Doctor aus und führt einen lokalen Agent-Turn gegen einen gemockten OpenAI-Endpunkt aus.
    • Verwenden Sie OPENCLAW_NPM_ONBOARD_CHANNEL=discord, um dieselbe Packaged-Install- Lane mit Discord auszuführen.
  • pnpm test:docker:session-runtime-context
    • Führt einen deterministischen Built-App-Docker-Smoke für eingebettete Runtime-Kontext- Transkripte aus. Er verifiziert, dass versteckter OpenClaw-Runtime-Kontext als nicht angezeigte benutzerdefinierte Nachricht persistiert wird, statt in den sichtbaren User-Turn zu lecken, seedet dann eine betroffene defekte Session-JSONL und verifiziert, dass openclaw doctor --fix sie mit einem Backup auf den aktiven Branch umschreibt.
  • pnpm test:docker:npm-telegram-live
    • Installiert einen OpenClaw-Paketkandidaten in Docker, führt Onboarding für installierte Pakete aus, konfiguriert Telegram über die installierte CLI und verwendet dann die Live-Telegram-QA-Lane mit diesem installierten Paket als SUT-Gateway erneut.
    • Standardwert ist OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta; setzen Sie OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz oder OPENCLAW_CURRENT_PACKAGE_TGZ, um stattdessen einen aufgelösten lokalen Tarball zu testen, anstatt aus der Registry zu installieren.
    • Verwendet dieselben Telegram-env-Anmeldedaten oder dieselbe Convex-Anmeldedatenquelle wie pnpm openclaw qa telegram. Für CI-/Release-Automatisierung setzen Sie OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex plus OPENCLAW_QA_CONVEX_SITE_URL und das Rollen-Secret. Wenn OPENCLAW_QA_CONVEX_SITE_URL und ein Convex-Rollen-Secret in CI vorhanden sind, wählt der Docker-Wrapper Convex automatisch aus.
    • Der Wrapper validiert die Env für Telegram- oder Convex-Anmeldedaten auf dem Host, bevor Docker-Build-/Installationsarbeit beginnt. Setzen Sie OPENCLAW_NPM_TELEGRAM_SKIP_CREDENTIAL_PREFLIGHT=1 nur, wenn Sie die Einrichtung vor den Anmeldedaten bewusst debuggen.
    • OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer überschreibt die gemeinsame OPENCLAW_QA_CREDENTIAL_ROLE nur für diese Lane.
    • GitHub Actions stellt diese Lane als manuellen Maintainer-Workflow NPM Telegram Beta E2E bereit. Sie läuft nicht bei einem Merge. Der Workflow verwendet die qa-live-shared-Umgebung und Convex-CI-Anmeldedaten-Leases.
  • GitHub Actions stellt außerdem Package Acceptance für produktbezogene Side-Run-Nachweise gegen ein Kandidatenpaket bereit. Es akzeptiert einen vertrauenswürdigen Ref, eine veröffentlichte npm-Spezifikation, eine HTTPS-Tarball-URL plus SHA-256 oder ein Tarball-Artefakt aus einem anderen Lauf, lädt das normalisierte openclaw-current.tgz als package-under-test hoch und führt dann den vorhandenen Docker-E2E-Scheduler mit Smoke-, Paket-, Produkt-, Full- oder benutzerdefinierten Lane-Profilen aus. Setzen Sie telegram_mode=mock-openai oder live-frontier, um den Telegram-QA-Workflow gegen dasselbe package-under-test-Artefakt auszuführen.
    • Aktueller Beta-Produktnachweis:
gh workflow run package-acceptance.yml --ref main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f telegram_mode=mock-openai
  • Exakter Tarball-URL-Nachweis erfordert einen Digest:
gh workflow run package-acceptance.yml --ref main \
  -f source=url \
  -f package_url=https://registry.npmjs.org/openclaw/-/openclaw-VERSION.tgz \
  -f package_sha256=<sha256> \
  -f suite_profile=package
  • Artefaktnachweis lädt ein Tarball-Artefakt aus einem anderen Actions-Lauf herunter:
gh workflow run package-acceptance.yml --ref main \
  -f source=artifact \
  -f artifact_run_id=<run-id> \
  -f artifact_name=<artifact-name> \
  -f suite_profile=smoke

  • pnpm test:docker:plugins

    • Packt und installiert den aktuellen OpenClaw-Build in Docker, startet den Gateway mit konfiguriertem OpenAI und aktiviert dann gebündelte Kanäle/Plugins über Konfigurationsänderungen.
    • Verifiziert, dass Setup-Discovery unkonfigurierte herunterladbare Plugins auslässt, die erste konfigurierte Doctor-Reparatur jedes fehlende herunterladbare Plugin explizit installiert und ein zweiter Neustart keine versteckte Dependency- Reparatur ausführt.
    • Installiert außerdem eine bekannte ältere npm-Baseline, aktiviert Telegram vor dem Ausführen von openclaw update --tag <candidate> und verifiziert, dass der Post-Update-Doctor des Kandidaten Altlasten von Plugin-Dependencies ohne harnessseitige Postinstall-Reparatur bereinigt.

  • pnpm test:parallels:npm-update

    • Führt den nativen Packaged-Install-Update-Smoke über Parallels-Gäste hinweg aus. Jede ausgewählte Plattform installiert zuerst das angeforderte Baseline-Paket und führt dann den installierten Befehl openclaw update im selben Gast aus und verifiziert die installierte Version, den Update-Status, die Gateway-Bereitschaft und einen lokalen Agent- Turn.

    • Verwenden Sie --platform macos, --platform windows oder --platform linux, während Sie an einem Gast iterieren. Verwenden Sie --json für den Pfad des Zusammenfassungsartefakts und den Status pro Lane.

    • Die OpenAI-Lane verwendet standardmäßig openai/gpt-5.5 für den Live-Agent-Turn- Nachweis. Übergeben Sie --model <provider/model> oder setzen Sie OPENCLAW_PARALLELS_OPENAI_MODEL, wenn Sie bewusst ein anderes OpenAI-Modell validieren.

    • Umgeben Sie lange lokale Läufe mit einem Host-Timeout, damit Parallels-Transport-Hänger nicht den Rest des Testfensters verbrauchen können:

      timeout --foreground 150m pnpm test:parallels:npm-update -- --json
timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json

    • Das Skript schreibt verschachtelte Lane-Logs unter /tmp/openclaw-parallels-npm-update.*. Prüfen Sie windows-update.log, macos-update.log oder linux-update.log, bevor Sie annehmen, dass der äußere Wrapper hängt.

    • Windows-Updates können auf einem kalten Gast 10 bis 15 Minuten in Post-Update-Doctor- und Paket- Update-Arbeit verbringen; das ist weiterhin gesund, wenn das verschachtelte npm- Debug-Log voranschreitet.

    • Führen Sie diesen aggregierten Wrapper nicht parallel zu einzelnen Parallels- macOS-, Windows- oder Linux-Smoke-Lanes aus. Sie teilen VM-Zustand und können bei Snapshot-Wiederherstellung, Paketbereitstellung oder Gast-Gateway-Zustand kollidieren.

    • Der Post-Update-Nachweis führt die normale gebündelte Plugin-Oberfläche aus, weil Capability-Fassaden wie Sprache, Bilderzeugung und Medien- Verständnis über gebündelte Runtime-APIs geladen werden, selbst wenn der Agent- Turn selbst nur eine einfache Textantwort prüft.

  • pnpm openclaw qa aimock

    • Startet nur den lokalen AIMock-Provider-Server für direkte Protocol-Smoke- Tests.

  • pnpm openclaw qa matrix

    • Führt die Matrix-Live-QA-Lane gegen einen wegwerfbaren Docker-gestützten Tuwunel-Homeserver aus. Nur Source-Checkout — paketierte Installationen liefern qa-lab nicht mit.
    • Vollständige CLI, Profil-/Szenariokatalog, Env-Vars und Artefaktlayout: Matrix-QA.

  • pnpm openclaw qa telegram

    • Führt die Telegram-Live-QA-Lane gegen eine echte private Gruppe aus, wobei Driver- und SUT-Bot-Token aus env verwendet werden.
    • Erfordert OPENCLAW_QA_TELEGRAM_GROUP_ID, OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN und OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN. Die Gruppen-ID muss die numerische Telegram-Chat-ID sein.
    • Unterstützt --credential-source convex für gemeinsam gepoolte Anmeldedaten. Verwenden Sie standardmäßig den env-Modus oder setzen Sie OPENCLAW_QA_CREDENTIAL_SOURCE=convex, um gepoolte Leases zu verwenden.
    • Beendet sich mit einem Exit-Code ungleich null, wenn ein Szenario fehlschlägt. Verwenden Sie --allow-failures, wenn Sie Artefakte ohne fehlschlagenden Exit-Code wünschen.
    • Erfordert zwei unterschiedliche Bots in derselben privaten Gruppe, wobei der SUT-Bot einen Telegram-Benutzernamen bereitstellt.
    • Für stabile Bot-zu-Bot-Beobachtung aktivieren Sie Bot-to-Bot Communication Mode in @BotFather für beide Bots und stellen Sie sicher, dass der Driver-Bot Gruppen-Bot-Traffic beobachten kann.
    • Schreibt einen Telegram-QA-Bericht, eine Zusammenfassung und ein Artefakt mit beobachteten Nachrichten unter .artifacts/qa-e2e/.... Antwortszenarien enthalten RTT von der Sendeanfrage des Drivers bis zur beobachteten SUT-Antwort.

Live-Transport-Lanes teilen einen Standardvertrag, damit neue Transports nicht auseinanderlaufen; die Abdeckungsmatrix pro Lane befindet sich in QA-Übersicht → Live-Transport-Abdeckung. qa-channel ist die breite synthetische Suite und ist nicht Teil dieser Matrix.

Gemeinsame Telegram-Anmeldedaten über Convex (v1)

Wenn --credential-source convex (oder OPENCLAW_QA_CREDENTIAL_SOURCE=convex) für openclaw qa telegram aktiviert ist, erwirbt QA Lab eine exklusive Lease aus einem Convex-gestützten Pool, heartbeated diese Lease, während die Lane läuft, und gibt die Lease beim Herunterfahren frei.

Referenz-Convex-Projektscaffold:

  • qa/convex-credential-broker/

Erforderliche Env-Vars:

  • OPENCLAW_QA_CONVEX_SITE_URL (zum Beispiel https://your-deployment.convex.site)
  • Ein Secret für die ausgewählte Rolle:
    • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER für maintainer
    • OPENCLAW_QA_CONVEX_SECRET_CI für ci
  • Auswahl der Anmeldedatenrolle:
    • CLI: --credential-role maintainer|ci
    • Env-Standard: OPENCLAW_QA_CREDENTIAL_ROLE (Standard ist ci in CI, sonst maintainer)

Optionale Env-Vars:

  • OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS (Standard 1200000)
  • OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS (Standard 30000)
  • OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS (Standard 90000)
  • OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS (Standard 15000)
  • OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX (Standard /qa-credentials/v1)
  • OPENCLAW_QA_CREDENTIAL_OWNER_ID (optionale Trace-ID)
  • OPENCLAW_QA_ALLOW_INSECURE_HTTP=1 erlaubt loopback-http://-Convex-URLs für rein lokale Entwicklung.

OPENCLAW_QA_CONVEX_SITE_URL sollte im normalen Betrieb https:// verwenden.

Maintainer-Admin-Befehle (Pool hinzufügen/entfernen/auflisten) erfordern ausdrücklich OPENCLAW_QA_CONVEX_SECRET_MAINTAINER.

CLI-Helfer für Maintainer:

pnpm openclaw qa credentials doctor
pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json
pnpm openclaw qa credentials list --kind telegram
pnpm openclaw qa credentials remove --credential-id <credential-id>

Verwenden Sie doctor vor Live-Läufen, um die Convex-Site-URL, Broker-Secrets, Endpoint-Präfix, HTTP-Timeout und Admin-/Listen-Erreichbarkeit zu prüfen, ohne Secret-Werte auszugeben. Verwenden Sie --json für maschinenlesbare Ausgabe in Skripten und CI- Hilfsprogrammen.

Standard-Endpoint-Vertrag (OPENCLAW_QA_CONVEX_SITE_URL + /qa-credentials/v1):

  • POST /acquire
    • Anfrage: { kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }
    • Erfolg: { status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }
    • Erschöpft/wiederholbar: { status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }
  • POST /heartbeat
    • Anfrage: { kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }
    • Erfolg: { status: "ok" } (oder leeres 2xx)
  • POST /release
    • Anfrage: { kind, ownerId, actorRole, credentialId, leaseToken }
    • Erfolg: { status: "ok" } (oder leeres 2xx)
  • POST /admin/add (nur Maintainer-Secret)
    • Anfrage: { kind, actorId, payload, note?, status? }
    • Erfolg: { status: "ok", credential }
  • POST /admin/remove (nur Maintainer-Secret)
    • Anfrage: { credentialId, actorId }
    • Erfolg: { status: "ok", changed, credential }
    • Schutz bei aktivem Lease: { status: "error", code: "LEASE_ACTIVE", ... }
  • POST /admin/list (nur Maintainer-Secret)
    • Anfrage: { kind?, status?, includePayload?, limit? }
    • Erfolg: { status: "ok", credentials, count }

Payload-Form für Telegram-Kind:

  • { groupId: string, driverToken: string, sutToken: string }
  • groupId muss eine numerische Telegram-Chat-ID-Zeichenfolge sein.
  • admin/add validiert diese Form für kind: "telegram" und weist fehlerhafte Payloads zurück.

Kanal zu QA hinzufügen

Die Architektur und Namen der Szenario-Helfer für neue Kanaladapter finden Sie in QA-Übersicht → Kanal hinzufügen. Mindestanforderung: den Transport-Runner auf der gemeinsamen qa-lab-Host-Schnittstelle implementieren, qaRunners im Plugin-Manifest deklarieren, als openclaw qa <runner> einbinden und Szenarien unter qa/scenarios/ erstellen.

Test-Suites (was wo ausgeführt wird)

Betrachten Sie die Suites als „zunehmenden Realismus“ (und zunehmende Instabilität/Kosten):

Unit / Integration (Standard)

  • Befehl: pnpm test
  • Konfiguration: Läufe ohne Zielangabe verwenden den vitest.full-*.config.ts-Shard-Satz und können Mehrprojekt-Shards für parallele Planung in projektbezogene Konfigurationen aufteilen
  • Dateien: Core-/Unit-Inventare unter src/**/*.test.ts, packages/**/*.test.ts und test/**/*.test.ts; UI-Unit-Tests laufen im dedizierten unit-ui-Shard
  • Umfang:
    • Reine Unit-Tests
    • In-Process-Integrationstests (Gateway-Authentifizierung, Routing, Tooling, Parsing, Konfiguration)
    • Deterministische Regressionen für bekannte Fehler
  • Erwartungen:
    • Läuft in CI
    • Keine echten Schlüssel erforderlich
    • Sollte schnell und stabil sein
    • Resolver- und Public-Surface-Loader-Tests müssen breites Fallback-Verhalten von api.js und runtime-api.js mit generierten kleinen Plugin-Fixtures nachweisen, nicht mit echten Quell-APIs gebündelter Plugins. Echte Plugin-API-Ladevorgänge gehören in Plugin-eigene Vertrags-/Integrations-Suites.
- `pnpm test` ohne Zielangabe führt zwölf kleinere Shard-Konfigurationen (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) statt eines einzigen riesigen nativen Root-Projekt-Prozesses aus. Das senkt die maximale RSS auf ausgelasteten Maschinen und verhindert, dass Auto-Reply-/Plugin-Arbeit andere Suites ausbremst.
- `pnpm test --watch` verwendet weiterhin den nativen Root-Projektgraphen `vitest.config.ts`, weil eine Multi-Shard-Watch-Schleife nicht praktikabel ist.
- `pnpm test`, `pnpm test:watch` und `pnpm test:perf:imports` leiten explizite Datei-/Verzeichnisziele zuerst durch bereichsbezogene Lanes, sodass `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` die vollen Startkosten des Root-Projekts vermeidet.
- `pnpm test:changed` erweitert geänderte Git-Pfade standardmäßig zu günstigen bereichsbezogenen Lanes: direkte Teständerungen, benachbarte `*.test.ts`-Dateien, explizite Quellzuordnungen und lokale Importgraph-Abhängige. Konfigurations-, Setup- und Paketänderungen führen keine breiten Testläufe aus, sofern Sie nicht ausdrücklich `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` verwenden.
- `pnpm check:changed` ist das normale intelligente lokale Check-Gate für eng umrissene Arbeit. Es klassifiziert den Diff in Core, Core-Tests, Plugins, Plugin-Tests, Apps, Docs, Release-Metadaten, Live-Docker-Tooling und Tooling und führt dann die passenden Typecheck-, Lint- und Guard-Befehle aus. Es führt keine Vitest-Tests aus; rufen Sie `pnpm test:changed` oder explizit `pnpm test <target>` für Testnachweise auf. Versionssprünge nur bei Release-Metadaten führen gezielte Versions-/Konfigurations-/Root-Abhängigkeitsprüfungen aus, mit einem Guard, der Paketänderungen außerhalb des obersten Versionsfelds ablehnt.
- Änderungen am Live-Docker-ACP-Harness führen fokussierte Prüfungen aus: Shell-Syntax für die Live-Docker-Auth-Skripte und einen Live-Docker-Scheduler-Trockenlauf. Änderungen an `package.json` werden nur einbezogen, wenn der Diff auf `scripts["test:docker:live-*"]` beschränkt ist; Abhängigkeits-, Export-, Versions- und andere Paketoberflächenänderungen verwenden weiterhin die breiteren Guards.
- Import-leichte Unit-Tests aus Agents, Befehlen, Plugins, Auto-Reply-Helfern, `plugin-sdk` und ähnlichen reinen Hilfsbereichen laufen über die `unit-fast`-Lane, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete oder runtime-lastige Dateien bleiben auf den bestehenden Lanes.
- Ausgewählte `plugin-sdk`- und `commands`-Helferquelldateien ordnen Changed-Mode-Läufe außerdem expliziten benachbarten Tests in diesen leichten Lanes zu, sodass Helferänderungen nicht die komplette schwere Suite für dieses Verzeichnis erneut ausführen müssen.
- `auto-reply` hat dedizierte Buckets für Top-Level-Core-Helfer, Top-Level-`reply.*`-Integrationstests und den Teilbaum `src/auto-reply/reply/**`. CI teilt den Reply-Teilbaum zusätzlich in Shards für Agent-Runner, Dispatch und Befehls-/Zustandsrouting auf, damit ein importlastiger Bucket nicht den gesamten Node-Ausläufer dominiert.
- Normale PR-/Main-CI überspringt absichtlich den Plugin-Batch-Sweep und den release-only `agentic-plugins`-Shard. Full Release Validation dispatcht den separaten untergeordneten Workflow `Plugin Prerelease` für diese Plugin-lastigen Suites auf Release-Kandidaten.

- Wenn Sie Eingaben für die Message-Tool-Erkennung oder den Laufzeitkontext der Compaction ändern,
  behalten Sie beide Abdeckungsebenen bei.
- Fügen Sie fokussierte Helfer-Regressionen für reine Routing- und Normalisierungsgrenzen hinzu.
- Halten Sie die Integrations-Suites des eingebetteten Runners intakt:
  `src/agents/pi-embedded-runner/compact.hooks.test.ts`,
  `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` und
  `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`.
- Diese Suites verifizieren, dass bereichsbezogene IDs und Compaction-Verhalten weiterhin
  durch die echten `run.ts`- / `compact.ts`-Pfade fließen; reine Helfertests sind
  kein ausreichender Ersatz für diese Integrationspfade.

- Die Basis-Vitest-Konfiguration verwendet standardmäßig `threads`.
- Die gemeinsame Vitest-Konfiguration setzt `isolate: false` fest und verwendet den
  nicht isolierten Runner über Root-Projekte, E2E- und Live-Konfigurationen hinweg.
- Die Root-UI-Lane behält ihr `jsdom`-Setup und ihren Optimizer, läuft aber ebenfalls auf dem
  gemeinsamen nicht isolierten Runner.
- Jeder `pnpm test`-Shard erbt dieselben Standardwerte `threads` + `isolate: false`
  aus der gemeinsamen Vitest-Konfiguration.
- `scripts/run-vitest.mjs` fügt standardmäßig `--no-maglev` für Vitest-Child-Node-
  Prozesse hinzu, um V8-Kompilieraufwand bei großen lokalen Läufen zu verringern.
  Setzen Sie `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, um gegen das Standardverhalten von V8
  zu vergleichen.

- `pnpm changed:lanes` zeigt, welche architektonischen Lanes ein Diff auslöst.
- Der Pre-Commit-Hook dient nur der Formatierung. Er nimmt formatierte Dateien wieder in den Index auf und
  führt weder Linting noch Typecheck oder Tests aus.
- Führen Sie `pnpm check:changed` ausdrücklich vor der Übergabe oder dem Push aus, wenn Sie
  das intelligente lokale Check-Gate benötigen.
- `pnpm test:changed` läuft standardmäßig über günstige bereichsbezogene Lanes. Verwenden Sie
  `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` nur, wenn der Agent
  entscheidet, dass eine Änderung an Harness, Konfiguration, Paket oder Vertrag wirklich breitere
  Vitest-Abdeckung benötigt.
- `pnpm test:max` und `pnpm test:changed:max` behalten dasselbe Routing-
  Verhalten bei, nur mit einer höheren Worker-Obergrenze.
- Lokale automatische Worker-Skalierung ist bewusst konservativ und fährt zurück,
  wenn die Host-Load-Average bereits hoch ist, sodass mehrere gleichzeitige
  Vitest-Läufe standardmäßig weniger Schaden anrichten.
- Die Basis-Vitest-Konfiguration markiert die Projekte/Konfigurationsdateien als
  `forceRerunTriggers`, damit Changed-Mode-Neuläufe korrekt bleiben, wenn sich die Test-
  Verkabelung ändert.
- Die Konfiguration lässt `OPENCLAW_VITEST_FS_MODULE_CACHE` auf unterstützten
  Hosts aktiviert; setzen Sie `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, wenn Sie
  einen expliziten Cache-Ort für direktes Profiling möchten.

- `pnpm test:perf:imports` aktiviert Vitest-Reporting für Import-Dauer plus
  Import-Aufschlüsselung.
- `pnpm test:perf:imports:changed` beschränkt dieselbe Profiling-Ansicht auf
  Dateien, die seit `origin/main` geändert wurden.
- Shard-Timing-Daten werden nach `.artifacts/vitest-shard-timings.json` geschrieben.
  Läufe über die gesamte Konfiguration verwenden den Konfigurationspfad als Schlüssel; Include-Pattern-CI-
  Shards hängen den Shard-Namen an, damit gefilterte Shards separat verfolgt
  werden können.
- Wenn ein heißer Test weiterhin den Großteil seiner Zeit in Start-Imports verbringt,
  halten Sie schwere Abhängigkeiten hinter einer engen lokalen `*.runtime.ts`-Schnittstelle und
  mocken Sie diese Schnittstelle direkt, statt Runtime-Helfer nur deshalb tief zu importieren,
  um sie durch `vi.mock(...)` zu reichen.
- `pnpm test:perf:changed:bench -- --ref <git-ref>` vergleicht geroutetes
  `test:changed` mit dem nativen Root-Projektpfad für diesen committeten
  Diff und gibt Wandzeit plus macOS-Max-RSS aus.
- `pnpm test:perf:changed:bench -- --worktree` benchmarked den aktuellen
  Dirty Tree, indem die geänderte Dateiliste durch
  `scripts/test-projects.mjs` und die Root-Vitest-Konfiguration geroutet wird.
- `pnpm test:perf:profile:main` schreibt ein Main-Thread-CPU-Profil für
  Vitest-/Vite-Start und Transformations-Overhead.
- `pnpm test:perf:profile:runner` schreibt Runner-CPU- und Heap-Profile für die
  Unit-Suite mit deaktivierter Dateiparallelität.

Stabilität (Gateway)

  • Befehl: pnpm test:stability:gateway
  • Konfiguration: vitest.gateway.config.ts, auf einen Worker erzwungen
  • Umfang:
    • Startet standardmäßig ein echtes loopback-Gateway mit aktivierter Diagnose
    • Treibt synthetische Gateway-Nachrichten-, Memory- und Large-Payload-Last durch den Diagnoseereignispfad
    • Fragt diagnostics.stability über den Gateway-WS-RPC ab
    • Deckt Persistenzhelfer für Diagnose-Stabilitätsbundles ab
    • Stellt sicher, dass der Recorder begrenzt bleibt, synthetische RSS-Samples unter dem Druckbudget bleiben und Queue-Tiefen pro Sitzung wieder auf null ablaufen
  • Erwartungen:
    • CI-sicher und ohne Schlüssel
    • Enge Lane für Nachverfolgung von Stabilitätsregressionen, kein Ersatz für die vollständige Gateway-Suite

E2E (Gateway-Smoke)

  • Befehl: pnpm test:e2e
  • Konfiguration: vitest.e2e.config.ts
  • Dateien: src/**/*.e2e.test.ts, test/**/*.e2e.test.ts und gebündelte Plugin-E2E-Tests unter extensions/
  • Runtime-Standards:
    • Verwendet Vitest-threads mit isolate: false, passend zum Rest des Repos.
    • Verwendet adaptive Worker (CI: bis zu 2, lokal: standardmäßig 1).
    • Läuft standardmäßig im stillen Modus, um Console-I/O-Overhead zu reduzieren.
  • Nützliche Overrides:
    • OPENCLAW_E2E_WORKERS=<n>, um die Worker-Anzahl zu erzwingen (auf 16 begrenzt).
    • OPENCLAW_E2E_VERBOSE=1, um ausführliche Konsolenausgabe wieder zu aktivieren.
  • Umfang:
    • End-to-End-Verhalten für Multi-Instanz-Gateway
    • WebSocket/HTTP-Oberflächen, Node-Pairing und aufwendigere Netzwerkfunktionen
  • Erwartungen:
    • Läuft in CI (wenn in der Pipeline aktiviert)
    • Keine echten Schlüssel erforderlich
    • Mehr bewegliche Teile als Unit-Tests (kann langsamer sein)

E2E: OpenShell-Backend-Smoke-Test

  • Befehl: pnpm test:e2e:openshell
  • Datei: extensions/openshell/src/backend.e2e.test.ts
  • Umfang:
    • Startet ein isoliertes OpenShell-Gateway auf dem Host über Docker
    • Erstellt eine Sandbox aus einer temporären lokalen Dockerfile
    • Übt OpenClaws OpenShell-Backend über echtes sandbox ssh-config + SSH-Ausführung aus
    • Verifiziert remote-kanonisches Dateisystemverhalten über die Sandbox-fs-Bridge
  • Erwartungen:
    • Nur Opt-in; nicht Teil des standardmäßigen pnpm test:e2e-Laufs
    • Erfordert eine lokale openshell-CLI sowie einen funktionierenden Docker-Daemon
    • Verwendet isolierte HOME / XDG_CONFIG_HOME, zerstört anschließend das Test-Gateway und die Sandbox
  • Nützliche Overrides:
    • OPENCLAW_E2E_OPENSHELL=1, um den Test zu aktivieren, wenn die breitere E2E-Suite manuell ausgeführt wird
    • OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell, um auf ein nicht standardmäßiges CLI-Binary oder Wrapper-Skript zu zeigen

Live (echte Provider + echte Modelle)

  • Befehl: pnpm test:live
  • Konfiguration: vitest.live.config.ts
  • Dateien: src/**/*.live.test.ts, test/**/*.live.test.ts und gebündelte Plugin-Live-Tests unter extensions/
  • Standard: durch pnpm test:live aktiviert (setzt OPENCLAW_LIVE_TEST=1)
  • Umfang:
    • „Funktioniert dieser Provider/dieses Modell heute tatsächlich mit echten Zugangsdaten?“
    • Fängt Provider-Formatänderungen, Eigenheiten bei Tool-Calling, Auth-Probleme und Rate-Limit-Verhalten ab
  • Erwartungen:
    • Absichtlich nicht CI-stabil (echte Netzwerke, echte Provider-Richtlinien, Kontingente, Ausfälle)
    • Kostet Geld / nutzt Rate Limits
    • Eng eingegrenzte Teilmengen statt „alles“ bevorzugen
  • Live-Läufe sourcen ~/.profile, um fehlende API-Schlüssel aufzunehmen.
  • Standardmäßig isolieren Live-Läufe weiterhin HOME und kopieren Konfigurations-/Auth-Material in ein temporäres Test-Home, damit Unit-Fixtures Ihr echtes ~/.openclaw nicht verändern können.
  • Setzen Sie OPENCLAW_LIVE_USE_REAL_HOME=1 nur, wenn Live-Tests absichtlich Ihr echtes Home-Verzeichnis verwenden sollen.
  • pnpm test:live verwendet jetzt standardmäßig einen ruhigeren Modus: Die [live] ...-Fortschrittsausgabe bleibt erhalten, aber der zusätzliche ~/.profile-Hinweis wird unterdrückt und Gateway-Bootstrap-Logs/Bonjour-Meldungen werden stummgeschaltet. Setzen Sie OPENCLAW_LIVE_TEST_QUIET=0, wenn Sie die vollständigen Start-Logs zurückhaben möchten.
  • API-Schlüsselrotation (Provider-spezifisch): Setzen Sie *_API_KEYS im Komma-/Semikolonformat oder *_API_KEY_1, *_API_KEY_2 (zum Beispiel OPENAI_API_KEYS, ANTHROPIC_API_KEYS, GEMINI_API_KEYS) oder einen Live-spezifischen Override über OPENCLAW_LIVE_*_KEY; Tests versuchen es bei Rate-Limit-Antworten erneut.
  • Fortschritts-/Heartbeat-Ausgabe:
    • Live-Suites geben jetzt Fortschrittszeilen auf stderr aus, damit lange Provider-Aufrufe sichtbar aktiv sind, selbst wenn Vitests Console-Erfassung ruhig ist.
    • vitest.live.config.ts deaktiviert Vitests Console-Interception, damit Provider-/Gateway-Fortschrittszeilen während Live-Läufen sofort gestreamt werden.
    • Passen Sie Direct-Model-Heartbeats mit OPENCLAW_LIVE_HEARTBEAT_MS an.
    • Passen Sie Gateway-/Probe-Heartbeats mit OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS an.

Welche Suite sollte ich ausführen?

Verwenden Sie diese Entscheidungstabelle:

  • Logik/Tests bearbeiten: pnpm test ausführen (und pnpm test:coverage, wenn Sie viel geändert haben)
  • Gateway-Netzwerk / WS-Protokoll / Pairing anfassen: pnpm test:e2e hinzufügen
  • „Mein Bot ist ausgefallen“ / Provider-spezifische Fehler / Tool-Calling debuggen: ein eingegrenztes pnpm test:live ausführen

Live-Tests (mit Netzwerkzugriff)

Für die Live-Modellmatrix, CLI-Backend-Smoke-Tests, ACP-Smoke-Tests, das Codex-App-Server- Harness und alle Medien-Provider-Live-Tests (Deepgram, BytePlus, ComfyUI, Bild, Musik, Video, Medien-Harness) sowie die Anmeldeinformationsbehandlung für Live-Läufe siehe Live-Suites testen. Für die dedizierte Checkliste für Updates und Plugin-Validierung siehe Updates und Plugins testen.

Docker-Runner (optionale „funktioniert unter Linux“-Prüfungen)

Diese Docker-Runner sind in zwei Gruppen aufgeteilt:

  • Live-Modell-Runner: test:docker:live-models und test:docker:live-gateway führen nur ihre passende Profil-Schlüssel-Live-Datei im Repo-Docker-Image aus (src/agents/models.profiles.live.test.ts und src/gateway/gateway-models.profiles.live.test.ts), mounten Ihr lokales Konfigurationsverzeichnis und Ihren Workspace (und sourcen ~/.profile, falls gemountet). Die passenden lokalen Einstiegspunkte sind test:live:models-profiles und test:live:gateway-profiles.
  • Docker-Live-Runner verwenden standardmäßig ein kleineres Smoke-Limit, damit ein vollständiger Docker-Sweep praktikabel bleibt: test:docker:live-models verwendet standardmäßig OPENCLAW_LIVE_MAX_MODELS=12, und test:docker:live-gateway verwendet standardmäßig OPENCLAW_LIVE_GATEWAY_SMOKE=1, OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8, OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000 und OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000. Überschreiben Sie diese Env-Vars, wenn Sie ausdrücklich den größeren vollständigen Scan wünschen.
  • test:docker:all baut das Live-Docker-Image einmal über test:docker:live-build, paketiert OpenClaw einmal als npm-Tarball über scripts/package-openclaw-for-docker.mjs und baut/verwendet anschließend zwei scripts/e2e/Dockerfile-Images wieder. Das Bare-Image ist nur der Node/Git-Runner für Installations-/Update-/Plugin-Dependency-Lanes; diese Lanes mounten den vorgebauten Tarball. Das funktionale Image installiert denselben Tarball nach /app für Built-App-Funktionalitäts-Lanes. Docker-Lane-Definitionen liegen in scripts/lib/docker-e2e-scenarios.mjs; Planner-Logik liegt in scripts/lib/docker-e2e-plan.mjs; scripts/test-docker-all.mjs führt den ausgewählten Plan aus. Das Aggregat verwendet einen gewichteten lokalen Scheduler: OPENCLAW_DOCKER_ALL_PARALLELISM steuert Prozess-Slots, während Ressourcenlimits verhindern, dass schwere Live-, npm-Installations- und Multi-Service-Lanes alle gleichzeitig starten. Wenn eine einzelne Lane schwerer ist als die aktiven Limits, kann der Scheduler sie trotzdem starten, wenn der Pool leer ist, und lässt sie dann allein laufen, bis wieder Kapazität verfügbar ist. Standards sind 10 Slots, OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9, OPENCLAW_DOCKER_ALL_NPM_LIMIT=10 und OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7; passen Sie OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT oder OPENCLAW_DOCKER_ALL_DOCKER_LIMIT nur an, wenn der Docker-Host mehr Spielraum hat. Der Runner führt standardmäßig einen Docker-Preflight aus, entfernt veraltete OpenClaw-E2E-Container, gibt alle 30 Sekunden Status aus, speichert erfolgreiche Lane-Zeiten in .artifacts/docker-tests/lane-timings.json und verwendet diese Zeiten, um bei späteren Läufen längere Lanes zuerst zu starten. Verwenden Sie OPENCLAW_DOCKER_ALL_DRY_RUN=1, um das gewichtete Lane-Manifest ohne Bauen oder Ausführen von Docker auszugeben, oder node scripts/test-docker-all.mjs --plan-json, um den CI-Plan für ausgewählte Lanes, Paket-/Image-Bedarfe und Anmeldeinformationen auszugeben.
  • Package Acceptance ist das GitHub-native Paket-Gate für „funktioniert dieser installierbare Tarball als Produkt?“. Es löst ein Kandidatenpaket aus source=npm, source=ref, source=url oder source=artifact auf, lädt es als package-under-test hoch und führt dann die wiederverwendbaren Docker-E2E-Lanes gegen genau diesen Tarball aus, anstatt die ausgewählte Ref neu zu paketieren. Profile sind nach Breite geordnet: smoke, package, product und full. Siehe Updates und Plugins testen für den Paket-/Update-/Plugin-Vertrag, die Survivor-Matrix für veröffentlichte Upgrades, Release-Standards und Fehlertriage.
  • Build- und Release-Prüfungen führen scripts/check-cli-bootstrap-imports.mjs nach tsdown aus. Der Guard durchläuft den statischen gebauten Graphen ab dist/entry.js und dist/cli/run-main.js und schlägt fehl, wenn Startup-Importe vor dem Dispatch Paketabhängigkeiten wie Commander, Prompt-UI, undici oder Logging vor dem Befehlsdispatch importieren; außerdem hält er den gebündelten Gateway-Run-Chunk unter dem Budget und lehnt statische Importe bekannter kalter Gateway-Pfade ab. Der paketierte CLI-Smoke-Test deckt außerdem Root-Hilfe, Onboard-Hilfe, Doctor-Hilfe, Status, Konfigurationsschema und einen Model-List-Befehl ab.
  • Die Legacy-Kompatibilität von Package Acceptance ist auf 2026.4.25 begrenzt (2026.4.25-beta.* eingeschlossen). Bis zu diesem Stichtag toleriert das Harness nur Metadatenlücken ausgelieferter Pakete: ausgelassene private QA-Inventareinträge, fehlendes gateway install --wrapper, fehlende Patch-Dateien im aus dem Tarball abgeleiteten Git-Fixture, fehlendes persistiertes update.channel, alte Speicherorte für Plugin-Installationsdatensätze, fehlende Persistenz von Marketplace-Installationsdatensätzen und Migration von Konfigurationsmetadaten während plugins update. Für Pakete nach 2026.4.25 sind diese Pfade strikte Fehler.
  • Container-Smoke-Runner: test:docker:openwebui, test:docker:onboard, test:docker:npm-onboard-channel-agent, test:docker:update-channel-switch, test:docker:upgrade-survivor, test:docker:published-upgrade-survivor, test:docker:session-runtime-context, test:docker:agents-delete-shared-workspace, test:docker:gateway-network, test:docker:browser-cdp-snapshot, test:docker:mcp-channels, test:docker:pi-bundle-mcp-tools, test:docker:cron-mcp-cleanup, test:docker:plugins, test:docker:plugin-update, test:docker:plugin-lifecycle-matrix und test:docker:config-reload booten einen oder mehrere echte Container und verifizieren Integrationspfade auf höherer Ebene.

Die Live-Modell-Docker-Runner binden außerdem nur die benötigten CLI-Auth-Homes ein (oder alle unterstützten, wenn der Lauf nicht eingegrenzt ist) und kopieren sie anschließend vor dem Lauf in das Container-Home, damit OAuth externer CLIs Tokens aktualisieren kann, ohne den Auth-Speicher des Hosts zu verändern:

  • Direkte Modelle: pnpm test:docker:live-models (Skript: scripts/test-live-models-docker.sh)
  • ACP-Bind-Smoke: pnpm test:docker:live-acp-bind (Skript: scripts/test-live-acp-bind-docker.sh; deckt standardmäßig Claude, Codex und Gemini ab, mit strikter Droid-/OpenCode-Abdeckung über pnpm test:docker:live-acp-bind:droid und pnpm test:docker:live-acp-bind:opencode)
  • CLI-Backend-Smoke: pnpm test:docker:live-cli-backend (Skript: scripts/test-live-cli-backend-docker.sh)
  • Codex-App-Server-Harness-Smoke: pnpm test:docker:live-codex-harness (Skript: scripts/test-live-codex-harness-docker.sh)
  • Gateway + Entwicklungs-Agent: pnpm test:docker:live-gateway (Skript: scripts/test-live-gateway-models-docker.sh)
  • Observability-Smoke: pnpm qa:otel:smoke ist eine private QA-Source-Checkout-Lane. Sie ist absichtlich nicht Teil der Docker-Release-Lanes für Pakete, weil der npm-Tarball QA Lab auslässt.
  • Open WebUI-Live-Smoke: pnpm test:docker:openwebui (Skript: scripts/e2e/openwebui-docker.sh)
  • Onboarding-Assistent (TTY, vollständiges Scaffolding): pnpm test:docker:onboard (Skript: scripts/e2e/onboard-docker.sh)
  • Npm-Tarball-Onboarding-/Channel-/Agent-Smoke: pnpm test:docker:npm-onboard-channel-agent installiert den gepackten OpenClaw-Tarball global in Docker, konfiguriert OpenAI über env-ref-Onboarding sowie standardmäßig Telegram, führt doctor aus und führt einen gemockten OpenAI-Agent-Turn aus. Verwenden Sie einen vorab gebauten Tarball mit OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz erneut, überspringen Sie den Host-Rebuild mit OPENCLAW_NPM_ONBOARD_HOST_BUILD=0, oder wechseln Sie den Channel mit OPENCLAW_NPM_ONBOARD_CHANNEL=discord oder OPENCLAW_NPM_ONBOARD_CHANNEL=slack.
  • Update-Channel-Wechsel-Smoke: pnpm test:docker:update-channel-switch installiert den gepackten OpenClaw-Tarball global in Docker, wechselt von Paket stable zu Git dev, verifiziert, dass der persistierte Channel und die Plugin-Post-Update-Funktion funktionieren, wechselt dann zurück zu Paket stable und prüft den Update-Status.
  • Upgrade-Survivor-Smoke: pnpm test:docker:upgrade-survivor installiert den gepackten OpenClaw-Tarball über ein verschmutztes Altbenutzer-Fixture mit Agents, Channel-Konfiguration, Plugin-Allowlists, veraltetem Plugin-Abhängigkeitszustand und bestehenden Workspace-/Session-Dateien. Es führt Paket-Update plus nicht interaktiven doctor ohne Live-Provider- oder Channel-Schlüssel aus, startet dann ein loopback-Gateway und prüft Konfigurations-/Zustandserhaltung sowie Start-/Status-Budgets.
  • Veröffentlichter Upgrade-Survivor-Smoke: pnpm test:docker:published-upgrade-survivor installiert standardmäßig openclaw@latest, erzeugt realistische Bestandsbenutzerdateien, konfiguriert diese Baseline mit einem eingebauten Befehlsrezept, validiert die resultierende Konfiguration, aktualisiert diese veröffentlichte Installation auf den Kandidaten-Tarball, führt den nicht interaktiven doctor aus, schreibt .artifacts/upgrade-survivor/summary.json, startet dann ein loopback-Gateway und prüft konfigurierte Intents, Zustandserhaltung, Start, /healthz, /readyz und RPC-Status-Budgets. Überschreiben Sie eine Baseline mit OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC, lassen Sie den aggregierten Scheduler exakte Baselines mit OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS wie all-since-2026.4.23 erweitern, und erweitern Sie issue-förmige Fixtures mit OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS wie reported-issues; das reported-issues-Set enthält configured-plugin-installs für die automatische Reparatur externer OpenClaw-Plugin-Installationen. Package Acceptance stellt diese als published_upgrade_survivor_baseline, published_upgrade_survivor_baselines und published_upgrade_survivor_scenarios bereit; Full Release Validation verwendet die standardmäßige latest-Baseline im blockierenden Pfad und erweitert nur für run_release_soak=true oder release_profile=full auf all-since/reported-issues.
  • Session-Runtime-Kontext-Smoke: pnpm test:docker:session-runtime-context verifiziert die Persistenz versteckter Runtime-Kontext-Transkripte plus doctor-Reparatur betroffener duplizierter Prompt-Rewrite-Branches.
  • Bun-Global-Install-Smoke: bash scripts/e2e/bun-global-install-smoke.sh packt den aktuellen Tree, installiert ihn mit bun install -g in einem isolierten Home und verifiziert, dass openclaw infer image providers --json gebündelte Image-Provider zurückgibt, statt zu hängen. Verwenden Sie einen vorab gebauten Tarball mit OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz erneut, überspringen Sie den Host-Build mit OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0, oder kopieren Sie dist/ aus einem gebauten Docker-Image mit OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local.
  • Installer-Docker-Smoke: bash scripts/test-install-sh-docker.sh teilt einen npm-Cache zwischen seinen Root-, Update- und Direct-npm-Containern. Update-Smoke verwendet standardmäßig npm latest als stabile Baseline, bevor auf den Kandidaten-Tarball aktualisiert wird. Überschreiben Sie lokal mit OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22 oder mit der Eingabe update_baseline_version des Install-Smoke-Workflows auf GitHub. Nicht-Root-Installer-Prüfungen behalten einen isolierten npm-Cache, damit root-eigene Cache-Einträge das benutzerlokale Installationsverhalten nicht verdecken. Setzen Sie OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache, um den Root-/Update-/Direct-npm-Cache über lokale Wiederholungen hinweg erneut zu verwenden.
  • Install-Smoke-CI überspringt das doppelte direkte globale npm-Update mit OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1; führen Sie das Skript lokal ohne diese Umgebung aus, wenn direkte npm install -g-Abdeckung benötigt wird.
  • Agents-delete-shared-workspace-CLI-Smoke: pnpm test:docker:agents-delete-shared-workspace (Skript: scripts/e2e/agents-delete-shared-workspace-docker.sh) baut standardmäßig das Root-Dockerfile-Image, legt zwei Agents mit einem Workspace in einem isolierten Container-Home an, führt agents delete --json aus und verifiziert gültiges JSON plus Verhalten mit beibehaltenem Workspace. Verwenden Sie das install-smoke-Image mit OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1 erneut.
  • Gateway-Netzwerk (zwei Container, WS-Auth + Health): pnpm test:docker:gateway-network (Skript: scripts/e2e/gateway-network-docker.sh)
  • Browser-CDP-Snapshot-Smoke: pnpm test:docker:browser-cdp-snapshot (Skript: scripts/e2e/browser-cdp-snapshot-docker.sh) baut das Source-E2E-Image plus eine Chromium-Schicht, startet Chromium mit rohem CDP, führt browser doctor --deep aus und verifiziert, dass CDP-Rollen-Snapshots Link-URLs, cursor-promoted Clickables, iframe-Refs und Frame-Metadaten abdecken.
  • OpenAI-Responses-web_search-Regression für minimales Reasoning: pnpm test:docker:openai-web-search-minimal (Skript: scripts/e2e/openai-web-search-minimal-docker.sh) führt einen gemockten OpenAI-Server über Gateway aus, verifiziert, dass web_search reasoning.effort von minimal auf low anhebt, erzwingt dann die Ablehnung durch das Provider-Schema und prüft, dass das rohe Detail in Gateway-Logs erscheint.
  • MCP-Channel-Bridge (geseedetes Gateway + stdio-Bridge + roher Claude-Notification-Frame-Smoke): pnpm test:docker:mcp-channels (Skript: scripts/e2e/mcp-channels-docker.sh)
  • Pi-Bundle-MCP-Tools (echter stdio-MCP-Server + eingebetteter Pi-Profil-Allow-/Deny-Smoke): pnpm test:docker:pi-bundle-mcp-tools (Skript: scripts/e2e/pi-bundle-mcp-tools-docker.sh)
  • Cron-/Subagent-MCP-Bereinigung (echtes Gateway + stdio-MCP-Child-Teardown nach isolierten cron- und One-shot-Subagent-Läufen): pnpm test:docker:cron-mcp-cleanup (Skript: scripts/e2e/cron-mcp-cleanup-docker.sh)
  • Plugins (Install-/Update-Smoke für lokalen Pfad, file:, npm-Registry mit hoisted Abhängigkeiten, bewegliche Git-Refs, ClawHub-Kitchen-Sink, Marketplace-Updates und Claude-Bundle-Aktivieren/Prüfen): pnpm test:docker:plugins (Skript: scripts/e2e/plugins-docker.sh) Setzen Sie OPENCLAW_PLUGINS_E2E_CLAWHUB=0, um den ClawHub-Block zu überspringen, oder überschreiben Sie das standardmäßige Kitchen-Sink-Paket-/Runtime-Paar mit OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC und OPENCLAW_PLUGINS_E2E_CLAWHUB_ID. Ohne OPENCLAW_CLAWHUB_URL/CLAWHUB_URL verwendet der Test einen hermetischen lokalen ClawHub-Fixture-Server.
  • Plugin-Update-Unchanged-Smoke: pnpm test:docker:plugin-update (Skript: scripts/e2e/plugin-update-unchanged-docker.sh)
  • Plugin-Lifecycle-Matrix-Smoke: pnpm test:docker:plugin-lifecycle-matrix installiert den gepackten OpenClaw-Tarball in einem leeren Container, installiert ein npm-Plugin, schaltet enable/disable um, aktualisiert es und führt ein Downgrade über eine lokale npm-Registry durch, löscht den installierten Code und verifiziert dann, dass uninstall weiterhin veralteten Zustand entfernt, während für jede Lifecycle-Phase RSS-/CPU-Metriken protokolliert werden.
  • Config-Reload-Metadata-Smoke: pnpm test:docker:config-reload (Skript: scripts/e2e/config-reload-source-docker.sh)
  • Plugins: pnpm test:docker:plugins deckt Install-/Update-Smoke für lokalen Pfad, file:, npm-Registry mit hoisted Abhängigkeiten, bewegliche Git-Refs, ClawHub-Fixtures, Marketplace-Updates und Claude-Bundle-Aktivieren/Prüfen ab. pnpm test:docker:plugin-update deckt unverändertes Update-Verhalten für installierte Plugins ab. pnpm test:docker:plugin-lifecycle-matrix deckt ressourcenverfolgte npm-Plugin-Installation, enable, disable, Upgrade, Downgrade und missing-code-uninstall ab.

So bauen Sie das gemeinsam genutzte funktionale Image manuell vor und verwenden es erneut:

OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-build
OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels

Suite-spezifische Image-Overrides wie OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE haben weiterhin Vorrang, wenn sie gesetzt sind. Wenn OPENCLAW_SKIP_DOCKER_BUILD=1 auf ein entferntes gemeinsam genutztes Image verweist, ziehen die Skripte es, falls es noch nicht lokal vorhanden ist. Die QR- und Installer-Docker-Tests behalten ihre eigenen Dockerfiles, weil sie Paket-/Installationsverhalten statt der gemeinsam genutzten Built-App-Runtime validieren.

Die Docker-Runner für Live-Modelle binden außerdem den aktuellen Checkout schreibgeschützt ein und stagen ihn in ein temporäres Arbeitsverzeichnis im Container. Dadurch bleibt das Laufzeit- Image schlank, während Vitest weiterhin gegen Ihre exakt lokale Source-/Config-Version läuft. Der Staging-Schritt überspringt große, nur lokal relevante Caches und App-Build-Ausgaben wie .pnpm-store, .worktrees, __openclaw_vitest__ sowie app-lokale .build- oder Gradle-Ausgabeverzeichnisse, damit Docker-Live-Ausführungen nicht minutenlang maschinenspezifische Artefakte kopieren. Sie setzen außerdem OPENCLAW_SKIP_CHANNELS=1, damit Gateway-Live-Probes keine echten Telegram-/Discord-/usw.-Kanal-Worker im Container starten. test:docker:live-models führt weiterhin pnpm test:live aus. Reichen Sie daher auch OPENCLAW_LIVE_GATEWAY_* durch, wenn Sie die Gateway-Live-Abdeckung in dieser Docker-Lane eingrenzen oder ausschließen müssen. test:docker:openwebui ist ein höherstufiger Kompatibilitäts-Smoke-Test: Er startet einen OpenClaw-Gateway-Container mit aktivierten OpenAI-kompatiblen HTTP-Endpunkten, startet einen gepinnten Open-WebUI-Container gegen dieses Gateway, meldet sich über Open WebUI an, prüft, dass /api/models openclaw/default bereitstellt, und sendet dann eine echte Chat-Anfrage über den /api/chat/completions-Proxy von Open WebUI. Der erste Lauf kann spürbar langsamer sein, weil Docker möglicherweise das Open-WebUI-Image abrufen muss und Open WebUI sein eigenes Cold-Start-Setup abschließen muss. Diese Lane erwartet einen nutzbaren Schlüssel für ein Live-Modell, und OPENCLAW_PROFILE_FILE (standardmäßig ~/.profile) ist der primäre Weg, ihn in Dockerisierten Läufen bereitzustellen. Erfolgreiche Läufe geben eine kleine JSON-Nutzlast wie { "ok": true, "model": "openclaw/default", ... } aus. test:docker:mcp-channels ist absichtlich deterministisch und benötigt kein echtes Telegram-, Discord- oder iMessage-Konto. Es startet einen vorbefüllten Gateway- Container, startet einen zweiten Container, der openclaw mcp serve startet, und prüft dann geroutete Konversationserkennung, Lesen von Transkripten, Anhangsmetadaten, Verhalten der Live-Event-Queue, Routing ausgehender Sendungen sowie Kanal- und Berechtigungsbenachrichtigungen im Claude-Stil über die echte stdio-MCP-Bridge. Die Benachrichtigungsprüfung inspiziert die rohen stdio-MCP-Frames direkt, damit der Smoke-Test validiert, was die Bridge tatsächlich ausgibt, nicht nur, was ein bestimmtes Client-SDK zufällig sichtbar macht. test:docker:pi-bundle-mcp-tools ist deterministisch und benötigt keinen Live-Modellschlüssel. Es baut das Repo-Docker-Image, startet einen echten stdio-MCP-Probe-Server im Container, materialisiert diesen Server über die eingebettete Pi-Bundle- MCP-Laufzeit, führt das Tool aus und prüft dann, dass coding und messaging bundle-mcp-Tools behalten, während minimal und tools.deny: ["bundle-mcp"] sie herausfiltern. test:docker:cron-mcp-cleanup ist deterministisch und benötigt keinen Live-Modellschlüssel. Es startet ein vorbefülltes Gateway mit einem echten stdio-MCP-Probe-Server, führt einen isolierten Cron-Turn und einen /subagents spawn-One-Shot-Child-Turn aus und prüft dann, dass der MCP-Kindprozess nach jedem Lauf beendet wird.

Manueller ACP-Smoke-Test für Threads in natürlicher Sprache (nicht CI):

  • bun scripts/dev/discord-acp-plain-language-smoke.ts --channel <discord-channel-id> ...
  • Behalten Sie dieses Skript für Regressions-/Debug-Workflows. Es kann für die ACP-Thread-Routing-Validierung erneut benötigt werden, löschen Sie es daher nicht.

Nützliche Umgebungsvariablen:

  • OPENCLAW_CONFIG_DIR=... (Standard: ~/.openclaw) wird nach /home/node/.openclaw gemountet
  • OPENCLAW_WORKSPACE_DIR=... (Standard: ~/.openclaw/workspace) wird nach /home/node/.openclaw/workspace gemountet
  • OPENCLAW_PROFILE_FILE=... (Standard: ~/.profile) wird nach /home/node/.profile gemountet und vor dem Ausführen der Tests gesourct
  • OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1, um nur aus OPENCLAW_PROFILE_FILE gesourcte Umgebungsvariablen zu prüfen, mit temporären Config-/Workspace-Verzeichnissen und ohne externe CLI-Auth-Mounts
  • OPENCLAW_DOCKER_CLI_TOOLS_DIR=... (Standard: ~/.cache/openclaw/docker-cli-tools) wird nach /home/node/.npm-global für gecachte CLI-Installationen innerhalb von Docker gemountet
  • Externe CLI-Auth-Verzeichnisse/-Dateien unter $HOME werden schreibgeschützt unter /host-auth... gemountet und dann vor Testbeginn nach /home/node/... kopiert
    • Standardverzeichnisse: .minimax
    • Standarddateien: ~/.codex/auth.json, ~/.codex/config.toml, .claude.json, ~/.claude/.credentials.json, ~/.claude/settings.json, ~/.claude/settings.local.json
    • Eingegrenzte Provider-Läufe mounten nur die benötigten Verzeichnisse/Dateien, die aus OPENCLAW_LIVE_PROVIDERS / OPENCLAW_LIVE_GATEWAY_PROVIDERS abgeleitet werden
    • Manuelle Überschreibung mit OPENCLAW_DOCKER_AUTH_DIRS=all, OPENCLAW_DOCKER_AUTH_DIRS=none oder einer kommagetrennten Liste wie OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex
  • OPENCLAW_LIVE_GATEWAY_MODELS=... / OPENCLAW_LIVE_MODELS=..., um den Lauf einzugrenzen
  • OPENCLAW_LIVE_GATEWAY_PROVIDERS=... / OPENCLAW_LIVE_PROVIDERS=..., um Provider im Container zu filtern
  • OPENCLAW_SKIP_DOCKER_BUILD=1, um ein vorhandenes openclaw:local-live-Image für Wiederholungsläufe wiederzuverwenden, die keinen Neuaufbau benötigen
  • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um sicherzustellen, dass Zugangsdaten aus dem Profil-Store stammen (nicht aus der Umgebung)
  • OPENCLAW_OPENWEBUI_MODEL=..., um das Modell auszuwählen, das vom Gateway für den Open-WebUI-Smoke-Test bereitgestellt wird
  • OPENCLAW_OPENWEBUI_PROMPT=..., um den vom Open-WebUI-Smoke-Test verwendeten Nonce-Check-Prompt zu überschreiben
  • OPENWEBUI_IMAGE=..., um den gepinnten Open-WebUI-Image-Tag zu überschreiben

Docs-Sanity

Führen Sie nach Dokumentationsänderungen Docs-Prüfungen aus: pnpm check:docs. Führen Sie die vollständige Mintlify-Ankervalidierung aus, wenn Sie auch In-Page-Überschriftenprüfungen benötigen: pnpm docs:check-links:anchors.

Offline-Regression (CI-sicher)

Dies sind „echte Pipeline“-Regressionen ohne echte Provider:

  • Gateway-Tool-Calling (Mock-OpenAI, echtes Gateway + Agent-Loop): src/gateway/gateway.test.ts (Fall: "runs a mock OpenAI tool call end-to-end via gateway agent loop")
  • Gateway-Assistent (WS wizard.start/wizard.next, schreibt Config + Auth erzwungen): src/gateway/gateway.test.ts (Fall: "runs wizard over ws and writes auth token config")

Agent-Zuverlässigkeits-Evals (Skills)

Wir haben bereits einige CI-sichere Tests, die sich wie „Agent-Zuverlässigkeits-Evals“ verhalten:

  • Mock-Tool-Calling durch das echte Gateway + Agent-Loop (src/gateway/gateway.test.ts).
  • End-to-End-Assistenten-Flows, die Session-Verkabelung und Config-Auswirkungen validieren (src/gateway/gateway.test.ts).

Was für Skills noch fehlt (siehe Skills):

  • Entscheidungslogik: Wenn Skills im Prompt aufgeführt sind, wählt der Agent den richtigen Skill (oder vermeidet irrelevante)?
  • Compliance: Liest der Agent SKILL.md vor der Verwendung und folgt er den erforderlichen Schritten/Argumenten?
  • Workflow-Verträge: Mehrstufige Szenarien, die Tool-Reihenfolge, Übernahme der Session-Historie und Sandbox-Grenzen prüfen.

Künftige Evals sollten zuerst deterministisch bleiben:

  • Ein Szenario-Runner mit Mock-Providern, um Tool-Aufrufe + Reihenfolge, Skill-Datei-Lesevorgänge und Session-Verkabelung zu prüfen.
  • Eine kleine Suite Skill-fokussierter Szenarien (verwenden vs. vermeiden, Gating, Prompt-Injection).
  • Optionale Live-Evals (Opt-in, per Umgebungsvariablen gesteuert) erst, nachdem die CI-sichere Suite vorhanden ist.

Vertragstests (Plugin- und Kanalform)

Vertragstests prüfen, dass jedes registrierte Plugin und jeder registrierte Kanal seinem Interface-Vertrag entspricht. Sie iterieren über alle gefundenen Plugins und führen eine Suite von Form- und Verhaltensassertions aus. Die standardmäßige pnpm test-Unit-Lane überspringt diese gemeinsamen Seam- und Smoke-Dateien absichtlich; führen Sie die Vertragsbefehle explizit aus, wenn Sie gemeinsame Kanal- oder Provider-Oberflächen berühren.

Befehle

  • Alle Verträge: pnpm test:contracts
  • Nur Kanalverträge: pnpm test:contracts:channels
  • Nur Provider-Verträge: pnpm test:contracts:plugins

Kanalverträge

Zu finden in src/channels/plugins/contracts/*.contract.test.ts:

  • plugin - Grundlegende Plugin-Form (ID, Name, Fähigkeiten)
  • setup - Setup-Assistentenvertrag
  • session-binding - Session-Binding-Verhalten
  • outbound-payload - Nachrichten-Nutzlaststruktur
  • inbound - Verarbeitung eingehender Nachrichten
  • actions - Kanal-Aktionshandler
  • threading - Thread-ID-Verarbeitung
  • directory - Directory/Roster-API
  • group-policy - Durchsetzung von Gruppenrichtlinien

Provider-Statusverträge

Zu finden in src/plugins/contracts/*.contract.test.ts.

  • status - Kanalstatus-Probes
  • registry - Plugin-Registry-Form

Provider-Verträge

Zu finden in src/plugins/contracts/*.contract.test.ts:

  • auth - Auth-Flow-Vertrag
  • auth-choice - Auth-Auswahl/Selektion
  • catalog - Modellkatalog-API
  • discovery - Plugin-Erkennung
  • loader - Plugin-Laden
  • runtime - Provider-Laufzeit
  • shape - Plugin-Form/Interface
  • wizard - Setup-Assistent

Wann ausführen

  • Nach Änderungen an plugin-sdk-Exports oder Subpfaden
  • Nach dem Hinzufügen oder Ändern eines Kanal- oder Provider-Plugins
  • Nach dem Refactoring von Plugin-Registrierung oder -Erkennung

Vertragstests laufen in CI und benötigen keine echten API-Schlüssel.

Regressionen hinzufügen (Leitlinien)

Wenn Sie ein Provider-/Modellproblem beheben, das live entdeckt wurde:

  • Fügen Sie nach Möglichkeit eine CI-sichere Regression hinzu (Mock-/Stub-Provider oder Erfassung der exakten Request-Shape-Transformation)
  • Wenn es inhärent nur live prüfbar ist (Rate-Limits, Auth-Richtlinien), halten Sie den Live-Test eng begrenzt und per Umgebungsvariablen opt-in
  • Zielen Sie bevorzugt auf die kleinste Ebene, die den Fehler erkennt:
    • Provider-Request-Konvertierungs-/Replay-Fehler → direkter Modelltest
    • Gateway-Session-/History-/Tool-Pipeline-Fehler → Gateway-Live-Smoke-Test oder CI-sicherer Gateway-Mock-Test
  • SecretRef-Traversal-Guardrail:
    • src/secrets/exec-secret-ref-id-parity.test.ts leitet aus Registry-Metadaten (listSecretTargetRegistryEntries()) ein gesampeltes Ziel pro SecretRef-Klasse ab und asserted dann, dass Exec-IDs mit Traversal-Segmenten abgelehnt werden.
    • Wenn Sie in src/secrets/target-registry-data.ts eine neue includeInPlan-SecretRef-Zielfamilie hinzufügen, aktualisieren Sie classifyTargetClass in diesem Test. Der Test schlägt bei nicht klassifizierten Ziel-IDs absichtlich fehl, damit neue Klassen nicht stillschweigend übersprungen werden können.

Verwandt