From e5de2beed467105e88d7e3c819619451fad22eb0 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Thu, 30 Apr 2026 18:42:12 +0000 Subject: [PATCH] chore(i18n): refresh de translations --- docs/de/ci.md | 312 +++++++------- docs/de/concepts/agent-loop.md | 181 ++++---- docs/de/concepts/queue.md | 104 ++--- docs/de/help/testing.md | 734 ++++++++++++++++----------------- docs/de/reference/test.md | 113 ++--- 5 files changed, 707 insertions(+), 737 deletions(-) diff --git a/docs/de/ci.md b/docs/de/ci.md index b4519b26b..1095a1c31 100644 --- a/docs/de/ci.md +++ b/docs/de/ci.md @@ -2,74 +2,74 @@ read_when: - Sie müssen nachvollziehen, warum ein CI-Job ausgeführt wurde oder nicht - Sie untersuchen eine fehlgeschlagene GitHub Actions-Prüfung - - Sie koordinieren einen Release-Validierungslauf oder dessen erneute Ausführung -summary: CI-Jobgraph, Bereichsprüfungen, Release-Sammelprüfungen und lokale Befehlsäquivalente + - Sie koordinieren einen Release-Validierungslauf oder dessen Wiederholung +summary: CI-Jobgraph, Bereichs-Gates, Release-Dachbereiche und lokale Befehlsentsprechungen title: CI-Pipeline x-i18n: - generated_at: "2026-04-30T09:34:53Z" + generated_at: "2026-04-30T18:38:49Z" model: gpt-5.5 provider: openai - source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62 + source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd source_path: ci.md workflow: 16 --- -OpenClaw CI läuft bei jedem Push auf `main` und bei jedem Pull Request. Der `preflight`-Job klassifiziert den Diff und deaktiviert teure Lanes, wenn sich nur nicht zusammenhängende Bereiche geändert haben. Manuelle `workflow_dispatch`-Läufe umgehen das Smart Scoping absichtlich und fächern den vollständigen Graphen für Release-Kandidaten und breite Validierung auf. Android-Lanes bleiben über `include_android` opt-in. Release-exklusive Plugin-Abdeckung liegt im separaten [`Plugin-Prerelease`](#plugin-prerelease)-Workflow und läuft nur über [`Vollständige Release-Validierung`](#full-release-validation) oder einen expliziten manuellen Dispatch. +OpenClaw-CI läuft bei jedem Push nach `main` und bei jedem Pull Request. Der Job `preflight` klassifiziert den Diff und deaktiviert teure Lanes, wenn nur nicht zugehörige Bereiche geändert wurden. Manuelle `workflow_dispatch`-Läufe umgehen das intelligente Scoping absichtlich und fächern den vollständigen Graphen für Release Candidates und breite Validierung auf. Android-Lanes bleiben über `include_android` optional. Die reine Release-Abdeckung für Plugins befindet sich im separaten Workflow [`Plugin-Prerelease`](#plugin-prerelease) und läuft nur aus [`Vollständige Release-Validierung`](#full-release-validation) heraus oder durch einen expliziten manuellen Dispatch. -## Pipeline-Übersicht +## Pipeline-Überblick -| Job | Zweck | Wann er läuft | -| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- | -| `preflight` | Erkennt reine Docs-Änderungen, geänderte Scopes, geänderte Extensions und erstellt das CI-Manifest | Immer bei Nicht-Draft-Pushes und PRs | -| `security-scm-fast` | Erkennung privater Schlüssel und Workflow-Audit über `zizmor` | Immer bei Nicht-Draft-Pushes und PRs | -| `security-dependency-audit` | Abhängigkeitsfreies Produktions-Lockfile-Audit gegen npm-Advisories | Immer bei Nicht-Draft-Pushes und PRs | -| `security-fast` | Erforderliches Aggregat für die schnellen Security-Jobs | Immer bei Nicht-Draft-Pushes und PRs | -| `check-dependencies` | Produktions-Knip-Durchlauf nur für Abhängigkeiten plus Guard für die Allowlist ungenutzter Dateien | Node-relevante Änderungen | -| `build-artifacts` | Erstellt `dist/`, Control UI, Built-Artifact-Prüfungen und wiederverwendbare Downstream-Artefakte | Node-relevante Änderungen | -| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie gebündelte/Plugin-Contract/Protocol-Prüfungen | Node-relevante Änderungen | -| `checks-fast-contracts-channels` | Gesplittete Channel-Contract-Prüfungen mit stabilem aggregiertem Prüfergebnis | Node-relevante Änderungen | -| `checks-node-core-test` | Core-Node-Test-Shards, ohne Channel-, gebündelte, Contract- und Extension-Lanes | Node-relevante Änderungen | -| `check` | Gesplittetes Äquivalent zum wichtigsten lokalen Gate: Produktionstypen, Lint, Guards, Testtypen und strikter Smoke | Node-relevante Änderungen | -| `check-additional` | Architektur-, Boundary-, Extension-Surface-Guards, Package-Boundary- und Gateway-Watch-Shards | Node-relevante Änderungen | -| `build-smoke` | Built-CLI-Smoke-Tests und Startup-Memory-Smoke | Node-relevante Änderungen | -| `checks` | Verifier für Built-Artifact-Channel-Tests | Node-relevante Änderungen | -| `checks-node-compat-node22` | Node-22-Kompatibilitäts-Build und Smoke-Lane | Manueller CI-Dispatch für Releases | -| `check-docs` | Docs-Formatierung, Lint und Broken-Link-Prüfungen | Docs geändert | -| `skills-python` | Ruff + pytest für Python-gestützte Skills | Python-Skill-relevante Änderungen | -| `checks-windows` | Windows-spezifische Prozess-/Pfadtests plus Regressionen bei gemeinsamen Runtime-Import-Specifiers | Windows-relevante Änderungen | -| `macos-node` | macOS-TypeScript-Test-Lane mit den gemeinsamen Built Artifacts | macOS-relevante Änderungen | -| `macos-swift` | Swift-Lint, Build und Tests für die macOS-App | macOS-relevante Änderungen | -| `android` | Android-Unit-Tests für beide Flavors plus ein Debug-APK-Build | Android-relevante Änderungen | -| `test-performance-agent` | Tägliche Codex-Optimierung langsamer Tests nach vertrauenswürdiger Aktivität | Main-CI-Erfolg oder manueller Dispatch | +| Job | Zweck | Wann er läuft | +| -------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------- | +| `preflight` | Erkennt reine Docs-Änderungen, geänderte Scopes, geänderte Plugins und erstellt das CI-Manifest | Immer bei Nicht-Draft-Pushes und PRs | +| `security-scm-fast` | Erkennung privater Schlüssel und Workflow-Audit über `zizmor` | Immer bei Nicht-Draft-Pushes und PRs | +| `security-dependency-audit` | Abhängigkeitsfreier Audit des Produktions-Lockfiles gegen npm-Advisories | Immer bei Nicht-Draft-Pushes und PRs | +| `security-fast` | Erforderliches Aggregat für die schnellen Security-Jobs | Immer bei Nicht-Draft-Pushes und PRs | +| `check-dependencies` | Produktions-Knip-Durchlauf nur für Abhängigkeiten plus Guard für die Allowlist ungenutzter Dateien | Node-relevante Änderungen | +| `build-artifacts` | Baut `dist/`, Control UI, Prüfungen gebauter Artefakte und wiederverwendbare Downstream-Artefakte | Node-relevante Änderungen | +| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie gebündelte/Plugin-Vertrags-/Protokollprüfungen | Node-relevante Änderungen | +| `checks-fast-contracts-channels` | Geshardete Channel-Vertragsprüfungen mit stabilem aggregiertem Prüfergebnis | Node-relevante Änderungen | +| `checks-node-core-test` | Core-Node-Test-Shards, ohne Channel-, gebündelte, Vertrags- und Plugin-Lanes | Node-relevante Änderungen | +| `check` | Gesplittetes Äquivalent des lokalen Haupt-Gates: Produktions-Typen, Lint, Guards, Testtypen und strikter Smoke-Test | Node-relevante Änderungen | +| `check-additional` | Architektur-, Boundary-, Plugin-Oberflächen-Guards, Package-Boundary- und Gateway-Watch-Shards | Node-relevante Änderungen | +| `build-smoke` | Smoke-Tests für die gebaute CLI und Startup-Memory-Smoke | Node-relevante Änderungen | +| `checks` | Verifier für gebaute Artefakt-Channel-Tests | Node-relevante Änderungen | +| `checks-node-compat-node22` | Node-22-Kompatibilitäts-Build und Smoke-Lane | Manueller CI-Dispatch für Releases | +| `check-docs` | Docs-Formatierung, Lint und Prüfungen auf defekte Links | Docs geändert | +| `skills-python` | Ruff + pytest für Python-gestützte Skills | Python-Skill-relevante Änderungen | +| `checks-windows` | Windows-spezifische Prozess-/Pfadtests plus Regressionen bei gemeinsamen Runtime-Import-Specifiern | Windows-relevante Änderungen | +| `macos-node` | macOS-TypeScript-Test-Lane mit den gemeinsamen gebauten Artefakten | macOS-relevante Änderungen | +| `macos-swift` | Swift-Lint, Build und Tests für die macOS-App | macOS-relevante Änderungen | +| `android` | Android-Unit-Tests für beide Varianten plus ein Debug-APK-Build | Android-relevante Änderungen | +| `test-performance-agent` | Tägliche Codex-Optimierung langsamer Tests nach vertrauenswürdiger Aktivität | Erfolgreiche Main-CI oder manueller Dispatch | -## Fail-Fast-Reihenfolge +## Reihenfolge für schnelles Fehlschlagen -1. `preflight` entscheidet, welche Lanes überhaupt existieren. Die Logik `docs-scope` und `changed-scope` sind Schritte innerhalb dieses Jobs, keine eigenständigen Jobs. +1. `preflight` entscheidet, welche Lanes überhaupt existieren. Die Logik für `docs-scope` und `changed-scope` sind Schritte innerhalb dieses Jobs, keine eigenständigen Jobs. 2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` und `skills-python` schlagen schnell fehl, ohne auf die schwereren Artefakt- und Plattform-Matrix-Jobs zu warten. -3. `build-artifacts` überschneidet sich mit den schnellen Linux-Lanes, damit Downstream-Consumer starten können, sobald der gemeinsame Build bereit ist. -4. Schwerere Plattform- und Runtime-Lanes fächern danach auf: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` und `android`. +3. `build-artifacts` überlappt mit den schnellen Linux-Lanes, damit Downstream-Konsumenten starten können, sobald der gemeinsame Build bereit ist. +4. Danach fächern schwerere Plattform- und Runtime-Lanes auf: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` und `android`. -GitHub kann überholte Jobs als `cancelled` markieren, wenn ein neuerer Push auf demselben PR- oder `main`-Ref landet. Behandeln Sie das als CI-Rauschen, sofern nicht auch der neueste Lauf für denselben Ref fehlschlägt. Aggregierte Shard-Prüfungen verwenden `!cancelled() && always()`, sodass sie normale Shard-Fehler weiterhin melden, aber nicht mehr in die Warteschlange gehen, nachdem der gesamte Workflow bereits überholt wurde. Der automatische CI-Concurrency-Key ist versioniert (`CI-v7-*`), damit ein GitHub-seitiger Zombie in einer alten Queue-Gruppe neuere Main-Läufe nicht unbegrenzt blockieren kann. Manuelle Full-Suite-Läufe verwenden `CI-manual-v1-*` und brechen laufende Läufe nicht ab. +GitHub kann ersetzte Jobs als `cancelled` markieren, wenn ein neuerer Push auf demselben PR oder derselben `main`-Ref landet. Behandeln Sie das als CI-Rauschen, außer der neueste Lauf für dieselbe Ref schlägt ebenfalls fehl. Aggregierte Shard-Prüfungen verwenden `!cancelled() && always()`, sodass sie normale Shard-Fehler weiterhin melden, aber nicht mehr eingereiht werden, nachdem der gesamte Workflow bereits ersetzt wurde. Der automatische CI-Concurrency-Schlüssel ist versioniert (`CI-v7-*`), sodass ein GitHub-seitiger Zombie in einer alten Queue-Gruppe neuere Main-Läufe nicht unbegrenzt blockieren kann. Manuelle Full-Suite-Läufe verwenden `CI-manual-v1-*` und brechen laufende Läufe nicht ab. ## Scope und Routing -Die Scope-Logik liegt in `scripts/ci-changed-scope.mjs` und ist durch Unit-Tests in `src/scripts/ci-changed-scope.test.ts` abgedeckt. Manueller Dispatch überspringt die Changed-Scope-Erkennung und lässt das Preflight-Manifest so handeln, als hätte sich jeder gescopte Bereich geändert. +Die Scope-Logik befindet sich in `scripts/ci-changed-scope.mjs` und ist durch Unit-Tests in `src/scripts/ci-changed-scope.test.ts` abgedeckt. Manueller Dispatch überspringt die Changed-Scope-Erkennung und lässt das Preflight-Manifest so agieren, als hätte sich jeder gescopte Bereich geändert. - **CI-Workflow-Änderungen** validieren den Node-CI-Graphen plus Workflow-Linting, erzwingen aber für sich genommen keine nativen Windows-, Android- oder macOS-Builds; diese Plattform-Lanes bleiben auf Plattform-Quelländerungen beschränkt. -- **CI-Änderungen nur am Routing, ausgewählte günstige Core-Test-Fixture-Änderungen und enge Plugin-Contract-Helper-/Test-Routing-Änderungen** verwenden einen schnellen reinen Node-Manifest-Pfad: `preflight`, Security und eine einzelne `checks-fast-core`-Aufgabe. Dieser Pfad überspringt Build-Artefakte, Node-22-Kompatibilität, Channel Contracts, vollständige Core-Shards, Bundled-Plugin-Shards und zusätzliche Guard-Matrizen, wenn die Änderung auf Routing- oder Helper-Oberflächen begrenzt ist, die die schnelle Aufgabe direkt ausübt. -- **Windows-Node-Prüfungen** sind auf Windows-spezifische Prozess-/Pfad-Wrapper, npm/pnpm/UI-Runner-Helper, Package-Manager-Konfiguration und die CI-Workflow-Oberflächen beschränkt, die diese Lane ausführen; nicht zusammenhängende Quell-, Plugin-, Install-Smoke- und reine Teständerungen bleiben auf den Linux-Node-Lanes. +- **Reine CI-Routing-Änderungen, ausgewählte günstige Core-Test-Fixture-Änderungen und schmale Plugin-Vertrags-Helfer-/Test-Routing-Änderungen** verwenden einen schnellen reinen Node-Manifestpfad: `preflight`, Security und eine einzelne `checks-fast-core`-Aufgabe. Dieser Pfad überspringt Build-Artefakte, Node-22-Kompatibilität, Channel-Verträge, vollständige Core-Shards, Shards gebündelter Plugins und zusätzliche Guard-Matrizen, wenn die Änderung auf die Routing- oder Helferoberflächen begrenzt ist, die die schnelle Aufgabe direkt ausführt. +- **Windows-Node-Prüfungen** sind auf Windows-spezifische Prozess-/Pfad-Wrapper, npm-/pnpm-/UI-Runner-Helfer, Paketmanager-Konfiguration und die CI-Workflow-Oberflächen beschränkt, die diese Lane ausführen; nicht zugehörige Quell-, Plugin-, Install-Smoke- und reine Teständerungen bleiben auf den Linux-Node-Lanes. -Die langsamsten Node-Testfamilien sind aufgeteilt oder ausbalanciert, damit jeder Job klein bleibt, ohne Runner zu stark zu reservieren: Channel Contracts laufen als drei gewichtete Shards, kleine Core-Unit-Lanes werden gepaart, Auto-Reply läuft als vier ausbalancierte Worker (wobei der Reply-Subtree in Agent-Runner-, Dispatch- und Commands/State-Routing-Shards aufgeteilt ist), und agentische Gateway-/Plugin-Konfigurationen werden auf die vorhandenen source-only-agentic-Node-Jobs verteilt, statt auf Built Artifacts zu warten. Breite Browser-, QA-, Media- und sonstige Plugin-Tests verwenden ihre dedizierten Vitest-Konfigurationen statt des gemeinsamen Plugin-Catch-Alls. Include-Pattern-Shards zeichnen Timing-Einträge mit dem CI-Shard-Namen auf, sodass `.artifacts/vitest-shard-timings.json` eine gesamte Konfiguration von einem gefilterten Shard unterscheiden kann. `check-additional` hält Package-Boundary-Compile-/Canary-Arbeit zusammen und trennt Runtime-Topology-Architektur von Gateway-Watch-Abdeckung; der Boundary-Guard-Shard führt seine kleinen unabhängigen Guards innerhalb eines Jobs gleichzeitig aus. Gateway Watch, Channel-Tests und der Core-Support-Boundary-Shard laufen innerhalb von `build-artifacts` gleichzeitig, nachdem `dist/` und `dist-runtime/` bereits gebaut wurden. +Die langsamsten Node-Testfamilien sind aufgeteilt oder ausbalanciert, damit jeder Job klein bleibt, ohne Runner übermäßig zu reservieren: Channel-Verträge laufen als drei gewichtete Shards, kleine Core-Unit-Lanes werden gepaart, Auto-Reply läuft als vier ausbalancierte Worker (wobei der Reply-Teilbaum in Shards für Agent-Runner, Dispatch und Commands/State-Routing aufgeteilt ist), und agentische Gateway-/Plugin-Konfigurationen werden auf die vorhandenen reinen Source-agentischen Node-Jobs verteilt, statt auf gebaute Artefakte zu warten. Breite Browser-, QA-, Medien- und sonstige Plugin-Tests verwenden ihre eigenen dedizierten Vitest-Konfigurationen statt des gemeinsamen Plugin-Catch-all. Include-Pattern-Shards zeichnen Timing-Einträge mit dem CI-Shard-Namen auf, sodass `.artifacts/vitest-shard-timings.json` eine ganze Konfiguration von einem gefilterten Shard unterscheiden kann. `check-additional` hält Package-Boundary-Compile-/Canary-Arbeit zusammen und trennt Runtime-Topologie-Architektur von Gateway-Watch-Abdeckung; der Boundary-Guard-Shard führt seine kleinen unabhängigen Guards innerhalb eines Jobs parallel aus. Gateway-Watch-, Channel-Tests und der Core-Support-Boundary-Shard laufen innerhalb von `build-artifacts` parallel, nachdem `dist/` und `dist-runtime/` bereits gebaut wurden. -Android-CI führt sowohl `testPlayDebugUnitTest` als auch `testThirdPartyDebugUnitTest` aus und baut anschließend das Play-Debug-APK. Der Third-Party-Flavor hat kein separates Source Set und kein separates Manifest; seine Unit-Test-Lane kompiliert den Flavor trotzdem mit den SMS-/Call-Log-BuildConfig-Flags, während ein doppelter Debug-APK-Packaging-Job bei jedem Android-relevanten Push vermieden wird. +Android-CI führt sowohl `testPlayDebugUnitTest` als auch `testThirdPartyDebugUnitTest` aus und baut danach das Play-Debug-APK. Die Drittanbieter-Variante hat kein separates Source Set oder Manifest; ihre Unit-Test-Lane kompiliert die Variante weiterhin mit den SMS-/Call-Log-BuildConfig-Flags, vermeidet aber einen doppelten Debug-APK-Packaging-Job bei jedem Android-relevanten Push. -Der `check-dependencies`-Shard führt `pnpm deadcode:dependencies` (einen Produktions-Knip-Durchlauf nur für Abhängigkeiten, der auf die neueste Knip-Version gepinnt ist, wobei pnpm's Mindest-Release-Alter für die `dlx`-Installation deaktiviert ist) und `pnpm deadcode:unused-files` aus, das Knips Produktionsfunde ungenutzter Dateien mit `scripts/deadcode-unused-files.allowlist.mjs` vergleicht. Der Guard für ungenutzte Dateien schlägt fehl, wenn ein PR eine neue ungeprüfte ungenutzte Datei hinzufügt oder einen veralteten Allowlist-Eintrag zurücklässt, während beabsichtigte dynamische Plugin-, generierte, Build-, Live-Test- und Package-Bridge-Oberflächen erhalten bleiben, die Knip statisch nicht auflösen kann. +Der Shard `check-dependencies` führt `pnpm deadcode:dependencies` (einen Produktions-Knip-Durchlauf nur für Abhängigkeiten, gepinnt auf die neueste Knip-Version, wobei pnpm's Mindestveröffentlichungsalter für die `dlx`-Installation deaktiviert ist) und `pnpm deadcode:unused-files` aus, das Knips Produktionsfunde ungenutzter Dateien mit `scripts/deadcode-unused-files.allowlist.mjs` vergleicht. Der Guard für ungenutzte Dateien schlägt fehl, wenn ein PR eine neue ungeprüfte ungenutzte Datei hinzufügt oder einen veralteten Allowlist-Eintrag zurücklässt, während absichtliche dynamische Plugin-, generierte, Build-, Live-Test- und Package-Bridge-Oberflächen erhalten bleiben, die Knip nicht statisch auflösen kann. ## Manuelle Dispatches -Manuelle CI-Dispatches führen denselben Job-Graphen wie normale CI aus, erzwingen aber jede gescopte Nicht-Android-Lane: Linux-Node-Shards, Bundled-Plugin-Shards, Channel Contracts, Node-22-Kompatibilität, `check`, `check-additional`, Build Smoke, Docs-Prüfungen, Python-Skills, Windows, macOS und Control-UI-i18n. Eigenständige manuelle CI-Dispatches führen Android nur mit `include_android=true` aus; das vollständige Release-Umbrella aktiviert Android durch Übergabe von `include_android=true`. Statische Plugin-Prerelease-Prüfungen, der release-exklusive `agentic-plugins`-Shard, der vollständige Extension-Batch-Sweep und Plugin-Prerelease-Docker-Lanes sind von CI ausgeschlossen. Die Docker-Prerelease-Suite läuft nur, wenn `Full Release Validation` den separaten `Plugin Prerelease`-Workflow mit aktiviertem Release-Validation-Gate auslöst. +Manuell ausgelöste CI-Läufe führen denselben Job-Graphen wie normale CI aus, erzwingen aber jede nicht-Android-gescopte Lane: Linux-Node-Shards, gebündelte Plugin-Shards, Channel-Verträge, Node-22-Kompatibilität, `check`, `check-additional`, Build-Smoke, Docs-Prüfungen, Python-Skills, Windows, macOS und Control-UI-i18n. Eigenständige manuell ausgelöste CI-Läufe führen Android nur mit `include_android=true` aus; der vollständige Release-Umbrella aktiviert Android, indem er `include_android=true` übergibt. Statische Plugin-Prerelease-Prüfungen, der reine Release-Shard `agentic-plugins`, der vollständige Batch-Sweep der Plugins und Plugin-Prerelease-Docker-Lanes sind von CI ausgeschlossen. Die Docker-Prerelease-Suite läuft nur, wenn `Full Release Validation` den separaten Workflow `Plugin Prerelease` mit aktiviertem Release-Validation-Gate dispatcht. -Manuelle Läufe verwenden eine eindeutige Concurrency-Gruppe, damit eine Release-Candidate-Full-Suite nicht durch einen anderen Push- oder PR-Lauf auf demselben Ref abgebrochen wird. Die optionale Eingabe `target_ref` ermöglicht es einem vertrauenswürdigen Aufrufer, diesen Graphen gegen einen Branch, Tag oder vollständigen Commit-SHA auszuführen und dabei die Workflow-Datei aus dem ausgewählten Dispatch-Ref zu verwenden. +Manuelle Läufe verwenden eine eindeutige Concurrency-Gruppe, damit eine vollständige Release-Candidate-Suite nicht durch einen anderen Push- oder PR-Lauf auf derselben Ref abgebrochen wird. Die optionale Eingabe `target_ref` ermöglicht es einem vertrauenswürdigen Aufrufer, diesen Graphen gegen einen Branch, ein Tag oder eine vollständige Commit-SHA auszuführen, während die Workflow-Datei aus der ausgewählten Dispatch-Ref verwendet wird. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -79,15 +79,15 @@ gh workflow run full-release-validation.yml --ref main -f ref= ## Runner -| Runner | Jobs | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `ubuntu-24.04` | `preflight`, schnelle Sicherheits-Jobs und Aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), schnelle Protokoll-/Contract-/gebündelte Prüfungen, geshardete Channel-Contract-Prüfungen, `check`-Shards außer Lint, `check-additional`-Shards und Aggregate, Node-Test-Aggregatverifizierer, Docs-Prüfungen, Python-Skills, Workflow-Sanity, Labeler, Auto-Response; install-smoke-Preflight nutzt ebenfalls GitHub-gehostetes Ubuntu, damit die Blacksmith-Matrix früher eingereiht werden kann | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, kleinere Plugin-Shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` und `check-test-types` | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, Build-Smoke, Linux-Node-Test-Shards, gebündelte Plugin-Test-Shards, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (CPU-empfindlich genug, dass 8 vCPU mehr kosteten, als sie einsparten); install-smoke-Docker-Builds (32-vCPU-Wartezeit kostete mehr, als sie einsparten) | -| `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück | +| Runner | Jobs | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, schnelle Sicherheits-Jobs und Aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), schnelle Protokoll-/Contract-/gebündelte Prüfungen, aufgeteilte Channel-Contract-Prüfungen, `check`-Shards außer Lint, `check-additional`-Shards und -Aggregate, Node-Test-Aggregatverifizierer, Dokumentationsprüfungen, Python-Skills, Workflow-Sanity, Labeler, Auto-Response; die Install-Smoke-Preflight verwendet ebenfalls von GitHub gehostetes Ubuntu, damit die Blacksmith-Matrix früher in die Warteschlange eingereiht werden kann | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, leichtere Plugin-Shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` und `check-test-types` | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, Build-Smoke, Linux-Node-Test-Shards, Test-Shards für gebündelte Plugins, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (CPU-sensitiv genug, dass 8 vCPUs mehr kosteten, als sie einsparten); Docker-Builds für Install-Smoke (die Wartezeit in der 32-vCPU-Warteschlange kostete mehr, als sie einsparten) | +| `blacksmith-16vcpu-windows-2025` | `checks-windows` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück | ## Lokale Entsprechungen @@ -117,23 +117,23 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Vollständige Release-Validierung -`Full Release Validation` ist der manuelle Dach-Workflow für „alles vor dem Release ausführen“. Er akzeptiert einen Branch, Tag oder vollständigen Commit-SHA, startet den manuellen `CI`-Workflow mit diesem Ziel, startet `Plugin Prerelease` für release-spezifische Plugin-/Package-/Static-/Docker-Nachweise und startet `OpenClaw Release Checks` für Install-Smoke, Package Acceptance, Docker-Release-Pfad-Suites, Live/E2E, OpenWebUI, QA-Lab-Parität, Matrix und Telegram-Lanes. Er kann außerdem den Post-Publish-Workflow `NPM Telegram Beta E2E` ausführen, wenn eine veröffentlichte Package-Spezifikation angegeben wird. +`Full Release Validation` ist der manuelle Umbrella-Workflow für „alles vor dem Release ausführen“. Er akzeptiert einen Branch, ein Tag oder einen vollständigen Commit-SHA, startet den manuellen `CI`-Workflow mit diesem Ziel, startet `Plugin Prerelease` für Release-spezifische Plugin-/Paket-/statische/Docker-Nachweise und startet `OpenClaw Release Checks` für Install-Smoke, Paketakzeptanz, Docker-Release-Pfad-Suiten, Live/E2E, OpenWebUI, QA-Lab-Parität, Matrix- und Telegram-Lanes. Er kann außerdem den Post-Publish-Workflow `NPM Telegram Beta E2E` ausführen, wenn eine veröffentlichte Paketspezifikation angegeben wird. `release_profile` steuert die Live-/Provider-Breite, die an Release-Prüfungen übergeben wird: - `minimum` behält die schnellsten OpenAI-/Core-releasekritischen Lanes bei. - `stable` fügt den stabilen Provider-/Backend-Satz hinzu. -- `full` führt die breite Advisory-Provider-/Medien-Matrix aus. +- `full` führt die breite beratende Provider-/Medien-Matrix aus. -Der Dach-Workflow zeichnet die gestarteten Child-Run-IDs auf, und der abschließende Job `Verify full validation` prüft die aktuellen Child-Run-Ergebnisse erneut und hängt Tabellen mit den langsamsten Jobs für jeden Child-Run an. Wenn ein Child-Workflow erneut ausgeführt wird und grün wird, führen Sie nur den Parent-Verifiziererjob erneut aus, um das Ergebnis und die Timing-Zusammenfassung des Dach-Workflows zu aktualisieren. +Der Umbrella zeichnet die gestarteten untergeordneten Run-IDs auf, und der abschließende Job `Verify full validation` prüft die aktuellen Ergebnisse der untergeordneten Runs erneut und hängt Tabellen mit den langsamsten Jobs für jeden untergeordneten Run an. Wenn ein untergeordneter Workflow erneut ausgeführt wird und grün wird, führen Sie nur den übergeordneten Verifizierer-Job erneut aus, um das Umbrella-Ergebnis und die Timing-Zusammenfassung zu aktualisieren. -Für die Wiederherstellung akzeptieren sowohl `Full Release Validation` als auch `OpenClaw Release Checks` `rerun_group`. Verwenden Sie `all` für einen Release-Kandidaten, `ci` nur für das normale vollständige CI-Child, `release-checks` für jedes Release-Child oder eine engere Gruppe: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` oder `npm-telegram` im Dach-Workflow. So bleibt die erneute Ausführung einer fehlgeschlagenen Release-Box nach einem gezielten Fix begrenzt. +Für die Wiederherstellung akzeptieren sowohl `Full Release Validation` als auch `OpenClaw Release Checks` `rerun_group`. Verwenden Sie `all` für einen Release-Kandidaten, `ci` nur für das normale vollständige untergeordnete CI, `release-checks` für jedes untergeordnete Release oder eine engere Gruppe: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` oder `npm-telegram` im Umbrella. Dadurch bleibt ein erneuter Lauf einer fehlgeschlagenen Release-Box nach einer gezielten Korrektur begrenzt. -`OpenClaw Release Checks` verwendet die vertrauenswürdige Workflow-Referenz, um die ausgewählte Referenz einmal in ein `release-package-under-test`-Tarball aufzulösen, und übergibt dieses Artefakt dann sowohl an den Live/E2E-Docker-Workflow für den Release-Pfad als auch an den Package-Acceptance-Shard. Dadurch bleiben die Package-Bytes über Release-Boxen hinweg konsistent, und das erneute Packen desselben Kandidaten in mehreren Child-Jobs wird vermieden. +`OpenClaw Release Checks` verwendet die vertrauenswürdige Workflow-Ref, um die ausgewählte Ref einmal in einen `release-package-under-test`-Tarball aufzulösen, und übergibt dieses Artefakt dann sowohl an den Docker-Workflow für den Live/E2E-Release-Pfad als auch an den Paketakzeptanz-Shard. Dadurch bleiben die Paket-Bytes über Release-Boxen hinweg konsistent und es wird vermieden, denselben Kandidaten in mehreren untergeordneten Jobs erneut zu packen. ## Live- und E2E-Shards -Das Release-Live/E2E-Child behält eine breite native `pnpm test:live`-Abdeckung bei, führt sie jedoch als benannte Shards über `scripts/test-live-shard.mjs` statt als einen seriellen Job aus: +Das untergeordnete Release-Live/E2E behält eine breite native `pnpm test:live`-Abdeckung bei, führt sie jedoch als benannte Shards über `scripts/test-live-shard.mjs` statt als einen seriellen Job aus: - `native-live-src-agents` - `native-live-src-gateway-core` @@ -145,57 +145,57 @@ Das Release-Live/E2E-Child behält eine breite native `pnpm test:live`-Abdeckung - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- aufgeteilte Audio-/Video-Medien-Shards und Provider-gefilterte Musik-Shards +- aufgeteilte Medien-Audio-/Video-Shards und Provider-gefilterte Musik-Shards -Das behält dieselbe Dateiabdeckung bei und macht langsame Live-Provider-Fehler zugleich leichter erneut ausführbar und diagnostizierbar. Die aggregierten Shard-Namen `native-live-extensions-o-z`, `native-live-extensions-media` und `native-live-extensions-media-music` bleiben für manuelle einmalige Wiederholungen gültig. +Dadurch bleibt dieselbe Dateiabdeckung erhalten, während langsame Live-Provider-Fehler leichter erneut ausgeführt und diagnostiziert werden können. Die aggregierten Shard-Namen `native-live-extensions-o-z`, `native-live-extensions-media` und `native-live-extensions-media-music` bleiben für manuelle einmalige erneute Läufe gültig. -Die nativen Live-Medien-Shards laufen in `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, gebaut vom Workflow `Live Media Runner Image`. Dieses Image installiert `ffmpeg` und `ffprobe` vor; Medien-Jobs verifizieren vor der Einrichtung nur die Binaries. Belassen Sie Docker-gestützte Live-Suites auf normalen Blacksmith-Runnern - Container-Jobs sind der falsche Ort, um verschachtelte Docker-Tests zu starten. +Die nativen Live-Medien-Shards laufen in `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, das vom Workflow `Live Media Runner Image` gebaut wird. Dieses Image installiert `ffmpeg` und `ffprobe` vor; Medien-Jobs verifizieren die Binärdateien nur vor dem Setup. Belassen Sie Docker-gestützte Live-Suiten auf normalen Blacksmith-Runnern, da Container-Jobs der falsche Ort sind, um verschachtelte Docker-Tests zu starten. -Docker-gestützte Live-Modell-/Backend-Shards verwenden ein separates gemeinsames Image `ghcr.io/openclaw/openclaw-live-test:` pro ausgewähltem Commit. Der Live-Release-Workflow baut und pusht dieses Image einmal, danach laufen die Docker-Live-Modell-, Gateway-, CLI-Backend-, ACP-Bind- und Codex-Harness-Shards mit `OPENCLAW_SKIP_DOCKER_BUILD=1`. Wenn diese Shards das vollständige Source-Docker-Ziel unabhängig neu bauen, ist der Release-Run falsch konfiguriert und verschwendet Laufzeit für doppelte Image-Builds. +Docker-gestützte Live-Modell-/Backend-Shards verwenden ein separates gemeinsames Image `ghcr.io/openclaw/openclaw-live-test:` pro ausgewähltem Commit. Der Live-Release-Workflow baut und pusht dieses Image einmal, dann laufen die Docker-Live-Modell-, Gateway-, CLI-Backend-, ACP-Bind- und Codex-Harness-Shards mit `OPENCLAW_SKIP_DOCKER_BUILD=1`. Wenn diese Shards das vollständige Source-Docker-Ziel unabhängig neu bauen, ist der Release-Run falsch konfiguriert und verschwendet Laufzeit für doppelte Image-Builds. -## Package Acceptance +## Paketakzeptanz -Verwenden Sie `Package Acceptance`, wenn die Frage lautet: „Funktioniert dieses installierbare OpenClaw-Package als Produkt?“ Es unterscheidet sich von normalem CI: Normales CI validiert den Source Tree, während Package Acceptance ein einzelnes Tarball über denselben Docker-E2E-Harness validiert, den Benutzer nach Installation oder Update ausführen. +Verwenden Sie `Package Acceptance`, wenn die Frage lautet: „Funktioniert dieses installierbare OpenClaw-Paket als Produkt?“ Sie unterscheidet sich von normaler CI: Normale CI validiert den Quellbaum, während die Paketakzeptanz einen einzelnen Tarball über denselben Docker-E2E-Harness validiert, den Benutzer nach Installation oder Update ausführen. ### Jobs -1. `resolve_package` checkt `workflow_ref` aus, löst einen Package-Kandidaten auf, schreibt `.artifacts/docker-e2e-package/openclaw-current.tgz`, schreibt `.artifacts/docker-e2e-package/package-candidate.json`, lädt beide als Artefakt `package-under-test` hoch und gibt Quelle, Workflow-Referenz, Package-Referenz, Version, SHA-256 und Profil in der GitHub-Schrittzusammenfassung aus. -2. `docker_acceptance` ruft `openclaw-live-and-e2e-checks-reusable.yml` mit `ref=workflow_ref` und `package_artifact_name=package-under-test` auf. Der wiederverwendbare Workflow lädt dieses Artefakt herunter, validiert das Tarball-Inventar, bereitet bei Bedarf Package-Digest-Docker-Images vor und führt die ausgewählten Docker-Lanes gegen dieses Package aus, statt den Workflow-Checkout zu packen. Wenn ein Profil mehrere gezielte `docker_lanes` auswählt, bereitet der wiederverwendbare Workflow das Package und die gemeinsamen Images einmal vor und verteilt diese Lanes dann als parallele gezielte Docker-Jobs mit eindeutigen Artefakten. -3. `package_telegram` ruft optional `NPM Telegram Beta E2E` auf. Es läuft, wenn `telegram_mode` nicht `none` ist, und installiert dasselbe `package-under-test`-Artefakt, wenn Package Acceptance eines aufgelöst hat; ein eigenständiger Telegram-Dispatch kann weiterhin eine veröffentlichte npm-Spezifikation installieren. -4. `summary` lässt den Workflow fehlschlagen, wenn Package-Auflösung, Docker Acceptance oder die optionale Telegram-Lane fehlgeschlagen ist. +1. `resolve_package` checkt `workflow_ref` aus, löst einen Paketkandidaten auf, schreibt `.artifacts/docker-e2e-package/openclaw-current.tgz`, schreibt `.artifacts/docker-e2e-package/package-candidate.json`, lädt beide als Artefakt `package-under-test` hoch und gibt Quelle, Workflow-Ref, Paket-Ref, Version, SHA-256 und Profil in der GitHub-Schrittzusammenfassung aus. +2. `docker_acceptance` ruft `openclaw-live-and-e2e-checks-reusable.yml` mit `ref=workflow_ref` und `package_artifact_name=package-under-test` auf. Der wiederverwendbare Workflow lädt dieses Artefakt herunter, validiert den Tarball-Bestand, bereitet bei Bedarf Package-Digest-Docker-Images vor und führt die ausgewählten Docker-Lanes gegen dieses Paket aus, statt den Workflow-Checkout zu packen. Wenn ein Profil mehrere gezielte `docker_lanes` auswählt, bereitet der wiederverwendbare Workflow das Paket und die gemeinsamen Images einmal vor und fächert diese Lanes dann als parallele gezielte Docker-Jobs mit eindeutigen Artefakten auf. +3. `package_telegram` ruft optional `NPM Telegram Beta E2E` auf. Es läuft, wenn `telegram_mode` nicht `none` ist, und installiert dasselbe Artefakt `package-under-test`, wenn Package Acceptance eines aufgelöst hat; ein eigenständiger Telegram-Dispatch kann weiterhin eine veröffentlichte npm-Spezifikation installieren. +4. `summary` lässt den Workflow fehlschlagen, wenn die Paketauflösung, Docker-Akzeptanz oder die optionale Telegram-Lane fehlgeschlagen ist. ### Kandidatenquellen - `source=npm` akzeptiert nur `openclaw@beta`, `openclaw@latest` oder eine exakte OpenClaw-Release-Version wie `openclaw@2026.4.27-beta.2`. Verwenden Sie dies für die Abnahme veröffentlichter Beta-/Stable-Versionen. -- `source=ref` packt einen vertrauenswürdigen `package_ref`-Branch, Tag oder vollständigen Commit-SHA. Der Resolver ruft OpenClaw-Branches/-Tags ab, verifiziert, dass der ausgewählte Commit aus der Repository-Branch-Historie oder einem Release-Tag erreichbar ist, installiert Abhängigkeiten in einem losgelösten Worktree und packt ihn mit `scripts/package-openclaw-for-docker.mjs`. -- `source=url` lädt eine HTTPS-`.tgz` herunter; `package_sha256` ist erforderlich. -- `source=artifact` lädt eine `.tgz` aus `artifact_run_id` und `artifact_name` herunter; `package_sha256` ist optional, sollte aber für extern freigegebene Artefakte angegeben werden. +- `source=ref` paketiert einen vertrauenswürdigen `package_ref`-Branch, ein Tag oder einen vollständigen Commit-SHA. Der Resolver ruft OpenClaw-Branches/-Tags ab, prüft, ob der ausgewählte Commit über die Branch-Historie des Repositorys oder ein Release-Tag erreichbar ist, installiert Abhängigkeiten in einem losgelösten Worktree und paketiert ihn mit `scripts/package-openclaw-for-docker.mjs`. +- `source=url` lädt ein HTTPS-`.tgz` herunter; `package_sha256` ist erforderlich. +- `source=artifact` lädt ein `.tgz` aus `artifact_run_id` und `artifact_name` herunter; `package_sha256` ist optional, sollte aber für extern geteilte Artefakte angegeben werden. -Halten Sie `workflow_ref` und `package_ref` getrennt. `workflow_ref` ist der vertrauenswürdige Workflow-/Harness-Code, der den Test ausführt. `package_ref` ist der Source-Commit, der gepackt wird, wenn `source=ref` gilt. Dadurch kann der aktuelle Test-Harness ältere vertrauenswürdige Source-Commits validieren, ohne alte Workflow-Logik auszuführen. +Halten Sie `workflow_ref` und `package_ref` getrennt. `workflow_ref` ist der vertrauenswürdige Workflow-/Harness-Code, der den Test ausführt. `package_ref` ist der Quell-Commit, der paketiert wird, wenn `source=ref` ist. Dadurch kann der aktuelle Test-Harness ältere vertrauenswürdige Quell-Commits validieren, ohne alte Workflow-Logik auszuführen. ### Suite-Profile - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload` -- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` +- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` - `product` — `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` - `full` — vollständige Docker-Release-Pfad-Chunks mit OpenWebUI - `custom` — exakte `docker_lanes`; erforderlich, wenn `suite_profile=custom` -Das `package`-Profil verwendet Offline-Plugin-Abdeckung, sodass die Validierung veröffentlichter Pakete nicht von der Live-Verfügbarkeit von ClawHub abhängt. Die optionale Telegram-Lane verwendet das `package-under-test`-Artefakt in `NPM Telegram Beta E2E` wieder, wobei der veröffentlichte npm-Spec-Pfad für eigenständige Dispatches beibehalten wird. +Das Profil `package` verwendet Offline-Plugin-Abdeckung, damit die Validierung veröffentlichter Pakete nicht von der Live-Verfügbarkeit von ClawHub abhängt. Die optionale Telegram-Lane verwendet das Artefakt `package-under-test` in `NPM Telegram Beta E2E` wieder, wobei der veröffentlichte npm-Spezifikationspfad für eigenständige Dispatches erhalten bleibt. -Release-Prüfungen rufen Package Acceptance mit `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` und `telegram_mode=mock-openai` auf. Release-Pfad-Docker-Chunks decken die überlappenden Paket-/Update-/Plugin-Lanes ab; Package Acceptance behält den artefaktnativen Nachweis für bundled-channel-Kompatibilität, Offline-Plugin und Telegram gegen denselben aufgelösten Paket-Tarball bei. Plattformübergreifende Release-Prüfungen decken weiterhin OS-spezifisches Onboarding, Installer- und Plattformverhalten ab; Paket-/Update-Produktvalidierung sollte mit Package Acceptance beginnen. Die Windows-Packaged- und Installer-Fresh-Lanes verifizieren außerdem, dass ein installiertes Paket ein Browser-Control-Override aus einem rohen absoluten Windows-Pfad importieren kann. Der OpenAI-Cross-OS-Agent-Turn-Smoke verwendet standardmäßig `OPENCLAW_CROSS_OS_OPENAI_MODEL`, wenn gesetzt, andernfalls `openai/gpt-5.4-mini`, sodass der Installations- und Gateway-Nachweis schnell und deterministisch bleibt. +Release-Prüfungen rufen Package Acceptance mit `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` und `telegram_mode=mock-openai` auf. Docker-Chunks des Release-Pfads decken die überlappenden Paket-/Update-/Plugin-Lanes ab; Package Acceptance behält den artefaktnativen Kompatibilitätsnachweis für gebündelte Channels, den Offline-Plugin-Nachweis und den Telegram-Nachweis gegen denselben aufgelösten Paket-Tarball bei. Cross-OS-Release-Prüfungen decken weiterhin OS-spezifisches Onboarding-, Installer- und Plattformverhalten ab; die Produktvalidierung für Paket/Update sollte mit Package Acceptance beginnen. Die Windows-Lanes für paketierte und frische Installer-Installationen prüfen außerdem, dass ein installiertes Paket ein Browser-Control-Override aus einem rohen absoluten Windows-Pfad importieren kann. Der OpenAI-Cross-OS-Agent-Turn-Smoke verwendet standardmäßig `OPENCLAW_CROSS_OS_OPENAI_MODEL`, wenn gesetzt, andernfalls `openai/gpt-5.4-mini`, damit der Installations- und Gateway-Nachweis schnell und deterministisch bleibt. -### Zeitfenster für Legacy-Kompatibilität +### Legacy-Kompatibilitätsfenster -Package Acceptance hat begrenzte Zeitfenster für Legacy-Kompatibilität für bereits veröffentlichte Pakete. Pakete bis einschließlich `2026.4.25`, einschließlich `2026.4.25-beta.*`, können den Kompatibilitätspfad verwenden: +Package Acceptance hat begrenzte Legacy-Kompatibilitätsfenster für bereits veröffentlichte Pakete. Pakete bis einschließlich `2026.4.25`, einschließlich `2026.4.25-beta.*`, dürfen den Kompatibilitätspfad verwenden: -- bekannte private QA-Einträge in `dist/postinstall-inventory.json` können auf Dateien verweisen, die im Tarball fehlen; -- `doctor-switch` kann den Persistenz-Subfall `gateway install --wrapper` überspringen, wenn das Paket dieses Flag nicht verfügbar macht; -- `update-channel-switch` kann fehlende `pnpm.patchedDependencies` aus dem aus dem Tarball abgeleiteten Fake-Git-Fixture entfernen und fehlendes persistiertes `update.channel` protokollieren; -- Plugin-Smokes können Legacy-Install-Record-Speicherorte lesen oder fehlende Marketplace-Install-Record-Persistenz akzeptieren; -- `plugin-update` kann die Migration von Konfigurationsmetadaten zulassen, während weiterhin verlangt wird, dass Install-Record- und No-Reinstall-Verhalten unverändert bleiben. +- bekannte private QA-Einträge in `dist/postinstall-inventory.json` dürfen auf Dateien verweisen, die im Tarball ausgelassen wurden; +- `doctor-switch` darf den Persistenz-Unterfall `gateway install --wrapper` überspringen, wenn das Paket dieses Flag nicht bereitstellt; +- `update-channel-switch` darf fehlende `pnpm.patchedDependencies` aus der vom Tarball abgeleiteten gefälschten Git-Fixture entfernen und fehlendes persistiertes `update.channel` protokollieren; +- Plugin-Smokes dürfen Legacy-Speicherorte für Installationsdatensätze lesen oder fehlende Marketplace-Persistenz von Installationsdatensätzen akzeptieren; +- `plugin-update` darf die Migration von Konfigurationsmetadaten erlauben, während weiterhin erforderlich bleibt, dass Installationsdatensatz und Verhalten ohne Neuinstallation unverändert bleiben. -Das veröffentlichte Paket `2026.4.26` kann außerdem Warnungen für lokale Build-Metadaten-Stamp-Dateien ausgeben, die bereits ausgeliefert wurden. Spätere Pakete müssen die modernen Verträge erfüllen; dieselben Bedingungen führen dann zu Fehlern statt zu Warnungen oder Überspringen. +Das veröffentlichte Paket `2026.4.26` darf außerdem vor lokal ausgelieferten Build-Metadaten-Stempeldateien warnen. Spätere Pakete müssen die modernen Verträge erfüllen; dieselben Bedingungen schlagen dann fehl, anstatt zu warnen oder übersprungen zu werden. ### Beispiele @@ -238,47 +238,47 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Wenn Sie einen fehlgeschlagenen Package-Acceptance-Lauf debuggen, beginnen Sie bei der Zusammenfassung `resolve_package`, um Paketquelle, Version und SHA-256 zu bestätigen. Prüfen Sie anschließend den untergeordneten Lauf `docker_acceptance` und seine Docker-Artefakte: `.artifacts/docker-tests/**/summary.json`, `failures.json`, Lane-Logs, Phasen-Timings und Rerun-Befehle. Führen Sie bevorzugt das fehlgeschlagene Paketprofil oder die exakten Docker-Lanes erneut aus, statt die vollständige Release-Validierung erneut auszuführen. +Beginnen Sie beim Debuggen eines fehlgeschlagenen Package-Acceptance-Laufs mit der Zusammenfassung `resolve_package`, um Paketquelle, Version und SHA-256 zu bestätigen. Prüfen Sie anschließend den untergeordneten Lauf `docker_acceptance` und seine Docker-Artefakte: `.artifacts/docker-tests/**/summary.json`, `failures.json`, Lane-Logs, Phasen-Timings und Befehle zum erneuten Ausführen. Führen Sie bevorzugt das fehlgeschlagene Paketprofil oder die exakten Docker-Lanes erneut aus, statt die vollständige Release-Validierung erneut auszuführen. ## Install-Smoke Der separate Workflow `Install Smoke` verwendet dasselbe Scope-Skript über seinen eigenen `preflight`-Job wieder. Er teilt die Smoke-Abdeckung in `run_fast_install_smoke` und `run_full_install_smoke` auf. -- **Schneller Pfad** läuft für Pull Requests, die Docker-/Paketoberflächen, Änderungen an gebündelten Plugin-Paketen/-Manifesten oder Core-Plugin-/Channel-/Gateway-/Plugin-SDK-Oberflächen betreffen, die von den Docker-Smoke-Jobs ausgeübt werden. Reine Source-Änderungen an gebündelten Plugins, reine Test-Änderungen und reine Docs-Änderungen reservieren keine Docker-Worker. Der schnelle Pfad baut das Root-Dockerfile-Image einmal, prüft die CLI, führt den Shared-Workspace-CLI-Smoke zum Löschen von Agenten aus, führt das Container-`gateway-network`-E2E aus, verifiziert ein Build-Argument für eine gebündelte Erweiterung und führt das begrenzte gebündelte-Plugin-Docker-Profil unter einem aggregierten Befehls-Timeout von 240 Sekunden aus (jeder Docker-Lauf eines Szenarios ist separat begrenzt). -- **Vollständiger Pfad** behält QR-Paketinstallation und Installer-Docker-/Update-Abdeckung für nächtliche geplante Läufe, manuelle Dispatches, Workflow-Call-Release-Prüfungen und Pull Requests bei, die tatsächlich Installer-/Paket-/Docker-Oberflächen berühren. Im vollständigen Modus bereitet install-smoke ein GHCR-Root-Dockerfile-Smoke-Image für den Ziel-SHA vor oder verwendet es wieder und führt dann QR-Paketinstallation, Root-Dockerfile-/Gateway-Smokes, Installer-/Update-Smokes und das schnelle gebündelte-Plugin-Docker-E2E als separate Jobs aus, damit Installer-Arbeit nicht hinter den Root-Image-Smokes warten muss. +- **Schneller Pfad** läuft für Pull Requests, die Docker-/Paketoberflächen, Änderungen an gebündelten Plugin-Paketen/-Manifesten oder zentrale Plugin-/Channel-/Gateway-/Plugin-SDK-Oberflächen berühren, die von den Docker-Smoke-Jobs ausgeübt werden. Reine Quelländerungen an gebündelten Plugins, reine Teständerungen und reine Dokumentationsänderungen reservieren keine Docker-Worker. Der schnelle Pfad baut das Root-Dockerfile-Image einmal, prüft die CLI, führt den CLI-Smoke zum Löschen von Agents in einem geteilten Workspace aus, führt das Container-`gateway-network`-E2E aus, verifiziert ein Build-Argument für gebündelte Erweiterungen und führt das begrenzte Docker-Profil für gebündelte Plugins unter einem aggregierten Befehls-Timeout von 240 Sekunden aus, wobei jeder Docker-Lauf eines Szenarios separat begrenzt ist. +- **Vollständiger Pfad** behält QR-Paketinstallation und Installer-Docker-/Update-Abdeckung für nächtlich geplante Läufe, manuelle Dispatches, Release-Prüfungen per Workflow-Aufruf und Pull Requests bei, die wirklich Installer-/Paket-/Docker-Oberflächen berühren. Im vollständigen Modus bereitet Install-Smoke ein GHCR-Root-Dockerfile-Smoke-Image für den Ziel-SHA vor oder verwendet es wieder und führt anschließend QR-Paketinstallation, Root-Dockerfile-/Gateway-Smokes, Installer-/Update-Smokes und das schnelle Docker-E2E für gebündelte Plugins als separate Jobs aus, damit Installer-Arbeit nicht hinter den Root-Image-Smokes warten muss. -`main`-Pushes (einschließlich Merge-Commits) erzwingen den vollständigen Pfad nicht; wenn die Changed-Scope-Logik bei einem Push vollständige Abdeckung anfordern würde, behält der Workflow den schnellen Docker-Smoke bei und überlässt den vollständigen Install-Smoke der nächtlichen oder Release-Validierung. +`main`-Pushes, einschließlich Merge-Commits, erzwingen nicht den vollständigen Pfad; wenn die Changed-Scope-Logik bei einem Push vollständige Abdeckung anfordern würde, behält der Workflow den schnellen Docker-Smoke bei und überlässt den vollständigen Install-Smoke der nächtlichen oder Release-Validierung. -Der langsame Bun-Global-Install-Image-Provider-Smoke wird separat durch `run_bun_global_install_smoke` gesteuert. Er läuft im nächtlichen Zeitplan und aus dem Release-Checks-Workflow heraus, und manuelle `Install Smoke`-Dispatches können ihn aktivieren, aber Pull Requests und `main`-Pushes tun dies nicht. QR- und Installer-Docker-Tests behalten ihre eigenen installationsorientierten Dockerfiles. +Der langsame Bun-Global-Install-Image-Provider-Smoke wird separat durch `run_bun_global_install_smoke` gesteuert. Er läuft im nächtlichen Zeitplan und aus dem Release-Checks-Workflow, und manuelle `Install Smoke`-Dispatches können ihn aktivieren, Pull Requests und `main`-Pushes jedoch nicht. QR- und Installer-Docker-Tests behalten ihre eigenen installationsfokussierten Dockerfiles. ## Lokales Docker-E2E -`pnpm test:docker:all` baut ein gemeinsames Live-Test-Image vorab, packt OpenClaw einmal als npm-Tarball und baut zwei gemeinsame `scripts/e2e/Dockerfile`-Images: +`pnpm test:docker:all` baut ein gemeinsames Live-Test-Image vor, paketiert OpenClaw einmal als npm-Tarball und baut zwei gemeinsame `scripts/e2e/Dockerfile`-Images: -- einen einfachen Node-/Git-Runner für Installer-/Update-/Plugin-Abhängigkeits-Lanes; -- ein funktionales Image, das denselben Tarball für normale Funktions-Lanes in `/app` installiert. +- einen schlanken Node-/Git-Runner für Installer-/Update-/Plugin-Abhängigkeits-Lanes; +- ein funktionsfähiges Image, das denselben Tarball für normale Funktions-Lanes in `/app` installiert. -Docker-Lane-Definitionen befinden sich in `scripts/lib/docker-e2e-scenarios.mjs`, Planner-Logik befindet sich in `scripts/lib/docker-e2e-plan.mjs`, und der Runner führt nur den ausgewählten Plan aus. Der Scheduler wählt das Image pro Lane mit `OPENCLAW_DOCKER_E2E_BARE_IMAGE` und `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` aus und führt dann Lanes mit `OPENCLAW_SKIP_DOCKER_BUILD=1` aus. +Docker-Lane-Definitionen befinden sich in `scripts/lib/docker-e2e-scenarios.mjs`, die Planner-Logik befindet sich in `scripts/lib/docker-e2e-plan.mjs`, und der Runner führt nur den ausgewählten Plan aus. Der Scheduler wählt das Image pro Lane mit `OPENCLAW_DOCKER_E2E_BARE_IMAGE` und `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` aus und führt Lanes dann mit `OPENCLAW_SKIP_DOCKER_BUILD=1` aus. ### Einstellbare Parameter | Variable | Standard | Zweck | | -------------------------------------- | -------- | --------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Slot-Anzahl des Haupt-Pools für normale Lanes. | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Slot-Anzahl des Haupt-Pools für normale Lanes. | | `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Slot-Anzahl des Provider-sensitiven Tail-Pools. | | `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Obergrenze für gleichzeitige Live-Lanes, damit Provider nicht drosseln. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Obergrenze für gleichzeitige npm-Installations-Lanes. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Obergrenze für gleichzeitige npm-Installations-Lanes. | | `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Obergrenze für gleichzeitige Multi-Service-Lanes. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Versatz zwischen Lane-Starts, um Docker-Daemon-Create-Stürme zu vermeiden; setzen Sie `0` für keinen Versatz. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Staffelung zwischen Lane-Starts, um Docker-Daemon-Erstellungsstürme zu vermeiden; setzen Sie `0` für keine Staffelung. | | `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Fallback-Timeout pro Lane (120 Minuten); ausgewählte Live-/Tail-Lanes verwenden engere Grenzen. | | `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` gibt den Scheduler-Plan aus, ohne Lanes auszuführen. | -| `OPENCLAW_DOCKER_ALL_LANES` | unset | Kommagetrennte exakte Lane-Liste; überspringt Cleanup-Smoke, damit Agenten eine fehlgeschlagene Lane reproduzieren können. | +| `OPENCLAW_DOCKER_ALL_LANES` | unset | Kommagetrennte exakte Lane-Liste; überspringt Cleanup-Smoke, damit Agents eine fehlgeschlagene Lane reproduzieren können. | -Eine Lane, die schwerer als ihre effektive Grenze ist, kann trotzdem aus einem leeren Pool starten und läuft dann allein, bis sie Kapazität freigibt. Die lokale aggregierte Ausführung führt Docker-Preflights aus, entfernt veraltete OpenClaw-E2E-Container, gibt den Active-Lane-Status aus, persistiert Lane-Timings für Longest-First-Reihenfolge und stoppt standardmäßig nach dem ersten Fehler die Planung neuer gepoolter Lanes. +Eine Lane, die schwerer ist als ihre effektive Grenze, kann trotzdem aus einem leeren Pool starten und läuft dann allein, bis sie Kapazität freigibt. Das lokale Aggregat prüft Docker vorab, entfernt veraltete OpenClaw-E2E-Container, gibt den Status aktiver Lanes aus, persistiert Lane-Timings für eine längste-zuerst-Reihenfolge und plant standardmäßig nach dem ersten Fehler keine neuen gepoolten Lanes mehr ein. ### Wiederverwendbarer Live-/E2E-Workflow -Der wiederverwendbare Live-/E2E-Workflow fragt `scripts/test-docker-all.mjs --plan-json`, welche Paket-, Image-Art, Live-Image-, Lane- und Credential-Abdeckung erforderlich ist. `scripts/docker-e2e.mjs` wandelt diesen Plan dann in GitHub-Ausgaben und Zusammenfassungen um. Es packt OpenClaw entweder über `scripts/package-openclaw-for-docker.mjs`, lädt ein Paketartefakt aus dem aktuellen Lauf herunter oder lädt ein Paketartefakt aus `package_artifact_run_id` herunter; validiert das Tarball-Inventar; baut und pusht paketdigest-getaggte Bare-/Functional-GHCR-Docker-E2E-Images über Blacksmiths Docker-Layer-Cache, wenn der Plan Lanes mit installiertem Paket benötigt; und verwendet bereitgestellte Eingaben `docker_e2e_bare_image`/`docker_e2e_functional_image` oder vorhandene paketdigest-Images wieder, statt neu zu bauen. Docker-Image-Pulls werden mit einem begrenzten Timeout von 180 Sekunden pro Versuch erneut versucht, sodass ein hängender Registry-/Cache-Stream schnell erneut versucht wird, statt den Großteil des kritischen CI-Pfads zu verbrauchen. +Der wiederverwendbare Live-/E2E-Workflow fragt mit `scripts/test-docker-all.mjs --plan-json` ab, welche Paket-, Image-Art-, Live-Image-, Lane- und Anmeldedatenabdeckung erforderlich ist. `scripts/docker-e2e.mjs` wandelt diesen Plan anschließend in GitHub-Ausgaben und Zusammenfassungen um. Er paketiert OpenClaw entweder über `scripts/package-openclaw-for-docker.mjs`, lädt ein Paketartefakt aus dem aktuellen Lauf herunter oder lädt ein Paketartefakt aus `package_artifact_run_id`; validiert das Tarball-Inventar; baut und pusht paket-digest-getaggte Bare-/Functional-GHCR-Docker-E2E-Images über Blacksmiths Docker-Layer-Cache, wenn der Plan Lanes mit installiertem Paket benötigt; und verwendet bereitgestellte Eingaben `docker_e2e_bare_image`/`docker_e2e_functional_image` oder vorhandene Paket-Digest-Images wieder, anstatt neu zu bauen. Docker-Image-Pulls werden mit einem begrenzten Timeout von 180 Sekunden pro Versuch wiederholt, sodass ein festhängender Registry-/Cache-Stream schnell erneut versucht wird, statt den Großteil des kritischen CI-Pfads zu verbrauchen. ### Release-Pfad-Chunks @@ -287,103 +287,103 @@ Release-Docker-Abdeckung läuft in kleineren gechunkten Jobs mit `OPENCLAW_SKIP_ - `OPENCLAW_DOCKER_ALL_PROFILE=release-path` - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels` -Aktuelle Release-Docker-Chunks sind `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` bis `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` und `bundled-channels-contracts`. Der aggregierte Chunk `bundled-channels` bleibt für manuelle einmalige Neuausführungen verfügbar, und `plugins-runtime-core`, `plugins-runtime` sowie `plugins-integrations` bleiben aggregierte Plugin-/Runtime-Aliasse. Der Lane-Alias `install-e2e` bleibt der aggregierte manuelle Neuausführungsalias für beide Provider-Installer-Lanes. Der Chunk `bundled-channels` führt aufgeteilte Lanes `bundled-channel-*` und `bundled-channel-update-*` aus, nicht die serielle All-in-one-Lane `bundled-channel-deps`. +Aktuelle Release-Docker-Abschnitte sind `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` bis `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` und `bundled-channels-contracts`. Der aggregierte Abschnitt `bundled-channels` bleibt für manuelle einmalige Wiederholungen verfügbar, und `plugins-runtime-core`, `plugins-runtime` sowie `plugins-integrations` bleiben aggregierte Plugin-/Runtime-Aliasse. Der Lane-Alias `install-e2e` bleibt der aggregierte manuelle Wiederholungsalias für beide Provider-Installer-Lanes. Der Abschnitt `bundled-channels` führt aufgeteilte Lanes `bundled-channel-*` und `bundled-channel-update-*` aus, statt der seriellen All-in-one-Lane `bundled-channel-deps`. -OpenWebUI wird in `plugins-runtime-services` integriert, wenn vollständige Release-Pfad-Abdeckung dies anfordert, und behält einen eigenständigen Chunk `openwebui` nur für reine OpenWebUI-Dispatches. Update-Lanes für gebündelte Kanäle wiederholen sich einmal bei vorübergehenden npm-Netzwerkfehlern. +OpenWebUI wird in `plugins-runtime-services` integriert, wenn vollständige Abdeckung des Release-Pfads dies anfordert, und behält einen eigenständigen Abschnitt `openwebui` nur für reine OpenWebUI-Ausführungen. Aktualisierungs-Lanes für gebündelte Kanäle wiederholen sich bei vorübergehenden npm-Netzwerkfehlern einmal. -Jeder Chunk lädt `.artifacts/docker-tests/` mit Lane-Logs, Timings, `summary.json`, `failures.json`, Phasen-Timings, Scheduler-Plan-JSON, Tabellen langsamer Lanes und Neuausführungsbefehlen pro Lane hoch. Die Workflow-Eingabe `docker_lanes` führt ausgewählte Lanes gegen die vorbereiteten Images aus statt der Chunk-Jobs. Dadurch bleibt das Debugging fehlgeschlagener Lanes auf einen gezielten Docker-Job begrenzt und das Paketartefakt wird für diesen Lauf vorbereitet, heruntergeladen oder wiederverwendet; wenn eine ausgewählte Lane eine Live-Docker-Lane ist, baut der gezielte Job das Live-Test-Image lokal für diese Neuausführung. Generierte GitHub-Neuausführungsbefehle pro Lane enthalten `package_artifact_run_id`, `package_artifact_name` und vorbereitete Image-Eingaben, wenn diese Werte vorhanden sind, sodass eine fehlgeschlagene Lane exakt das Paket und die Images aus dem fehlgeschlagenen Lauf wiederverwenden kann. +Jeder Abschnitt lädt `.artifacts/docker-tests/` mit Lane-Logs, Zeitmessungen, `summary.json`, `failures.json`, Phasenzeiten, Scheduler-Plan-JSON, Tabellen langsamer Lanes und Wiederholungsbefehlen pro Lane hoch. Die Workflow-Eingabe `docker_lanes` führt ausgewählte Lanes gegen die vorbereiteten Images aus statt der Abschnitt-Jobs. Dadurch bleibt die Fehlersuche für fehlgeschlagene Lanes auf einen gezielten Docker-Job begrenzt und das Paketartefakt für diesen Lauf wird vorbereitet, heruntergeladen oder wiederverwendet; wenn eine ausgewählte Lane eine Live-Docker-Lane ist, baut der gezielte Job das Live-Test-Image lokal für diese Wiederholung. Generierte GitHub-Wiederholungsbefehle pro Lane enthalten `package_artifact_run_id`, `package_artifact_name` und vorbereitete Image-Eingaben, wenn diese Werte vorhanden sind, sodass eine fehlgeschlagene Lane exakt dasselbe Paket und dieselben Images aus dem fehlgeschlagenen Lauf wiederverwenden kann. ```bash pnpm test:docker:rerun # download Docker artifacts and print combined/per-lane targeted rerun commands pnpm test:docker:timings # slow-lane and phase critical-path summaries ``` -Der geplante Live-/E2E-Workflow führt die vollständige Docker-Suite für den Release-Pfad täglich aus. +Der geplante Live-/E2E-Workflow führt täglich die vollständige Docker-Suite des Release-Pfads aus. ## Plugin-Vorabversion -`Plugin Prerelease` ist aufwendigere Produkt-/Paketabdeckung und daher ein separater Workflow, der von `Full Release Validation` oder durch einen expliziten Operator ausgelöst wird. Normale Pull Requests, Pushes nach `main` und eigenständige manuelle CI-Dispatches lassen diese Suite deaktiviert. Er verteilt gebündelte Plugin-Tests auf acht Extension-Worker; diese Extension-Shard-Jobs führen bis zu zwei Plugin-Konfigurationsgruppen gleichzeitig aus, mit einem Vitest-Worker pro Gruppe und einem größeren Node-Heap, damit importlastige Plugin-Batches keine zusätzlichen CI-Jobs erzeugen. +`Plugin Prerelease` ist eine teurere Produkt-/Paketabdeckung und daher ein separater Workflow, der von `Full Release Validation` oder durch einen expliziten Operator ausgelöst wird. Normale Pull Requests, `main`-Pushes und eigenständige manuelle CI-Ausführungen lassen diese Suite deaktiviert. Sie verteilt gebündelte Plugin-Tests auf acht Erweiterungs-Worker; diese Erweiterungs-Shard-Jobs führen bis zu zwei Plugin-Konfigurationsgruppen gleichzeitig aus, mit einem Vitest-Worker pro Gruppe und einem größeren Node-Heap, damit importlastige Plugin-Stapel keine zusätzlichen CI-Jobs erzeugen. ## QA Lab -QA Lab hat dedizierte CI-Lanes außerhalb des zentralen smart gescopten Workflows. +QA Lab verfügt über dedizierte CI-Lanes außerhalb des wichtigsten smart eingegrenzten Workflows. -- Der Workflow `Parity gate` läuft bei passenden PR-Änderungen und manuellem Dispatch; er baut die private QA-Runtime und vergleicht die agentischen Mock-Packs GPT-5.5 und Opus 4.6. -- Der Workflow `QA-Lab - All Lanes` läuft nächtlich auf `main` und bei manuellem Dispatch; er fächert das Mock-Parity-Gate, die Live-Matrix-Lane sowie die Live-Lanes für Telegram und Discord als parallele Jobs auf. Live-Jobs verwenden die Umgebung `qa-live-shared`, und Telegram/Discord verwenden Convex-Leases. +- Der Workflow `Parity gate` läuft bei passenden PR-Änderungen und manueller Ausführung; er baut die private QA-Runtime und vergleicht die agentischen Pakete mit Mock GPT-5.5 und Opus 4.6. +- Der Workflow `QA-Lab - All Lanes` läuft nächtlich auf `main` und bei manueller Ausführung; er fächert das Mock-Paritäts-Gate, die Live-Matrix-Lane sowie die Live-Telegram- und Discord-Lanes als parallele Jobs auf. Live-Jobs verwenden die Umgebung `qa-live-shared`, und Telegram/Discord verwenden Convex-Leases. -Release-Prüfungen führen Matrix- und Telegram-Live-Transport-Lanes mit dem deterministischen Mock-Provider und mock-qualifizierten Modellen (`mock-openai/gpt-5.5` und `mock-openai/gpt-5.5-alt`) aus, sodass der Kanalvertrag von Live-Modelllatenz und normalem Start des Provider-Plugins isoliert ist. Das Live-Transport-Gateway deaktiviert die Speichersuche, weil QA-Parität das Speicherverhalten separat abdeckt; Provider-Konnektivität wird durch die separaten Suites für Live-Modell, nativen Provider und Docker-Provider abgedeckt. +Release-Prüfungen führen Matrix- und Telegram-Live-Transport-Lanes mit dem deterministischen Mock-Provider und mockqualifizierten Modellen (`mock-openai/gpt-5.5` und `mock-openai/gpt-5.5-alt`) aus, damit der Kanalvertrag von Live-Modell-Latenz und normalem Start des Provider-Plugins isoliert ist. Das Live-Transport-Gateway deaktiviert die Speichersuche, weil QA-Parität das Speicherverhalten separat abdeckt; Provider-Konnektivität wird durch die separaten Suiten für Live-Modelle, native Provider und Docker-Provider abgedeckt. -Matrix verwendet `--profile fast` für geplante Gates und Release-Gates und fügt `--fail-fast` nur hinzu, wenn die ausgecheckte CLI dies unterstützt. Der CLI-Standard und die manuelle Workflow-Eingabe bleiben `all`; ein manueller Dispatch mit `matrix_profile=all` shardet die vollständige Matrix-Abdeckung immer in die Jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` und `e2ee-cli`. +Matrix verwendet `--profile fast` für geplante und Release-Gates und ergänzt `--fail-fast` nur, wenn die ausgecheckte CLI dies unterstützt. Die CLI-Standardeinstellung und die manuelle Workflow-Eingabe bleiben `all`; eine manuelle Ausführung mit `matrix_profile=all` teilt die vollständige Matrix-Abdeckung immer in die Jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` und `e2ee-cli` auf. -`OpenClaw Release Checks` führt außerdem die releasekritischen QA-Lab-Lanes vor der Release-Freigabe aus; sein QA-Parity-Gate führt Kandidaten- und Baseline-Packs als parallele Lane-Jobs aus und lädt anschließend beide Artefakte in einen kleinen Bericht-Job für den finalen Paritätsvergleich herunter. +`OpenClaw Release Checks` führt außerdem die releasekritischen QA-Lab-Lanes vor der Release-Freigabe aus; sein QA-Paritäts-Gate führt die Kandidaten- und Baseline-Pakete als parallele Lane-Jobs aus und lädt anschließend beide Artefakte in einen kleinen Report-Job für den finalen Paritätsvergleich herunter. -Setzen Sie den PR-Landepfad nicht hinter `Parity gate`, es sei denn, die Änderung betrifft tatsächlich die QA-Runtime, Modell-Pack-Parität oder eine Oberfläche, die dem Parity-Workflow gehört. Für normale Kanal-, Konfigurations-, Dokumentations- oder Unit-Test-Korrekturen behandeln Sie es als optionales Signal und folgen stattdessen den gescopten CI-/Prüfnachweisen. +Setzen Sie den PR-Landing-Pfad nicht hinter `Parity gate`, sofern die Änderung nicht tatsächlich die QA-Runtime, Modellpaket-Parität oder eine Oberfläche berührt, die dem Paritäts-Workflow gehört. Behandeln Sie es bei normalen Korrekturen an Kanälen, Konfiguration, Dokumentation oder Unit-Tests als optionales Signal und folgen Sie stattdessen den eingegrenzten CI-/Prüfnachweisen. ## CodeQL -Der Workflow `CodeQL` ist bewusst ein enger erster Security-Scanner, nicht der vollständige Repository-Sweep. Tägliche, manuelle und nicht als Draft markierte Pull-Request-Guard-Läufe scannen Actions-Workflow-Code plus die JavaScript-/TypeScript-Oberflächen mit dem höchsten Risiko und verwenden dabei hochkonfidente Sicherheitsabfragen, gefiltert auf hohe/kritische `security-severity`. +Der Workflow `CodeQL` ist absichtlich ein enger erster Sicherheits-Scanner, nicht der vollständige Repository-Durchlauf. Tägliche, manuelle und Nicht-Draft-Pull-Request-Schutzläufe scannen Actions-Workflow-Code sowie die JavaScript-/TypeScript-Oberflächen mit dem höchsten Risiko mit Security-Queries hoher Konfidenz, gefiltert auf hohe/kritische `security-severity`. -Der Pull-Request-Guard bleibt schlank: Er startet nur bei Änderungen unter `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` oder `src` und führt dieselbe hochkonfidente Sicherheitsmatrix wie der geplante Workflow aus. Android- und macOS-CodeQL bleiben außerhalb der PR-Standards. +Der Pull-Request-Schutz bleibt leichtgewichtig: Er startet nur bei Änderungen unter `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` oder `src` und führt dieselbe Security-Matrix hoher Konfidenz aus wie der geplante Workflow. Android- und macOS-CodeQL bleiben aus den PR-Standardeinstellungen heraus. ### Sicherheitskategorien -| Kategorie | Oberfläche | +| Kategorie | Oberfläche | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Auth, Secrets, Sandbox, Cron und Gateway-Baseline | -| `/codeql-security-high/channel-runtime-boundary` | Implementierungsverträge der Kernkanäle plus Kanal-Plugin-Runtime, Gateway, Plugin SDK, Secrets, Audit-Berührungspunkte | -| `/codeql-security-high/network-ssrf-boundary` | Kern-SSRF, IP-Parsing, Netzwerk-Guard, Web-Fetch und SSRF-Policy-Oberflächen des Plugin SDK | -| `/codeql-security-high/mcp-process-tool-boundary` | MCP-Server, Hilfen zur Prozessausführung, ausgehende Zustellung und Gates für Agent-Tool-Ausführung | -| `/codeql-security-high/plugin-trust-boundary` | Plugin-Installation, Loader, Manifest, Registry, Staging von Runtime-Abhängigkeiten, Quellcode-Laden und Vertrauensoberflächen des Plugin-SDK-Paketvertrags | +| `/codeql-security-high/core-auth-secrets` | Authentifizierung, Secrets, Sandbox, Cron und Gateway-Baseline | +| `/codeql-security-high/channel-runtime-boundary` | Kernverträge der Kanalimplementierung plus Kanal-Plugin-Runtime, Gateway, Plugin SDK, Secrets, Audit-Berührungspunkte | +| `/codeql-security-high/network-ssrf-boundary` | Kern-SSRF, IP-Parsing, Netzwerk-Guard, Web-Fetch und SSRF-Richtlinienoberflächen des Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | MCP-Server, Prozessausführungshelfer, ausgehende Zustellung und Gates für die Tool-Ausführung von Agenten | +| `/codeql-security-high/plugin-trust-boundary` | Plugin-Installation, Loader, Manifest, Registry, Runtime-Abhängigkeits-Staging, Quellladen und Vertrauensoberflächen des Plugin-SDK-Paketvertrags | -### Plattformspezifische Security-Shards +### Plattformspezifische Sicherheits-Shards -- `CodeQL Android Critical Security` — geplanter Android-Security-Shard. Baut die Android-App manuell für CodeQL auf dem kleinsten Blacksmith-Linux-Runner, der von der Workflow-Sanity akzeptiert wird. Lädt unter `/codeql-critical-security/android` hoch. -- `CodeQL macOS Critical Security` — wöchentlicher/manueller macOS-Security-Shard. Baut die macOS-App manuell für CodeQL auf Blacksmith macOS, filtert Ergebnisse von Dependency-Builds aus dem hochgeladenen SARIF heraus und lädt unter `/codeql-critical-security/macos` hoch. Bleibt außerhalb der täglichen Standards, weil der macOS-Build auch bei sauberem Lauf die Laufzeit dominiert. +- `CodeQL Android Critical Security` — geplanter Android-Sicherheits-Shard. Baut die Android-App manuell für CodeQL auf dem kleinsten Blacksmith-Linux-Runner, den die Workflow-Sanity akzeptiert. Lädt unter `/codeql-critical-security/android` hoch. +- `CodeQL macOS Critical Security` — wöchentlicher/manueller macOS-Sicherheits-Shard. Baut die macOS-App manuell für CodeQL auf Blacksmith macOS, filtert Build-Ergebnisse von Abhängigkeiten aus dem hochgeladenen SARIF heraus und lädt unter `/codeql-critical-security/macos` hoch. Bleibt außerhalb täglicher Standardeinstellungen, weil der macOS-Build die Laufzeit selbst bei sauberem Zustand dominiert. ### Kategorien für kritische Qualität -`CodeQL Critical Quality` ist der entsprechende Nicht-Security-Shard. Er führt nur JavaScript-/TypeScript-Qualitätsabfragen mit Fehler-Schweregrad und ohne Security-Bezug über eng begrenzte hochwertige Oberflächen auf dem kleineren Blacksmith-Linux-Runner aus. Sein Pull-Request-Guard ist bewusst kleiner als das geplante Profil: Nicht-Draft-PRs führen nur die passenden Shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` und `plugin-sdk-reply-runtime` für Änderungen an Agent-Befehls-/Modell-/Tool-Ausführung und Reply-Dispatch-Code, Konfigurationsschema-/Migrations-/IO-Code, Auth-/Secrets-/Sandbox-/Security-Code, Kernkanal- und gebündelter Kanal-Plugin-Runtime, Gateway-Protokoll-/Server-Method-Code, Memory-Runtime-/SDK-Glue, MCP-/Prozess-/ausgehender Zustellung, Provider-Runtime-/Modellkatalog, Sitzungsdiagnose-/Zustellungswarteschlangen, Plugin-Loader, Plugin-SDK-/Paketvertrag oder Plugin-SDK-Reply-Runtime aus. Änderungen an CodeQL-Konfiguration und Qualitätsworkflow führen alle zwölf PR-Qualitäts-Shards aus. +`CodeQL Critical Quality` ist der passende Nicht-Sicherheits-Shard. Er führt ausschließlich JavaScript-/TypeScript-Qualitätsabfragen mit Fehler-Schweregrad und ohne Sicherheitsbezug über enge, hochwertige Oberflächen auf dem kleineren Blacksmith-Linux-Runner aus. Sein Pull-Request-Schutz ist absichtlich kleiner als das geplante Profil: Nicht-Draft-PRs führen nur die passenden Shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` und `plugin-sdk-reply-runtime` für Änderungen an Agentenbefehls-/Modell-/Tool-Ausführung und Reply-Dispatch-Code, Konfigurationsschema-/Migrations-/IO-Code, Auth-/Secrets-/Sandbox-/Sicherheitscode, Kernkanal- und gebündelter Kanal-Plugin-Runtime, Gateway-Protokoll-/Server-Methoden, Memory-Runtime-/SDK-Verbindungscode, MCP-/Prozess-/ausgehender Zustellung, Provider-Runtime-/Modellkatalog, Sitzungsdiagnose-/Zustellungswarteschlangen, Plugin-Loader, Plugin-SDK-/Paketvertrag oder Plugin-SDK-Reply-Runtime aus. Änderungen an CodeQL-Konfiguration und Qualitäts-Workflow führen alle zwölf PR-Qualitäts-Shards aus. -Manueller Dispatch akzeptiert: +Manuelle Ausführung akzeptiert: ``` profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary ``` -Die engen Profile sind Lern-/Iterations-Hooks, um einen Qualitäts-Shard isoliert auszuführen. +Die engen Profile sind Lehr-/Iterations-Hooks, um einen Qualitäts-Shard isoliert auszuführen. -| Kategorie | Oberfläche | -| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Auth-, Secret-, Sandbox-, Cron- und Gateway-Sicherheitsgrenzcode | -| `/codeql-critical-quality/config-boundary` | Konfigurationsschema, Migration, Normalisierung und IO-Verträge | -| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway-Protokollschemata und Servermethoden-Verträge | -| `/codeql-critical-quality/channel-runtime-boundary` | Verträge für Core-Kanäle und Implementierungen gebündelter Channel-Plugins | -| `/codeql-critical-quality/agent-runtime-boundary` | Befehlsausführung, Model-/Provider-Dispatch, Auto-Reply-Dispatch und Warteschlangen sowie Runtime-Verträge der ACP-Control-Plane | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-Server und Tool-Bridges, Hilfen zur Prozessüberwachung und Verträge für ausgehende Zustellung | -| `/codeql-critical-quality/memory-runtime-boundary` | Memory-Host-SDK, Memory-Runtime-Fassaden, Memory-Aliase des Plugin SDK, Aktivierungs-Glue der Memory-Runtime und Memory-Doctor-Befehle | -| `/codeql-critical-quality/session-diagnostics-boundary` | Interna der Antwortwarteschlange, Sitzungs-Zustellungswarteschlangen, Hilfen für ausgehende Sitzungsbindung/-zustellung, Oberflächen für Diagnoseereignisse/Log-Bundles und Sitzungs-Doctor-CLI-Verträge | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Eingehender Reply-Dispatch des Plugin SDK, Hilfen für Reply-Payload/Chunking/Runtime, Channel-Reply-Optionen, Zustellungswarteschlangen und Hilfen für Sitzungs-/Thread-Bindung | -| `/codeql-critical-quality/provider-runtime-boundary` | Normalisierung des Model-Katalogs, Provider-Auth und -Discovery, Provider-Runtime-Registrierung, Provider-Defaults/-Kataloge sowie Web-/Search-/Fetch-/Embedding-Registries | -| `/codeql-critical-quality/ui-control-plane` | Control-UI-Bootstrap, lokale Persistenz, Gateway-Control-Flows und Runtime-Verträge der Task-Control-Plane | -| `/codeql-critical-quality/web-media-runtime-boundary` | Core-Web-Fetch/Search, Medien-IO, Medienverständnis, Bilderzeugung und Runtime-Verträge für Medienerzeugung | -| `/codeql-critical-quality/plugin-boundary` | Verträge für Loader, Registry, öffentliche Oberfläche und Plugin SDK-Einstiegspunkte | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Veröffentlichter package-seitiger Plugin SDK-Quellcode und Hilfen für Plugin-Package-Verträge | +| Kategorie | Bereich | +| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-critical-quality/core-auth-secrets` | Authentifizierung, Secrets, Sandbox, Cron und Code für die Sicherheitsgrenze des Gateway | +| `/codeql-critical-quality/config-boundary` | Konfigurationsschema, Migration, Normalisierung und IO-Verträge | +| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway-Protokollschemata und Verträge für Servermethoden | +| `/codeql-critical-quality/channel-runtime-boundary` | Core-Kanal- und Implementierungsverträge für gebündelte Kanal-Plugins | +| `/codeql-critical-quality/agent-runtime-boundary` | Befehlsausführung, Modell-/Provider-Dispatch, Auto-Reply-Dispatch und Warteschlangen sowie Laufzeitverträge der ACP-Control-Plane | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-Server und Tool-Brücken, Hilfsfunktionen für Prozessüberwachung und Verträge für ausgehende Zustellung | +| `/codeql-critical-quality/memory-runtime-boundary` | Memory-Host-SDK, Memory-Laufzeitfassaden, Memory-Plugin-SDK-Aliase, Memory-Laufzeitaktivierungs-Glue und Memory-Doctor-Befehle | +| `/codeql-critical-quality/session-diagnostics-boundary` | Interna der Antwortwarteschlange, Sitzungszustellungswarteschlangen, Hilfsfunktionen für ausgehende Sitzungsbindung/-zustellung, Oberflächen für Diagnoseereignisse/Log-Bundles und Sitzungs-Doctor-CLI-Verträge | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Eingehender Antwort-Dispatch des Plugin-SDK, Antwort-Payload-/Chunking-/Laufzeit-Hilfsfunktionen, Kanalantwortoptionen, Zustellungswarteschlangen und Hilfsfunktionen für Sitzungs-/Thread-Bindung | +| `/codeql-critical-quality/provider-runtime-boundary` | Modellkatalog-Normalisierung, Provider-Authentifizierung und -Erkennung, Provider-Laufzeitregistrierung, Provider-Standards/-Kataloge und Web-/Such-/Fetch-/Embedding-Registries | +| `/codeql-critical-quality/ui-control-plane` | Bootstrap der Control-UI, lokale Persistenz, Gateway-Control-Flows und Laufzeitverträge der Task-Control-Plane | +| `/codeql-critical-quality/web-media-runtime-boundary` | Core-Web-Fetch/-Suche, Medien-IO, Medienverständnis, Bildgenerierung und Laufzeitverträge für Mediengenerierung | +| `/codeql-critical-quality/plugin-boundary` | Loader-, Registry-, Public-Surface- und Plugin-SDK-Entrypoint-Verträge | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Veröffentlichter paketbezogener Plugin-SDK-Quellcode und Hilfsfunktionen für Plugin-Paketverträge | -Qualität bleibt von Sicherheit getrennt, damit Qualitätsbefunde geplant, gemessen, deaktiviert oder erweitert werden können, ohne das Sicherheitssignal zu verschleiern. Die CodeQL-Erweiterung für Swift, Python und gebündelte Plugins sollte erst wieder als scoped oder sharded Folgearbeit hinzugefügt werden, nachdem die engen Profile stabile Runtime und stabiles Signal haben. +Qualität bleibt von Sicherheit getrennt, damit Qualitätsbefunde geplant, gemessen, deaktiviert oder erweitert werden können, ohne das Sicherheitssignal zu verdecken. Die CodeQL-Erweiterung für Swift, Python und gebündelte Plugins sollte erst dann wieder als eingegrenzte oder geshardete Nacharbeit hinzugefügt werden, wenn die schmalen Profile eine stabile Laufzeit und ein stabiles Signal haben. ## Wartungsworkflows ### Docs Agent -Der Workflow `Docs Agent` ist eine ereignisgesteuerte Codex-Wartungslane, um vorhandene Dokumentation an kürzlich gelandete Änderungen anzupassen. Er hat keinen reinen Zeitplan: Ein erfolgreicher Nicht-Bot-Push-CI-Lauf auf `main` kann ihn auslösen, und ein manueller Dispatch kann ihn direkt ausführen. Workflow-Run-Aufrufe werden übersprungen, wenn `main` bereits weitergelaufen ist oder wenn in der letzten Stunde ein anderer nicht übersprungener Docs-Agent-Lauf erstellt wurde. Wenn er ausgeführt wird, prüft er den Commit-Bereich vom vorherigen nicht übersprungenen Docs-Agent-Quell-SHA bis zum aktuellen `main`, sodass ein stündlicher Lauf alle Main-Änderungen abdecken kann, die sich seit dem letzten Dokumentationsdurchlauf angesammelt haben. +Der Workflow `Docs Agent` ist eine ereignisgesteuerte Codex-Wartungsspur, die bestehende Dokumentation mit kürzlich gelandeten Änderungen abgleicht. Er hat keinen reinen Zeitplan: Ein erfolgreicher Nicht-Bot-Push-CI-Lauf auf `main` kann ihn auslösen, und ein manueller Dispatch kann ihn direkt ausführen. Workflow-Run-Aufrufe werden übersprungen, wenn `main` bereits weitergelaufen ist oder wenn in der letzten Stunde ein anderer nicht übersprungener Docs-Agent-Lauf erstellt wurde. Wenn er läuft, prüft er den Commit-Bereich von der vorherigen nicht übersprungenen Docs-Agent-Quell-SHA bis zum aktuellen `main`, sodass ein stündlicher Lauf alle Änderungen auf main abdecken kann, die seit dem letzten Dokumentationsdurchlauf aufgelaufen sind. ### Test Performance Agent -Der Workflow `Test Performance Agent` ist eine ereignisgesteuerte Codex-Wartungslane für langsame Tests. Er hat keinen reinen Zeitplan: Ein erfolgreicher Nicht-Bot-Push-CI-Lauf auf `main` kann ihn auslösen, aber er wird übersprungen, wenn an diesem UTC-Tag bereits ein anderer Workflow-Run-Aufruf gelaufen ist oder läuft. Manueller Dispatch umgeht dieses tägliche Aktivitäts-Gate. Die Lane erstellt einen gruppierten Vitest-Performance-Bericht für die gesamte Suite, lässt Codex nur kleine, coverage-erhaltende Test-Performance-Fixes statt breiter Refactorings vornehmen, führt dann den Full-Suite-Bericht erneut aus und lehnt Änderungen ab, die die Baseline-Anzahl bestandener Tests verringern. Wenn die Baseline fehlgeschlagene Tests hat, darf Codex nur offensichtliche Fehler beheben, und der Full-Suite-Bericht nach dem Agent muss bestehen, bevor etwas committet wird. Wenn `main` vor dem Bot-Push weiterläuft, rebased die Lane den validierten Patch, führt `pnpm check:changed` erneut aus und versucht den Push erneut; kollidierende veraltete Patches werden übersprungen. Sie verwendet GitHub-gehostetes Ubuntu, damit die Codex-Action dieselbe Drop-Sudo-Sicherheitshaltung wie der Docs Agent beibehalten kann. +Der Workflow `Test Performance Agent` ist eine ereignisgesteuerte Codex-Wartungsspur für langsame Tests. Er hat keinen reinen Zeitplan: Ein erfolgreicher Nicht-Bot-Push-CI-Lauf auf `main` kann ihn auslösen, aber er wird übersprungen, wenn ein anderer Workflow-Run-Aufruf an diesem UTC-Tag bereits gelaufen ist oder läuft. Ein manueller Dispatch umgeht dieses tägliche Aktivitäts-Gate. Die Spur erstellt einen gruppierten Vitest-Performancebericht für die gesamte Suite, lässt Codex nur kleine, abdeckungserhaltende Test-Performance-Fixes statt breiter Refactorings vornehmen, führt den Bericht für die gesamte Suite anschließend erneut aus und lehnt Änderungen ab, die die Baseline-Anzahl bestandener Tests reduzieren. Wenn die Baseline fehlschlagende Tests enthält, darf Codex nur offensichtliche Fehler beheben, und der Full-Suite-Bericht nach dem Agenten muss bestehen, bevor etwas committet wird. Wenn `main` vor dem Bot-Push weiterläuft, rebased die Spur den validierten Patch, führt `pnpm check:changed` erneut aus und versucht den Push erneut; widersprüchliche veraltete Patches werden übersprungen. Sie verwendet GitHub-gehostetes Ubuntu, damit die Codex-Action dieselbe Drop-Sudo-Sicherheitsausrichtung wie der Docs-Agent beibehalten kann. -### Doppelte PRs nach Merge +### Doppelte PRs nach dem Merge -Der Workflow `Duplicate PRs After Merge` ist ein manueller Maintainer-Workflow für die Bereinigung doppelter PRs nach dem Landen. Standardmäßig läuft er als Dry-Run und schließt explizit aufgelistete PRs nur, wenn `apply=true` ist. Bevor GitHub verändert wird, prüft er, dass der gelandete PR gemergt ist und dass jeder doppelte PR entweder ein gemeinsam referenziertes Issue oder überlappende geänderte Hunks hat. +Der Workflow `Duplicate PRs After Merge` ist ein manueller Maintainer-Workflow für die Bereinigung doppelter PRs nach dem Landen. Standardmäßig läuft er als Dry-Run und schließt nur explizit aufgeführte PRs, wenn `apply=true` gesetzt ist. Bevor GitHub mutiert wird, prüft er, dass der gelandete PR gemergt wurde und dass jedes Duplikat entweder ein gemeinsam referenziertes Issue oder überlappende geänderte Hunks hat. ```bash gh workflow run duplicate-after-merge.yml \ @@ -392,29 +392,29 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Lokale Check-Gates und Änderungsrouting +## Lokale Check-Gates und Routing geänderter Dateien -Die lokale Changed-Lane-Logik liegt in `scripts/changed-lanes.mjs` und wird von `scripts/check-changed.mjs` ausgeführt. Dieses lokale Check-Gate ist bei Architekturgrenzen strenger als der breite CI-Plattform-Scope: +Die lokale Changed-Lane-Logik befindet sich in `scripts/changed-lanes.mjs` und wird von `scripts/check-changed.mjs` ausgeführt. Dieses lokale Check-Gate ist bei Architekturgrenzen strenger als der breite Scope der CI-Plattform: -- Core-Produktionsänderungen führen Core-Prod- und Core-Test-Typecheck plus Core-Lint/Guards aus; -- reine Core-Teständerungen führen nur Core-Test-Typecheck plus Core-Lint aus; -- Extension-Produktionsänderungen führen Extension-Prod- und Extension-Test-Typecheck plus Extension-Lint aus; -- reine Extension-Teständerungen führen Extension-Test-Typecheck plus Extension-Lint aus; -- Änderungen am öffentlichen Plugin SDK oder an Plugin-Verträgen werden auf Extension-Typecheck erweitert, weil Extensions von diesen Core-Verträgen abhängen (Vitest-Extension-Sweeps bleiben explizite Testarbeit); +- Core-Produktionsänderungen führen Core-Prod- und Core-Test-Typecheck sowie Core-Lint/Guards aus; +- reine Core-Teständerungen führen nur Core-Test-Typecheck sowie Core-Lint aus; +- Plugin-Produktionsänderungen führen Plugin-Prod- und Plugin-Test-Typecheck sowie Plugin-Lint aus; +- reine Plugin-Teständerungen führen Plugin-Test-Typecheck sowie Plugin-Lint aus; +- Änderungen am öffentlichen Plugin-SDK oder an Plugin-Verträgen erweitern auf Plugin-Typecheck, weil Plugins von diesen Core-Verträgen abhängen (Vitest-Plugin-Sweeps bleiben explizite Testarbeit); - reine Release-Metadaten-Versionsbumps führen gezielte Versions-/Konfigurations-/Root-Dependency-Checks aus; - unbekannte Root-/Konfigurationsänderungen fallen sicherheitshalber auf alle Check-Lanes zurück. -Das lokale Changed-Test-Routing liegt in `scripts/test-projects.test-support.mjs` und ist absichtlich günstiger als `check:changed`: Direkte Teständerungen führen sich selbst aus, Quelländerungen bevorzugen explizite Mappings, dann Geschwistertests und Import-Graph-Abhängige. Die Shared-Group-Room-Zustellungskonfiguration ist eines der expliziten Mappings: Änderungen an der für die Gruppe sichtbaren Reply-Konfiguration, am Source-Reply-Zustellungsmodus oder am Message-Tool-System-Prompt laufen über die Core-Reply-Tests plus Discord- und Slack-Zustellungsregressionen, damit eine Änderung eines gemeinsamen Defaults vor dem ersten PR-Push fehlschlägt. Verwenden Sie `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` nur, wenn die Änderung harness-weit genug ist, dass das günstige gemappte Set kein vertrauenswürdiger Proxy ist. +Das lokale Routing geänderter Tests befindet sich in `scripts/test-projects.test-support.mjs` und ist absichtlich günstiger als `check:changed`: Direkte Teständerungen führen sich selbst aus, Quelländerungen bevorzugen explizite Mappings, danach Geschwistertests und Importgraph-Abhängige. Die Konfiguration für die Zustellung in gemeinsam genutzten Gruppenräumen ist eines der expliziten Mappings: Änderungen an der für Gruppen sichtbaren Antwortkonfiguration, am Quell-Antwortzustellmodus oder am System-Prompt des Message-Tools laufen über die Core-Antworttests plus Discord- und Slack-Zustellungsregressionen, damit eine Änderung an einem gemeinsam genutzten Standard vor dem ersten PR-Push fehlschlägt. Verwenden Sie `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` nur, wenn die Änderung so harness-weit ist, dass die günstige gemappte Menge kein vertrauenswürdiger Proxy ist. ## Testbox-Validierung -Führen Sie Testbox vom Repo-Root aus und bevorzugen Sie für breiten Nachweis eine frisch vorgewärmte Box. Bevor Sie ein langsames Gate auf einer Box ausführen, die wiederverwendet wurde, abgelaufen ist oder gerade einen unerwartet großen Sync gemeldet hat, führen Sie zuerst `pnpm testbox:sanity` innerhalb der Box aus. +Führen Sie Testbox aus dem Repo-Root aus und bevorzugen Sie für breite Nachweise eine frisch vorgewärmte Box. Bevor Sie ein langsames Gate auf einer Box ausgeben, die wiederverwendet wurde, abgelaufen ist oder gerade eine unerwartet große Synchronisierung gemeldet hat, führen Sie zuerst `pnpm testbox:sanity` innerhalb der Box aus. -Der Sanity-Check schlägt schnell fehl, wenn erforderliche Root-Dateien wie `pnpm-lock.yaml` verschwunden sind oder wenn `git status --short` mindestens 200 getrackte Löschungen zeigt. Das bedeutet in der Regel, dass der Remote-Sync-Status keine vertrauenswürdige Kopie des PR ist; stoppen Sie diese Box und wärmen Sie eine frische auf, statt den Produkttestfehler zu debuggen. Für absichtliche PRs mit vielen Löschungen setzen Sie für diesen Sanity-Lauf `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1`. +Der Sanity-Check schlägt schnell fehl, wenn erforderliche Root-Dateien wie `pnpm-lock.yaml` verschwunden sind oder wenn `git status --short` mindestens 200 getrackte Löschungen anzeigt. Das bedeutet in der Regel, dass der Remote-Sync-Status keine vertrauenswürdige Kopie des PR ist; stoppen Sie diese Box und wärmen Sie eine frische vor, statt den Produkt-Testfehler zu debuggen. Für beabsichtigte PRs mit vielen Löschungen setzen Sie für diesen Sanity-Lauf `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1`. -`pnpm testbox:run` beendet außerdem einen lokalen Blacksmith-CLI-Aufruf, der länger als fünf Minuten ohne Post-Sync-Ausgabe in der Sync-Phase bleibt. Setzen Sie `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, um diesen Guard zu deaktivieren, oder verwenden Sie für ungewöhnlich große lokale Diffs einen größeren Millisekundenwert. +`pnpm testbox:run` beendet außerdem eine lokale Blacksmith-CLI-Ausführung, die länger als fünf Minuten ohne Ausgabe nach der Synchronisierung in der Synchronisierungsphase verbleibt. Setzen Sie `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, um diese Schutzvorrichtung zu deaktivieren, oder verwenden Sie für ungewöhnlich große lokale Diffs einen größeren Millisekundenwert. ## Verwandt -- [Installationsüberblick](/de/install) +- [Installationsübersicht](/de/install) - [Entwicklungskanäle](/de/install/development-channels) diff --git a/docs/de/concepts/agent-loop.md b/docs/de/concepts/agent-loop.md index affbadb72..fdb4e352d 100644 --- a/docs/de/concepts/agent-loop.md +++ b/docs/de/concepts/agent-loop.md @@ -1,154 +1,155 @@ --- read_when: - - Sie benötigen eine genaue Schritt-für-Schritt-Anleitung zur Agenten-Schleife oder zu Lifecycle-Ereignissen - - Sie ändern die Warteschlangenbildung für Sitzungen, Transkript-Schreibvorgänge oder das Verhalten der Schreibsperre für Sitzungen -summary: Lebenszyklus der Agent-Schleife, Streams und Wartesemantik -title: Agent-Schleife + - Sie benötigen eine genaue Schritt-für-Schritt-Anleitung zur Agentenschleife oder zu Lebenszyklusereignissen + - Sie ändern die Warteschlangenverarbeitung von Sitzungen, Transkript-Schreibvorgänge oder das Verhalten der Schreibsperre für Sitzungen +summary: Lebenszyklus des Agent-Loops, Streams und Wartesemantik +title: Agentenschleife x-i18n: - generated_at: "2026-04-30T06:47:44Z" + generated_at: "2026-04-30T18:38:40Z" model: gpt-5.5 provider: openai - source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32 + source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df source_path: concepts/agent-loop.md workflow: 16 --- -Ein agentischer Loop ist die vollständige „echte“ Ausführung eines Agenten: Eingang → Kontextzusammenstellung → Modellinferenz → +Ein agentischer Loop ist der vollständige „echte“ Lauf eines Agenten: Eingang → Kontextzusammenstellung → Modellinferenz → Tool-Ausführung → Streaming-Antworten → Persistenz. Er ist der maßgebliche Pfad, der eine Nachricht -in Aktionen und eine finale Antwort umsetzt und dabei den Sitzungsstatus konsistent hält. +in Aktionen und eine finale Antwort umwandelt und dabei den Sitzungszustand konsistent hält. -In OpenClaw ist ein Loop eine einzelne, serialisierte Ausführung pro Sitzung, die Lebenszyklus- und Stream-Ereignisse -ausgibt, während das Modell denkt, Tools aufruft und Ausgaben streamt. Dieses Dokument erklärt, wie dieser authentische Loop -End-to-End verdrahtet ist. +In OpenClaw ist ein Loop ein einzelner, serialisierter Lauf pro Sitzung, der Lifecycle- und Stream-Ereignisse ausgibt, +während das Modell nachdenkt, Tools aufruft und Ausgaben streamt. Dieses Dokument erklärt, wie dieser authentische Loop +durchgängig verdrahtet ist. ## Einstiegspunkte - Gateway-RPC: `agent` und `agent.wait`. - CLI: Befehl `agent`. -## Funktionsweise (überblicksartig) +## Funktionsweise (allgemein) 1. `agent`-RPC validiert Parameter, löst die Sitzung auf (sessionKey/sessionId), persistiert Sitzungsmetadaten und gibt sofort `{ runId, acceptedAt }` zurück. 2. `agentCommand` führt den Agenten aus: - - löst Modell- sowie Standardwerte für Denken/Verbose/Trace auf + - löst Modell- sowie Thinking/Verbose/Trace-Standardwerte auf - lädt den Skills-Snapshot - ruft `runEmbeddedPiAgent` auf (pi-agent-core-Runtime) - - gibt **Lebenszyklus-Ende/-Fehler** aus, wenn der eingebettete Loop keines ausgibt + - gibt **Lifecycle-Ende/Fehler** aus, falls der eingebettete Loop dies nicht selbst ausgibt 3. `runEmbeddedPiAgent`: - - serialisiert Ausführungen über sitzungsspezifische und globale Queues - - löst Modell und Authentifizierungsprofil auf und erstellt die Pi-Sitzung + - serialisiert Läufe über sitzungsbezogene und globale Queues + - löst Modell und Auth-Profil auf und erstellt die Pi-Sitzung - abonniert Pi-Ereignisse und streamt Assistant-/Tool-Deltas - - erzwingt Timeout -> bricht die Ausführung ab, wenn es überschritten wird + - erzwingt Timeout -> bricht den Lauf ab, wenn er überschritten wird + - bricht bei Codex-App-Server-Turns einen akzeptierten Turn ab, der vor einem terminalen Ereignis keinen App-Server-Fortschritt mehr erzeugt - gibt Payloads und Nutzungsmetadaten zurück 4. `subscribeEmbeddedPiSession` überbrückt pi-agent-core-Ereignisse zum OpenClaw-`agent`-Stream: - Tool-Ereignisse => `stream: "tool"` - Assistant-Deltas => `stream: "assistant"` - - Lebenszyklusereignisse => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`) + - Lifecycle-Ereignisse => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`) 5. `agent.wait` verwendet `waitForAgentRun`: - - wartet auf **Lebenszyklus-Ende/-Fehler** für `runId` + - wartet auf **Lifecycle-Ende/Fehler** für `runId` - gibt `{ status: ok|error|timeout, startedAt, endedAt, error? }` zurück -## Queueing + Nebenläufigkeit +## Queueing und Nebenläufigkeit -- Ausführungen werden pro Sitzungsschlüssel (Sitzungs-Lane) serialisiert und optional über eine globale Lane geführt. +- Läufe werden pro Sitzungsschlüssel (Sitzungs-Lane) und optional über eine globale Lane serialisiert. - Dies verhindert Tool-/Sitzungs-Races und hält den Sitzungsverlauf konsistent. -- Messaging-Kanäle können Queue-Modi (collect/steer/followup) wählen, die in dieses Lane-System einspeisen. - Siehe [Befehls-Queue](/de/concepts/queue). -- Transkriptschreibvorgänge werden außerdem durch eine Sitzungsschreibsperre auf der Sitzungsdatei geschützt. Die Sperre ist - prozessbewusst und dateibasiert, sodass sie Schreibende erfasst, die die prozessinterne Queue umgehen oder aus +- Messaging-Kanäle können Queue-Modi wählen (collect/steer/followup), die dieses Lane-System speisen. + Siehe [Command Queue](/de/concepts/queue). +- Transkript-Schreibvorgänge werden ebenfalls durch eine Sitzungs-Schreibsperre auf der Sitzungsdatei geschützt. Die Sperre ist + prozessbewusst und dateibasiert, sodass sie Writer erfasst, die die In-Process-Queue umgehen oder aus einem anderen Prozess stammen. -- Sitzungsschreibsperren sind standardmäßig nicht reentrant. Wenn ein Helper absichtlich den Erwerb - derselben Sperre verschachtelt und dabei einen logischen Schreibenden beibehält, muss er dies explizit mit +- Sitzungs-Schreibsperren sind standardmäßig nicht wiedereintrittsfähig. Wenn ein Helper absichtlich den Erwerb + derselben Sperre verschachtelt und dabei einen logischen Writer beibehält, muss er dies explizit mit `allowReentrant: true` aktivieren. -## Sitzungs- und Workspace-Vorbereitung +## Vorbereitung von Sitzung und Arbeitsbereich -- Der Workspace wird aufgelöst und erstellt; sandboxed Ausführungen können zu einem Sandbox-Workspace-Root umgeleitet werden. +- Der Arbeitsbereich wird aufgelöst und erstellt; sandboxierte Läufe können auf ein Sandbox-Arbeitsbereich-Root umgeleitet werden. - Skills werden geladen (oder aus einem Snapshot wiederverwendet) und in Umgebung und Prompt injiziert. - Bootstrap-/Kontextdateien werden aufgelöst und in den System-Prompt-Bericht injiziert. -- Eine Sitzungsschreibsperre wird erworben; `SessionManager` wird vor dem Streaming geöffnet und vorbereitet. Jeder - spätere Pfad für Transkript-Neuschreibung, Compaction oder Kürzung muss dieselbe Sperre erwerben, bevor er die Transkriptdatei öffnet oder +- Eine Sitzungs-Schreibsperre wird erworben; `SessionManager` wird vor dem Streaming geöffnet und vorbereitet. Jeder + spätere Pfad zum Neuschreiben, zur Compaction oder zur Kürzung des Transkripts muss dieselbe Sperre erwerben, bevor er die Transkriptdatei öffnet oder verändert. -## Prompt-Zusammenstellung + System-Prompt +## Prompt-Zusammenstellung und System-Prompt -- Der System-Prompt wird aus OpenClaws Basis-Prompt, Skills-Prompt, Bootstrap-Kontext und ausführungsspezifischen Überschreibungen erstellt. -- Modellspezifische Limits und Reserve-Tokens für Compaction werden erzwungen. -- Siehe [System-Prompt](/de/concepts/system-prompt), um zu sehen, was das Modell erhält. +- Der System-Prompt wird aus OpenClaws Basis-Prompt, Skills-Prompt, Bootstrap-Kontext und laufbezogenen Overrides aufgebaut. +- Modellspezifische Limits und reservierte Token für Compaction werden erzwungen. +- Siehe [System-Prompt](/de/concepts/system-prompt) dafür, was das Modell sieht. -## Hook-Punkte (wo Sie eingreifen können) +## Hook-Punkte (an denen Sie eingreifen können) OpenClaw hat zwei Hook-Systeme: -- **Interne Hooks** (Gateway-Hooks): ereignisgesteuerte Skripte für Befehle und Lebenszyklusereignisse. -- **Plugin-Hooks**: Erweiterungspunkte innerhalb des Agent-/Tool-Lebenszyklus und der Gateway-Pipeline. +- **Interne Hooks** (Gateway-Hooks): ereignisgesteuerte Skripte für Befehle und Lifecycle-Ereignisse. +- **Plugin-Hooks**: Erweiterungspunkte innerhalb des Agent-/Tool-Lifecycles und der Gateway-Pipeline. ### Interne Hooks (Gateway-Hooks) -- **`agent:bootstrap`**: läuft beim Erstellen von Bootstrap-Dateien, bevor der System-Prompt finalisiert wird. - Verwenden Sie dies, um Bootstrap-Kontextdateien hinzuzufügen/zu entfernen. -- **Befehls-Hooks**: `/new`, `/reset`, `/stop` und andere Befehlsereignisse (siehe Hooks-Dokument). +- **`agent:bootstrap`**: läuft beim Aufbau von Bootstrap-Dateien, bevor der System-Prompt finalisiert wird. + Verwenden Sie dies, um Bootstrap-Kontextdateien hinzuzufügen oder zu entfernen. +- **Command-Hooks**: `/new`, `/reset`, `/stop` und andere Befehlsereignisse (siehe Hooks-Dokument). Siehe [Hooks](/de/automation/hooks) für Einrichtung und Beispiele. -### Plugin-Hooks (Agent- + Gateway-Lebenszyklus) +### Plugin-Hooks (Agent- und Gateway-Lifecycle) -Diese laufen innerhalb des Agent-Loops oder der Gateway-Pipeline: +Diese laufen innerhalb des Agenten-Loops oder der Gateway-Pipeline: -- **`before_model_resolve`**: läuft vor der Sitzung (keine `messages`), um Provider/Modell vor der Modellauflösung deterministisch zu überschreiben. -- **`before_prompt_build`**: läuft nach dem Laden der Sitzung (mit `messages`), um `prependContext`, `systemPrompt`, `prependSystemContext` oder `appendSystemContext` vor der Prompt-Übermittlung zu injizieren. Verwenden Sie `prependContext` für dynamischen Text pro Turn und Systemkontextfelder für stabile Anweisungen, die im System-Prompt-Bereich stehen sollen. -- **`before_agent_start`**: Legacy-Kompatibilitäts-Hook, der in beiden Phasen laufen kann; bevorzugen Sie die expliziten Hooks oben. +- **`before_model_resolve`**: läuft vor der Sitzung (keine `messages`), um Provider/Modell deterministisch vor der Modellauflösung zu überschreiben. +- **`before_prompt_build`**: läuft nach dem Laden der Sitzung (mit `messages`), um vor der Prompt-Übermittlung `prependContext`, `systemPrompt`, `prependSystemContext` oder `appendSystemContext` zu injizieren. Verwenden Sie `prependContext` für dynamischen Text pro Turn und Systemkontext-Felder für stabile Leitlinien, die im System-Prompt-Bereich stehen sollen. +- **`before_agent_start`**: Legacy-Kompatibilitätshook, der in beiden Phasen laufen kann; bevorzugen Sie die expliziten Hooks oben. - **`before_agent_reply`**: läuft nach Inline-Aktionen und vor dem LLM-Aufruf, sodass ein Plugin den Turn übernehmen und eine synthetische Antwort zurückgeben oder den Turn vollständig stummschalten kann. -- **`agent_end`**: inspiziert die finale Nachrichtenliste und Ausführungsmetadaten nach Abschluss. -- **`before_compaction` / `after_compaction`**: beobachtet oder annotiert Compaction-Zyklen. -- **`before_tool_call` / `after_tool_call`**: fängt Tool-Parameter/-Ergebnisse ab. -- **`before_install`**: inspiziert eingebaute Scan-Ergebnisse und blockiert optional Skill- oder Plugin-Installationen. -- **`tool_result_persist`**: transformiert Tool-Ergebnisse synchron, bevor sie in ein von OpenClaw verwaltetes Sitzungstranskript geschrieben werden. -- **`message_received` / `message_sending` / `message_sent`**: Hooks für eingehende und ausgehende Nachrichten. -- **`session_start` / `session_end`**: Grenzen des Sitzungslebenszyklus. -- **`gateway_start` / `gateway_stop`**: Gateway-Lebenszyklusereignisse. +- **`agent_end`**: finale Nachrichtenliste und Laufmetadaten nach Abschluss prüfen. +- **`before_compaction` / `after_compaction`**: Compaction-Zyklen beobachten oder annotieren. +- **`before_tool_call` / `after_tool_call`**: Tool-Parameter/-Ergebnisse abfangen. +- **`before_install`**: integrierte Scan-Ergebnisse prüfen und Skill- oder Plugin-Installationen optional blockieren. +- **`tool_result_persist`**: Tool-Ergebnisse synchron transformieren, bevor sie in ein OpenClaw-eigenes Sitzungstranskript geschrieben werden. +- **`message_received` / `message_sending` / `message_sent`**: eingehende und ausgehende Nachrichten-Hooks. +- **`session_start` / `session_end`**: Sitzungs-Lifecycle-Grenzen. +- **`gateway_start` / `gateway_stop`**: Gateway-Lifecycle-Ereignisse. Hook-Entscheidungsregeln für Outbound-/Tool-Guards: - `before_tool_call`: `{ block: true }` ist terminal und stoppt Handler mit niedrigerer Priorität. -- `before_tool_call`: `{ block: false }` ist ein No-op und hebt keine frühere Blockierung auf. +- `before_tool_call`: `{ block: false }` ist ein No-op und hebt einen vorherigen Block nicht auf. - `before_install`: `{ block: true }` ist terminal und stoppt Handler mit niedrigerer Priorität. -- `before_install`: `{ block: false }` ist ein No-op und hebt keine frühere Blockierung auf. +- `before_install`: `{ block: false }` ist ein No-op und hebt einen vorherigen Block nicht auf. - `message_sending`: `{ cancel: true }` ist terminal und stoppt Handler mit niedrigerer Priorität. -- `message_sending`: `{ cancel: false }` ist ein No-op und hebt keinen früheren Abbruch auf. +- `message_sending`: `{ cancel: false }` ist ein No-op und hebt ein vorheriges Cancel nicht auf. Siehe [Plugin-Hooks](/de/plugins/hooks) für die Hook-API und Registrierungsdetails. -Harnesses können diese Hooks unterschiedlich adaptieren. Der Codex-App-Server-Harness behält +Harnesses können diese Hooks unterschiedlich adaptieren. Der Codex-App-Server-Harness hält OpenClaw-Plugin-Hooks als Kompatibilitätsvertrag für dokumentierte gespiegelte -Oberflächen bei, während native Codex-Hooks ein separater, niedrigerer Codex-Mechanismus bleiben. +Oberflächen aufrecht, während native Codex-Hooks ein separater, niedrigerer Codex-Mechanismus bleiben. -## Streaming + Teilantworten +## Streaming und Teilantworten -- Assistant-Deltas werden aus pi-agent-core gestreamt und als `assistant`-Ereignisse ausgegeben. +- Assistant-Deltas werden von pi-agent-core gestreamt und als `assistant`-Ereignisse ausgegeben. - Block-Streaming kann Teilantworten entweder bei `text_end` oder `message_end` ausgeben. - Reasoning-Streaming kann als separater Stream oder als Blockantworten ausgegeben werden. -- Siehe [Streaming](/de/concepts/streaming) für Chunking und Verhalten von Blockantworten. +- Siehe [Streaming](/de/concepts/streaming) für Chunking- und Blockantwort-Verhalten. -## Tool-Ausführung + Messaging-Tools +## Tool-Ausführung und Messaging-Tools - Tool-Start-/Update-/Ende-Ereignisse werden im `tool`-Stream ausgegeben. -- Tool-Ergebnisse werden vor dem Protokollieren/Ausgeben hinsichtlich Größe und Bild-Payloads bereinigt. -- Sends von Messaging-Tools werden nachverfolgt, um doppelte Assistant-Bestätigungen zu unterdrücken. +- Tool-Ergebnisse werden vor dem Logging/der Ausgabe hinsichtlich Größe und Bild-Payloads bereinigt. +- Sends von Messaging-Tools werden verfolgt, um doppelte Assistant-Bestätigungen zu unterdrücken. -## Antwortformung + Unterdrückung +## Antwortformung und Unterdrückung -- Finale Payloads werden zusammengesetzt aus: +- Finale Payloads werden zusammengestellt aus: - Assistant-Text (und optional Reasoning) - - Inline-Tool-Zusammenfassungen (wenn verbose + erlaubt) - - Assistant-Fehlertext, wenn das Modell Fehler verursacht -- Das exakte stille Token `NO_REPLY` / `no_reply` wird aus ausgehenden + - Inline-Tool-Zusammenfassungen (wenn verbose und erlaubt) + - Assistant-Fehlertext, wenn das Modell Fehler ausgibt +- Das exakte stumme Token `NO_REPLY` / `no_reply` wird aus ausgehenden Payloads herausgefiltert. - Duplikate von Messaging-Tools werden aus der finalen Payload-Liste entfernt. -- Wenn keine darstellbaren Payloads übrig bleiben und ein Tool fehlgeschlagen ist, wird eine Fallback-Tool-Fehlerantwort ausgegeben - (es sei denn, ein Messaging-Tool hat bereits eine für Benutzer sichtbare Antwort gesendet). +- Wenn keine renderbaren Payloads übrig bleiben und bei einem Tool ein Fehler aufgetreten ist, wird eine Fallback-Tool-Fehlerantwort ausgegeben + (sofern nicht bereits ein Messaging-Tool eine für Benutzer sichtbare Antwort gesendet hat). -## Compaction + Wiederholungen +## Compaction und Wiederholungen - Auto-Compaction gibt `compaction`-Stream-Ereignisse aus und kann eine Wiederholung auslösen. - Bei einer Wiederholung werden In-Memory-Puffer und Tool-Zusammenfassungen zurückgesetzt, um doppelte Ausgaben zu vermeiden. @@ -156,35 +157,35 @@ Oberflächen bei, während native Codex-Hooks ein separater, niedrigerer Codex-M ## Ereignis-Streams (heute) -- `lifecycle`: ausgegeben durch `subscribeEmbeddedPiSession` (und als Fallback durch `agentCommand`) -- `assistant`: gestreamte Deltas aus pi-agent-core -- `tool`: gestreamte Tool-Ereignisse aus pi-agent-core +- `lifecycle`: ausgegeben von `subscribeEmbeddedPiSession` (und als Fallback von `agentCommand`) +- `assistant`: gestreamte Deltas von pi-agent-core +- `tool`: gestreamte Tool-Ereignisse von pi-agent-core -## Chatkanal-Behandlung +## Umgang mit Chat-Kanälen - Assistant-Deltas werden in Chat-`delta`-Nachrichten gepuffert. -- Ein Chat-`final` wird bei **Lebenszyklus-Ende/-Fehler** ausgegeben. +- Ein Chat-`final` wird bei **Lifecycle-Ende/Fehler** ausgegeben. ## Timeouts -- Standardwert für `agent.wait`: 30 s (nur das Warten). Parameter `timeoutMs` überschreibt ihn. -- Agent-Runtime: `agents.defaults.timeoutSeconds` Standardwert 172800 s (48 Stunden); erzwungen im Abbruch-Timer von `runEmbeddedPiAgent`. -- Cron-Runtime: isoliertes `timeoutSeconds` für Agent-Turns wird von cron verwaltet. Der Scheduler startet diesen Timer, wenn die Ausführung beginnt, bricht die zugrunde liegende Ausführung zur konfigurierten Deadline ab und führt dann begrenzte Bereinigung aus, bevor der Timeout aufgezeichnet wird, sodass eine veraltete Child-Sitzung die Lane nicht blockiert halten kann. -- Wiederherstellung blockierter Sitzungen: Wenn Diagnose aktiviert ist, erkennt `diagnostics.stuckSessionWarnMs` lange `processing`-Sitzungen. Aktive eingebettete Ausführungen, aktive Antwortoperationen und aktive Sitzungs-Lane-Tasks bleiben standardmäßig nur Warnungen; wenn die Diagnose keine aktive Arbeit für die Sitzung zeigt, gibt der Watchdog die betroffene Sitzungs-Lane frei, damit eingereihte Startarbeit abfließen kann. -- Modell-Leerlauf-Timeout: OpenClaw bricht eine Modellanfrage ab, wenn vor Ablauf des Leerlauffensters keine Antwort-Chunks eintreffen. `models.providers..timeoutSeconds` erweitert diesen Leerlauf-Watchdog für langsame lokale/selbst gehostete Provider; andernfalls verwendet OpenClaw `agents.defaults.timeoutSeconds`, wenn konfiguriert, standardmäßig auf 120 s gedeckelt. Durch Cron ausgelöste Ausführungen ohne explizites Modell- oder Agent-Timeout deaktivieren den Leerlauf-Watchdog und verlassen sich auf den äußeren Cron-Timeout. -- HTTP-Anfrage-Timeout des Providers: `models.providers..timeoutSeconds` gilt für die Modell-HTTP-Fetches dieses Providers, einschließlich Verbindung, Header, Body, SDK-Anfrage-Timeout, gesamter geschützter Fetch-Abbruchbehandlung und Modell-Stream-Leerlauf-Watchdog. Verwenden Sie dies für langsame lokale/selbst gehostete Provider wie Ollama, bevor Sie den gesamten Agent-Runtime-Timeout erhöhen. +- `agent.wait`-Standardwert: 30 s (nur das Warten). Parameter `timeoutMs` überschreibt dies. +- Agenten-Runtime: `agents.defaults.timeoutSeconds` Standardwert 172800 s (48 Stunden); durch den Abbruch-Timer in `runEmbeddedPiAgent` erzwungen. +- Cron-Runtime: Das `timeoutSeconds` eines isolierten Agent-Turns gehört Cron. Der Scheduler startet diesen Timer, wenn die Ausführung beginnt, bricht den zugrunde liegenden Lauf zum konfigurierten Stichtag ab und führt anschließend begrenztes Cleanup aus, bevor der Timeout aufgezeichnet wird, damit eine veraltete Child-Sitzung die Lane nicht blockiert halten kann. +- Wiederherstellung festhängender Sitzungen: Mit aktivierten Diagnosen erkennt `diagnostics.stuckSessionWarnMs` lange `processing`-Sitzungen. Aktive eingebettete Läufe, aktive Antwortoperationen und aktive Sitzungs-Lane-Aufgaben bleiben standardmäßig nur Warnungen; wenn die Diagnosen keine aktive Arbeit für die Sitzung zeigen, gibt der Watchdog die betroffene Sitzungs-Lane frei, damit aufgereihte Startarbeit abfließen kann. +- Modell-Inaktivitäts-Timeout: OpenClaw bricht eine Modellanfrage ab, wenn vor Ablauf des Inaktivitätsfensters keine Antwort-Chunks eintreffen. `models.providers..timeoutSeconds` erweitert diesen Inaktivitäts-Watchdog für langsame lokale/selbst gehostete Provider; andernfalls verwendet OpenClaw `agents.defaults.timeoutSeconds`, wenn konfiguriert, standardmäßig bei 120 s gedeckelt. Von Cron ausgelöste Läufe ohne explizites Modell- oder Agent-Timeout deaktivieren den Inaktivitäts-Watchdog und verlassen sich auf den äußeren Cron-Timeout. +- Provider-HTTP-Anfrage-Timeout: `models.providers..timeoutSeconds` gilt für Modell-HTTP-Fetches dieses Providers, einschließlich Verbindung, Headern, Body, SDK-Anfrage-Timeout, gesamter Guarded-Fetch-Abbruchbehandlung und Modell-Stream-Inaktivitäts-Watchdog. Verwenden Sie dies für langsame lokale/selbst gehostete Provider wie Ollama, bevor Sie den gesamten Agenten-Runtime-Timeout erhöhen. ## Wo Dinge vorzeitig enden können -- Agent-Timeout (Abbruch) +- Agenten-Timeout (Abbruch) - AbortSignal (Abbrechen) - Gateway-Trennung oder RPC-Timeout - `agent.wait`-Timeout (nur Warten, stoppt den Agenten nicht) -## Verwandte Themen +## Verwandt -- [Tools](/de/tools) — verfügbare Agent-Tools -- [Hooks](/de/automation/hooks) — ereignisgesteuerte Skripte, die durch Agent-Lebenszyklusereignisse ausgelöst werden +- [Tools](/de/tools) — verfügbare Agenten-Tools +- [Hooks](/de/automation/hooks) — ereignisgesteuerte Skripte, die durch Agenten-Lifecycle-Ereignisse ausgelöst werden - [Compaction](/de/concepts/compaction) — wie lange Unterhaltungen zusammengefasst werden -- [Exec-Freigaben](/de/tools/exec-approvals) — Freigabe-Gates für Shell-Befehle -- [Denken](/de/tools/thinking) — Konfiguration der Denk-/Reasoning-Stufe +- [Exec-Genehmigungen](/de/tools/exec-approvals) — Genehmigungsgates für Shell-Befehle +- [Thinking](/de/tools/thinking) — Konfiguration der Thinking-/Reasoning-Stufe diff --git a/docs/de/concepts/queue.md b/docs/de/concepts/queue.md index 75686b591..39a3cd4a7 100644 --- a/docs/de/concepts/queue.md +++ b/docs/de/concepts/queue.md @@ -1,64 +1,64 @@ --- read_when: - Ausführung oder Parallelität automatischer Antworten ändern - - Erläuterung von /queue-Modi oder des Verhaltens der Nachrichtensteuerung -summary: Modi der Warteschlange für automatische Antworten, Standardeinstellungen und sitzungsspezifische Überschreibungen + - Erläuterung der /queue-Modi oder des Verhaltens zur Nachrichtensteuerung +summary: Warteschlangenmodi, Standardwerte und sitzungsspezifische Überschreibungen für automatische Antworten title: Befehlswarteschlange x-i18n: - generated_at: "2026-04-30T06:50:46Z" + generated_at: "2026-04-30T18:38:36Z" model: gpt-5.5 provider: openai - source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d + source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0 source_path: concepts/queue.md workflow: 16 --- -Wir serialisieren eingehende Auto-Reply-Läufe (alle Kanäle) über eine kleine In-Process-Warteschlange, um zu verhindern, dass mehrere Agent-Läufe kollidieren, während sichere Parallelität über Sitzungen hinweg weiterhin möglich bleibt. +Wir serialisieren eingehende automatische Antwortläufe (alle Kanäle) über eine kleine In-Process-Warteschlange, um zu verhindern, dass mehrere Agentenläufe kollidieren, während sichere Parallelität über Sitzungen hinweg weiterhin möglich ist. ## Warum -- Auto-Reply-Läufe können teuer sein (LLM-Aufrufe) und kollidieren, wenn mehrere eingehende Nachrichten kurz nacheinander eintreffen. +- Automatische Antwortläufe können teuer sein (LLM-Aufrufe) und kollidieren, wenn mehrere eingehende Nachrichten kurz nacheinander eintreffen. - Serialisierung vermeidet Konkurrenz um gemeinsam genutzte Ressourcen (Sitzungsdateien, Logs, CLI-stdin) und reduziert die Wahrscheinlichkeit von Upstream-Rate-Limits. ## Funktionsweise -- Eine Lane-bewusste FIFO-Warteschlange leert jede Lane mit einer konfigurierbaren Nebenläufigkeitsgrenze (standardmäßig 1 für nicht konfigurierte Lanes; main standardmäßig 4, subagent 8). -- `runEmbeddedPiAgent` reiht nach **Sitzungsschlüssel** ein (Lane `session:`), um zu garantieren, dass pro Sitzung nur ein aktiver Lauf existiert. -- Jeder Sitzungslauf wird anschließend in eine **globale Lane** eingereiht (standardmäßig `main`), sodass die gesamte Parallelität durch `agents.defaults.maxConcurrent` begrenzt wird. -- Wenn ausführliche Protokollierung aktiviert ist, geben eingereihte Läufe einen kurzen Hinweis aus, falls sie vor dem Start mehr als etwa 2 s gewartet haben. -- Tippindikatoren werden weiterhin sofort beim Einreihen ausgelöst (wenn vom Kanal unterstützt), sodass die Benutzererfahrung unverändert bleibt, während wir warten, bis wir an der Reihe sind. +- Eine Lane-bewusste FIFO-Warteschlange leert jede Lane mit einem konfigurierbaren Nebenläufigkeitslimit (Standard 1 für nicht konfigurierte Lanes; main standardmäßig 4, subagent 8). +- `runEmbeddedPiAgent` reiht nach **Sitzungsschlüssel** ein (Lane `session:`), um zu garantieren, dass pro Sitzung nur ein Lauf aktiv ist. +- Jeder Sitzungslauf wird anschließend in eine **globale Lane** eingereiht (`main` standardmäßig), sodass die Gesamtparallelität durch `agents.defaults.maxConcurrent` begrenzt ist. +- Wenn ausführliches Logging aktiviert ist, geben eingereihte Läufe einen kurzen Hinweis aus, wenn sie mehr als ca. 2 s vor dem Start gewartet haben. +- Tippindikatoren werden weiterhin sofort beim Einreihen ausgelöst (wenn vom Kanal unterstützt), sodass die Nutzererfahrung unverändert bleibt, während wir warten, bis wir an der Reihe sind. ## Standardwerte -Wenn nicht festgelegt, verwenden alle eingehenden Kanaloberflächen: +Wenn nicht gesetzt, verwenden alle eingehenden Kanaloberflächen: - `mode: "steer"` - `debounceMs: 500` - `cap: 20` - `drop: "summarize"` -`steer` ist der Standard, weil es den aktiven Modell-Turn reaktionsschnell hält, ohne -einen zweiten Sitzungslauf zu starten. Es verarbeitet alle Steuerungsnachrichten, die -vor der nächsten Modellgrenze eingetroffen sind. Wenn der aktuelle Lauf keine Steuerung -annehmen kann, fällt OpenClaw auf einen Follow-up-Warteschlangeneintrag zurück. +`steer` ist der Standard, weil es den aktiven Modell-Turn reaktionsfähig hält, ohne +einen zweiten Sitzungslauf zu starten. Es verarbeitet alle Steuerungsnachrichten, +die vor der nächsten Modellgrenze eingetroffen sind. Wenn der aktuelle Lauf keine +Steuerung annehmen kann, fällt OpenClaw auf einen Follow-up-Warteschlangeneintrag zurück. ## Warteschlangenmodi Eingehende Nachrichten können den aktuellen Lauf steuern, auf einen Follow-up-Turn warten oder beides tun: -- `steer`: Steuerungsnachrichten in die aktive Runtime einreihen. Pi liefert alle ausstehenden Steuerungsnachrichten **nachdem der aktuelle Assistant-Turn die Ausführung seiner Tool-Aufrufe abgeschlossen hat**, vor dem nächsten LLM-Aufruf; der Codex-App-Server erhält ein gebündeltes `turn/steer`. Wenn der Lauf nicht aktiv streamt oder Steuerung nicht verfügbar ist, fällt OpenClaw auf einen Follow-up-Warteschlangeneintrag zurück. -- `queue` (Legacy): alte, einzelne Steuerung nacheinander. Pi liefert an jeder Modellgrenze eine eingereihte Steuerungsnachricht; der Codex-App-Server erhält separate `turn/steer`-Anfragen. Bevorzugen Sie `steer`, sofern Sie nicht das frühere serialisierte Verhalten benötigen. -- `followup`: jede Nachricht für einen späteren Agent-Turn nach Ende des aktuellen Laufs einreihen. -- `collect`: eingereihte Nachrichten nach dem Ruhefenster zu einem **einzigen** Follow-up-Turn zusammenführen. Wenn Nachrichten auf unterschiedliche Kanäle/Threads zielen, werden sie einzeln geleert, um das Routing zu erhalten. -- `steer-backlog` (auch `steer+backlog`): jetzt steuern **und** dieselbe Nachricht für einen Follow-up-Turn beibehalten. -- `interrupt` (Legacy): den aktiven Lauf für diese Sitzung abbrechen und anschließend die neueste Nachricht ausführen. +- `steer`: Steuerungsnachrichten in die aktive Runtime-Warteschlange einreihen. Pi liefert alle ausstehenden Steuerungsnachrichten **nachdem der aktuelle Assistant-Turn seine Tool-Aufrufe fertig ausgeführt hat**, vor dem nächsten LLM-Aufruf; Codex app-server erhält ein gebündeltes `turn/steer`. Wenn der Lauf nicht aktiv streamt oder Steuerung nicht verfügbar ist, fällt OpenClaw auf einen Follow-up-Warteschlangeneintrag zurück. +- `queue` (Legacy): alte Steuerung einzeln nacheinander. Pi liefert an jeder Modellgrenze eine eingereihte Steuerungsnachricht; Codex app-server erhält separate `turn/steer`-Anfragen. Bevorzugen Sie `steer`, sofern Sie nicht das frühere serialisierte Verhalten benötigen. +- `followup`: Jede Nachricht für einen späteren Agenten-Turn einreihen, nachdem der aktuelle Lauf endet. +- `collect`: Eingereihte Nachrichten nach dem Ruhefenster zu einem **einzelnen** Follow-up-Turn zusammenführen. Wenn Nachrichten unterschiedliche Kanäle/Threads adressieren, werden sie einzeln verarbeitet, um das Routing zu erhalten. +- `steer-backlog` (auch `steer+backlog`): jetzt steuern **und** dieselbe Nachricht für einen Follow-up-Turn bewahren. +- `interrupt` (Legacy): Den aktiven Lauf für diese Sitzung abbrechen und dann die neueste Nachricht ausführen. -Steer-backlog bedeutet, dass Sie nach dem gesteuerten Lauf eine Follow-up-Antwort erhalten können, sodass -Streaming-Oberflächen wie Duplikate wirken können. Bevorzugen Sie `collect`/`steer`, wenn Sie -eine Antwort pro eingehender Nachricht möchten. +Steer-backlog bedeutet, dass Sie nach dem gesteuerten Lauf eine Follow-up-Antwort +erhalten können, sodass Streaming-Oberflächen wie Duplikate wirken können. +Bevorzugen Sie `collect`/`steer`, wenn Sie eine Antwort pro eingehender Nachricht wünschen. -Für Runtime-spezifisches Timing und Abhängigkeitsverhalten siehe -[Steuerungswarteschlange](/de/concepts/queue-steering). +Informationen zu runtime-spezifischem Timing und Abhängigkeitsverhalten finden Sie unter +[Steering-Warteschlange](/de/concepts/queue-steering). Global oder pro Kanal über `messages.queue` konfigurieren: @@ -78,52 +78,54 @@ Global oder pro Kanal über `messages.queue` konfigurieren: ## Warteschlangenoptionen -Optionen gelten für `followup`, `collect` und `steer-backlog` (und für `steer` oder Legacy-`queue`, wenn Steuerung auf Follow-up zurückfällt): +Optionen gelten für `followup`, `collect` und `steer-backlog` (sowie für `steer` oder Legacy-`queue`, wenn Steuerung auf Follow-up zurückfällt): -- `debounceMs`: Ruhefenster vor dem Leeren eingereihter Follow-ups. Reine Zahlen sind Millisekunden; die Einheiten `ms`, `s`, `m`, `h` und `d` werden von `/queue`-Optionen akzeptiert. -- `cap`: maximale Anzahl eingereihter Nachrichten pro Sitzung. Werte unter `1` werden ignoriert. -- `drop: "summarize"`: Standard. Die ältesten eingereihten Einträge bei Bedarf verwerfen, kompakte Zusammenfassungen behalten und sie als synthetischen Follow-up-Prompt einfügen. -- `drop: "old"`: die ältesten eingereihten Einträge bei Bedarf verwerfen, ohne Zusammenfassungen zu behalten. -- `drop: "new"`: die neueste Nachricht ablehnen, wenn die Warteschlange bereits voll ist. +- `debounceMs`: Ruhefenster vor dem Verarbeiten eingereihter Follow-ups. Reine Zahlen sind Millisekunden; die Einheiten `ms`, `s`, `m`, `h` und `d` werden von `/queue`-Optionen akzeptiert. +- `cap`: Maximale Anzahl eingereihter Nachrichten pro Sitzung. Werte unter `1` werden ignoriert. +- `drop: "summarize"`: Standard. Die ältesten eingereihten Einträge bei Bedarf verwerfen, kompakte Zusammenfassungen behalten und diese als synthetischen Follow-up-Prompt einfügen. +- `drop: "old"`: Die ältesten eingereihten Einträge bei Bedarf verwerfen, ohne Zusammenfassungen zu bewahren. +- `drop: "new"`: Die neueste Nachricht ablehnen, wenn die Warteschlange bereits voll ist. Standardwerte: `debounceMs: 500`, `cap: 20`, `drop: summarize`. -## Vorrang +## Priorität -Für die Modusauswahl löst OpenClaw auf: +Für die Modusauswahl löst OpenClaw wie folgt auf: -1. Inline- oder gespeicherte sitzungsspezifische `/queue`-Überschreibung. +1. Inline oder gespeicherter sitzungsspezifischer `/queue`-Override. 2. `messages.queue.byChannel.`. 3. `messages.queue.mode`. 4. Standard `steer`. -Für Optionen haben Inline- oder gespeicherte `/queue`-Optionen Vorrang vor der Konfiguration. Danach werden -kanalspezifisches Debounce (`messages.queue.debounceMsByChannel`), Plugin- +Für Optionen haben Inline- oder gespeicherte `/queue`-Optionen Vorrang vor der Konfiguration. Danach +werden kanalspezifisches Debounce (`messages.queue.debounceMsByChannel`), Plugin- Debounce-Standardwerte, globale `messages.queue`-Optionen und eingebaute Standardwerte -angewendet. `cap` und `drop` sind globale/Sitzungsoptionen, keine kanalspezifischen Konfigurationsschlüssel. +angewendet. `cap` und `drop` sind globale/Sitzungsoptionen, keine kanalspezifischen +Konfigurationsschlüssel. -## Sitzungsspezifische Überschreibungen +## Sitzungsspezifische Overrides - Senden Sie `/queue ` als eigenständigen Befehl, um den Modus für die aktuelle Sitzung zu speichern. - Optionen können kombiniert werden: `/queue collect debounce:0.5s cap:25 drop:summarize` -- `/queue default` oder `/queue reset` löscht die Sitzungsüberschreibung. +- `/queue default` oder `/queue reset` löscht den Sitzungs-Override. -## Geltungsbereich und Garantien +## Umfang und Garantien -- Gilt für Auto-Reply-Agent-Läufe über alle eingehenden Kanäle hinweg, die die Gateway-Antwortpipeline verwenden (WhatsApp Web, Telegram, Slack, Discord, Signal, iMessage, Webchat usw.). -- Die Standard-Lane (`main`) ist prozessweit für eingehende Nachrichten und Haupt-Heartbeats; setzen Sie `agents.defaults.maxConcurrent`, um mehrere Sitzungen parallel zu erlauben. -- Zusätzliche Lanes können existieren (z. B. `cron`, `cron-nested`, `nested`, `subagent`), sodass Hintergrundjobs parallel laufen können, ohne eingehende Antworten zu blockieren. Isolierte Cron-Agent-Turns belegen einen `cron`-Slot, während ihre innere Agent-Ausführung `cron-nested` verwendet; beide verwenden `cron.maxConcurrentRuns`. Gemeinsame Nicht-Cron-`nested`-Abläufe behalten ihr eigenes Lane-Verhalten. Diese entkoppelten Läufe werden als [Hintergrundaufgaben](/de/automation/tasks) nachverfolgt. -- Sitzungsspezifische Lanes garantieren, dass jeweils nur ein Agent-Lauf eine bestimmte Sitzung berührt. +- Gilt für automatische Agentenantwortläufe über alle eingehenden Kanäle hinweg, die die Gateway-Antwortpipeline verwenden (WhatsApp Web, Telegram, Slack, Discord, Signal, iMessage, Webchat usw.). +- Die Standard-Lane (`main`) ist prozessweit für eingehende Antworten + Haupt-Heartbeats; setzen Sie `agents.defaults.maxConcurrent`, um mehrere Sitzungen parallel zuzulassen. +- Zusätzliche Lanes können existieren (z. B. `cron`, `cron-nested`, `nested`, `subagent`), sodass Hintergrundjobs parallel laufen können, ohne eingehende Antworten zu blockieren. Isolierte Cron-Agenten-Turns belegen einen `cron`-Slot, während ihre innere Agentenausführung `cron-nested` verwendet; beide nutzen `cron.maxConcurrentRuns`. Geteilte Nicht-Cron-`nested`-Abläufe behalten ihr eigenes Lane-Verhalten. Diese entkoppelten Läufe werden als [Hintergrundaufgaben](/de/automation/tasks) nachverfolgt. +- Sitzungsspezifische Lanes garantieren, dass jeweils nur ein Agentenlauf eine bestimmte Sitzung berührt. - Keine externen Abhängigkeiten oder Hintergrund-Worker-Threads; reines TypeScript + Promises. ## Fehlerbehebung -- Wenn Befehle festzustecken scheinen, aktivieren Sie ausführliche Logs und suchen Sie nach Zeilen wie „queued for …ms“, um zu bestätigen, dass die Warteschlange geleert wird. +- Wenn Befehle festzustecken scheinen, aktivieren Sie ausführliche Logs und suchen Sie nach Zeilen „queued for …ms“, um zu bestätigen, dass die Warteschlange verarbeitet wird. - Wenn Sie die Warteschlangentiefe benötigen, aktivieren Sie ausführliche Logs und achten Sie auf Warteschlangen-Timing-Zeilen. -- Wenn Diagnosen aktiviert sind, protokollieren Sitzungen, die über `diagnostics.stuckSessionWarnMs` hinaus in `processing` bleiben, eine Warnung zu feststeckenden Sitzungen. Aktive eingebettete Läufe, aktive Antwortoperationen und aktive Lane-Aufgaben bleiben standardmäßig reine Warnungen; veraltete Startbuchhaltung ohne aktive Sitzungsarbeit kann die betroffene Sitzungs-Lane freigeben, sodass eingereihte Arbeit abläuft. +- Codex app-server-Läufe, die einen Turn annehmen und dann keinen Fortschritt mehr ausgeben, werden vom Codex-Adapter unterbrochen, damit die aktive Sitzungs-Lane freigegeben werden kann, statt auf das Timeout des äußeren Laufs zu warten. +- Wenn Diagnosen aktiviert sind, protokollieren Sitzungen, die über `diagnostics.stuckSessionWarnMs` hinaus in `processing` bleiben, eine Warnung zu einer festhängenden Sitzung. Aktive eingebettete Läufe, aktive Antwortoperationen und aktive Lane-Aufgaben bleiben standardmäßig reine Warnungen; veraltete Startbuchhaltung ohne aktive Sitzungsarbeit kann die betroffene Sitzungs-Lane freigeben, sodass eingereihte Arbeit verarbeitet wird. -## Verwandte Themen +## Verwandt - [Sitzungsverwaltung](/de/concepts/session) -- [Steuerungswarteschlange](/de/concepts/queue-steering) -- [Retry-Richtlinie](/de/concepts/retry) +- [Steering-Warteschlange](/de/concepts/queue-steering) +- [Wiederholungsrichtlinie](/de/concepts/retry) diff --git a/docs/de/help/testing.md b/docs/de/help/testing.md index 287285036..d94b9dfc1 100644 --- a/docs/de/help/testing.md +++ b/docs/de/help/testing.md @@ -1,108 +1,108 @@ --- read_when: - - Tests lokal oder in der CI ausführen + - Tests lokal oder in CI ausführen - Regressionstests für Modell-/Provider-Fehler hinzufügen - - Fehlerbehebung für Gateway- und Agent-Verhalten -summary: 'Testkit: Unit-/e2e-/Live-Suites, Docker-Runner und was jeder Test abdeckt' + - Debugging von Gateway- und Agent-Verhalten +summary: 'Test-Kit: Unit-/e2e-/Live-Suites, Docker-Runner und was jeder Test abdeckt' title: Testen x-i18n: - generated_at: "2026-04-30T06:59:04Z" + generated_at: "2026-04-30T18:38:46Z" model: gpt-5.5 provider: openai - source_hash: c7b506350f11431195cb55c84cb10e99efb5f43b934079528b982627024d1ffc + source_hash: 470a96c6b47c2708950d05adc4a4efba5fe290f0675a131e2888d2d0032d5953 source_path: help/testing.md workflow: 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: +OpenClaw verfügt über drei Vitest-Suites (Unit/Integration, E2E, Live) und einen kleinen Satz +von Docker-Runnern. Dieses Dokument ist ein Leitfaden dazu, „wie wir testen“: -- Was jede Suite abdeckt (und was sie absichtlich _nicht_ abdeckt). -- Welche Befehle für gängige Workflows auszuführen sind (lokal, vor dem Push, Debugging). -- Wie Live-Tests Zugangsdaten finden und Modelle/Provider auswählen. -- Wie Regressionen für reale Modell-/Provider-Probleme hinzugefügt werden. +- Was jede Suite abdeckt (und was sie bewusst _nicht_ abdeckt). +- Welche Befehle Sie für gängige Workflows ausführen sollten (lokal, vor dem Push, Debugging). +- Wie Live-Tests Zugangsdaten erkennen und Modelle/Provider auswählen. +- Wie Sie Regressionen für reale Modell-/Provider-Probleme hinzufügen. -**QA-Stack (`qa-lab`, `qa-channel`, Live-Transport-Lanes)** ist separat dokumentiert: +**QA-Stack (qa-lab, qa-channel, Live-Transport-Lanes)** ist separat dokumentiert: - [QA-Übersicht](/de/concepts/qa-e2e-automation) — Architektur, Befehlsoberfläche, Szenario-Erstellung. - [Matrix-QA](/de/concepts/qa-matrix) — Referenz für `pnpm openclaw qa matrix`. - [QA-Kanal](/de/channels/qa-channel) — 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](#qa-specific-runners)) listet die konkreten `qa`-Aufrufe auf und verweist zurück auf die oben genannten Referenzen. +Diese Seite behandelt das Ausführen der regulären Test-Suites und Docker-/Parallels-Runner. Der Abschnitt zu QA-spezifischen Runnern unten ([QA-spezifische Runner](#qa-specific-runners)) listet die konkreten `qa`-Aufrufe auf und verweist zurück auf die obigen Referenzen. ## Schnellstart An den meisten Tagen: -- Vollständiger Gate (vor dem Push erwartet): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Schnellerer lokaler Lauf der vollständigen Suite auf einer großzügig ausgestatteten Maschine: `pnpm test:max` +- Vollständiges Gate (vor dem Push erwartet): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` +- Schnellere lokale Ausführung der vollständigen Suite auf einer großzügig ausgestatteten Maschine: `pnpm test:max` - Direkte Vitest-Watch-Schleife: `pnpm test:watch` -- Direktes Datei-Targeting routet jetzt auch Erweiterungs-/Kanalpfade: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Direkte Dateizielauswahl routet jetzt auch Erweiterungs-/Kanalpfade: `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-Website: `pnpm qa:lab:up` +- 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 anfassen oder zusätzliche Sicherheit möchten: +Wenn Sie Tests anfassen oder zusätzliche Sicherheit wünschen: - Coverage-Gate: `pnpm test:coverage` - E2E-Suite: `pnpm test:e2e` -Beim Debuggen realer Provider/Modelle (erfordert echte Zugangsdaten): +Beim Debuggen echter Provider/Modelle (erfordert echte Zugangsdaten): - Live-Suite (Modelle + Gateway-Tool-/Bildprüfungen): `pnpm test:live` -- Eine Live-Datei leise gezielt ausführen: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Eine Live-Datei gezielt und leise ausführen: `pnpm test:live -- src/agents/models.profiles.live.test.ts` - Docker-Live-Modell-Sweep: `pnpm test:docker:live-models` - Jedes ausgewählte Modell führt jetzt einen Text-Turn plus eine kleine dateilesenartige Prüfung aus. Modelle, deren Metadaten `image`-Eingabe 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: Das tägliche `OpenClaw Scheduled Live And E2E Checks` und das manuelle + - CI-Abdeckung: Die täglichen `OpenClaw Scheduled Live And E2E Checks` und manuellen `OpenClaw Release Checks` rufen beide den wiederverwendbaren Live-/E2E-Workflow mit - `include_live_suites: true` auf, was separate Docker-Live-Modell- - Matrix-Jobs einschließt, die nach Provider geshardet sind. - - Für fokussierte CI-Neuläufe starten Sie `OpenClaw Live And E2E Checks (Reusable)` + `include_live_suites: true` auf; dieser umfasst separate Docker-Live-Modell- + Matrix-Jobs, nach Provider aufgeteilt. + - Für fokussierte CI-Wiederholungen starten Sie `OpenClaw Live And E2E Checks (Reusable)` mit `include_live_suites: true` und `live_models_only: true`. - - Fügen Sie neue aussagekräftige Provider-Secrets zu `scripts/ci-hydrate-live-auth.sh` - sowie `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` und den + - Fügen Sie neue hochsignalige Provider-Secrets zu `scripts/ci-hydrate-live-auth.sh` + sowie `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` und dessen geplanten/Release-Aufrufern hinzu. -- Nativer Codex-Bound-Chat-Smoke: `pnpm test:docker:live-codex-bind` +- Nativer Codex-Smoke für gebundenen Chat: `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 + `/codex permissions` aus und verifiziert anschließend, 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, + - Führt Gateway-Agent-Turns über 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 nach der Sub-Agent-Prüfung, sofern nicht + Dies beendet sich nach der Sub-Agent-Prüfung, sofern nicht `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0` gesetzt ist. -- Crestodian-Rescue-Command-Smoke: `pnpm test:live:crestodian-rescue-channel` - - Opt-in-Prüfung mit doppelter Absicherung für die Message-Channel-Rescue-Command- - Oberfläche. Sie übt `/crestodian status` aus, stellt eine persistente Modell- - Änderung in die Warteschlange, antwortet `/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 gefälschten Claude CLI auf `PATH` - aus und verifiziert, dass der Fuzzy-Planner-Fallback in einen auditierten typisierten - Config-Schreibvorgang übersetzt wird. -- Crestodian-First-Run-Docker-Smoke: `pnpm test:docker:crestodian-first-run` - - Startet aus einem leeren OpenClaw-State-Verzeichnis, routet reines `openclaw` zu - 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. +- Crestodian-Smoke für den Rettungsbefehl: `pnpm test:live:crestodian-rescue-channel` + - Optionale zusätzliche Prüfung für die Oberfläche des Rettungsbefehls im Nachrichtenkanal. + Sie übt `/crestodian status` aus, stellt eine persistente Modelländerung in die Warteschlange, + antwortet mit `/crestodian yes` und verifiziert den Audit-/Konfigurationsschreibpfad. +- Crestodian-Planer-Docker-Smoke: `pnpm test:docker:crestodian-planner` + - Führt Crestodian in einem konfigurationslosen Container mit einer gefälschten Claude-CLI auf `PATH` + aus und verifiziert, dass der unscharfe Planer-Fallback in einen auditierten typisierten + Konfigurationsschreibvorgang übersetzt wird. +- Crestodian-Erstlauf-Docker-Smoke: `pnpm test:docker:crestodian-first-run` + - Startet aus einem leeren OpenClaw-Zustandsverzeichnis, routet blankes `openclaw` zu + Crestodian, wendet Setup-/Modell-/Agent-/Discord-Plugin- + SecretRef-Schreibvorgänge an, + validiert die Konfiguration und verifiziert Audit-Einträge. Derselbe Ring-0-Setup-Pfad ist + auch in QA Lab abgedeckt durch + `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. - Moonshot-/Kimi-Kosten-Smoke: Führen Sie mit gesetztem `MOONSHOT_API_KEY` - `openclaw models list --provider moonshot --json` aus, danach einen isolierten + `openclaw models list --provider moonshot --json` aus und anschließend einen isolierten `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` gegen `moonshot/kimi-k2.6`. Verifizieren Sie, dass das JSON Moonshot/K2.6 meldet und das - Assistant-Transkript normalisierte `usage.cost` speichert. + Assistententranskript normalisierte `usage.cost` speichert. -Wenn Sie nur einen fehlschlagenden Fall benötigen, grenzen Sie Live-Tests bevorzugt über die unten beschriebenen Allowlist-Env-Vars ein. +Wenn Sie nur einen fehlgeschlagenen Fall benötigen, grenzen Sie Live-Tests bevorzugt über die unten beschriebenen Allowlist-Umgebungsvariablen ein. ## QA-spezifische Runner @@ -110,21 +110,21 @@ Wenn Sie nur einen fehlschlagenden Fall benötigen, grenzen Sie Live-Tests bevor Diese Befehle stehen neben den Haupt-Test-Suites, wenn Sie QA-Lab-Realismus benötigen: CI führt QA Lab in dedizierten Workflows aus. `Parity gate` läuft auf passenden PRs und -per manueller Auslösung mit Mock-Providern. `QA-Lab - All Lanes` läuft nächtlich auf -`main` und per manueller Auslösung mit dem Mock-Parity-Gate, der Live-Matrix-Lane, -der Convex-verwalteten Live-Telegram-Lane und der Convex-verwalteten Live-Discord-Lane als +per manuellem Dispatch mit Mock-Providern. `QA-Lab - All Lanes` läuft nachts auf +`main` und per manuellem Dispatch mit dem Mock-Paritäts-Gate, der Live-Matrix-Lane, +der von Convex verwalteten Live-Telegram-Lane und der von Convex verwalteten Live-Discord-Lane als parallele Jobs. Geplante QA- und Release-Prüfungen übergeben Matrix `--profile fast` -explizit, während die Standardwerte der Matrix CLI und der manuellen Workflow-Eingabe -`all` bleiben; manuelle Auslösung kann `all` in `transport`, `media`, `e2ee-smoke`, -`e2ee-deep` und `e2ee-cli` Jobs sharden. `OpenClaw Release Checks` führt Parity plus -die schnellen Matrix- und Telegram-Lanes vor der Release-Freigabe aus und verwendet +explizit, während die Standardwerte der Matrix-CLI und der manuellen Workflow-Eingabe +`all` bleiben; 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-Transportprüfungen, damit sie deterministisch bleiben -und den normalen Provider-Plugin-Start vermeiden. Diese Live-Transport-Gateways deaktivieren -Memory-Suche; Memory-Verhalten bleibt durch die QA-Parity-Suites abgedeckt. +und den normalen Start von Provider-Plugins vermeiden. Diese Live-Transport-Gateways deaktivieren +die Speichersuche; Speicherverhalten bleibt durch die QA-Paritäts-Suites abgedeckt. Vollständige 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 gemeinsame +`ffmpeg` und `ffprobe` enthält. Docker-Live-Modell-/Backend-Shards verwenden das gemeinsam genutzte `ghcr.io/openclaw/openclaw-live-test:`-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. @@ -132,76 +132,76 @@ 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 `, um die Worker- + Gateway-Workern aus. `qa-channel` verwendet standardmäßig Nebenläufigkeit 4 (begrenzt durch die + ausgewählte Szenarioanzahl). Verwenden Sie `--concurrency `, um die Worker- Anzahl anzupassen, oder `--concurrency 1` für die ältere serielle Lane. - - Beendet mit einem Nicht-Null-Code, wenn ein Szenario fehlschlägt. Verwenden Sie `--allow-failures`, wenn Sie + - Beendet sich mit einem Nicht-Null-Code, wenn irgendein Szenario fehlschlägt. Verwenden Sie `--allow-failures`, wenn Sie Artefakte ohne fehlschlagenden Exit-Code möchten. - - Unterstützt die Provider-Modi `live-frontier`, `mock-openai` und `aimock`. + - Unterstützt 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 + Fixture- und Protokoll-Mock-Abdeckung, ohne die szenariobewusste `mock-openai`-Lane zu ersetzen. - `pnpm test:gateway:cpu-scenarios` - - Führt den Gateway-Startup-Bench plus ein kleines Mock-QA-Lab-Szenariopaket + - Führt den Gateway-Startup-Benchmark plus ein kleines Mock-QA-Lab-Szenariopaket (`channel-chat-baseline`, `memory-failure-fallback`, `gateway-restart-inflight-run`) aus 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 erfasst werden, + - Markiert standardmäßig nur anhaltende Hot-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 auszusehen. - 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 kurzlebigen Multipass-Linux-VM aus. - - Behält dasselbe Szenarioauswahlverhalten wie `qa suite` auf dem Host bei. + - Führt dieselbe QA-Suite in einer verwerfbaren Multipass-Linux-VM aus. + - Behält dasselbe Verhalten zur Szenarioauswahl wie `qa suite` auf dem Host bei. - Verwendet dieselben Provider-/Modellauswahl-Flags wie `qa suite`. - Live-Läufe leiten die unterstützten QA-Auth-Eingaben weiter, die für den Gast praktikabel sind: - env-basierte Provider-Schlüssel, den QA-Live-Provider-Config-Pfad und `CODEX_HOME`, - falls vorhanden. + umgebungsbasierte Provider-Schlüssel, den QA-Live-Provider-Konfigurationspfad 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 plus Zusammenfassung sowie Multipass-Logs unter + den eingehängten Workspace zurückschreiben kann. + - Schreibt den normalen QA-Bericht + 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. + - Startet die Docker-gestützte QA-Site für operatorartige QA-Arbeit. - `pnpm test:docker:npm-onboard-channel-agent` - - Baut ein npm-Tarball aus dem aktuellen Checkout, installiert es global in - Docker, führt nicht-interaktives OpenAI-API-Key-Onboarding aus, konfiguriert standardmäßig Telegram, + - Baut einen npm-Tarball aus dem aktuellen Checkout, installiert ihn global in + Docker, führt nichtinteraktives OpenAI-API-Key-Onboarding aus, konfiguriert standardmäßig Telegram, verifiziert, dass das Aktivieren des Plugin Runtime-Abhängigkeiten bei Bedarf installiert, - führt Doctor aus und führt einen lokalen Agent-Turn gegen einen gemockten OpenAI- + 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. + - Verwenden Sie `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, um dieselbe Lane für die Paketinstallation + 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 verborgener OpenClaw-Runtime-Kontext als - nicht angezeigte Custom Message persistiert wird, statt in den sichtbaren User-Turn zu leaken, - seeded dann ein betroffenes defektes Session-JSONL und verifiziert, dass - `openclaw doctor --fix` es mit einem Backup auf den aktiven Branch umschreibt. + nicht angezeigte benutzerdefinierte Nachricht persistiert wird, statt in den sichtbaren Benutzer-Turn zu gelangen, + legt anschließend eine betroffene defekte Sitzungs-JSONL an und verifiziert, + dass `openclaw doctor --fix` sie mit Backup auf den aktiven Branch umschreibt. - `pnpm test:docker:npm-telegram-live` - - Installiert einen OpenClaw-Paketkandidaten in Docker, führt Installed-Package- - Onboarding aus, konfiguriert Telegram über die installierte CLI und verwendet dann erneut die - Live-Telegram-QA-Lane mit diesem installierten Paket als SUT-Gateway. + - Installiert einen OpenClaw-Paketkandidaten in Docker, führt Onboarding für das installierte Paket aus, + konfiguriert Telegram über die installierte CLI und verwendet anschließend die + Live-Telegram-QA-Lane mit diesem installierten Paket als SUT-Gateway erneut. - Standard 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 ein aufgelöstes lokales Tarball zu testen, - anstatt aus der Registry zu installieren. - - Verwendet dieselben Telegram-Env-Zugangsdaten oder dieselbe Convex-Zugangsdatenquelle wie - `pnpm openclaw qa telegram`. Für CI-/Release-Automatisierung setzen Sie + `OPENCLAW_CURRENT_PACKAGE_TGZ`, um stattdessen einen aufgelösten lokalen Tarball zu testen, + statt aus der Registry zu installieren. + - Verwendet dieselben Telegram-Umgebungszugangsdaten oder dieselbe Convex-Zugangsdatenquelle wie + `pnpm openclaw qa telegram`. Setzen Sie für CI-/Release-Automation `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` plus - `OPENCLAW_QA_CONVEX_SITE_URL` und das Role-Secret. Wenn - `OPENCLAW_QA_CONVEX_SITE_URL` und ein Convex-Role-Secret in CI vorhanden sind, - wählt der Docker-Wrapper Convex automatisch. - - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` überschreibt die gemeinsame + `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. + - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` überschreibt die gemeinsam genutzte `OPENCLAW_QA_CREDENTIAL_ROLE` nur für diese Lane. - GitHub Actions stellt diese Lane als manuellen Maintainer-Workflow - `NPM Telegram Beta E2E` bereit. Er läuft nicht beim Merge. Der Workflow verwendet die - `qa-live-shared`-Umgebung und Convex-CI-Zugangsdaten-Leases. -- GitHub Actions stellt außerdem `Package Acceptance` für nebenläufige Produktnachweise + `NPM Telegram Beta E2E` bereit. Sie läuft nicht bei Merge. Der Workflow verwendet die + Umgebung `qa-live-shared` und Convex-CI-Zugangsdaten-Leases. +- GitHub Actions stellt außerdem `Package Acceptance` für nebenläufigen Produktnachweis gegen ein Kandidatenpaket bereit. Es akzeptiert eine vertrauenswürdige 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 - bestehenden Docker-E2E-Scheduler mit Smoke-, Package-, Product-, Full- oder Custom- + das normalisierte `openclaw-current.tgz` als `package-under-test` hoch und führt anschließend den + bestehenden Docker-E2E-Scheduler mit Smoke-, Paket-, Produkt-, vollständigen 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. - Neuester Beta-Produktnachweis: @@ -214,7 +214,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- Nachweis für genaue Tarball-URL erfordert einen Digest: +- Nachweis mit exakter Tarball-URL erfordert einen Digest: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -224,7 +224,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Der Artefaktnachweis lädt ein Tarball-Artefakt aus einem anderen Actions-Lauf herunter: +- Artefakt-Nachweis lädt ein Tarball-Artefakt aus einem anderen Actions-Lauf herunter: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -235,30 +235,31 @@ gh workflow run package-acceptance.yml --ref main \ ``` - `pnpm test:docker:bundled-channel-deps` - - Packt und installiert den aktuellen OpenClaw-Build in Docker, startet das Gateway + - Paketiert 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. - - Überprüft, dass die Einrichtungserkennung unkonfigurierte Runtime-Abhängigkeiten - von Plugins auslässt, der erste konfigurierte Gateway- oder Doctor-Lauf die - Runtime-Abhängigkeiten jedes gebündelten Plugins bei Bedarf installiert und - ein zweiter Neustart bereits aktivierte Abhängigkeiten nicht erneut installiert. - - Installiert außerdem eine bekannte ältere npm-Basisversion, aktiviert Telegram vor dem Ausführen von - `openclaw update --tag ` und überprüft, dass der Doctor nach dem Update des Kandidaten - gebündelte Kanal-Runtime-Abhängigkeiten ohne harness-seitige Postinstall-Reparatur repariert. + - Verifiziert, dass die Setup-Erkennung unkonfigurierte Plugin-Laufzeitabhängigkeiten + nicht installiert, der erste konfigurierte Gateway- oder Doctor-Lauf die Laufzeitabhängigkeiten + jedes gebündelten Plugins bei Bedarf installiert und ein zweiter Neustart bereits + aktivierte Abhängigkeiten nicht erneut installiert. + - Installiert außerdem eine bekannte ältere npm-Baseline, aktiviert Telegram vor dem Ausführen von + `openclaw update --tag ` und verifiziert, dass der Post-Update-Doctor des Kandidaten + die Laufzeitabhängigkeiten gebündelter Kanäle ohne harness-seitige Postinstall-Reparatur behebt. - `pnpm test:parallels:npm-update` - Führt den nativen Smoke-Test für Updates paketierter Installationen über Parallels-Gäste hinweg aus. Jede - ausgewählte Plattform installiert zuerst das angeforderte Basispaket, führt dann - den installierten Befehl `openclaw update` im selben Gast aus und überprüft die - installierte Version, den Update-Status, die Gateway-Bereitschaft und einen lokalen Agent-Turn. + ausgewählte Plattform installiert zuerst das angeforderte Baseline-Paket, führt dann + im selben Gast den installierten Befehl `openclaw update` 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 + Sie an einem Gast iterieren. Verwenden Sie `--json` für den Pfad zum Zusammenfassungsartefakt und den Status pro Lane. - - Die OpenAI-Lane verwendet standardmäßig `openai/gpt-5.5` für den Live-Nachweis des Agent-Turns. + - Die OpenAI-Lane verwendet standardmäßig `openai/gpt-5.5` für den Nachweis eines Live-Agent-Turns. Übergeben Sie `--model ` oder setzen Sie `OPENCLAW_PARALLELS_OPENAI_MODEL`, wenn Sie bewusst ein anderes OpenAI-Modell validieren. - - Kapseln Sie lange lokale Läufe in ein Host-Timeout, damit Parallels-Transportblockaden - nicht den Rest des Testfensters verbrauchen können: + - Kapseln Sie lange lokale Läufe mit einem Host-Timeout, damit Parallels-Transport-Hänger nicht + den Rest des Testfensters verbrauchen können: ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json @@ -268,56 +269,55 @@ gh workflow run package-acceptance.yml --ref main \ - 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. - - Das Windows-Update kann auf einem kalten Gast 10 bis 15 Minuten mit Doctor-/Runtime- - Abhängigkeitsreparatur nach dem Update verbringen; das ist weiterhin fehlerfrei, wenn das verschachtelte - npm-Debug-Log voranschreitet. - - Führen Sie diesen aggregierten Wrapper nicht parallel zu einzelnen Parallels- - Smoke-Lanes für macOS, Windows oder Linux aus. Sie teilen sich VM-Zustand und können bei + - Windows-Updates können auf einem kalten Gast 10 bis 15 Minuten in der Post-Update-Doctor-/Laufzeitabhängigkeitsreparatur + verbringen; das ist weiterhin gesund, solange das verschachtelte + npm-Debug-Log fortschreitet. + - Führen Sie diesen aggregierten Wrapper nicht parallel zu einzelnen Parallels-Smoke-Lanes + für macOS, Windows oder Linux aus. Sie teilen sich den VM-Zustand und können bei Snapshot-Wiederherstellung, Paketbereitstellung oder Gast-Gateway-Zustand kollidieren. - - Der Nachweis nach dem Update führt die normale Oberfläche gebündelter Plugins aus, weil - Capability-Fassaden wie Sprache, Bildgenerierung und Medienverständnis - über gebündelte Runtime-APIs geladen werden, auch wenn der Agent-Turn selbst + - Der Post-Update-Nachweis führt die normale gebündelte Plugin-Oberfläche aus, weil + Capability-Fassaden wie Sprache, Bilderzeugung und Medienverständnis + über gebündelte Laufzeit-APIs geladen werden, auch 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. + - Startet nur den lokalen AIMock-Provider-Server für direkte Protokoll-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](/de/concepts/qa-matrix). + - Führt die Matrix-Live-QA-Lane gegen einen kurzlebigen Docker-gestützten Tuwunel-Homeserver aus. Nur Source-Checkout — paketierte Installationen liefern `qa-lab` nicht aus. + - Vollständige CLI, Profil-/Szenariokatalog, Umgebungsvariablen und Artefaktlayout: [Matrix-QA](/de/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Führt die Telegram-Live-QA-Lane gegen eine echte private Gruppe mit den Driver- und SUT-Bot-Tokens aus der Umgebung aus. + - Führt die Telegram-Live-QA-Lane gegen eine echte private Gruppe aus und verwendet dabei die Driver- und SUT-Bot-Tokens aus der Umgebung. - 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 genutzte gepoolte Zugangsdaten. Verwenden Sie standardmäßig den Env-Modus oder setzen Sie `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, um gepoolte Leases zu nutzen. - - Beendet sich mit einem Wert ungleich null, wenn ein Szenario fehlschlägt. Verwenden Sie `--allow-failures`, wenn Sie - Artefakte ohne fehlschlagenden Exit-Code möchten. + - Unterstützt `--credential-source convex` für gemeinsam genutzte gepoolte Anmeldedaten. Verwenden Sie standardmäßig den Env-Modus oder setzen Sie `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, um gepoolte Leases zu nutzen. + - Beendet sich mit einem von null verschiedenen Exit-Code, wenn ein Szenario fehlschlägt. Verwenden Sie `--allow-failures`, wenn Sie + Artefakte ohne fehlgeschlagenen 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 den 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 die RTT von der Sendeanforderung des Drivers bis zur beobachteten SUT-Antwort. + - Aktivieren Sie für eine stabile Bot-zu-Bot-Beobachtung den Bot-zu-Bot-Kommunikationsmodus 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 Sendeanforderung des Drivers bis zur beobachteten SUT-Antwort. -Live-Transport-Lanes teilen sich einen Standardvertrag, damit neue Transporte nicht auseinanderlaufen; die Abdeckungsmatrix pro Lane befindet sich in [QA-Übersicht → Live-Transportabdeckung](/de/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` ist die breite synthetische Suite und nicht Teil dieser Matrix. +Live-Transport-Lanes teilen sich einen Standardvertrag, damit neue Transporte nicht auseinanderlaufen; die Coverage-Matrix pro Lane befindet sich in [QA-Übersicht → Live-Transport-Coverage](/de/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` ist die breite synthetische Suite und ist nicht Teil dieser Matrix. -### Gemeinsame Telegram-Zugangsdaten über Convex (v1) +### Gemeinsame Telegram-Anmeldedaten über Convex (v1) Wenn `--credential-source convex` (oder `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) für -`openclaw qa telegram` aktiviert ist, erwirbt das QA-Lab eine exklusive Lease aus einem Convex-gestützten Pool, sendet Heartbeats +`openclaw qa telegram` aktiviert ist, bezieht das QA-Lab eine exklusive Lease aus einem Convex-gestützten Pool, sendet Heartbeats für diese Lease, während die Lane läuft, und gibt die Lease beim Herunterfahren frei. Referenz-Scaffold für das Convex-Projekt: - `qa/convex-credential-broker/` -Erforderliche Env-Vars: +Erforderliche Umgebungsvariablen: - `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 Zugangsdatenrolle: +- Auswahl der Anmeldedatenrolle: - CLI: `--credential-role maintainer|ci` - - Env-Standard: `OPENCLAW_QA_CREDENTIAL_ROLE` (standardmäßig `ci` in CI, sonst `maintainer`) + - Env-Standard: `OPENCLAW_QA_CREDENTIAL_ROLE` (standardmäßig `ci` in CI, andernfalls `maintainer`) -Optionale Env-Vars: +Optionale Umgebungsvariablen: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (Standard `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (Standard `30000`) @@ -325,11 +325,11 @@ Optionale Env-Vars: - `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_ALLOW_INSECURE_HTTP=1` erlaubt loopback-`http://`-Convex-URLs nur für lokale Entwicklung. -`OPENCLAW_QA_CONVEX_SITE_URL` sollte im Normalbetrieb `https://` verwenden. +`OPENCLAW_QA_CONVEX_SITE_URL` sollte im normalen Betrieb `https://` verwenden. -Maintainer-Admin-Befehle (Pool hinzufügen/entfernen/auflisten) erfordern +Admin-Befehle für Maintainer (Pool hinzufügen/entfernen/auflisten) erfordern speziell `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. CLI-Helfer für Maintainer: @@ -342,9 +342,8 @@ pnpm openclaw qa credentials remove --credential-id ``` Verwenden Sie `doctor` vor Live-Läufen, um die Convex-Site-URL, Broker-Secrets, -den Endpoint-Präfix, das HTTP-Timeout und die Admin-/Listen-Erreichbarkeit zu prüfen, ohne -Secret-Werte auszugeben. Verwenden Sie `--json` für maschinenlesbare Ausgabe in Skripten und CI- -Hilfsprogrammen. +Endpoint-Präfix, HTTP-Timeout und Admin-/List-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`): @@ -354,149 +353,114 @@ Standard-Endpoint-Vertrag (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`) - Erschöpft/wiederholbar: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Anfrage: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - - Erfolg: `{ status: "ok" }` (oder leerer `2xx`) + - Erfolg: `{ status: "ok" }` (oder leeres `2xx`) - `POST /release` - Anfrage: `{ kind, ownerId, actorRole, credentialId, leaseToken }` - - Erfolg: `{ status: "ok" }` (oder leerer `2xx`) + - 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 vor aktiver Lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` + - Schutz bei aktiver 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: +Payload-Form für die Telegram-Art: - `{ groupId: string, driverToken: string, sutToken: string }` - `groupId` muss ein numerischer Telegram-Chat-ID-String sein. -- `admin/add` validiert diese Form für `kind: "telegram"` und lehnt fehlerhafte Payloads ab. +- `admin/add` validiert diese Form für `kind: "telegram"` und weist fehlerhafte Payloads zurück. ### Einen Kanal zu QA hinzufügen -Die Architektur- und Szenario-Helfernamen für neue Kanaladapter befinden sich in [QA-Übersicht → Einen Kanal hinzufügen](/de/concepts/qa-e2e-automation#adding-a-channel). Die Mindestanforderung: den Transport-Runner auf dem gemeinsamen `qa-lab`-Host-Seam implementieren, `qaRunners` im Plugin-Manifest deklarieren, als `openclaw qa ` einbinden und Szenarien unter `qa/scenarios/` erstellen. +Die Architektur- und Szenario-Helfernamen für neue Kanaladapter befinden sich in [QA-Übersicht → Einen Kanal hinzufügen](/de/concepts/qa-e2e-automation#adding-a-channel). Die Mindestanforderung: den Transport-Runner auf der gemeinsamen `qa-lab`-Host-Naht implementieren, `qaRunners` im Plugin-Manifest deklarieren, als `openclaw qa ` einhängen und Szenarien unter `qa/scenarios/` erstellen. -## Testsuiten (was wo läuft) +## Test-Suites (was wo läuft) -Betrachten Sie die Suiten als „zunehmenden Realismus“ (und zunehmende Flakiness/Kosten): +Betrachten Sie die Suites als „zunehmender Realismus“ (und zunehmende Flakiness/Kosten): ### Unit / Integration (Standard) - Befehl: `pnpm test` -- Konfiguration: Nicht zielgerichtete Läufe verwenden das Shard-Set `vitest.full-*.config.ts` und können Multi-Projekt-Shards für paralleles Scheduling in projektbezogene Konfigurationen erweitern -- Dateien: Core-/Unit-Inventare unter `src/**/*.test.ts`, `packages/**/*.test.ts` und `test/**/*.test.ts`; UI-Unit-Tests laufen im dedizierten Shard `unit-ui` +- Konfiguration: Nicht zielgerichtete Läufe verwenden das Shard-Set `vitest.full-*.config.ts` und können Multi-Projekt-Shards für parallele Planung in projektbezogene Konfigurationen erweitern +- 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-Auth, Routing, Tooling, Parsing, Konfiguration) - - Deterministische Regressionen für bekannte Bugs + - In-Prozess-Integrationstests (Gateway-Auth, 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 das broad-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-Loads gehören in - Plugin-eigene Contract-/Integrationssuiten. + - Resolver- und Public-Surface-Loader-Tests müssen breites `api.js`- und + `runtime-api.js`-Fallback-Verhalten mit generierten kleinen Plugin-Fixtures nachweisen, nicht mit + echten gebündelten Plugin-Quell-APIs. Echte Plugin-API-Ladevorgänge gehören in + Plugin-eigene Contract-/Integration-Suites. - + - - Nicht zielgerichtete `pnpm test`-Ausführungen verwenden 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 riesigen nativen Root-Projektprozesses. Das senkt den Spitzen-RSS auf ausgelasteten Rechnern und verhindert, dass auto-reply-/extension-Arbeit unabhängige Suites verdrängt. - - `pnpm test --watch` verwendet weiterhin den nativen Root-`vitest.config.ts`-Projektgraphen, weil eine Watch-Schleife mit mehreren Shards 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 vollständigen 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 Source-Zuordnungen und lokale Importgraph-Abhängige. Config-/Setup-/Package-Änderungen führen keine breiten Testläufe aus, außer Sie verwenden ausdrücklich `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` ist das normale intelligente lokale Check-Gate für eng begrenzte Arbeit. Es klassifiziert den Diff in Core, Core-Tests, extensions, extension-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 ` für Testnachweise auf. Reine Release-Metadaten-Versionsanhebungen führen zielgerichtete Versions-/Config-/Root-Dependency-Checks aus, mit einem Guard, der Package-Änderungen außerhalb des obersten Versionsfelds ablehnt. - - Änderungen am Live-Docker-ACP-Harness führen fokussierte Checks aus: Shell-Syntax für die Live-Docker-Auth-Skripte und einen Live-Docker-Scheduler-Dry-Run. `package.json`-Änderungen werden nur einbezogen, wenn der Diff auf `scripts["test:docker:live-*"]` beschränkt ist; Dependency-, Export-, Versions- und andere Package-Oberflächenänderungen verwenden weiterhin die breiteren Guards. - - Import-leichte Unit-Tests aus Agents, Commands, Plugins, auto-reply-Helfern, `plugin-sdk` und ähnlichen reinen Utility-Bereichen laufen über die `unit-fast`-Lane, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete/runtime-lastige Dateien bleiben auf den bestehenden Lanes. - - Ausgewählte `plugin-sdk`- und `commands`-Helfer-Quelldateien ordnen Changed-Mode-Ausführungen außerdem expliziten benachbarten Tests in diesen leichten Lanes zu, sodass Helferänderungen vermeiden, die vollständige schwere Suite für dieses Verzeichnis erneut auszuführen. - - `auto-reply` hat dedizierte Buckets für Core-Helfer der obersten Ebene, Top-Level-`reply.*`-Integrationstests und den `src/auto-reply/reply/**`-Unterbaum. CI teilt den reply-Unterbaum zusätzlich in agent-runner-, dispatch- und commands/state-routing-Shards auf, damit kein importlastiger Bucket den gesamten Node-Nachlauf besitzt. - - Normale PR-/main-CI überspringt absichtlich den Extension-Batch-Sweep und den nur für Releases vorgesehenen `agentic-plugins`-Shard. Full Release Validation startet den separaten `Plugin Prerelease`-Child-Workflow für diese Plugin-/Extension-lastigen Suites auf Release Candidates. + - Nicht zielgerichtete `pnpm test`-Läufe verwenden 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. Das senkt den Spitzen-RSS auf ausgelasteten Maschinen und verhindert, dass Auto-Reply-/Plugin-Arbeit unabhängige Suites ausbremst. + - `pnpm test --watch` verwendet weiterhin den nativen Root-Projektgraphen aus `vitest.config.ts`, weil ein Multi-Shard-Watch-Loop nicht praktikabel ist. + - `pnpm test`, `pnpm test:watch` und `pnpm test:perf:imports` leiten explizite Datei-/Verzeichnisziele zuerst über scoped Lanes, sodass `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` nicht die volle Startlast des Root-Projekts zahlt. + - `pnpm test:changed` erweitert geänderte Git-Pfade standardmäßig zu günstigen scoped Lanes: direkte Teständerungen, benachbarte `*.test.ts`-Dateien, explizite Source-Mappings und lokale Importgraph-Abhängige. Config-/Setup-/Package-Änderungen führen keine breiten Testläufe aus, außer Sie verwenden explizit `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. + - `pnpm check:changed` ist das normale intelligente lokale Check-Gate für eng begrenzte Arbeit. Es klassifiziert das 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; verwenden Sie `pnpm test:changed` oder explizit `pnpm test ` als Testnachweis. Version-Bumps, die nur Release-Metadaten betreffen, führen gezielte Versions-/Config-/Root-Abhängigkeitschecks aus, mit einem Guard, der Package-Änderungen außerhalb des obersten Versionsfelds ablehnt. + - Änderungen am Live-Docker-ACP-Harness führen fokussierte Checks aus: Shell-Syntax für die Live-Docker-Auth-Skripte und einen Live-Docker-Scheduler-Dry-Run. `package.json`-Änderungen werden nur einbezogen, wenn das Diff auf `scripts["test:docker:live-*"]` beschränkt ist; Änderungen an Abhängigkeiten, Exporten, Versionen und anderen Package-Oberflächen verwenden weiterhin die breiteren Guards. + - Import-leichte Unit-Tests aus Agenten, Befehlen, Plugins, Auto-Reply-Helfern, `plugin-sdk` und ähnlichen reinen Utility-Bereichen laufen über die Lane `unit-fast`, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete/runtime-lastige Dateien bleiben auf den bestehenden Lanes. + - Ausgewählte Helper-Quelldateien aus `plugin-sdk` und `commands` mappen Läufe im Changed-Modus ebenfalls auf explizite benachbarte Tests in diesen leichten Lanes, sodass Helper-Änderungen nicht erneut die vollständige schwere Suite für dieses Verzeichnis ausführen. + - `auto-reply` hat dedizierte Buckets für Top-Level-Core-Helfer, Top-Level-Integrationstests `reply.*` und den Teilbaum `src/auto-reply/reply/**`. CI teilt den Reply-Teilbaum zusätzlich in Shards für Agent-Runner, Dispatch und Commands/State-Routing auf, damit ein importlastiger Bucket nicht den gesamten Node-Nachlauf besitzt. + - Normale PR-/Main-CI überspringt absichtlich den Plugin-Batch-Sweep und den release-only Shard `agentic-plugins`. Full Release Validation startet den separaten Child-Workflow `Plugin Prerelease` für diese Plugin-lastigen Suites auf Release Candidates. - - Wenn Sie Discovery-Eingaben für Message-Tools oder Compaction-Runtime- - Kontext ändern, behalten Sie beide Abdeckungsebenen bei. - - Fügen Sie fokussierte Helfer-Regressionen für reine Routing- und Normalisierungs- - Grenzen hinzu. - - Halten Sie die Integration-Suites des eingebetteten Runners gesund: + - Wenn Sie Eingaben für die Message-Tool-Erkennung oder den Compaction-Runtime-Kontext ändern, behalten Sie beide Abdeckungsebenen bei. + - Fügen Sie fokussierte Helper-Regressionen für reine Routing- und Normalisierungsgrenzen hinzu. + - Halten Sie die Integrations-Suites des eingebetteten Runners funktionsfähig: `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 realen `run.ts`- / `compact.ts`-Pfade fließen; reine Helfertests sind - kein ausreichender Ersatz für diese Integrationspfade. + - Diese Suites verifizieren, dass scoped IDs und Compaction-Verhalten weiterhin durch die echten Pfade `run.ts` / `compact.ts` laufen; reine Helper-Tests 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 die Root-Projekte, e2e- und Live-Konfigurationen hinweg. - - Die Root-UI-Lane behält ihr `jsdom`-Setup und ihren Optimizer bei, läuft aber ebenfalls auf dem - gemeinsamen nicht isolierten Runner. - - Jeder `pnpm test`-Shard erbt dieselben `threads`- + `isolate: false`- - Standardwerte 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 während großer lokaler Ausführungen zu reduzieren. - Setzen Sie `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, um mit dem Standard-V8- - Verhalten zu vergleichen. + - Die gemeinsame Vitest-Konfiguration setzt `isolate: false` fest und verwendet den nicht isolierten Runner über die Root-Projekte, e2e- und Live-Konfigurationen hinweg. + - Die Root-UI-Lane behält ihr `jsdom`-Setup und den Optimizer bei, läuft aber ebenfalls auf dem gemeinsamen nicht isolierten Runner. + - Jeder `pnpm test`-Shard erbt dieselben Defaults `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-Compile-Churn bei großen lokalen Läufen zu reduzieren. Setzen Sie `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, um mit dem Standardverhalten von V8 zu vergleichen. - - `pnpm changed:lanes` zeigt, welche Architektur-Lanes ein Diff auslöst. - - Der Pre-Commit-Hook dient nur der Formatierung. Er staget formatierte Dateien erneut und - führt weder Lint, Typecheck noch Tests aus. - - Führen Sie `pnpm check:changed` ausdrücklich vor Übergabe oder 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 Harness-, Config-, Package- oder Contract-Änderung 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. - - Die lokale Worker-Autoskalierung ist absichtlich konservativ und regelt herunter, - wenn der Load Average des Hosts bereits hoch ist, sodass mehrere gleichzeitige - Vitest-Ausführungen standardmäßig weniger Schaden anrichten. - - Die Basis-Vitest-Konfiguration markiert die Projekte/Config-Dateien als - `forceRerunTriggers`, damit Changed-Mode-Neuausführungen korrekt bleiben, wenn sich die Test- - Verkabelung ändert. - - Die Config hält `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 wünschen. + - `pnpm changed:lanes` zeigt, welche architektonischen Lanes ein Diff auslöst. + - Der Pre-Commit-Hook führt nur Formatierung aus. Er staged formatierte Dateien erneut und führt weder Lint, Typecheck noch Tests aus. + - Führen Sie `pnpm check:changed` explizit vor der Übergabe oder dem Push aus, wenn Sie das intelligente lokale Check-Gate benötigen. + - `pnpm test:changed` routet standardmäßig über günstige scoped Lanes. Verwenden Sie `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` nur, wenn der Agent entscheidet, dass eine Harness-, Config-, Package- oder Contract-Änderung 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. + - Die lokale automatische Worker-Skalierung ist absichtlich konservativ und reduziert die Auslastung, wenn der 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 Wiederholungen im Changed-Modus korrekt bleiben, wenn sich die Testverdrahtung ändert. + - Die Konfiguration hält `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-Speicherort für direktes Profiling wünschen. - + - - `pnpm test:perf:imports` aktiviert Vitest-Importdauer-Reporting plus - Import-Breakdown-Ausgabe. - - `pnpm test:perf:imports:changed` begrenzt dieselbe Profiling-Ansicht auf - seit `origin/main` geänderte Dateien. - - Shard-Timing-Daten werden nach `.artifacts/vitest-shard-timings.json` geschrieben. - Whole-Config-Ausführungen verwenden den Config-Pfad 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 die meiste Zeit in Startup-Imports verbringt, - halten Sie schwere Dependencies hinter einer schmalen lokalen `*.runtime.ts`-Grenze und - mocken Sie diese Grenze direkt, statt Runtime-Helfer tief zu importieren, nur - um sie durch `vi.mock(...)` zu reichen. - - `pnpm test:perf:changed:bench -- --ref ` vergleicht geroutetes - `test:changed` mit dem nativen Root-Projektpfad für diesen committeten - Diff und gibt Wall Time plus macOS Max RSS aus. - - `pnpm test:perf:changed:bench -- --worktree` benchmarket den aktuellen - Dirty Tree, indem die Liste geänderter Dateien 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-Startup- und Transform-Overhead. - - `pnpm test:perf:profile:runner` schreibt Runner-CPU-+Heap-Profile für die - Unit-Suite mit deaktivierter Dateiparallelität. + - `pnpm test:perf:imports` aktiviert Vitest-Importdauer-Reporting plus Import-Breakdown-Ausgabe. + - `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 Startimporten verbringt, halten Sie schwere Abhängigkeiten hinter einer engen lokalen `*.runtime.ts`-Nahtstelle und mocken Sie diese Nahtstelle direkt, statt Runtime-Helfer nur tief zu importieren, um sie durch `vi.mock(...)` zu schleusen. + - `pnpm test:perf:changed:bench -- --ref ` vergleicht geroutetes `test:changed` mit dem nativen Root-Projektpfad für dieses committete Diff und gibt Wall-Time 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-Startup- und Transform-Overhead. + - `pnpm test:perf:profile:runner` schreibt Runner-CPU+Heap-Profile für die Unit-Suite mit deaktivierter Dateiparallelität. @@ -504,32 +468,32 @@ Betrachten Sie die Suiten als „zunehmenden Realismus“ (und zunehmende Flakin ### Stabilität (Gateway) - Befehl: `pnpm test:stability:gateway` -- Config: `vitest.gateway.config.ts`, auf einen Worker erzwungen +- Konfiguration: `vitest.gateway.config.ts`, auf einen Worker erzwungen - Umfang: - - Startet standardmäßig ein echtes local loopback Gateway mit aktivierter Diagnose - - Treibt synthetischen Gateway-Message-, Memory- und Large-Payload-Churn durch den Diagnose-Event-Pfad - - Fragt `diagnostics.stability` über das Gateway-WS-RPC ab - - Deckt Hilfen zur Persistierung des Diagnose-Stabilitätsbundles ab - - Stellt sicher, dass der Recorder begrenzt bleibt, synthetische RSS-Samples unter dem Druckbudget bleiben und Queue-Tiefen pro Session wieder auf null ablaufen + - Startet standardmäßig einen echten Loopback-Gateway mit aktivierter Diagnose + - Treibt synthetischen Gateway-Nachrichten-, Memory- und Large-Payload-Churn durch den Diagnose-Event-Pfad + - Fragt `diagnostics.stability` über den Gateway-WS-RPC ab + - Deckt Persistenz-Helper für Diagnose-Stabilitätsbundles ab + - Stellt sicher, dass der Recorder begrenzt bleibt, synthetische RSS-Samples unter dem Pressure-Budget bleiben und Queue-Tiefen pro Sitzung wieder auf null ablaufen - Erwartungen: - CI-sicher und ohne Schlüssel - - Schmale Lane für die Nachverfolgung von Stabilitätsregressionen, kein Ersatz für die vollständige Gateway-Suite + - Enge Lane für Nachverfolgung von Stabilitätsregressionen, kein Ersatz für die vollständige Gateway-Suite ### E2E (Gateway-Smoke) - Befehl: `pnpm test:e2e` -- Config: `vitest.e2e.config.ts` -- Dateien: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` und gebündelte Plugin-E2E-Tests unter `extensions/` -- Runtime-Standards: +- Konfiguration: `vitest.e2e.config.ts` +- Dateien: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` und E2E-Tests gebündelter Plugins unter `extensions/` +- Runtime-Defaults: - 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 Silent-Modus, um Console-I/O-Overhead zu reduzieren. - Nützliche Overrides: - - `OPENCLAW_E2E_WORKERS=` zum Erzwingen der Worker-Anzahl (auf 16 begrenzt). - - `OPENCLAW_E2E_VERBOSE=1` zum erneuten Aktivieren ausführlicher Console-Ausgabe. + - `OPENCLAW_E2E_WORKERS=`, 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 des Gateways mit mehreren Instanzen - - WebSocket-/HTTP-Oberflächen, Node-Pairing und schwergewichtigere Netzwerkfunktionen + - End-to-End-Verhalten von Multi-Instance-Gateways + - WebSocket-/HTTP-Oberflächen, Node-Pairing und schwerere Netzwerkteile - Erwartungen: - Läuft in CI (wenn in der Pipeline aktiviert) - Keine echten Schlüssel erforderlich @@ -540,39 +504,39 @@ Betrachten Sie die Suiten als „zunehmenden Realismus“ (und zunehmende Flakin - 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 exec aus + - Startet über Docker einen isolierten OpenShell-Gateway auf dem Host + - Erstellt eine Sandbox aus einem temporären lokalen Dockerfile + - Testet das OpenShell-Backend von OpenClaw über echtes `sandbox ssh-config` + SSH-Ausführung - Verifiziert remote-kanonisches Dateisystemverhalten über die Sandbox-fs-Bridge - Erwartungen: - - Nur Opt-in; nicht Teil der standardmäßigen `pnpm test:e2e`-Ausführung + - Nur opt-in; nicht Teil des standardmäßigen `pnpm test:e2e`-Laufs - Erfordert eine lokale `openshell`-CLI plus einen funktionierenden Docker-Daemon - - Verwendet isolierte `HOME` / `XDG_CONFIG_HOME` und zerstört anschließend Test-Gateway und Sandbox + - Verwendet isoliertes `HOME` / `XDG_CONFIG_HOME` und zerstört anschließend den Test-Gateway und die Sandbox - Nützliche Overrides: - - `OPENCLAW_E2E_OPENSHELL=1`, um den Test beim manuellen Ausführen der breiteren e2e-Suite zu aktivieren - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, um auf ein nicht standardmäßiges CLI-Binary oder Wrapper-Skript zu zeigen + - `OPENCLAW_E2E_OPENSHELL=1`, um den Test zu aktivieren, wenn Sie die breitere e2e-Suite manuell ausführen + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, um auf ein nicht standardmäßiges CLI-Binary oder Wrapper-Skript zu verweisen ### Live (echte Provider + echte Modelle) - Befehl: `pnpm test:live` -- Config: `vitest.live.config.ts` -- Dateien: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` und gebündelte Plugin-Live-Tests unter `extensions/` +- Konfiguration: `vitest.live.config.ts` +- Dateien: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` und Live-Tests gebündelter Plugins unter `extensions/` - Standard: durch `pnpm test:live` **aktiviert** (setzt `OPENCLAW_LIVE_TEST=1`) - Umfang: - - „Funktioniert dieser Provider/dieses Modell _heute_ tatsächlich mit echten Anmeldedaten?“ - - Erkennt Provider-Formatänderungen, Eigenheiten beim Tool-Calling, Auth-Probleme und Rate-Limit-Verhalten + - „Funktioniert dieser Provider/dieses Modell _heute_ tatsächlich mit echten Zugangsdaten?“ + - Erkennt Provider-Formatänderungen, Tool-Calling-Eigenheiten, Auth-Probleme und Rate-Limit-Verhalten - Erwartungen: - - Von Natur aus nicht CI-stabil (echte Netzwerke, echte Provider-Richtlinien, Quoten, Ausfälle) - - Kostet Geld / verwendet Rate Limits - - Bevorzugen Sie eng begrenzte Teilmengen statt „alles“ -- Live-Ausführungen sourcen `~/.profile`, um fehlende API-Schlüssel aufzunehmen. -- Standardmäßig isolieren Live-Ausführungen weiterhin `HOME` und kopieren Config-/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 bewusst Ihr echtes Home-Verzeichnis verwenden müssen. -- `pnpm test:live` verwendet jetzt standardmäßig einen ruhigeren Modus: Er behält `[live] ...`-Fortschrittsausgabe bei, unterdrückt aber den zusätzlichen `~/.profile`-Hinweis und schaltet Gateway-Bootstrap-Logs/Bonjour-Gerede stumm. Setzen Sie `OPENCLAW_LIVE_TEST_QUIET=0`, wenn Sie die vollständigen Startup-Logs zurückhaben möchten. -- API-Schlüsselrotation (Provider-spezifisch): Setzen Sie `*_API_KEYS` mit Komma-/Semikolonformat oder `*_API_KEY_1`, `*_API_KEY_2` (zum Beispiel `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) oder einen pro-Live-Override über `OPENCLAW_LIVE_*_KEY`; Tests versuchen es bei Rate-Limit-Antworten erneut. + - Absichtlich nicht CI-stabil (echte Netzwerke, echte Provider-Richtlinien, Quotas, Ausfälle) + - Kostet Geld / verbraucht Rate-Limits + - Bevorzugen Sie eingegrenzte Teilmengen statt „alles“ +- Live-Läufe sourcen `~/.profile`, um fehlende API-Schlüssel aufzunehmen. +- Standardmäßig isolieren Live-Läufe weiterhin `HOME` und kopieren Config-/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` nutzt jetzt standardmäßig einen ruhigeren Modus: `[live] ...`-Fortschrittsausgabe bleibt erhalten, aber die zusätzliche `~/.profile`-Meldung wird unterdrückt und Gateway-Bootstrap-Logs/Bonjour-Ausgaben werden stummgeschaltet. Setzen Sie `OPENCLAW_LIVE_TEST_QUIET=0`, wenn Sie die vollständigen Startlogs 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 per `OPENCLAW_LIVE_*_KEY`; Tests versuchen es bei Rate-Limit-Antworten erneut. - Fortschritts-/Heartbeat-Ausgabe: - - Live-Suites geben jetzt Fortschrittszeilen nach stderr aus, sodass lange Provider-Aufrufe sichtbar aktiv sind, selbst wenn die Vitest-Console-Erfassung ruhig ist. - - `vitest.live.config.ts` deaktiviert Vitest-Console-Interception, sodass Provider-/Gateway-Fortschrittszeilen während Live-Ausführungen sofort gestreamt werden. + - Live-Suites geben jetzt Fortschrittszeilen nach stderr aus, sodass lange Provider-Aufrufe sichtbar aktiv sind, auch wenn Vitest-Console-Capture ruhig ist. + - `vitest.live.config.ts` deaktiviert Vitest-Console-Interception, damit Provider-/Gateway-Fortschrittszeilen während Live-Läufen sofort gestreamt werden. - Stimmen Sie Direct-Model-Heartbeats mit `OPENCLAW_LIVE_HEARTBEAT_MS` ab. - Stimmen Sie Gateway-/Probe-Heartbeats mit `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` ab. @@ -580,195 +544,197 @@ Betrachten Sie die Suiten als „zunehmenden Realismus“ (und zunehmende Flakin Verwenden Sie diese Entscheidungstabelle: -- Bearbeitungslogik/-tests: Führen Sie `pnpm test` aus (und `pnpm test:coverage`, wenn Sie viel geändert haben) -- Gateway-Netzwerk / WS-Protokoll / Pairing berühren: Fügen Sie `pnpm test:e2e` hinzu -- Debugging von „mein Bot ist offline“ / Provider-spezifischen Fehlern / Tool-Aufrufen: Führen Sie ein eingegrenztes `pnpm test:live` aus +- Bearbeiten von Logik/Tests: Führen Sie `pnpm test` aus (und `pnpm test:coverage`, wenn Sie viel geändert haben) +- Berühren von Gateway-Netzwerkkommunikation / WS-Protokoll / Pairing: Fügen Sie `pnpm test:e2e` hinzu +- Debugging von „mein Bot ist down“ / Provider-spezifischen Fehlern / Tool-Aufrufen: Führen Sie ein eingegrenztes `pnpm test:live` aus ## Live-Tests (mit Netzwerkzugriff) -Für die Live-Modellmatrix, CLI-Backend-Smokes, ACP-Smokes, das Codex-App-Server- -Harness und alle Live-Tests für Media-Provider (Deepgram, BytePlus, ComfyUI, Bild, -Musik, Video, Medien-Harness) — plus Umgang mit Anmeldedaten für Live-Läufe — siehe -[Tests — Live-Suites](/de/help/testing-live). +Für die Live-Modellmatrix, CLI-Backend-Smokes, ACP-Smokes, den Codex-App-Server- +Harness und alle Live-Tests für Medien-Provider (Deepgram, BytePlus, ComfyUI, Bild, +Musik, Video, Medien-Harness) – plus den Umgang mit Anmeldedaten für Live-Läufe – siehe +[Testing – Live-Suiten](/de/help/testing-live). -## Docker-Runner (optionale Prüfungen für „funktioniert unter Linux“) +## Docker-Runner (optionale „funktioniert unter Linux“-Prüfungen) -Diese Docker-Runner sind in zwei Gruppen aufgeteilt: +Diese Docker-Runner teilen sich in zwei Gruppen auf: -- Live-Modell-Runner: `test:docker:live-models` und `test:docker:live-gateway` führen nur ihre passende Live-Datei für den Profil-Key innerhalb des Repo-Docker-Images aus (`src/agents/models.profiles.live.test.ts` und `src/gateway/gateway-models.profiles.live.test.ts`), wobei Ihr lokales Konfigurationsverzeichnis und Ihr Workspace gemountet werden (und `~/.profile` eingelesen wird, falls gemountet). Die passenden lokalen Einstiegspunkte sind `test:live:models-profiles` und `test:live:gateway-profiles`. +- Live-Modell-Runner: `test:docker:live-models` und `test:docker:live-gateway` führen nur die jeweils passende Live-Datei mit Profil-Key im Docker-Image des Repos aus (`src/agents/models.profiles.live.test.ts` und `src/gateway/gateway-models.profiles.live.test.ts`), wobei Ihr lokales Konfigurationsverzeichnis und Ihr Workspace gemountet werden (und `~/.profile` eingelesen wird, falls gemountet). Die passenden lokalen Einstiegspunkte sind `test:live:models-profiles` und `test:live:gateway-profiles`. - Docker-Live-Runner verwenden standardmäßig eine kleinere Smoke-Obergrenze, damit ein vollständiger Docker-Durchlauf 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 Umgebungsvariablen, wenn Sie + `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`, packt OpenClaw einmal als npm-Tarball über `scripts/package-openclaw-for-docker.mjs` und baut/verwendet dann zwei `scripts/e2e/Dockerfile`-Images. Das Bare-Image ist nur der Node/Git-Runner für Installations-, Update- und Plugin-Abhängigkeits-Lanes; diese Lanes mounten den vorab gebauten Tarball. Das funktionale Image installiert denselben Tarball nach `/app` für Built-App-Funktions-Lanes. Docker-Lane-Definitionen befinden sich in `scripts/lib/docker-e2e-scenarios.mjs`; die Planner-Logik befindet sich 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 Ressourcenobergrenzen verhindern, dass schwere Live-, npm-Installations- und Multi-Service-Lanes alle gleichzeitig starten. Wenn eine einzelne Lane schwerer ist als die aktiven Obergrenzen, 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. Standardwerte 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 den Status aus, speichert erfolgreiche Lane-Zeiten in `.artifacts/docker-tests/lane-timings.json` und nutzt 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 Build oder Docker-Ausführung auszugeben, oder `node scripts/test-docker-all.mjs --plan-json`, um den CI-Plan für ausgewählte Lanes, Paket-/Image-Anforderungen und Anmeldedaten 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, statt den ausgewählten Ref neu zu packen. `workflow_ref` wählt die vertrauenswürdigen Workflow-/Harness-Skripte aus, während `package_ref` den Source-Commit/-Branch/-Tag auswählt, der gepackt wird, wenn `source=ref`; so kann die aktuelle Acceptance-Logik ältere vertrauenswürdige Commits validieren. Profile sind nach Breite geordnet: `smoke` ist schnelle Installation/Kanal/Agent plus Gateway/Konfiguration, `package` ist der Paket-/Update-/Plugin-Vertrag und der standardmäßige native Ersatz für die meiste Parallels-Paket-/Update-Abdeckung, `product` fügt MCP-Kanäle, Cron-/Subagent-Bereinigung, OpenAI-Websuche und OpenWebUI hinzu, und `full` führt die Docker-Abschnitte für den Release-Pfad mit OpenWebUI aus. Release-Validierung führt ein benutzerdefiniertes Paket-Delta aus (`bundled-channel-deps-compat plugins-offline`) plus Telegram-Paket-QA, weil die Docker-Abschnitte für den Release-Pfad die überlappenden Paket-/Update-/Plugin-Lanes bereits abdecken. Aus Artefakten generierte gezielte GitHub-Docker-Wiederholungskommandos enthalten vorherige Paketartefakt- und vorbereitete Image-Eingaben, sofern verfügbar, damit fehlgeschlagene Lanes vermeiden können, das Paket und die Images erneut zu bauen. -- Build- und Release-Prüfungen führen `scripts/check-cli-bootstrap-imports.mjs` nach tsdown aus. Der Guard durchläuft den statisch gebauten Graphen ab `dist/entry.js` und `dist/cli/run-main.js` und schlägt fehl, wenn der Start vor dem Dispatch Paketabhängigkeiten wie Commander, Prompt-UI, undici oder Logging vor dem Command-Dispatch importiert; außerdem hält er den gebündelten Gateway-Run-Chunk unter dem Budget und weist statische Importe bekannter kalter Gateway-Pfade zurück. Packaged-CLI-Smoke deckt außerdem Root-Hilfe, Onboard-Hilfe, Doctor-Hilfe, Status, Konfigurationsschema und einen Model-List-Befehl ab. -- 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 ausgelieferte Paket-Metadatenlücken: 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 Konfigurationsmetadaten-Migration 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: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` und `test:docker:config-reload` starten einen oder mehrere echte Container und prüfen Integrationspfade auf höherer Ebene. +- `test:docker:all` baut das Live-Docker-Image einmal über `test:docker:live-build`, packt OpenClaw einmal als npm-Tarball über `scripts/package-openclaw-for-docker.mjs` und baut bzw. verwendet dann zwei `scripts/e2e/Dockerfile`-Images erneut. Das Bare-Image ist nur der Node/Git-Runner für Installations-/Update-/Plugin-Abhängigkeits-Lanes; diese Lanes mounten den vorgebauten Tarball. Das funktionale Image installiert denselben Tarball nach `/app` für Lanes zur Funktionalität der gebauten App. Docker-Lane-Definitionen liegen in `scripts/lib/docker-e2e-scenarios.mjs`; die 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 Ressourcenobergrenzen verhindern, dass schwere Live-, npm-Installations- und Multi-Service-Lanes alle gleichzeitig starten. Wenn eine einzelne Lane schwerer ist als die aktiven Obergrenzen, 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. Standardwerte 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 den Status aus, speichert erfolgreiche Lane-Laufzeiten in `.artifacts/docker-tests/lane-timings.json` und verwendet diese Laufzeiten, 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-Anforderungen und Anmeldedaten 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, statt den ausgewählten Ref neu zu packen. `workflow_ref` wählt die vertrauenswürdigen Workflow-/Harness-Skripte aus, während `package_ref` den Source-Commit/-Branch/-Tag auswählt, der gepackt wird, wenn `source=ref` ist; dadurch kann aktuelle Acceptance-Logik ältere vertrauenswürdige Commits validieren. Profile sind nach Breite geordnet: `smoke` ist schnelle Installation/Channel/Agent plus Gateway/Konfiguration, `package` ist der Paket-/Update-/Plugin-Vertrag plus die keyless Upgrade-Survivor-Fixture und der standardmäßige native Ersatz für den Großteil der Parallels-Paket-/Update-Abdeckung, `product` ergänzt MCP-Channels, Cron-/Subagent-Bereinigung, OpenAI-Websuche und OpenWebUI, und `full` führt die Docker-Blöcke des Release-Pfads mit OpenWebUI aus. Release-Validierung führt ein benutzerdefiniertes Paket-Delta (`bundled-channel-deps-compat plugins-offline`) plus Telegram-Paket-QA aus, weil die Docker-Blöcke des Release-Pfads die überlappenden Paket-/Update-/Plugin-Lanes bereits abdecken. Aus Artefakten generierte gezielte GitHub-Docker-Rerun-Befehle enthalten frühere Paketartefakt- und vorbereitete Image-Eingaben, wenn verfügbar, sodass fehlgeschlagene Lanes vermeiden können, Paket und Images neu zu bauen. +- Build- und Release-Prüfungen führen `scripts/check-cli-bootstrap-imports.mjs` nach tsdown aus. Der Guard durchläuft den statisch gebauten Graphen ab `dist/entry.js` und `dist/cli/run-main.js` und schlägt fehl, wenn Pre-Dispatch-Startup Paketabhängigkeiten wie Commander, Prompt-UI, undici oder Logging vor dem Command-Dispatch importiert; außerdem hält er den gebündelten Gateway-Run-Chunk unter dem Budget und weist statische Importe bekannter kalter Gateway-Pfade zurück. Der paketierte CLI-Smoke deckt außerdem Root-Hilfe, Onboard-Hilfe, Doctor-Hilfe, Status, Konfigurationsschema und einen Modelllisten-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 der Harness nur ausgelieferte Paket-Metadatenlücken: ausgelassene private QA-Inventareinträge, fehlendes `gateway install --wrapper`, fehlende Patch-Dateien in der aus dem Tarball abgeleiteten Git-Fixture, fehlendes persistiertes `update.channel`, Legacy-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: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` und `test:docker:config-reload` starten 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 dann vor dem Lauf in das Container-Home, damit OAuth externer CLIs Tokens aktualisieren kann, ohne den Auth-Store des Hosts zu verändern: +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 dann vor dem Lauf in das Home-Verzeichnis des Containers, sodass 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-Test: `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`) +- ACP-Bind-Smoke-Test: `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-Test: `pnpm test:docker:live-cli-backend` (Skript: `scripts/test-live-cli-backend-docker.sh`) - Codex-App-Server-Harness-Smoke-Test: `pnpm test:docker:live-codex-harness` (Skript: `scripts/test-live-codex-harness-docker.sh`) -- Gateway + Entwicklungsagent: `pnpm test:docker:live-gateway` (Skript: `scripts/test-live-gateway-models-docker.sh`) -- Observability-Smoke-Test: `pnpm qa:otel:smoke` ist eine private QA-Lane für Source-Checkouts. Sie ist absichtlich nicht Teil der Package-Docker-Release-Lanes, weil der npm-Tarball QA Lab auslässt. +- Gateway + Entwicklungs-Agent: `pnpm test:docker:live-gateway` (Skript: `scripts/test-live-gateway-models-docker.sh`) +- Observability-Smoke-Test: `pnpm qa:otel:smoke` ist eine private QA-Lane für Source-Checkouts. Sie ist absichtlich nicht Teil der Docker-Release-Lanes für Pakete, weil der npm-Tarball QA Lab auslässt. - Open WebUI-Live-Smoke-Test: `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-/Kanal-/Agent-Smoke-Test: `pnpm test:docker:npm-onboard-channel-agent` installiert den gepackten OpenClaw-Tarball global in Docker, konfiguriert OpenAI per Env-Ref-Onboarding plus standardmäßig Telegram, verifiziert, dass Doctor aktivierte Plugin-Runtime-Abhängigkeiten repariert, und führt einen gemockten OpenAI-Agent-Turn aus. Verwenden Sie einen vorgebauten 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 Kanal mit `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Update-Kanalwechsel-Smoke-Test: `pnpm test:docker:update-channel-switch` installiert den gepackten OpenClaw-Tarball global in Docker, wechselt von Package-`stable` zu Git-`dev`, verifiziert den persistierten Kanal und die Plugin-Funktion nach dem Update, wechselt dann zurück zu Package-`stable` und prüft den Update-Status. -- Session-Runtime-Kontext-Smoke-Test: `pnpm test:docker:session-runtime-context` verifiziert die Persistenz verborgener Runtime-Kontext-Transkripte sowie die Doctor-Reparatur betroffener duplizierter Prompt-Rewrite-Branches. -- Bun-Smoke-Test für globale Installation: `bash scripts/e2e/bun-global-install-smoke.sh` packt den aktuellen Tree, installiert ihn mit `bun install -g` in einem isolierten Home-Verzeichnis und verifiziert, dass `openclaw infer image providers --json` gebündelte Bild-Provider zurückgibt, statt hängen zu bleiben. Verwenden Sie einen vorgebauten 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-Test: `bash scripts/test-install-sh-docker.sh` teilt einen npm-Cache zwischen Root-, Update- und direkten npm-Containern. Der Update-Smoke-Test verwendet standardmäßig npm `latest` als stabile Baseline, bevor auf den Kandidaten-Tarball aktualisiert wird. Überschreiben Sie dies lokal mit `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` oder auf GitHub mit der `update_baseline_version`-Eingabe des Install Smoke-Workflows. Nicht-Root-Installer-Prüfungen behalten einen isolierten npm-Cache, damit root-eigene Cache-Einträge das Installationsverhalten im Benutzerkontext nicht verdecken. Setzen Sie `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, um den Root-/Update-/Direct-npm-Cache bei lokalen erneuten Läufen wiederzuverwenden. -- 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 Env aus, wenn Abdeckung für direktes `npm install -g` benötigt wird. -- CLI-Smoke-Test zum Löschen gemeinsam genutzter Arbeitsbereiche durch Agents: `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 Arbeitsbereich in einem isolierten Container-Home an, führt `agents delete --json` aus und verifiziert gültiges JSON sowie das Verhalten beibehaltener Arbeitsbereiche. 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. +- npm-Tarball-Smoke-Test für Onboarding/Kanal/Agent: `pnpm test:docker:npm-onboard-channel-agent` installiert den gepackten OpenClaw-Tarball global in Docker, konfiguriert OpenAI per Env-Ref-Onboarding sowie standardmäßig Telegram, verifiziert, dass Doctor aktivierte Plugin-Runtime-Abhängigkeiten repariert, und führt eine gemockte OpenAI-Agent-Runde aus. Verwenden Sie einen vorgebauten Tarball mit `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, überspringen Sie den Host-Rebuild mit `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0`, oder wechseln Sie den Kanal mit `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Update-Kanalwechsel-Smoke-Test: `pnpm test:docker:update-channel-switch` installiert den gepackten OpenClaw-Tarball global in Docker, wechselt vom Paket `stable` zu Git `dev`, verifiziert den gespeicherten Kanal und die Plugin-Funktion nach dem Update, wechselt dann zurück zum Paket `stable` und prüft den Update-Status. +- Upgrade-Survivor-Smoke-Test: `pnpm test:docker:upgrade-survivor` installiert den gepackten OpenClaw-Tarball über ein verschmutztes Fixture eines alten Benutzers mit Agenten, Kanalkonfiguration, Plugin-Allowlists, veraltetem Plugin-Runtime-Deps-Status und bestehenden Workspace-/Sitzungsdateien. Es führt ein Paket-Update sowie einen nicht interaktiven Doctor ohne Live-Provider- oder Kanalschlüssel aus, startet dann ein local loopback-Gateway und prüft die Konfigurations-/Statusbewahrung sowie Start-/Status-Budgets. +- Smoke-Test für Sitzungs-Runtime-Kontext: `pnpm test:docker:session-runtime-context` verifiziert die Persistenz des versteckten Runtime-Kontext-Transkripts sowie die Doctor-Reparatur betroffener duplizierter Prompt-Rewrite-Branches. +- Smoke-Test für globale Bun-Installation: `bash scripts/e2e/bun-global-install-smoke.sh` packt den aktuellen Baum, installiert ihn mit `bun install -g` in einem isolierten Home und verifiziert, dass `openclaw infer image providers --json` gebündelte Bild-Provider zurückgibt, statt zu hängen. Verwenden Sie einen vorgebauten Tarball mit `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, ü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-Test: `bash scripts/test-install-sh-docker.sh` teilt einen npm-Cache zwischen seinen Root-, Update- und Direct-npm-Containern. Der Update-Smoke-Test verwendet standardmäßig npm `latest` als stabile Baseline vor dem Upgrade auf den Kandidaten-Tarball. Überschreiben Sie dies lokal mit `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` oder auf GitHub mit der Eingabe `update_baseline_version` des Install-Smoke-Workflows. Nicht-Root-Installer-Prüfungen verwenden 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 wiederzuverwenden. +- 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 Umgebungsvariable aus, wenn Abdeckung für direktes `npm install -g` benötigt wird. +- CLI-Smoke-Test für das Löschen gemeinsam genutzter Workspaces durch Agenten: `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 Agenten mit einem Workspace in einem isolierten Container-Home an, führt `agents delete --json` aus und verifiziert gültiges JSON sowie das Verhalten für beibehaltene Workspaces. 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`. - Gateway-Netzwerk (zwei Container, WS-Authentifizierung + Health): `pnpm test:docker:gateway-network` (Skript: `scripts/e2e/gateway-network-docker.sh`) -- Browser-CDP-Snapshot-Smoke-Test: `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, zu Cursor-Klickzielen hochgestufte Elemente, iframe-Refs und Frame-Metadaten abdecken. -- OpenAI Responses web_search-Regression mit minimalem 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` erhöht, erzwingt dann die Ablehnung durch das Provider-Schema und prüft, dass das rohe Detail in den Gateway-Logs erscheint. -- MCP-Kanal-Bridge (vorbereiteter Gateway + stdio-Bridge + roher Claude-Benachrichtigungs-Frame-Smoke-Test): `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-Test): `pnpm test:docker:pi-bundle-mcp-tools` (Skript: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Cron-/Subagent-MCP-Cleanup (echter Gateway + stdio-MCP-Kindprozess-Abbau nach isolierten Cron- und One-Shot-Subagent-Läufen): `pnpm test:docker:cron-mcp-cleanup` (Skript: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Browser-CDP-Snapshot-Smoke-Test: `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, per Cursor hochgestufte klickbare Elemente, iframe-Referenzen und Frame-Metadaten abdecken. +- Regression für OpenAI Responses `web_search` mit minimalem Reasoning: `pnpm test:docker:openai-web-search-minimal` (Skript: `scripts/e2e/openai-web-search-minimal-docker.sh`) führt einen gemockten OpenAI-Server durch das 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 Rohdetail in den Gateway-Logs erscheint. +- MCP-Kanal-Bridge (vorbefülltes Gateway + stdio-Bridge + roher Claude-Notification-Frame-Smoke-Test): `pnpm test:docker:mcp-channels` (Skript: `scripts/e2e/mcp-channels-docker.sh`) +- Pi-Bundle-MCP-Tools (echter stdio-MCP-Server + Smoke-Test für Allow/Deny des eingebetteten Pi-Profils): `pnpm test:docker:pi-bundle-mcp-tools` (Skript: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Cron/Subagent-MCP-Bereinigung (echtes Gateway + Abräumen von stdio-MCP-Child-Prozessen nach isolierten Cron- und einmaligen Subagent-Ausführungen): `pnpm test:docker:cron-mcp-cleanup` (Skript: `scripts/e2e/cron-mcp-cleanup-docker.sh`) - Plugins (Install-Smoke-Test, ClawHub-Kitchen-Sink-Installation/-Deinstallation, Marketplace-Updates und Claude-Bundle-Aktivierung/-Inspektion): `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-Package-/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-Test: `pnpm test:docker:plugin-update` (Skript: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Config-Reload-Metadaten-Smoke-Test: `pnpm test:docker:config-reload` (Skript: `scripts/e2e/config-reload-source-docker.sh`) -- Gebündelte Plugin-Runtime-Abhängigkeiten: `pnpm test:docker:bundled-channel-deps` baut standardmäßig ein kleines Docker-Runner-Image, baut und packt OpenClaw einmal auf dem Host und mountet diesen Tarball dann in jedes Linux-Installationsszenario. Verwenden Sie das Image mit `OPENCLAW_SKIP_DOCKER_BUILD=1` erneut, überspringen Sie den Host-Rebuild nach einem frischen lokalen Build mit `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, oder verweisen Sie mit `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz` auf einen vorhandenen Tarball. Das vollständige Docker-Aggregat und die gebündelten Release-Path-Channel-Chunks pre-packen diesen Tarball einmal und sharden dann gebündelte Kanalprüfungen in unabhängige Lanes, einschließlich separater Update-Lanes für Telegram, Discord, Slack, Feishu, memory-lancedb und ACPX. Release-Chunks teilen Kanal-Smoke-Tests, Update-Ziele und Setup-/Runtime-Verträge in `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` und `bundled-channels-contracts` auf; der aggregierte `bundled-channels`-Chunk bleibt für manuelle erneute Läufe verfügbar. Der Release-Workflow teilt außerdem Provider-Installer-Chunks und gebündelte Plugin-Install-/Uninstall-Chunks auf; die Legacy-Chunks `package-update`, `plugins-runtime` und `plugins-integrations` bleiben aggregierte Aliasse für manuelle erneute Läufe. Verwenden Sie `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, um die Kanalmatrix beim direkten Ausführen der gebündelten Lane einzugrenzen, oder `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, um das Update-Szenario einzugrenzen. Docker-Läufe pro Szenario verwenden standardmäßig `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; das Multi-Target-Update-Szenario verwendet standardmäßig `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. Die Lane verifiziert außerdem, dass `channels..enabled=false` und `plugins.entries..enabled=false` die Doctor-/Runtime-Abhängigkeitsreparatur unterdrücken. + 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. +- Smoke-Test für unveränderte Plugin-Updates: `pnpm test:docker:plugin-update` (Skript: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke-Test für Config-Reload-Metadaten: `pnpm test:docker:config-reload` (Skript: `scripts/e2e/config-reload-source-docker.sh`) +- Gebündelte Plugin-Runtime-Abhängigkeiten: `pnpm test:docker:bundled-channel-deps` baut standardmäßig ein kleines Docker-Runner-Image, baut und packt OpenClaw einmal auf dem Host und mountet diesen Tarball dann in jedes Linux-Installationsszenario. Verwenden Sie das Image erneut mit `OPENCLAW_SKIP_DOCKER_BUILD=1`, überspringen Sie den Host-Rebuild nach einem frischen lokalen Build mit `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, oder verweisen Sie mit `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz` auf einen bestehenden Tarball. Das vollständige Docker-Aggregat und die Bundled-Channel-Chunks des Release-Pfads vorpacken diesen Tarball einmal und teilen dann gebündelte Kanalprüfungen in unabhängige Lanes auf, einschließlich separater Update-Lanes für Telegram, Discord, Slack, Feishu, memory-lancedb und ACPX. Release-Chunks teilen Kanal-Smoke-Tests, Update-Ziele und Setup-/Runtime-Verträge in `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` und `bundled-channels-contracts` auf; der aggregierte Chunk `bundled-channels` bleibt für manuelle Wiederholungen verfügbar. Der Release-Workflow teilt außerdem Provider-Installer-Chunks und gebündelte Plugin-Installations-/Deinstallations-Chunks auf; die Legacy-Chunks `package-update`, `plugins-runtime` und `plugins-integrations` bleiben als Aggregat-Aliasse für manuelle Wiederholungen erhalten. Verwenden Sie `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, um die Kanalmatrix beim direkten Ausführen der gebündelten Lane einzugrenzen, oder `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, um das Update-Szenario einzugrenzen. Pro-Szenario-Docker-Ausführungen verwenden standardmäßig `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; das Multi-Target-Update-Szenario verwendet standardmäßig `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. Die Lane verifiziert außerdem, dass `channels..enabled=false` und `plugins.entries..enabled=false` die Doctor-/Runtime-Abhängigkeitsreparatur unterdrücken. - Grenzen Sie gebündelte Plugin-Runtime-Abhängigkeiten während der Iteration ein, indem Sie nicht zusammenhängende Szenarien deaktivieren, zum Beispiel: `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. -So bauen Sie das gemeinsam genutzte funktionale Image manuell vor und verwenden es erneut: +So bauen Sie das gemeinsam genutzte funktionale Image manuell vor und verwenden es wieder: ```bash 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 zeigt, ziehen die Skripte es, falls es nicht bereits lokal vorhanden ist. Die QR- und Installer-Docker-Tests behalten ihre eigenen Dockerfiles, weil sie Package-/Installationsverhalten statt der gemeinsam genutzten gebauten App-Runtime validieren. +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 zeigt, 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 gebauten App-Runtime validieren. -Die Live-Model-Docker-Runner binden außerdem den aktuellen Checkout schreibgeschützt ein und -stagen ihn in ein temporäres Arbeitsverzeichnis innerhalb des Containers. Dadurch bleibt das Runtime- -Image schlank, während Vitest dennoch gegen Ihre exakte lokale Source/Config ausgeführt wird. -Der Staging-Schritt überspringt große nur lokal relevante Caches und App-Build-Ausgaben wie +Die Docker-Runner für Live-Modelle binden außerdem den aktuellen Checkout schreibgeschützt ein und +stellen ihn in einem temporären Arbeitsverzeichnis innerhalb des Containers bereit. Dadurch bleibt das Runtime- +Image schlank, während Vitest trotzdem gegen Ihre exakte lokale Source-/Konfigurationsbasis läuft. +Der Staging-Schritt überspringt große, nur lokale Caches und App-Build-Ausgaben wie `.pnpm-store`, `.worktrees`, `__openclaw_vitest__` sowie app-lokale `.build`- oder -Gradle-Ausgabeverzeichnisse, damit Docker-Live-Läufe nicht minutenlang mit dem Kopieren -maschinenspezifischer Artefakte verbringen. +Gradle-Ausgabeverzeichnisse, damit Docker-Live-Läufe 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, leiten Sie daher auch -`OPENCLAW_LIVE_GATEWAY_*` durch, wenn Sie Gateway- +echten Telegram/Discord/usw.-Channel-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 aus dieser Docker-Lane eingrenzen oder ausschließen müssen. `test:docker:openwebui` ist ein höherwertiger 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, verifiziert, dass `/api/models` `openclaw/default` exponiert, und sendet dann eine +startet einen gepinnten Open-WebUI-Container gegen dieses Gateway, meldet sich über +Open WebUI an, verifiziert, 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 deutlich langsamer sein, weil Docker möglicherweise das -Open WebUI-Image ziehen muss und Open WebUI seine eigene Kaltstart-Einrichtung abschließen muss. +Der erste Lauf kann merklich langsamer sein, weil Docker möglicherweise das +Open-WebUI-Image laden muss und Open WebUI seine eigene Kaltstart-Einrichtung abschließen muss. Diese Lane erwartet einen nutzbaren Live-Modellschlüssel, und `OPENCLAW_PROFILE_FILE` -(standardmäßig `~/.profile`) ist der primäre Weg, ihn in dockerisierten Läufen bereitzustellen. +(standardmäßig `~/.profile`) ist der primäre Weg, ihn in Docker-basierten 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 vorbereiteten Gateway- -Container, startet einen zweiten Container, der `openclaw mcp serve` erzeugt, und -verifiziert dann geroutete Konversationserkennung, Transkript-Lesevorgänge, Anhangsmetadaten, -Verhalten der Live-Event-Queue, ausgehendes Send-Routing sowie Claude-artige Kanal- und -Berechtigungsbenachrichtigungen über die echte stdio-MCP-Bridge. Die Benachrichtigungsprüfung +echtes Telegram-, Discord- oder iMessage-Konto. Es bootet einen vorbefüllten Gateway- +Container, startet einen zweiten Container, der `openclaw mcp serve` startet, und +verifiziert dann geroutete Konversationserkennung, Transkriptlesezugriffe, Anhangsmetadaten, +Live-Event-Queue-Verhalten, Routing ausgehender Sendungen sowie Channel- und +Berechtigungsbenachrichtigungen im Claude-Stil über die echte stdio-MCP-Bridge. Die Benachrichtigungsprüfung inspiziert die rohen stdio-MCP-Frames direkt, sodass der Smoke-Test validiert, was die -Bridge tatsächlich ausgibt, nicht nur das, was ein bestimmtes Client-SDK zufällig verfügbar macht. +Bridge tatsächlich ausgibt, nicht nur das, was ein bestimmtes Client-SDK zufällig bereitstellt. `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 -innerhalb des Containers, materialisiert diesen Server über die eingebettete Pi-Bundle- +im Container, materialisiert diesen Server über die eingebettete Pi-Bundle- MCP-Runtime, führt das Tool aus und verifiziert dann, dass `coding` und `messaging` -`bundle-mcp`-Tools beibehalten, während `minimal` und `tools.deny: ["bundle-mcp"]` sie filtern. -`test:docker:cron-mcp-cleanup` ist deterministisch und benötigt keinen Live-Modell- -schlüssel. Es startet einen vorbereiteten Gateway mit einem echten stdio-MCP-Probe-Server, führt einen -isolierten Cron-Turn und einen `/subagents spawn`-One-Shot-Kind-Turn aus und verifiziert dann, -dass der MCP-Kindprozess nach jedem Lauf beendet wird. +`bundle-mcp`-Tools behalten, während `minimal` und `tools.deny: ["bundle-mcp"]` sie filtern. +`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`-Einmal-Child-Turn aus und verifiziert dann, +dass der MCP-Child-Prozess nach jedem Lauf beendet wird. -Manueller ACP-Smoke-Test für Threads in natürlicher Sprache (nicht CI): +Manueller ACP-Smoke-Test für Klartext-Threads (nicht CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Behalten Sie dieses Skript für Regressions-/Debug-Workflows. Es kann erneut für die Validierung des ACP-Thread-Routings benötigt werden, löschen Sie es daher nicht. +- Behalten Sie dieses Skript für Regressions-/Debug-Workflows bei. Es kann erneut für die Validierung des ACP-Thread-Routings 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 eingelesen -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, um nur Umgebungsvariablen zu prüfen, die aus `OPENCLAW_PROFILE_FILE` eingelesen wurden, mit temporären Konfigurations-/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 zwischengespeicherte CLI-Installationen in Docker gemountet +- `OPENCLAW_PROFILE_FILE=...` (Standard: `~/.profile`) wird nach `/home/node/.profile` gemountet und vor dem Ausführen von Tests eingelesen +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, um nur aus `OPENCLAW_PROFILE_FILE` eingelesene Umgebungsvariablen zu verifizieren, mit temporären Konfigurations-/Arbeitsverzeichnis-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` - - Eingeschränkte Provider-Läufe mounten nur die benötigten Verzeichnisse/Dateien, die aus `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` abgeleitet werden - - Manuell überschreiben mit `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` oder einer durch Kommas getrennten Liste wie `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Eingegrenzte Provider-Läufe mounten nur die benötigten Verzeichnisse/Dateien, die aus `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` abgeleitet werden + - Manuell überschreiben 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 Image `openclaw:local-live` für erneute Läufe wiederzuverwenden, die keinen Neubau benötigen -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um sicherzustellen, dass Anmeldedaten aus dem Profilspeicher stammen (nicht aus der Umgebung) -- `OPENCLAW_OPENWEBUI_MODEL=...`, um das vom Gateway für den Open-WebUI-Smoke bereitgestellte Modell auszuwählen -- `OPENCLAW_OPENWEBUI_PROMPT=...`, um den vom Open-WebUI-Smoke verwendeten Nonce-Prüf-Prompt zu überschreiben -- `OPENWEBUI_IMAGE=...`, um den angepinnten Open-WebUI-Image-Tag zu überschreiben +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, um ein vorhandenes `openclaw:local-live`-Image für erneute Läufe wiederzuverwenden, die keinen Neubau benötigen +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um sicherzustellen, dass Zugangsdaten aus dem Profilspeicher kommen (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 das gepinnte Open-WebUI-Image-Tag zu überschreiben -## Docs-Plausibilitätsprüfung +## Docs-Sanity -Führen Sie nach Dokumentationsänderungen Dokumentationsprüfungen aus: `pnpm check:docs`. -Führen Sie die vollständige Mintlify-Anker-Validierung aus, wenn Sie auch Prüfungen von Überschriften innerhalb der Seite benötigen: `pnpm docs:check-links:anchors`. +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 Überschriftenprüfungen innerhalb von Seiten benötigen: `pnpm docs:check-links:anchors`. ## Offline-Regression (CI-sicher) Dies sind Regressionen der „echten Pipeline“ ohne echte Provider: -- Gateway-Tool-Aufruf (Mock-OpenAI, echter Gateway + Agentenschleife): `src/gateway/gateway.test.ts` (Fall: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Gateway-Toolaufrufe (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 Konfiguration + 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-Aufruf über den echten Gateway + Agentenschleife (`src/gateway/gateway.test.ts`). -- End-to-End-Assistentenflüsse, die Sitzungsverdrahtung und Konfigurationseffekte validieren (`src/gateway/gateway.test.ts`). +- Mock-Toolaufrufe über das echte Gateway + Agent-Loop (`src/gateway/gateway.test.ts`). +- End-to-End-Assistentenflüsse, die Session-Verkabelung und Konfigurationseffekte validieren (`src/gateway/gateway.test.ts`). Was für Skills noch fehlt (siehe [Skills](/de/tools/skills)): -- **Entscheidungsfindung:** Wenn Skills im Prompt aufgeführt sind, wählt der Agent die richtige Skill (oder vermeidet irrelevante)? -- **Compliance:** Liest der Agent `SKILL.md` vor der Nutzung und befolgt die erforderlichen Schritte/Argumente? -- **Workflow-Verträge:** Mehrstufige Szenarien, die Tool-Reihenfolge, Übernahme des Sitzungsverlaufs und Sandbox-Grenzen prüfen. +- **Entscheidungsfindung:** Wenn Skills im Prompt aufgeführt sind, wählt der Agent den richtigen Skill aus (oder vermeidet irrelevante)? +- **Compliance:** Liest der Agent `SKILL.md` vor der Verwendung und befolgt die erforderlichen Schritte/Argumente? +- **Workflow-Verträge:** Mehrstufige Szenarien, die Tool-Reihenfolge, Übernahme des Session-Verlaufs 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 Sitzungsverdrahtung zu prüfen. -- Eine kleine Suite von Skill-fokussierten Szenarien (verwenden vs. vermeiden, Gating, Prompt-Injection). -- Optionale Live-Evals (Opt-in, über Umgebungsvariablen gesteuert) erst, nachdem die CI-sichere Suite vorhanden ist. +- Ein Szenario-Runner mit Mock-Providern, um Toolaufrufe + Reihenfolge, Skill-Dateilesezugriffe und Session-Verkabelung zu prüfen. +- Eine kleine Suite Skill-fokussierter Szenarien (verwenden vs. vermeiden, Gating, Prompt-Injection). +- Optionale Live-Evals (Opt-in, per Umgebung gesteuert) erst, nachdem die CI-sichere Suite vorhanden ist. -## Vertragstests (Plugin- und Kanalform) +## Vertragstests (Plugin- und Channel-Form) -Vertragstests prüfen, ob jedes registrierte Plugin und jeder Kanal seinem -Schnittstellenvertrag entspricht. Sie iterieren über alle entdeckten Plugins und führen eine Suite von -Form- und Verhaltensassertionen aus. Die standardmäßige `pnpm test`-Unit-Lane überspringt diese gemeinsamen Seam- und Smoke-Dateien absichtlich; führen Sie die Vertragsbefehle ausdrücklich aus, -wenn Sie gemeinsame Kanal- oder Provider-Oberflächen berühren. +Vertragstests verifizieren, dass jedes registrierte Plugin und jeder registrierte Channel seinem +Schnittstellenvertrag entspricht. Sie iterieren über alle erkannten Plugins und führen eine Suite aus +Form- und Verhaltensprüfungen 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 Channel- oder Provider-Surfaces ändern. ### Befehle - Alle Verträge: `pnpm test:contracts` -- Nur Kanalverträge: `pnpm test:contracts:channels` +- Nur Channel-Verträge: `pnpm test:contracts:channels` - Nur Provider-Verträge: `pnpm test:contracts:plugins` -### Kanalverträge +### Channel-Verträge Befinden sich in `src/channels/plugins/contracts/*.contract.test.ts`: - **plugin** - Grundlegende Plugin-Form (ID, Name, Fähigkeiten) -- **setup** - Vertrag für den Einrichtungsassistenten -- **session-binding** - Verhalten der Sitzungsbindung -- **outbound-payload** - Struktur der Nachrichten-Payload +- **setup** - Setup-Assistentenvertrag +- **session-binding** - Session-Binding-Verhalten +- **outbound-payload** - Struktur der Nachrichten-Nutzlast - **inbound** - Verarbeitung eingehender Nachrichten -- **actions** - Kanal-Aktionshandler +- **actions** - Channel-Action-Handler - **threading** - Thread-ID-Verarbeitung - **directory** - Verzeichnis-/Roster-API - **group-policy** - Durchsetzung von Gruppenrichtlinien @@ -777,42 +743,42 @@ Befinden sich in `src/channels/plugins/contracts/*.contract.test.ts`: Befinden sich in `src/plugins/contracts/*.contract.test.ts`. -- **status** - Kanalstatus-Prüfungen +- **status** - Channel-Status-Probes - **registry** - Form der Plugin-Registry ### Provider-Verträge Befinden sich in `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Authentifizierungsfluss-Vertrag -- **auth-choice** - Authentifizierungsauswahl +- **auth** - Auth-Flow-Vertrag +- **auth-choice** - Auth-Auswahl/Selektion - **catalog** - Modellkatalog-API - **discovery** - Plugin-Erkennung - **loader** - Plugin-Laden -- **runtime** - Provider-Laufzeit -- **shape** - Plugin-Form/-Schnittstelle -- **wizard** - Einrichtungsassistent +- **runtime** - Provider-Runtime +- **shape** - Plugin-Form/Schnittstelle +- **wizard** - Setup-Assistent ### Wann ausführen -- Nach dem Ändern von plugin-sdk-Exporten oder Subpfaden -- Nach dem Hinzufügen oder Ändern eines Kanal- oder Provider-Plugins -- Nach dem Refactoring der Plugin-Registrierung oder -Erkennung +- Nach Änderungen an plugin-sdk-Exports oder Unterpfaden +- Nach dem Hinzufügen oder Ändern eines Channel- oder Provider-Plugins +- Nach Refactorings an Plugin-Registrierung oder -Erkennung -Vertragstests laufen in CI und erfordern keine echten API-Schlüssel. +Vertragstests laufen in CI und benötigen keine echten API-Schlüssel. -## Regressionen hinzufügen (Anleitung) +## 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 erfassen Sie die exakte Transformation der Anfrageform) -- Wenn es inhärent nur live testbar ist (Rate Limits, Auth-Richtlinien), halten Sie den Live-Test eng begrenzt und per Umgebungsvariablen als Opt-in -- Zielen Sie bevorzugt auf die kleinste Schicht, die den Fehler abfängt: - - Fehler bei Provider-Anfragekonvertierung/-Replay → direkter Modelltest - - Fehler in Gateway-Sitzung/-Verlauf/-Tool-Pipeline → Gateway-Live-Smoke oder CI-sicherer Gateway-Mock-Test +- Fügen Sie nach Möglichkeit eine CI-sichere Regression hinzu (Mock-/Stub-Provider oder erfassen Sie die exakte Request-Shape-Transformation) +- Wenn es grundsätzlich nur live prüfbar ist (Ratenlimits, Auth-Richtlinien), halten Sie den Live-Test eng begrenzt und per Umgebungsvariablen opt-in +- Zielen Sie bevorzugt auf die kleinste Schicht, die den Fehler erkennt: + - Fehler bei Provider-Request-Konvertierung/-Replay → direkter Modelltest + - Gateway-Session-/History-/Tool-Pipeline-Fehler → Gateway-Live-Smoke-Test oder CI-sicherer Gateway-Mock-Test - SecretRef-Traversal-Leitplanke: - - `src/secrets/exec-secret-ref-id-parity.test.ts` leitet ein gesampeltes Ziel pro SecretRef-Klasse aus Registry-Metadaten (`listSecretTargetRegistryEntries()`) ab und assertiert dann, dass Exec-IDs mit Traversal-Segmenten abgelehnt werden. - - Wenn Sie eine neue `includeInPlan`-SecretRef-Zielfamilie in `src/secrets/target-registry-data.ts` hinzufügen, aktualisieren Sie `classifyTargetClass` in diesem Test. Der Test schlägt absichtlich bei nicht klassifizierten Ziel-IDs fehl, damit neue Klassen nicht stillschweigend übersprungen werden können. + - `src/secrets/exec-secret-ref-id-parity.test.ts` leitet je SecretRef-Klasse ein Stichprobenziel aus Registry-Metadaten (`listSecretTargetRegistryEntries()`) ab und prüft dann, dass Exec-IDs mit Traversal-Segmenten abgelehnt werden. + - Wenn Sie eine neue `includeInPlan`-SecretRef-Ziel-Familie in `src/secrets/target-registry-data.ts` hinzufügen, aktualisieren Sie `classifyTargetClass` in diesem Test. Der Test schlägt absichtlich bei nicht klassifizierten Ziel-IDs fehl, damit neue Klassen nicht stillschweigend übersprungen werden können. ## Verwandt diff --git a/docs/de/reference/test.md b/docs/de/reference/test.md index e8c2cf01c..c4e3f4fa6 100644 --- a/docs/de/reference/test.md +++ b/docs/de/reference/test.md @@ -1,58 +1,59 @@ --- read_when: - - Tests ausführen oder reparieren -summary: Wie Sie Tests lokal ausführen (vitest) und wann Sie Force-/Coverage-Modi verwenden + - Tests ausführen oder korrigieren +summary: So führen Sie Tests lokal aus (vitest) und wann Sie Erzwingungs- oder Testabdeckungsmodi verwenden title: Tests x-i18n: - generated_at: "2026-04-30T07:14:13Z" + generated_at: "2026-04-30T18:38:31Z" model: gpt-5.5 provider: openai - source_hash: 9328d6f0383b5067fa8bb5d0f1bf22a3b9048a267908bf85167842ddc3d12e42 + source_hash: 131f2bad3b2806d28394213cec38d632d106ddbf8ff04d06345ab8046fb8bcf2 source_path: reference/test.md workflow: 16 --- -- Vollständiges Test-Kit (Testsammlungen, Live-Tests, Docker): [Tests](/de/help/testing) +- Vollständiges Testkit (Suites, Live, Docker): [Testen](/de/help/testing) -- `pnpm test:force`: Beendet jeden verbleibenden Gateway-Prozess, der den standardmäßigen Control-Port hält, und führt dann die vollständige Vitest-Suite mit einem isolierten Gateway-Port aus, damit Server-Tests nicht mit einer laufenden Instanz kollidieren. Verwenden Sie dies, wenn ein vorheriger Gateway-Lauf Port 18789 belegt gelassen hat. -- `pnpm test:coverage`: Führt die Unit-Suite mit V8-Coverage aus (über `vitest.unit.config.ts`). Dies ist ein Coverage-Gate für geladene Unit-Dateien, keine All-File-Coverage für das gesamte Repository. Die Schwellenwerte sind 70 % für Zeilen/Funktionen/Anweisungen und 55 % für Branches. Da `coverage.all` false ist, misst das Gate Dateien, die von der Unit-Coverage-Suite geladen werden, statt jede Split-Lane-Quelldatei als nicht abgedeckt zu behandeln. -- `pnpm test:coverage:changed`: Führt Unit-Coverage nur für Dateien aus, die sich seit `origin/main` geändert haben. -- `pnpm test:changed`: günstiger intelligenter Changed-Testlauf. Er führt präzise Ziele aus direkten Teständerungen, benachbarten `*.test.ts`-Dateien, expliziten Quellzuordnungen und dem lokalen Importgraphen aus. Breite/config/package-Änderungen werden übersprungen, sofern sie nicht auf präzise Tests abbilden. -- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: expliziter breiter Changed-Testlauf. Verwenden Sie dies, wenn eine Änderung an Test-Harness/config/package auf das breitere Changed-Test-Verhalten von Vitest zurückfallen soll. -- `pnpm changed:lanes`: zeigt die architektonischen Lanes, die durch den Diff gegen `origin/main` ausgelöst werden. -- `pnpm check:changed`: führt das intelligente Changed-Check-Gate für den Diff gegen `origin/main` aus. Es führt Typecheck-, Lint- und Guard-Befehle für die betroffenen architektonischen Lanes aus, aber keine Vitest-Tests. Verwenden Sie `pnpm test:changed` oder explizit `pnpm test ` als Testnachweis. -- `pnpm test`: leitet explizite Datei-/Verzeichnisziele durch scoped Vitest-Lanes. Läufe ohne Ziel verwenden feste Shard-Gruppen und werden für lokale parallele Ausführung auf Leaf-Configs erweitert; die Plugin-Gruppe wird immer auf die Shard-Configs pro Plugin erweitert statt auf einen riesigen Root-Project-Prozess. +- `pnpm test:force`: Beendet jeden verbleibenden Gateway-Prozess, der den standardmäßigen Control-Port belegt, und führt dann die vollständige Vitest-Suite mit einem isolierten Gateway-Port aus, damit Server-Tests nicht mit einer laufenden Instanz kollidieren. Verwenden Sie dies, wenn ein vorheriger Gateway-Lauf Port 18789 belegt gelassen hat. +- `pnpm test:coverage`: Führt die Unit-Suite mit V8-Coverage aus (über `vitest.unit.config.ts`). Dies ist ein Unit-Coverage-Gate für geladene Dateien, keine Whole-Repo-All-File-Coverage. Die Schwellenwerte liegen bei 70 % für Zeilen/Funktionen/Statements und 55 % für Branches. Da `coverage.all` false ist, misst das Gate Dateien, die von der Unit-Coverage-Suite geladen werden, anstatt jede Split-Lane-Quelldatei als nicht abgedeckt zu behandeln. +- `pnpm test:coverage:changed`: Führt Unit-Coverage nur für Dateien aus, die seit `origin/main` geändert wurden. +- `pnpm test:changed`: günstiger intelligenter Changed-Test-Lauf. Er führt präzise Ziele aus direkten Teständerungen, benachbarten `*.test.ts`-Dateien, expliziten Quellzuordnungen und dem lokalen Importgraphen aus. Breite/config/package-Änderungen werden übersprungen, sofern sie nicht auf präzise Tests abbilden. +- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: expliziter breiter Changed-Test-Lauf. Verwenden Sie dies, wenn eine Änderung an Test-Harness/config/package auf das breitere Changed-Test-Verhalten von Vitest zurückfallen soll. +- `pnpm changed:lanes`: zeigt die durch den Diff gegen `origin/main` ausgelösten Architektur-Lanes. +- `pnpm check:changed`: führt das intelligente Changed-Check-Gate für den Diff gegen `origin/main` aus. Es führt Typecheck-, Lint- und Guard-Befehle für die betroffenen Architektur-Lanes aus, führt aber keine Vitest-Tests aus. Verwenden Sie `pnpm test:changed` oder explizit `pnpm test ` als Testnachweis. +- `pnpm test`: routet explizite Datei-/Verzeichnisziele durch scoped Vitest-Lanes. Nicht zielgerichtete Läufe verwenden feste Shard-Gruppen und erweitern auf Leaf-Configs für lokale parallele Ausführung; die Extension-Gruppe wird immer zu den pro Extension definierten Shard-Configs erweitert, statt zu einem einzigen riesigen Root-Project-Prozess. - Test-Wrapper-Läufe enden mit einer kurzen Zusammenfassung `[test] passed|failed|skipped ... in ...`. Die eigene Dauerzeile von Vitest bleibt das Detail pro Shard. -- Gemeinsamer OpenClaw-Testzustand: Verwenden Sie `src/test-utils/openclaw-test-state.ts` aus Vitest, wenn ein Test ein isoliertes `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, ein Config-Fixture, einen Workspace, ein Agent-Verzeichnis oder einen Auth-Profile-Store benötigt. -- Process-E2E-Helfer: Verwenden Sie `test/helpers/openclaw-test-instance.ts`, wenn ein Vitest-Prozess-Level-E2E-Test einen laufenden Gateway, CLI-Env, Log-Erfassung und Cleanup an einer Stelle benötigt. -- Docker/Bash-E2E-Helfer: Lanes, die `scripts/lib/docker-e2e-image.sh` sourcen, können `docker_e2e_test_state_shell_b64