OpenClaw Parallels Smoke

Was macht OpenClaw Parallels Smoke?

Verwenden Sie dieses Skill für Workflows mit Parallels-Gästen und Smoke-Interpretation. Laden Sie es nicht für normale Repository-Arbeit.

Globale Regeln

• Parallels ist standardmäßig eine Postpublish-Confidence-Abdeckung, keine Voraussetzung für die eingeschränkte Beta-Publish-Phase. Führen Sie es gegen eine exakte veröffentlichte Paketversion aus und zeichnen Sie das Validierungs-SHA + Tooling-SHA-Lauf-Tupel auf, das dieses Paket autorisiert hat. Validierungs-SHA wird seinem Code-SHA oder Release-SHA zugeordnet; es ist keine dritte Release-Identität.
• Eine fehlgeschlagene Postpublish-Parallels-Spur macht eine Beta nicht rückwirkend ungültig. Klassifizieren Sie sie als Produkt-, Werkzeug-/Provenienz-, Infrastruktur-/Berechtigungs- oder Wrapper-Fehler. Nur ein bestätigter Produktfehler geht in die nächste Beta ein.
• Verwenden Sie einen Koordinator und eine Spur pro unabhängiger Gastfamilie. Diagnostizieren und wiederholen Sie eine fehlgeschlagene Familie einmal, dann bewerten Sie neu; starten Sie die Gesamtmatrix nicht automatisch neu.
• Überprüfen Sie vorhandene VMs und Snapshots, bevor Sie etwas bereitstellen. Wenn ein vorkonfigurierter, unberührter Snapshot mit der angeforderten Basislinie übereinstimmt, wechseln Sie zu diesem und verwenden Sie dessen Benutzer, Tools und Basissetup weiter. Erstellen Sie keine neue VM, installieren Sie macOS nicht neu oder bauen Sie die Gast-Basislinie für einen „frischen“ Lauf nicht neu auf.
• „Frisch“ bedeutet, den nächstgelegenen vorhandenen unberührten Snapshot wiederherzustellen, keinen weiteren Snapshot zu erstellen. Erstellen Sie keine Ad-hoc-Snapshots, es sei denn, der Benutzer fordert dies explizit an oder es existiert keine geeignete Basislinie; stellen Sie den ursprünglichen Snapshot wieder her und lassen Sie den Gast nach einem Ad-hoc-Lauf gestoppt.
• Überprüfen Sie den Snapshot-Status, bevor Sie ihn wiederherstellen. Ein unberührter poweron-Snapshot kann die vorkonfigurierte angemeldete Sitzung enthalten; wechseln Sie normal zu diesem, damit Parallels diese Sitzung fortsetzt. Übergeben Sie --skip-resume nur dann am Testeinstieg, wenn der Lauf absichtlich die gespeicherte Sitzung verwerfen und vom Anmeldefenster aus booten soll. --skip-resume ist akzeptabel für die endgültige Bereinigung, die den wiederhergestellten Quell-Gast gestoppt hinterlassen muss.
• Die Gateway-Überprüfung in Smoke-Läufen sollte openclaw gateway status --deep --require-rpc verwenden, es sei denn, die getestete stabile Version unterstützt dies noch nicht.
• Stabile 2026.3.12 Pre-Upgrade-Diagnostik kann einen einfachen gateway status --deep-Fallback erfordern.
• Behandeln Sie precheck=latest-ref-fail auf dieser stabilen Pre-Upgrade-Spur als Basislinie, nicht automatisch als Regression.
• Übergeben Sie --json für maschinenlesbare Zusammenfassungen.
• Phasenlogs landen standardmäßig unter .artifacts/parallels/openclaw-parallels-*. Überschreiben Sie mit OPENCLAW_PARALLELS_ARTIFACT_ROOT, wenn ein Lauf ein anderes Artefakt-Volume benötigt.
• Führen Sie keine lokalen und Gateway-Agenten-Turns parallel im selben frischen Arbeitsbereich oder Sitzung aus.
• Begrenzen Sie jede Top-Level-Parallels-Spur hart mit dem Host-timeout --foreground (oder gtimeout --foreground, falls dieser Binary verfügbar ist), so dass eine blockierte Installation, ein Snapshot-Wechsel oder ein prlctl exec-Transport nicht den Rest des Testfensters verbrauchen kann. Standardeinstellungen:
  • macOS: 75m
  • Linux: 75m
  • Windows: 90m
  • Aggregat-npm-Update-Wrapper: 150m Wenn eine Spur die Grenze erreicht, stoppen Sie dort, überprüfen Sie das neueste /tmp/openclaw-parallels-*-Laufverzeichnis und das Phasenlog, dann beheben oder wiederholen Sie die kleinste betroffene Spur. Warten Sie nicht auf eine begrenzte Spur.
• Tatsächliche OpenClaw npm-Install-/Update-Phasen sind ein strengeres Signal als Spur-grenzen: Installationsphasen sollten normalerweise innerhalb von 7 Minuten abschließen, und Update-Phasen sollten normalerweise innerhalb von 5 Minuten sinnvollen Fortschritt zeigen. Wenn eine Phase namens install-main, install-latest, install-baseline oder install-baseline-package 420s überschreitet, oder eine Phase namens update-dev / gleich-Gast openclaw update 300s ohne neue Marker überschreitet, beginnen Sie die Diagnose von diesem Phasenlog und Gast-Prozesszustand. Aktuelle Windows-Update-Phasen können nach etwa 10-15 Minuten noch bestehen, da doctor --fix gebündelte Plugin-Laufzeitabhängigkeiten installieren kann; halten Sie das Skript-Hard-Limit nahe 20 Minuten, es sei denn, das Log ist wirklich veraltet.
• Für eine vollständige OS-Matrix bevorzugen Sie parallele Ausführung unabhängiger Gastfamilien-Spuren, wenn die Host-Kapazität dies erlaubt:
  • timeout --foreground 75m pnpm test:parallels:macos -- --json
  • timeout --foreground 90m pnpm test:parallels:windows -- --json
  • timeout --foreground 75m pnpm test:parallels:linux -- --json Halten Sie jede Spur in ihrer eigenen Shell/Sitzung und verfolgen Sie das Laufverzeichnis für jede. Bevor Sie die Matrix starten, führen Sie alle erforderlichen Host-Build-/Paket-Gates bis zum Abschluss aus. Wenn ein aktuelles Main-tgz-Paket benötigt wird, halten die Smoke-Skripte einen gemeinsamen Paket-Sperre durch pnpm build, Inventory/Staging und npm pack; wenn diese Sperre fehlt oder defekt ist, serialisieren Sie die Matrix anstatt gleichzeitige dist-Mutationen zu akzeptieren.
• Führen Sie nicht mehrere Smoke-Spuren gegen dieselbe Gastfamilie gleichzeitig aus. Tahoe-Spuren teilen sich den Host-HTTP-Port, und Windows/Linux-Spuren können bei Snapshot-Restore/Start-Status kollidieren, wenn zwei Jobs dieselbe VM gleichzeitig berühren.
• Führen Sie den aggregierten pnpm test:parallels:npm-update-Wrapper nicht parallel zu einzelnen macOS/Windows/Linux-Smoke-Spuren aus; er berührt dieselben Gastfamilien und Snapshots.
• Starten Sie keine Parallels-Spuren, während ein nicht zusammenhängender Host-Befehl dist neu erstellen, bereinigen oder neu einstufen könnte (pnpm build, pnpm ui:build, pnpm release:check, pnpm test:install:smoke, npm pack/install smoke oder Docker-Spuren, die Paket-/Build-Vorbereitung durchführen). Führen Sie zuerst nicht zusammenhängende Build-/Paket-Gates aus, lassen Sie sie beenden, dann starten Sie die VM-Matrix. Gleichzeitige dist-Mutation kann Host-npm pack mit fehlenden Dateien zum Scheitern bringen und verschwendet einen gesamten VM-Zyklus.
• Während der Ausführung oder Optimierung der Matrix zeichnen Sie die Wanduhrzeit pro Spur und die langsamste Phase aus den /tmp/openclaw-parallels-*-Logs auf. Verwenden Sie dieses Timing, bevor Sie die Smoke-Reihenfolge, Timeouts oder Helper-Verhalten ändern.
• Wenn ein Host-Build verfolgte generierte Dateien ändert, stoppen Sie, bevor Sie VM-Zeit aufwenden. Festschreiben Sie das generierte Artefakt separat oder beheben Sie die Generator-Abweichung, dann wiederholen Sie die kleinste betroffene Spur.
• Wenn main sich unter aktiver Multi-Agent-Arbeit bewegt, bevorzugen Sie einen abgetrennten Arbeitsbaum, der für lange Parallels-Suiten an einen Festschreibung angepinnt ist. Die Smoke-Skripte überprüfen jetzt den gepackten tgz-Festschreibung anstatt des Live-git rev-parse HEAD, aber ein angepinnten Arbeitsbaum vermeidet immer noch störenden Neubau-/Versionsdrift während Wiederholungen.
• Denken Sie bei openclaw update --channel dev-Spuren daran, dass der Gast GitHub main klont, nicht Ihren lokalen Arbeitsbaum. Wenn eine lokale Behebung existiert, aber die Wiederholung immer noch innerhalb des geklonten Dev-Checkouts fehlschlägt, behandeln Sie dies nicht als Widerlegung der Behebung, bis der Branch gepusht wurde.
• Übergeben Sie bei prlctl exec den VM-Namen vor --current-user (prlctl exec "$VM" --current-user ...), nicht umgekehrt.
• Wenn der Workflow OpenClaw aus einem Repo-Checkout installiert anstatt über den Site-Installer/npm-Release, beenden Sie mit der Installation eines echten Gast-CLI-Shims und überprüfen Sie ihn in einer frischen Gast-Shell. pnpm openclaw ... im Repo reicht nicht für die Übergabeparität.
• Bevorzugen Sie auf macOS-Gästen eine benutzerglobale Installation plus einen stabilen, im PATH sichtbaren Shim:
  • installieren mit NPM_CONFIG_PREFIX="$HOME/.npm-global" npm install -g .
  • stellen Sie sicher, dass ~/.local/bin/openclaw existiert oder ~/.npm-global/bin im PATH ist
  • überprüfen Sie von einer brandneuen Gast-Shell mit which openclaw und openclaw --version

npm installieren und dann updaten

• Bevorzugter Einstiegspunkt: pnpm test:parallels:npm-update
• Für einen macOS-only-Published-Release-Update-Check verwenden Sie:
  • timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@<old-version> --update-target <target-version-or-tag> --json Dies behält die Abdeckung des gleich-Gast-openclaw update --tag ... bei und verwendet den gemeinsamen macOS-Current-User/Sudo-Fallback, ohne Windows/Linux-Spuren zu starten.
• Erforderliche Abdeckung: Jeder Release/Update-Regressionslauf muss beide Spuren enthalten:
  • frischer Snapshot -> installiere angefordertes Paket/Basislinie -> Smoke
  • gleiche Gast-Basislinie -> führe den installierten openclaw update ...-Befehl des Gasts aus -> Smoke erneut
• Die Update-Spur muss OpenClaws internen Updater üben. Zählen Sie eine direkte npm install -g <tgz-or-spec>- oder Harness-seitige Paket-Swap nicht als Update-Flow-Abdeckung; diese sind nur Install-Smokes.
• Für veröffentlichte Ziele installieren Sie zuerst das alte Basispaket (z. B. [email protected]), dann führen Sie die installierte Gast-CLI mit dem beabsichtigten Kanal/Tag aus (z. B. openclaw update --channel beta --yes --json) und überprüfen Sie openclaw --version, openclaw update status --json, Gateway-RPC und einen Agenten-Turn nach dem Befehl.
• Für unveröffentlichte Ziele packen Sie den Kandidaten auf dem Host, servieren Sie das .tgz über den Harness-HTTP-Server und weisen Sie den Gast-Updater auf dieses servierte Paket. Bevorzugen Sie openclaw update --tag http://<host-ip>:<port>/openclaw-<version>.tgz --yes --json; wenn auch die Kanalpersistenz wichtig ist, übergeben Sie --channel <stable|beta> und setzen Sie OPENCLAW_UPDATE_PACKAGE_SPEC auf dieselbe servierte URL in der Gast-Update-Umgebung. Der zu testende Befehl muss immer noch openclaw update sein, nicht direkt npm.
• Denken Sie bei unveröffentlichter lokaler Behebungsvalidierung daran, dass der alte Basislinien-Updater-Code immer noch den ersten Hop kontrolliert. Eine Behebung, die nur im neuen Updater-Code lebt, kann diesen bereits laufenden alten Prozess nicht ändern; der servierte Kandidat muss entweder Paket-/Plugin-Metadaten kompatibel mit dem Basislinien-Host halten oder die Basislinie selbst muss die Updater-Behebung enthalten.
• Für Beta/Stable-Überprüfung lösen Sie das Tag unmittelbar vor dem Lauf auf (npm view openclaw@beta version dist.tarball oder npm view openclaw@latest ...). Tags können sich verschieben, während eine lange VM-Matrix bereits läuft; starten Sie die Matrix neu, wenn die beabsichtigte Prerelease nach einem früheren Registry-404/Tag-Lag-Check erscheint.
• Verwenden Sie den konfigurierten Secret-Workflow, um nur die von den OpenAI/Anthropic-Spuren benötigten Provider-Keys einzuspritzen. Drucken Sie keine Secrets oder Env-Dumps; übergeben Sie Provider-Secrets über die Gast-Exec-Umgebung.
• Die gleich-Gast-Aktualisierungsüberprüfung sollte das Standardmodell explizit auf openai/gpt-5.4 setzen, bevor der Agenten-Turn beginnt, und eine frische explizite --session-id verwenden, damit alter Sitzungsmodellstatus nicht in die Überprüfung einfließt.
• Der aggregierte npm-Update-Wrapper muss die Linux-VM mit derselben Ubuntu-Fallback-Richtlinie wie parallels-linux-smoke.sh auflösen, bevor sowohl frische als auch Update-Spuren erfolgen. Behandeln Sie jeden Ubuntu-Gast mit Hauptversion >= 24 als akzeptabel, wenn die genaue Standard-VM fehlt, und bevorzugen Sie den neuesten versionierten Ubuntu-Gast mit einem frischen Poweroff-Snapshot. Auf Peters aktuellem Host verwenden Sie heute Ubuntu 26.04.
• Starten Sie bei gleich-Gast-Aktualisierungsüberprüfungen unter macOS das Gateway nach dem npm-Upgrade neu, bevor gateway status / agent erfolgt; launchd kann andernfalls einen geladenen Dienst melden, während der alte Prozess beendet wurde und der frische Prozess noch nicht RPC-bereit ist.
• Das macOS-Aktualisierungsbein des npm-Update-Aggregats schreibt das Gast-Update-Skript als root und führt es dann als Desktop-Benutzer aus. Wenn prlctl exec "$MACOS_VM" --current-user ... nicht authentifizieren kann, wiederholen Sie durch einfaches prlctl exec als root plus sudo -u <desktop-user> /usr/bin/env HOME=/Users/<desktop-user> USER=<desktop-user> LOGNAME=<desktop-user> PATH=/opt/homebrew/bin:/opt/homebrew/opt/node/bin:/usr/bin:/bin:/usr/sbin:/sbin .... Dies ist ein Parallels-Transport-Fallback; überprüfen Sie trotzdem openclaw --version, Gateway-RPC und einen Agenten-Turn nach dem Update.
• Starten Sie bei gleich-Gast-Aktualisierungsüberprüfungen unter Windows das Gateway nach dem npm-Upgrade neu, bevor gateway status / agent erfolgt; In-Place-globale npm-Updates können andernfalls alte gehashte dist/* Modulimporte im laufenden Dienst lebendig lassen.
• Behandeln Sie bei diesen gleich-Gast-Aktualisierungsüberprüfungen unter Windows einen einzelnen nicht-null openclaw gateway restart nicht als endgültigen Fehler. Aktuelle Login-Item-Neustarts können einen Fehler melden, bevor der Hintergrunddienst wieder beobachtbar wird; folgen Sie mit einer längeren RPC-bereit-Wartezeit und verwenden Sie gateway start nur als Wiederherstellungsschritt, wenn die Bereitschaft immer noch nicht zurückkehrt.
• Vertrauen Sie nach diesem Windows-Neustart nicht einer einzigen gateway status --deep --require-rpc-Aufruf nach einem festen Sleep. Wiederholen Sie die RPC-bereit-Sonde für ungefähr 30 Sekunden und protokollieren Sie jeden Versuch; aktuelle Gäste können Port 18789 gebunden halten, während der frische RPC-Endpunkt noch hochkommt.
• Bevorzugen Sie bei gleich-Gast-Aktualisierungsüberprüfungen unter Windows das Done-File/Log-Drain-PowerShell-Runner-Muster über einen einzigen langlebigen prlctl exec ... powershell -EncodedCommand ...-Transport. Der Gast kann erfolgreich abschließen, während das äußere prlctl exec noch hängt.
• Der Windows-Gleich-Gast-Update-Helfer sollte Stufenmarker in sein Log schreiben, bevor lange Schritte wie tgz-Download und npm install -g beginnen, damit der äußere Fortschrittsmonitor nicht bei waiting for first log line während gesunder, aber leiser Installationen sitzen bleibt.
• Die Linux-Gleich-Gast-Update-Überprüfung sollte auch HOME=/root exportieren, OPENAI_API_KEY über prlctl exec ... /usr/bin/env übergeben und openclaw agent --local verwenden; die frische Linux-Basislinie verlässt sich nicht auf persistierte Gateway-Berechtigungen.
• Der npm-Update-Wrapper gibt jetzt pro-Spur-Fortschritt aus den verschachtelten Log-Dateien aus. Wenn eine Spur immer noch feststeckt, überprüfen Sie zuerst die verschachtelten Logs in runDir (macos-fresh.log, windows-fresh.log, linux-fresh.log, macos-update.log, windows-update.log, linux-update.log), anstatt anzunehmen, dass der äußere Wrapper hing.
• Jeder Lauf schreibt sowohl summary.json als auch summary.md; lesen Sie zuerst das Markdown für schnelles menschliches Triage, dann das JSON/Timing für Automatisierung.
• Für vollständige Beta-Validierung, nachdem ein Tag veröffentlicht wurde, bevorzugen Sie einen Befehl:
  • timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json Dies löst beta3 in die neueste *-beta.3 Version auf, führt aktuelle->diese Version gleich-Gast-Update-Abdeckung durch und führt dann frische Install-Smokes für dieses exakte veröffentlichte Ziel auf derselben ausgewählten OS-Matrix aus. Verwenden Sie --platform macos|windows|linux, um Wiederholungen einzuschränken.
• Für Beta 4 npm-Validierung mit Agenten-Turns ist die bekannte gute Form:
  • gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai/gpt-5.4 --json Bevorzugen Sie den expliziten beta4-Alias gegenüber openclaw@beta, wenn Sie eine bestimmte Prerelease-Nummer validieren; npm-Tags können sich verschieben.
• Wenn der Wrapper eine Spur fehlschlägt, lesen Sie zuerst den automatisch abgeworfenen Tail, dann das vollständige verschachtelte Log in runDir/<spur>.log. Suchen Sie nach Phase-Fehlern, vergessenen Provider-Keys fehlerhaften Timeout-Phasen oder veralteten Snapshots, die nicht mehr zur aktuellen Tool-Version passen, und stellen Sie dann die Spur entweder durch Ändern der Wrapper-Optionen oder durch Beheben der zugrunde liegenden Gast-/Snapshot-Voraussetzung wieder her. Starten Sie nicht blind die gesamte Matrix neu, bevor Sie verstehen, warum die anfängliche Spur fehlgeschlagen ist.

MacOS

• Bevorzugter Einstiegspunkt: pnpm test:parallels:macos
• Für einen macOS-only-Testlauf eines bestimmten installierten Pakets ohne Aktualisierung verwenden Sie:
  • timeout --foreground 75m pnpm test:parallels:macos -- --json --package-spec openclaw@<version>
• Das Smoke-Skript unter macOS sucht zuerst nach einer VM namens macOS im Parallels-Katalog. Wenn keine vorhanden ist, sucht es nach macOS 15 und schlägt fehl, wenn keine gefunden wird. Stellen Sie sicher, dass die richtige VM in den Parallels Desktop-Einstellungen konfiguriert ist.
• Das Skript sucht dann nach einem Snapshot mit dem Namen pristine-poweron, der die vorkonfigurierte Desktop-Sitzung enthält.
• Nach Abschluss stellt der Lauf den Snapshot auf pristine-poweron zurück und lässt den Gast gestoppt, sofern nicht anders angegeben.

Windows

• Bevorzugter Einstiegspunkt: pnpm test:parallels:windows
• Für einen Windows-only-Testlauf eines bestimmten installierten Pakets ohne Aktualisierung verwenden Sie:
  • timeout --foreground 90m pnpm test:parallels:windows -- --json --package-spec openclaw@<version>
• Das Smoke-Skript unter Windows sucht zuerst nach einer VM namens Windows im Parallels-Katalog. Wenn keine vorhanden ist, sucht es nach Windows 11 und schlägt fehl, wenn keine gefunden wird. Stellen Sie sicher, dass die richtige VM in den Parallels Desktop-Einstellungen konfiguriert ist.
• Das Skript sucht dann nach einem Snapshot mit dem Namen pristine-poweron, der die vorkonfigurierte Desktop-Sitzung enthält.
• Nach Abschluss stellt der Lauf den Snapshot auf pristine-poweron zurück und lässt den Gast gestoppt, sofern nicht anders angegeben.

Linux

• Bevorzugter Einstiegspunkt: pnpm test:parallels:linux
• Für einen Linux-only-Testlauf eines bestimmten installierten Pakets ohne Aktualisierung verwenden Sie:
  • timeout --foreground 75m pnpm test:parallels:linux -- --json --package-spec openclaw@<version>
• Das Smoke-Skript unter Linux sucht zuerst nach einer VM namens Ubuntu im Parallels-Katalog. Wenn keine vorhanden ist, sucht es nach Ubuntu 26.04 und schlägt fehl, wenn keine gefunden wird. Stellen Sie sicher, dass die richtige VM in den Parallels Desktop-Einstellungen konfiguriert ist.
• Das Skript sucht dann nach einem Snapshot mit dem Namen pristine-poweroff, der die vorkonfigurierte Ubuntu-Installation enthält, die noch nicht ausgeführt wurde.
• Nach Abschluss stellt der Lauf den Snapshot auf pristine-poweroff zurück und lässt den Gast gestoppt, sofern nicht anders angegeben.

Fehlerbehebung

• Wenn ein Lauf aufgrund eines fehlenden Snapshots fehlschlägt, überprüfen Sie das Parallels Desktop-GUI, um sicherzustellen, dass die richtigen VMs und Snapshots vorhanden sind.
• Wenn prlctl exec fehlschlägt, überprüfen Sie, ob der Gast läuft und ob die Parallels-Tools installiert sind.
• Wenn ein Update-Lauf fehlschlägt, überprüfen Sie das verschachtelte Log in runDir auf den genauen Fehler, z. B. vergessene Provider-Keys, Netzwerkkonnektivität oder Korruption der NPM-Installation.
• Wenn der Wrapper hängt, überprüfen Sie die verschachtelten Logs auf feststeckende Phasen, z. B. install-main, die 420s überschreitet, oder update-dev, die 300s ohne neuen Fortschritt überschreitet.
• Wenn ein Snapshot nicht wiederhergestellt werden kann, überprüfen Sie, ob der Gast ausgeschaltet ist und ob der Snapshot existiert. Wenn nicht, erstellen Sie den Snapshot manuell oder verwenden Sie den Standard-Snapshot.