OpenClaw Pre-Release Plugin Testing

Was macht OpenClaw Pre-Release Plugin Testing?

Verwende diese Skill, wenn der Benutzer nach Plugin-Release-Sicherheit, Plugin-Lebenszyklus-Sweeps, Paketartefakt-Plugin-Prüfungen fragt oder "Was sollten wir noch vor dem Release testen?". Sie ergänzt openclaw-testing; verwende auch diese Skill, wenn du den günstigsten sicheren Runner auswählst oder einen fehlschlagenden Lane debuggen möchtest.

Ziel

Das Plugin-System als Produkt-Surface beweisen, nicht nur als Source-Tests:

• Gebündelter Plugin-Lebenszyklus: installieren, inspizieren, aktivieren, deaktivieren, deinstallieren
• Paketartefakt-Verhalten aus einem sauberen HOME
• Doctor/Fix/Konfigurationsvalidierung und Idempotenz
• Konfigurationserkennung und Konfigurations-Roundtrip
• Status/Log-Sichtbarkeit und Diagnostik
• Gateway-Start/Bootstrap mit Plugin-Metadaten-Snapshots
• Öffentliche SDK-Kompatibilität für echte externe Plugins
• Live-Provider/Channel-Probes nur bei sicheren Anmeldedaten

Erste Prüfungen

Vom OpenClaw-Repository-Root aus:

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

Folge openclaw-testing für Dependency-Besitz und die Wahl zwischen lokalem oder Remote-Proof.

Runner-Auswahl

Bevorzuge diese Reihenfolge:

1. GitHub Package Acceptance für installierbare Paket-Produktprüfung.
2. Aktueller dedizierter Linux-Worker für vertrauenswürdigen Source/Paket/Docker-Proof, wenn er über die erforderlichen Abhängigkeiten und Fähigkeiten verfügt.
3. ci-build-artifacts-testbox.yml Testbox wenn Docker/Paket-Lanes dist, dist-runtime und Paket-Caches benötigen.
4. ci-check-testbox.yml Testbox für Source-Prüfungen, gezielte Vitest-Tests, Paketgrenzenprüfungen oder fokussierte Docker-Lanes.
5. Workstation-gezielte Befehle nur für kleine Format-/Statik-/Unit-Probes.

Vermeide lange Paket-Docker-Läufe aus einem veralteten spärlichen Worktree. Wenn die Testbox-Synchronisation Hunderte von geänderten Dateien meldet oder beginnt, Paket-Eingaben zu löschen, stoppe und wärme eine frische Box von dem aktuellen main, oder wechsle zu Package Acceptance.

Vorhandene Basislinie

Führe diese Prüfungen durch oder verifiziere sie, bevor du neue Coverage erfindest:

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

Für vollständigen gebündelten Install/Uninstall-Proof sharde den gepackten Sweep:

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

Dieses Beispiel partitioniert das Plugin-Inventar des ausgewählten Pakets über die Shards 0-7. Private QA-Plugins sind nur im Source-Modus, es sei denn, ein Paket schließt sie explizit ein.

Vertrauensmatrix

Verwende diese Matrix für das Pre-Release-Signoff. Notiere Pass/Fail, Run-URL/Testbox-ID, Paket-SHA/Version und den Grund für übersprungene Live-Tests.

Surface	Proof	Bevorzugter Runner
Paketartefakt	Package Acceptance suite_profile=package oder benutzerdefinierte Lanes	GitHub Actions
Gebündelte Lebenszyklen	Geshardeter test:docker:bundled-plugin-install-uninstall	Testbox oder Release-Docker
Externe Plugins	test:docker:plugins und plugins-offline	Testbox/Package Acceptance
Update-No-Op	test:docker:plugin-update	Testbox/Package Acceptance
Doctor/Fix	Gesäte fehlerhafte Konfigs + doctor --fix --non-interactive	Neues Docker/Testbox-Harness
Konfigurations-Roundtrip	config set/get, inspect, doctor, reload, diff hash	Neues Docker/Testbox-Harness
Gateway-Bootstrap	Sauberes HOME, Plugin-Gruppen aktiviert/deaktiviert, Status-JSON	Neues Docker/Testbox-Harness
SDK-Kompatibilität	Verzeichnis-, tgz- und file:-externe Plugins mit SDK-Subpfaden	test:docker:plugins plus neuer Smoke
Live-ähnlich	Redigierte Provider/Channel-Probes nur für vorhandene Env	Testbox-Live-Lanes

Package-Acceptance-Plan

Full Release Validation besitzt die endgültige Kandidatenqualifikation mit Q=C und den exakten Publikations-Tarballs. Verwende Standalone-Package-Acceptance für Diagnosen oder Post-Publish-Vertrauen, nicht als Ersatz für die Kandidatenqualifikation:

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

Verwende source=npm -f package_spec=openclaw@beta für gepublishte Beta-Prüfungen. Diese eigenständigen Diagnose-/Vertrauensläufe können vertrauenswürdigen aktuellen Harness-Code verwenden; die Kandidatenqualifikation muss stattdessen den eingefrorenen Harness des Kandidaten beibehalten.

Für erweiterte stabile gemeinsame Publikation erfordere eine vollständige exakt zielgerichtete Full-Release-Validation aus dem vom zugelassenen Kandidaten verwalteten release-ci/*-Harness bei Q=C, mit vertrauenswürdiger P-Zulassung und separaten Publikationswerkzeugen. Direkte kanonische Branch- oder main-Produzenten erfüllen nicht den geschützten Publisher. Package Acceptance ist ein Post-Publish-Selektor-Smoke:

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

Notiere die aufgelöste Version. Verifiziere trotzdem jedes Paket und jeden Selektor im all-publishable-Inventar des Tags; ein Smoke ist kein Registry-Readback.

Plugin-npm-Artfakt-Qualifikation

Für einen Publikationskandidaten besitzt Full Release Validation die Plugin-npm-Artfakt-Qualifikation. Liefere seine Publikationsauswahl beim Dispatch; der übergeordnete All-Group ruft plugin-npm-release.yml im Nur-Artfakt-Modus gegen die exakte Release-SHA auf, erfordert erfolgreiches Tarball-Readback und notiert den unveränderlichen aggregierten Deskriptor in publicationArtifacts.pluginNpm. Release Prepare und Publikation müssen diesen exakten Deskriptor übernehmen, anstatt Plugins neu zu packen.

Verwende einen eigenständigen vertrauenswürdigen Workflow-Preflight nur für eine gezielte Diagnose oder eine ausgewählte Plugin-Reparatur, die außerhalb eines regulären Publikationskandidaten liegt:

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

Übergib nicht release_publish_run_id. Erfordere, dass der Workflow verify_plugin_npm_preflight erfolgreich abschließt. Notiere die Run-URL, Workflow-SHA und Source-SHA. Der Workflow erstellt zuerst das Staging-/Readback-Artfakt plugin-npm-package-source-<source-sha>-<extension-id> mit npm-pack.json, preflight-manifest.json und dem Tarball. Anschließend lädt er das endgültige Consumer-Artfakt plugin-npm-package-<extension-id>-<version>-<route>-<run-id>-<attempt> mit dem Tarball und plugin-publication-manifest.json hoch.

Notiere den endgültigen Artfaktnamen und den Digest separat. Das Manifest verwendet openclaw.plugin-publication-artifact/v1 und notiert die Ziel-SHA, Paket-Manifest-Hashes, Publikationsroute und -Policy sowie Tarball-Hashes und Inventar. Dieser eigenständige Proof ist nur eine Validierung; er autorisiert oder staged keine Publikation und kann den manifestgebundenen Deskriptor der Full Release Validation nicht ersetzen. Das Artfakt-Inventar, nicht der entpackte Source-Baum, ist die Sicherheits- und Paket-Inhaltsgrenze: Source-Only-Fixtures sind irrelevant. Paket-eigene Test- und Fixture-Pfade außerhalb der ausgelieferten Runtime- und Skill-Assets bestehen die Qualifikation nicht; die ausgelieferte Runtime bleibt sicherheitsgescannt. Gebündelte node_modules bleiben mit Dependency-Nachweisen, nicht mit Plugin-Source-Policy. Der separate trusted_publisher_preflight=true OIDC-Check erfordert ein geschütztes release-publish/<tooling-sha12>-<epoch>-Dispatch-Tag und läuft in npm-publish. Echte Publikation erfordert ebenfalls dieses Tooling-Tag; ein direkter menschlicher Dispatch wartet auf seinen npm-release-Genehmigungsjob vor der Publikation. Für eine bereits veröffentlichte Version erfordere, dass dist.integrity und dist.shasum von npm mit dem verifizierten Tarball übereinstimmen. Behandle nur fehlende oder nachweislich ältere Dist-Tags als reparierbar; neuere oder nicht vergleichbare Selektoren sind ein Blockierer.

Neuer Testbox-Harness-Plan

Wenn mehr Sicherheit erforderlich ist, füge eine plugin-lifecycle-matrix Docker-Lane hinzu oder führe sie aus und verwende dabei einen Paket-Tarball und geshardete Plugin-Listen. Pro Plugin:

1. Starte mit einem sauberen HOME.
2. Erfasse plugins list --json.
3. plugins install <id>.
4. plugins inspect <id> --json.
5. plugins disable <id>, dann behaupte deaktivierte Sichtbarkeit.
6. plugins enable <id>, außer bei konfigurationserforderlichen Plugins ohne Konfiguration.
7. plugins registry --refresh.
8. doctor --non-interactive.
9. plugins uninstall <id> --force.
10. Behaute, dass der plugins.entries-Wert des Plugins genau { enabled: false } ist, während seine Allow/Deny-Einträge, der Installationsdatensatz, das verwaltete Verzeichnis und die gebündelten Runtime-Ladepfade verschwunden sind. Verwende die vorhandenen Harness-Erwartungen des existing Harness für historische Ziele.
11. Behaute, dass die Diagnostik kein level: "error" enthält und die Ausgabe geheimnisaussehende Werte redigiert.

Behandle memory-lancedb besonders: es ist konfigurationserforderlich. Behaute zuerst, dass die Installation es nicht ohne eingebettete Konfiguration aktiviert, dann führe einen zweiten konfigurierten Fall aus.

Doctor/Fix-Matrix

Säe fehlerhafte Zustände und erfordere, dass doctor --fix --non-interactive sie repariert, dann führe doctor erneut aus und erfordere Idempotenz:

• veralteter plugins.allow
• veralteter plugins.entries
• veraltete Channel-Konfiguration für fehlendes Channel-Plugin
• ungültiger plugins.entries.<id>.config
• gepackter gebündelter Pfad in plugins.load.paths
• veraltete plugins.installs
• deaktivierte Channel-/Plugin-Konfiguration, die keine Runtime-Dependencies bereitstellen darf
• root-besitzter globaler Paketbaum, der unverändert bleiben muss

Gateway-Bootstrap-Matrix

Starte gepacktes OpenClaw in Docker mit sauberem Zustand:

• Provider-Plugins aktiviert, keine Anmeldedaten: bereit mit Warnungen, kein Absturz
• Channel-Plugins konfiguriert deaktiviert: keine Runtime-Dependencies bereitgestellt
• Startup-Aktivierungs-Plugins aktiviert: bereit und im Status widergespiegelt
• ungültige einzelne Plugin-Konfiguration: fehlerhaftes Plugin übersprungen/quarantäniert, andere bleiben erhalten

Behaupte:

• Gateway erreicht Bereitschaft
• openclaw status --json enthält Plugin-Diagnostik
• openclaw plugins inspect --all --json ist analysierbar
• Paketbaum wird nicht mutiert
• Logs enthalten keine rohen Tokens

Config-Roundtrip-Repräsentanten

Verwende repräsentative Plugin-Familien anstelle jedes Plugins für tiefgehenden Konfigurations-Roundtrip:

• Provider: openai, anthropic, mistral, openrouter
• Channels: telegram, discord, slack, whatsapp
• Memory: memory-lancedb
• Funktion/Runtime: browser, acpx, tokenjuice

Für jeden Repräsentanten:

1. Schreibe Konfiguration über die CLI, wenn möglich.
2. Lese sie zurück über config get oder JSON.
3. Führe plugins inspect aus.
4. Führe doctor --non-interactive aus.
5. Löse Gateway-Konfigurationsreload aus, falls zutreffend.
6. Vergleiche den Konfigurations-Hash vor/nach No-Op-Befehlen.

Externer SDK-Smoke

Erstelle in einer Paket-Docker-Lane winzige externe Plugins und installiere sie von:

• lokalem Verzeichnis
• .tgz
• file: npm-Spezifikation

Decke CJS- und ESM-Formen ab, plus mindestens ein Plugin, das fokussierte openclaw/plugin-sdk/*-Subpfade importiert. Behaute, dass plugins inspect sein Tool, seine Gateway-Methode, seinen CLI-Befehl oder seinen Service erkennt.

Live-Ähnliche Probe-Regeln

Bevor du live-ähnliche Arbeit durchführst, hole die erlaubte Umgebung in Testbox und generiere eine redigierte Verfügbarkeitsmatrix: nur vorhanden/fehlend, niemals Werte.

Führe nur Probes für Anmeldedaten durch, die existieren. Bevorzuge Auth-/Katalog-/Status-Probes gegenüber dem Senden von für Benutzer sichtbaren Nachrichten. Wenn eine Probe einen externen Benutzer, Channel oder Arbeitsbereich kontaktieren könnte, stoppe und frage den Benutzer.

Berichterstattung

Berichte in dieser Form:

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:

Sage klar, wenn ein Fehler auf Testbox-Sync-/Env-Schaden und nicht auf Produktverhalten zurückzuführen ist, und beweise dies mit einem sauberen erneuten Lauf oder einem aktuellen main-Vergleich.