OpenClaw Vorab-Release Plugin-Testing

Was macht OpenClaw Vorab-Release Plugin-Testing?

Verwenden Sie diese Fähigkeit, wenn der Benutzer nach Plugin-Release-Sicherheit, Plugin-Lebenszyklus-Sweeps, Paketartefakt-Plugin-Nachweisen oder „Was sollten wir noch vor dem Release testen?“ fragt. Sie ergänzt openclaw-testing; nutzen Sie auch diese Fähigkeit, wenn Sie den günstigsten sicheren Runner auswählen oder eine fehlschlagende Lane debuggen.

Ziel

Nachweisen, dass das Plugin-System als Produktoberfläche funktioniert, nicht nur als Quellcode-Tests:

• Lebenszyklus gebündelter Plugins: installieren, inspizieren, aktivieren, deaktivieren, deinstallieren
• Paketartefakt-Verhalten in einem sauberen HOME
• Doctor/Fix/Konfigurationsvalidierung und Idempotenz
• Konfigurationserkennung und Konfigurationsrundgang
• Status-/Log-Sichtbarkeit und Diagnostik
• Gateway-Start/Bootstrap mit Plugin-Metadaten-Snapshots
• Öffentliche SDK-Kompatibilität für echte externe Plugins
• Live-ähnliche Provider-/Kanal-Abfragen nur, wenn sichere Anmeldeinformationen vorhanden sind

Erste Prüfungen

Aus dem OpenClaw-Repository-Stammverzeichnis:

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

In Codex-Worktrees unter .codex/worktrees muss node_modules ein Symlink zum Haupt-OpenClaw-Checkout sein. Führen Sie dort nicht pnpm install aus. Für breite oder paketlastige Nachweise verwenden Sie Blacksmith Testbox oder GitHub Actions.

Runner-Auswahl

Bevorzugen Sie diese Reihenfolge:

1. GitHub Package Acceptance für produktnahen Installationsnachweis von installierbaren Paketen.
2. ci-build-artifacts-testbox.yml Testbox, wenn Docker-/Paket-Lanes mit dist, dist-runtime und Paket-Caches gefüllt werden müssen.
3. ci-check-testbox.yml Testbox für Quellcode-Prüfungen, gezielte Vitest-Tests, Paketgrenzen-Prüfungen oder fokussierte Docker-Lanes.
4. Lokale gezielte Befehle nur für kleine Format-/Static-/Unit-Abfragen.

Vermeiden Sie lange Paket-Docker-Ausführungen aus einem veralteten spärlichen Worktree. Wenn die Testbox-Synchronisation Hunderte von geänderten Dateien meldet oder beginnt, Paket-Eingaben zu löschen, stoppen Sie und holen Sie eine frische Box vom aktuellen main, oder wechseln Sie zu Package Acceptance.

Vorhandene Basislinie

Führen Sie diese aus oder überprüfen Sie sie, bevor Sie neue Abdeckung erfinden:

OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm run test:extensions:package-boundary:canary
pnpm run test:extensions:package-boundary:compile
pnpm test:docker:plugins
OPENCLAW_PLUGINS_E2E_CLAWHUB=0 pnpm test:docker:plugins
pnpm test:docker:plugin-update
pnpm test:docker:bundled-channel-deps:fast

Für den vollständigen Installations-/Deinstallationsnachweis gebündelter Plugins verteilen Sie den Sweep:

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

Erwartete aktuelle Paketabdeckung: 116 öffentliche gebündelte Plugins über Shards 0–7. Private QA-Plugins sind nur im Quellmodus, es sei denn, ein Paket schließt sie explizit ein.

Vertrauensmatrix

Verwenden Sie diese Matrix für die Vorab-Freigabe. Erfassen Sie Erfolg/Fehlschlag, Run-URL/Testbox-ID, Paket-SHA/Version und Grund für ausgelassene Live-Tests.

Oberfläche	Nachweis	Bevorzugter Runner
Paketartefakt	Package Acceptance suite_profile=package oder benutzerdefinierte Lanes	GitHub Actions
Gebündelter Lebenszyklus	8-Shard test:docker:bundled-plugin-install-uninstall	Testbox oder Release Docker
Externe Plugins	test:docker:plugins und plugins-offline	Testbox/Package Acceptance
Update ohne Änderung	test:docker:plugin-update	Testbox/Package Acceptance
Channel-Laufzeitabhängigkeiten	test:docker:bundled-channel-deps:fast plus wichtige Channels	Testbox/Package Acceptance
Doctor/Fix	Gesäte fehlerhafte Konfigurationen + doctor --fix --non-interactive	Neue Docker/Testbox-Harness
Konfigurationsrundgang	config set/get, inspect, doctor, reload, diff hash	Neue Docker/Testbox-Harness
Gateway-Bootstrap	Sauberes HOME, Plugin-Gruppen aktiviert/deaktiviert, Status-JSON	Neue Docker/Testbox-Harness
SDK-Kompatibilität	Verzeichnis-, tgz- und file:-externe Plugins mit SDK-Unterpfaden	test:docker:plugins plus neuer Smoke
Live-ähnlich	Geschwärzte Provider-/Kanal-Abfragen nur für vorhandene Umgebung	Testbox Live-Lanes

Plan für Package Acceptance

Verwenden Sie dies, wenn Sie einen Release-Branch, eine Beta oder ein Kandidatenpaket validieren:

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=<branch-oder-sha> \
  -f suite_profile=custom \
  -f docker_lanes='plugins-offline plugin-update bundled-channel-deps-compat doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
  -f telegram_mode=mock-openai

Verwenden Sie source=npm -f package_spec=openclaw@beta für einen Nachweis der veröffentlichten Beta. Behalten Sie workflow_ref als vertrauenswürdigen aktuellen Harness-Code bei, es sei denn, der Release-Prozess sagt etwas anderes.

Plan für neue Testbox-Harness

Falls mehr Sicherheit erforderlich ist, fügen Sie eine Docker-Lane plugin-lifecycle-matrix hinzu oder führen Sie sie aus, die ein Paket-Tarball und verteilte Plugin-Listen verwendet. Pro Plugin:

1. Starten Sie mit einem sauberen HOME.
2. Erfassen Sie plugins list --json.
3. plugins install <id>.
4. plugins inspect <id> --json.
5. plugins disable <id>, dann bestätigen Sie die deaktivierte Sichtbarkeit.
6. plugins enable <id>, außer bei konfigurationserfordernden Plugins ohne Konfiguration.
7. plugins registry --refresh.
8. doctor --non-interactive.
9. plugins uninstall <id> --force.
10. Bestätigen Sie, dass kein Konfigurationseintrag, allow/deny-Rückstand, Installationsdatensatz, verwaltetes Verzeichnis oder gebündelter dist/extensions/...-Ladepfad übrig bleibt.
11. Bestätigen Sie, dass die Diagnostik kein level: "error" enthält und die Ausgabe geheimnisaussehende Werte schwärzt.

Behandeln Sie memory-lancedb speziell: es ist konfigurationserfordernd. Bestätigen Sie zuerst, dass die Installation es ohne eingebettete Konfiguration nicht aktiviert, führen Sie dann einen zweiten konfigurierten Fall aus.

Doctor/Fix-Matrix

Säen Sie fehlerhafte Zustände und verlangen Sie, dass doctor --fix --non-interactive sie repariert, führen Sie dann doctor erneut aus und verlangen Sie Idempotenz:

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

Gateway-Bootstrap-Matrix

Starten Sie gepacktes OpenClaw in Docker mit sauberem Zustand:

• Provider-Plugins aktiviert, keine Anmeldeinformationen: bereit mit Warnungen, kein Absturz
• Channel-Plugins als deaktiviert konfiguriert: keine Laufzeitabhängigkeiten bereitgestellt
• Startaktivierungs-Plugins aktiviert: bereit und im Status reflektiert
• Ungültige einzelne Plugin-Konfiguration: fehlerhaftes Plugin übersprungen/in Quarantäne, andere bleiben erhalten

Bestätigen Sie:

• Gateway erreicht den Zustand „bereit“
• openclaw status --json enthält Plugin-Diagnostik
• openclaw plugins inspect --all --json ist parsebar
• Paketbaum wird nicht verändert
• Logs enthalten keine rohen Tokens

Repräsentanten für Konfigurationsrundgang

Verwenden Sie repräsentative Plugin-Familien statt jedes Plugins für tiefe Konfigurationsrundgänge:

• Provider: openai, anthropic, mistral, openrouter
• Channels: telegram, discord, slack, whatsapp
• Speicher: memory-lancedb
• Feature/Laufzeit: browser, acpx, tokenjuice

Für jeden Repräsentanten:

1. Schreiben Sie Konfiguration über die CLI, wenn möglich.
2. Lesen Sie sie über config get oder JSON zurück.
3. Führen Sie plugins inspect aus.
4. Führen Sie doctor --non-interactive aus.
5. Lösen Sie gegebenenfalls einen Gateway-Konfigurationsneulad aus.
6. Vergleichen Sie den Konfigurations-Hash vor und nach No-Op-Befehlen.

Externer SDK-Smoke

Erstellen Sie in einer Paket-Docker-Lane winzige externe Plugins und installieren Sie sie von:

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

Decken Sie CJS- und ESM-Formen ab, sowie mindestens ein Plugin, das fokussierte openclaw/plugin-sdk/*-Unterpfade importiert. Bestätigen Sie, dass plugins inspect dessen Tool, Gateway-Methode, CLI-Befehl oder Dienst sieht.

Regeln für Live-ähnliche Abfragen

Bevor Sie live-ähnliche Arbeit durchführen, quellen Sie erlaubte Umgebung in Testbox und generieren Sie eine geschwärzte Verfügbarkeitsmatrix: nur vorhanden/fehlend, niemals Werte.

Führen Sie Abfragen nur für Anmeldeinformationen aus, die existieren. Bevorzugen Sie Auth-/Katalog-/Status-Abfragen gegenüber dem Senden von benutzersichtbaren Nachrichten. Wenn eine Abfrage einen externen Benutzer, Channel oder Arbeitsbereich kontaktieren könnte, stoppen Sie und fragen Sie den Benutzer.

Berichterstattung

Berichten Sie in dieser Form:

package/ref:
tbx ids / run urls:
matrix:
  gebündelter Lebenszyklus:
  Paketakzeptanz:
  doctor/fix:
  gateway-bootstrap:
  konfigurationsrundgang:
  sdk-extern:
  live-ähnlich:
fehlschläge:
auslassungen:
nächste lücke mit höchstem Wert:

Sagen Sie klar, wenn ein Fehlschlag auf Testbox-Synchronisations-/Umgebungsschäden und nicht auf Produktverhalten zurückzuführen ist, und beweisen Sie dies mit einem sauberen erneuten Lauf oder einem Vergleich mit aktuellen main.