From b7607ef1ccf40dba1e4ea4e6545b6de6e0abf5ac Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Thu, 30 Apr 2026 09:37:23 +0000 Subject: [PATCH] chore(i18n): refresh de translations --- docs/de/channels/qqbot.md | 145 +++++++------- docs/de/ci.md | 330 ++++++++++++++++---------------- docs/de/cli/cron.md | 112 +++++------ docs/de/gateway/local-models.md | 164 ++++++++-------- docs/de/plugins/community.md | 146 +++++++------- docs/de/tools/skills.md | 290 ++++++++++++++++------------ 6 files changed, 619 insertions(+), 568 deletions(-) diff --git a/docs/de/channels/qqbot.md b/docs/de/channels/qqbot.md index f3e94b220..c74c75ac7 100644 --- a/docs/de/channels/qqbot.md +++ b/docs/de/channels/qqbot.md @@ -1,36 +1,40 @@ --- read_when: - Sie möchten OpenClaw mit QQ verbinden - - Sie müssen die Zugangsdaten für QQ Bot einrichten - - Sie möchten QQ Bot-Unterstützung für Gruppen- oder private Chats -summary: 'QQ Bot: Einrichtung, Konfiguration und Verwendung' + - Sie müssen Zugangsdaten für QQ Bot einrichten + - Sie möchten Unterstützung für QQ Bot-Gruppenchats oder private Chats +summary: Einrichtung, Konfiguration und Nutzung des QQ-Bots title: QQ-Bot x-i18n: - generated_at: "2026-04-30T06:41:45Z" + generated_at: "2026-04-30T09:34:53Z" model: gpt-5.5 provider: openai - source_hash: aefece6b05bb16d5c4f588bf7af4fd710b5f98aab0dbed8221490c46bf3f379c + source_hash: 964a92021acc534b7ec2749670fedd0e8caa47d5edf67ced80f0a8fb3eda7600 source_path: channels/qqbot.md workflow: 16 --- -QQ Bot verbindet sich über die offizielle QQ Bot API (WebSocket-Gateway) mit OpenClaw. Das Plugin unterstützt private C2C-Chats, @Nachrichten in Gruppen und Nachrichten in Gildenkanälen mit Rich Media (Bilder, Sprache, Video, Dateien). +QQ Bot verbindet sich über die offizielle QQ Bot API (WebSocket-Gateway) mit OpenClaw. Das +Plugin unterstützt C2C-Privatchats, Gruppen-@Nachrichten und Guild-Channel-Nachrichten mit +Rich Media (Bilder, Sprache, Video, Dateien). -Status: gebündeltes Plugin. Direktnachrichten, Gruppenchats, Gildenkanäle und Medien werden unterstützt. Reaktionen und Threads werden nicht unterstützt. +Status: gebündeltes Plugin. Direktnachrichten, Gruppenchats, Guild-Channels und +Medien werden unterstützt. Reaktionen und Threads werden nicht unterstützt. ## Gebündeltes Plugin -Aktuelle OpenClaw-Versionen bündeln QQ Bot, daher benötigen normale paketierte Builds keinen separaten Schritt `openclaw plugins install`. +Aktuelle OpenClaw-Versionen bündeln QQ Bot, daher benötigen normale paketierte Builds keinen +separaten Schritt `openclaw plugins install`. ## Einrichtung 1. Gehen Sie zur [QQ Open Platform](https://q.qq.com/) und scannen Sie den QR-Code mit Ihrem - QQ auf dem Telefon, um sich zu registrieren / anzumelden. + Telefon-QQ, um sich zu registrieren / anzumelden. 2. Klicken Sie auf **Create Bot**, um einen neuen QQ-Bot zu erstellen. 3. Suchen Sie **AppID** und **AppSecret** auf der Einstellungsseite des Bots und kopieren Sie sie. -> AppSecret wird nicht im Klartext gespeichert — wenn Sie die Seite verlassen, ohne ihn zu speichern, -> müssen Sie einen neuen generieren. +> AppSecret wird nicht im Klartext gespeichert — wenn Sie die Seite verlassen, ohne es zu speichern, +> müssen Sie ein neues generieren. 4. Fügen Sie den Kanal hinzu: @@ -63,12 +67,12 @@ Minimale Konfiguration: } ``` -Env-Vars für das Standardkonto: +Env-Variablen für das Standardkonto: - `QQBOT_APP_ID` - `QQBOT_CLIENT_SECRET` -Dateibasierter AppSecret: +Dateibasierte AppSecret: ```json5 { @@ -84,12 +88,12 @@ Dateibasierter AppSecret: Hinweise: -- Env-Fallback gilt nur für das Standardkonto von QQ Bot. -- `openclaw channels add --channel qqbot --token-file ...` stellt nur den +- Der Env-Fallback gilt nur für das Standardkonto von QQ Bot. +- `openclaw channels add --channel qqbot --token-file ...` stellt nur das AppSecret bereit; die AppID muss bereits in der Konfiguration oder in `QQBOT_APP_ID` gesetzt sein. -- `clientSecret` akzeptiert auch SecretRef-Eingaben, nicht nur eine Klartext-Zeichenfolge. +- `clientSecret` akzeptiert auch SecretRef-Eingaben, nicht nur eine Klartextzeichenfolge. -### Einrichtung mit mehreren Konten +### Einrichtung mehrerer Konten Führen Sie mehrere QQ-Bots unter einer einzelnen OpenClaw-Instanz aus: @@ -115,7 +119,7 @@ Führen Sie mehrere QQ-Bots unter einer einzelnen OpenClaw-Instanz aus: Jedes Konto startet seine eigene WebSocket-Verbindung und verwaltet einen unabhängigen Token-Cache (isoliert nach `appId`). -Fügen Sie einen zweiten Bot über die CLI hinzu: +Fügen Sie per CLI einen zweiten Bot hinzu: ```bash openclaw channels add --channel qqbot --account bot2 --token "222222222:secret-of-bot-2" @@ -152,27 +156,27 @@ zu einer Gruppe hinzu und erwähnen Sie ihn dann oder konfigurieren Sie die Grup ``` `groups["*"]` legt Standardwerte für jede Gruppe fest, und ein konkreter -Eintrag `groups.GROUP_OPENID` überschreibt diese Standardwerte für eine Gruppe. Gruppen- -einstellungen umfassen: +Eintrag `groups.GROUP_OPENID` überschreibt diese Standardwerte für eine Gruppe. Gruppeneinstellungen +umfassen: -- `requireMention`: erfordert eine @mention, bevor der Bot antwortet. Standard: `true`. -- `ignoreOtherMentions`: verwirft Nachrichten, die eine andere Person, aber nicht den Bot erwähnen. -- `historyLimit`: bewahrt aktuelle Gruppenmeldungen ohne Erwähnung als Kontext für die nächste erwähnte Runde auf. Setzen Sie `0`, um dies zu deaktivieren. -- `toolPolicy`: `full`, `restricted` oder `none` für gruppenbezogene Tools. -- `name`: lesbares Label, das in Logs und im Gruppenkontext verwendet wird. -- `prompt`: verhaltensbezogener Prompt pro Gruppe, der an den Agentenkontext angehängt wird. +- `requireMention`: erfordert eine @Erwähnung, bevor der Bot antwortet. Standard: `true`. +- `ignoreOtherMentions`: verwirft Nachrichten, die jemand anderen erwähnen, aber nicht den Bot. +- `historyLimit`: behält aktuelle Gruppen-Nachrichten ohne Erwähnung als Kontext für die nächste erwähnte Runde bei. Setzen Sie `0`, um dies zu deaktivieren. +- `toolPolicy`: `full`, `restricted` oder `none` für gruppenspezifische Tools. +- `name`: benutzerfreundliche Bezeichnung, die in Logs und im Gruppenkontext verwendet wird. +- `prompt`: gruppenspezifischer Verhaltens-Prompt, der an den Agent-Kontext angehängt wird. Aktivierungsmodi sind `mention` und `always`. `requireMention: true` wird auf -`mention` abgebildet; `requireMention: false` wird auf `always` abgebildet. Eine Aktivierungs- -überschreibung auf Sitzungsebene hat, falls vorhanden, Vorrang vor der Konfiguration. +`mention` abgebildet; `requireMention: false` wird auf `always` abgebildet. Eine Aktivierungsüberschreibung auf Sitzungsebene +hat Vorrang vor der Konfiguration, wenn sie vorhanden ist. -Die eingehende Warteschlange ist pro Gegenstelle. Gruppengegenstellen erhalten ein größeres Warteschlangenlimit, behalten menschliche -Nachrichten vor botverfasstem Austausch, wenn sie voll sind, und führen Bursts normaler +Die eingehende Warteschlange ist pro Peer. Gruppen-Peers erhalten eine größere Warteschlangenkapazität, behalten menschliche +Nachrichten vor Bot-verfasstem Rauschen, wenn die Warteschlange voll ist, und fassen Bursts normaler Gruppennachrichten zu einer zugeschriebenen Runde zusammen. Slash-Befehle werden weiterhin einzeln ausgeführt. ### Sprache (STT / TTS) -STT- und TTS-Unterstützung nutzt eine zweistufige Konfiguration mit priorisiertem Fallback: +STT und TTS unterstützen eine zweistufige Konfiguration mit priorisiertem Fallback: | Einstellung | Plugin-spezifisch | Framework-Fallback | | ----------- | ------------------------------------------------------- | ----------------------------- | @@ -206,16 +210,16 @@ STT- und TTS-Unterstützung nutzt eine zweistufige Konfiguration mit priorisiert } ``` -Setzen Sie `enabled: false` bei einem der beiden, um ihn zu deaktivieren. -TTS-Überschreibungen auf Kontoebene verwenden dieselbe Struktur wie `messages.tts` und werden tief -über die kanalweite/globale TTS-Konfiguration zusammengeführt. +Setzen Sie bei einem der beiden `enabled: false`, um es zu deaktivieren. +TTS-Überschreibungen auf Kontoebene verwenden dieselbe Form wie `messages.tts` und werden per Deep Merge +über die Kanal-/globale TTS-Konfiguration gelegt. Eingehende QQ-Sprachanhänge werden Agents als Audiomedien-Metadaten bereitgestellt, während -unbearbeitete Sprachdateien aus generischen `MediaPaths` herausgehalten werden. `[[audio_as_voice]]`-Klartext- -antworten synthetisieren TTS und senden eine native QQ-Sprachnachricht, wenn TTS +Roh-Sprachdateien aus den generischen `MediaPaths` herausgehalten werden. Klartextantworten mit `[[audio_as_voice]]` +synthetisieren TTS und senden eine native QQ-Sprachnachricht, wenn TTS konfiguriert ist. -Das Verhalten für ausgehende Audio-Uploads/Transkodierung kann auch mit +Das Verhalten für ausgehende Audio-Uploads/-Transcodierung kann außerdem mit `channels.qqbot.audioFormatPolicy` angepasst werden: - `sttDirectFormats` @@ -224,11 +228,11 @@ Das Verhalten für ausgehende Audio-Uploads/Transkodierung kann auch mit ## Zielformate -| Format | Beschreibung | -| -------------------------- | ------------------ | -| `qqbot:c2c:OPENID` | Privater Chat (C2C) | -| `qqbot:group:GROUP_OPENID` | Gruppenchat | -| `qqbot:channel:CHANNEL_ID` | Gildenkanal | +| Format | Beschreibung | +| -------------------------- | ----------------- | +| `qqbot:c2c:OPENID` | Privatchat (C2C) | +| `qqbot:group:GROUP_OPENID` | Gruppenchat | +| `qqbot:channel:CHANNEL_ID` | Guild-Channel | > Jeder Bot hat seinen eigenen Satz von Benutzer-OpenIDs. Eine von Bot A empfangene OpenID **kann nicht** > verwendet werden, um Nachrichten über Bot B zu senden. @@ -237,54 +241,57 @@ Das Verhalten für ausgehende Audio-Uploads/Transkodierung kann auch mit Integrierte Befehle, die vor der KI-Warteschlange abgefangen werden: -| Befehl | Beschreibung | -| -------------- | ----------------------------------------------------------------------------------------------------------------- | -| `/bot-ping` | Latenztest | -| `/bot-version` | OpenClaw-Framework-Version anzeigen | -| `/bot-help` | Alle Befehle auflisten | -| `/bot-upgrade` | Link zum QQBot-Upgrade-Leitfaden anzeigen | -| `/bot-logs` | Aktuelle Gateway-Logs als Datei exportieren | -| `/bot-approve` | Eine ausstehende QQ Bot-Aktion über den nativen Ablauf genehmigen (zum Beispiel Bestätigung eines C2C- oder Gruppen-Uploads). | +| Befehl | Beschreibung | +| -------------- | ------------------------------------------------------------------------------------------------------------------------ | +| `/bot-ping` | Latenztest | +| `/bot-version` | Zeigt die Version des OpenClaw-Frameworks an | +| `/bot-help` | Listet alle Befehle auf | +| `/bot-me` | Zeigt die QQ-Benutzer-ID (openid) des Absenders für die Einrichtung von `allowFrom`/`groupAllowFrom` an | +| `/bot-upgrade` | Zeigt den Link zum QQBot-Upgrade-Leitfaden an | +| `/bot-logs` | Exportiert aktuelle Gateway-Logs als Datei | +| `/bot-approve` | Genehmigt eine ausstehende QQ Bot-Aktion (zum Beispiel das Bestätigen eines C2C- oder Gruppen-Uploads) über den nativen Ablauf. | Hängen Sie `?` an einen beliebigen Befehl an, um Nutzungshilfe zu erhalten (zum Beispiel `/bot-upgrade ?`). +Admin-Befehle (`/bot-me`, `/bot-upgrade`, `/bot-logs`, `/bot-clear-storage`, `/bot-streaming`, `/bot-approve`) sind nur für Direktnachrichten vorgesehen und erfordern die openid des Absenders in einer expliziten `allowFrom`-Liste ohne Wildcard. Eine Wildcard `allowFrom: ["*"]` erlaubt Chat, gewährt aber keinen Zugriff auf Admin-Befehle. Gruppennachrichten werden zuerst mit `groupAllowFrom` abgeglichen und fallen dann auf `allowFrom` zurück. Das Ausführen eines Admin-Befehls in einer Gruppe gibt einen Hinweis zurück, statt ihn stillschweigend zu verwerfen. + ## Engine-Architektur QQ Bot wird als eigenständige Engine innerhalb des Plugins ausgeliefert: -- Jedes Konto besitzt einen isolierten Ressourcen-Stack (WebSocket-Verbindung, API-Client, Token-Cache, Medien-Speicherwurzel), der nach `appId` indiziert ist. Konten teilen niemals eingehenden/ausgehenden Zustand. -- Der Multi-Konto-Logger markiert Log-Zeilen mit dem zugehörigen Konto, damit Diagnosen trennbar bleiben, wenn Sie mehrere Bots unter einem Gateway ausführen. -- Eingehende, ausgehende und Gateway-Bridge-Pfade teilen sich eine einzelne Medien-Payload-Wurzel unter `~/.openclaw/media`, sodass Uploads, Downloads und Transkodierungs-Caches in einem geschützten Verzeichnis statt in einem Baum pro Subsystem landen. -- Die Zustellung von Rich Media läuft über einen einzelnen `sendMedia`-Pfad für C2C- und Gruppenziele. Lokale Dateien und Buffer oberhalb des Schwellenwerts für große Dateien verwenden QQs Endpunkte für gestückelte Uploads, während kleinere Payloads die One-Shot-Medien-API verwenden. -- Zugangsdaten können als Teil standardmäßiger OpenClaw-Zugangsdaten-Snapshots gesichert und wiederhergestellt werden; die Engine hängt den Ressourcen-Stack jedes Kontos bei der Wiederherstellung wieder ein, ohne ein neues QR-Code-Paar zu benötigen. +- Jedes Konto besitzt einen isolierten Ressourcen-Stack (WebSocket-Verbindung, API-Client, Token-Cache, Medien-Speicherwurzel), der nach `appId` verschlüsselt ist. Konten teilen niemals eingehenden/ausgehenden Zustand. +- Der Logger für mehrere Konten versieht Log-Zeilen mit dem zugehörigen Konto, damit Diagnosen getrennt bleiben, wenn Sie mehrere Bots unter einem Gateway ausführen. +- Eingehende, ausgehende und Gateway-Bridge-Pfade teilen sich eine einzelne Medien-Payload-Wurzel unter `~/.openclaw/media`, sodass Uploads, Downloads und Transcode-Caches in einem geschützten Verzeichnis statt in einem Baum pro Subsystem landen. +- Rich-Media-Zustellung läuft über einen einzelnen `sendMedia`-Pfad für C2C- und Gruppenziele. Lokale Dateien und Puffer oberhalb des Schwellenwerts für große Dateien verwenden die Chunked-Upload-Endpunkte von QQ, während kleinere Payloads die One-Shot-Medien-API verwenden. +- Anmeldeinformationen können als Teil standardmäßiger OpenClaw-Anmeldeinformations-Snapshots gesichert und wiederhergestellt werden; die Engine hängt den Ressourcen-Stack jedes Kontos bei der Wiederherstellung erneut an, ohne ein frisches QR-Code-Pairing zu erfordern. ## QR-Code-Onboarding -Als Alternative zum manuellen Einfügen von `AppID:AppSecret` unterstützt die Engine einen QR-Code-Onboarding-Ablauf, um einen QQ Bot mit OpenClaw zu verknüpfen: +Als Alternative zum manuellen Einfügen von `AppID:AppSecret` unterstützt die Engine einen QR-Code-Onboarding-Ablauf zum Verknüpfen eines QQ Bot mit OpenClaw: -1. Führen Sie den QQ Bot-Einrichtungspfad aus (zum Beispiel `openclaw channels add --channel qqbot`) und wählen Sie bei Aufforderung den QR-Code-Ablauf aus. -2. Scannen Sie den generierten QR-Code mit der Telefon-App, die mit dem Ziel-QQ-Bot verknüpft ist. -3. Genehmigen Sie die Kopplung auf dem Telefon. OpenClaw speichert die zurückgegebenen Zugangsdaten im richtigen Kontogeltungsbereich unter `credentials/`. +1. Führen Sie den Einrichtungspfad für QQ Bot aus (zum Beispiel `openclaw channels add --channel qqbot`) und wählen Sie den QR-Code-Ablauf, wenn Sie dazu aufgefordert werden. +2. Scannen Sie den generierten QR-Code mit der Telefon-App, die mit dem Ziel-QQ Bot verknüpft ist. +3. Genehmigen Sie das Pairing auf dem Telefon. OpenClaw speichert die zurückgegebenen Anmeldeinformationen im richtigen Kontobereich unter `credentials/`. -Genehmigungsaufforderungen, die vom Bot selbst erzeugt werden (zum Beispiel Abläufe vom Typ „Diese Aktion zulassen?“, die von der QQ Bot API bereitgestellt werden), erscheinen als native OpenClaw-Aufforderungen, die Sie mit `/bot-approve` akzeptieren können, statt über den rohen QQ-Client zu antworten. +Vom Bot selbst generierte Genehmigungsaufforderungen (zum Beispiel Abläufe wie „diese Aktion erlauben?“, die von der QQ Bot API bereitgestellt werden) erscheinen als native OpenClaw-Prompts, die Sie mit `/bot-approve` akzeptieren können, statt über den rohen QQ-Client zu antworten. ## Fehlerbehebung -- **Bot antwortet „gone to Mars“:** Zugangsdaten sind nicht konfiguriert oder das Gateway wurde nicht gestartet. -- **Keine eingehenden Nachrichten:** Prüfen Sie, ob `appId` und `clientSecret` korrekt sind und der +- **Bot antwortet „gone to Mars“:** Anmeldeinformationen sind nicht konfiguriert oder das Gateway wurde nicht gestartet. +- **Keine eingehenden Nachrichten:** Verifizieren Sie, dass `appId` und `clientSecret` korrekt sind und der Bot auf der QQ Open Platform aktiviert ist. -- **Wiederholte Selbstantworten:** OpenClaw zeichnet ausgehende QQ-Referenzindizes als - botverfasst auf und ignoriert eingehende Ereignisse, deren aktueller `msgIdx` zu demselben - Bot-Konto passt. Dies verhindert Plattform-Echoschleifen und erlaubt Benutzern dennoch, +- **Wiederholte Selbstantworten:** OpenClaw zeichnet QQ-Referenzindizes für ausgehende Nachrichten als + vom Bot verfasst auf und ignoriert eingehende Ereignisse, deren aktueller `msgIdx` mit genau diesem + Bot-Konto übereinstimmt. Dies verhindert Plattform-Echo-Schleifen und erlaubt Benutzern trotzdem, frühere Bot-Nachrichten zu zitieren oder darauf zu antworten. - **Einrichtung mit `--token-file` zeigt weiterhin unkonfiguriert an:** `--token-file` setzt nur - den AppSecret. Sie benötigen weiterhin `appId` in der Konfiguration oder `QQBOT_APP_ID`. + das AppSecret. Sie benötigen weiterhin `appId` in der Konfiguration oder `QQBOT_APP_ID`. - **Proaktive Nachrichten kommen nicht an:** QQ kann vom Bot initiierte Nachrichten abfangen, wenn - der Benutzer kürzlich nicht interagiert hat. + der Benutzer in letzter Zeit nicht interagiert hat. - **Sprache wird nicht transkribiert:** Stellen Sie sicher, dass STT konfiguriert ist und der Provider erreichbar ist. -## Verwandte Themen +## Verwandt -- [Kopplung](/de/channels/pairing) +- [Pairing](/de/channels/pairing) - [Gruppen](/de/channels/groups) - [Kanal-Fehlerbehebung](/de/channels/troubleshooting) diff --git a/docs/de/ci.md b/docs/de/ci.md index cf985a3d1..b4519b26b 100644 --- a/docs/de/ci.md +++ b/docs/de/ci.md @@ -1,75 +1,75 @@ --- read_when: - Sie müssen nachvollziehen, warum ein CI-Job ausgeführt wurde oder nicht - - Sie debuggen eine fehlgeschlagene GitHub Actions-Prüfung - - Sie koordinieren einen Lauf oder eine Wiederholung der Release-Validierung -summary: CI-Job-Graph, Scope-Gates, Release-Umbrellas und lokale Befehlsäquivalente + - 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 title: CI-Pipeline x-i18n: - generated_at: "2026-04-30T06:43:34Z" + generated_at: "2026-04-30T09:34:53Z" model: gpt-5.5 provider: openai - source_hash: 256d47dacac7d5c49c8ad614fba2efdd94332d69903d8b70c653775b28bc3fd5 + source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62 source_path: ci.md workflow: 16 --- -OpenClaw-CI läuft bei jedem Push auf `main` und bei jedem Pull Request. Der Job `preflight` klassifiziert den Diff und deaktiviert teure Lanes, wenn sich nur nicht zusammenhängende Bereiche geändert haben. Manuelle `workflow_dispatch`-Läufe umgehen das intelligente 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-spezifische Plugin-Abdeckung befindet sich im separaten Workflow [`Plugin-Vorabrelease`](#plugin-prerelease) und läuft nur aus [`Vollständige Release-Validierung`](#full-release-validation) oder einem expliziten manuellen Dispatch. +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. ## Pipeline-Übersicht -| Job | Zweck | Wann er läuft | -| -------------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | -| `preflight` | Erkennt reine Docs-Änderungen, geänderte Scopes, geänderte Erweiterungen 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` | Dependency-freier 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` | Reiner Produktions-Knip-Durchlauf für Dependencies plus Guard für die Allowlist ungenutzter Dateien | Node-relevante Änderungen | -| `build-artifacts` | Erstellt `dist/`, Control UI, Prüfungen gebauter Artefakte und wiederverwendbare Downstream-Artefakte | Node-relevante Änderungen | -| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie Bundle-/Plugin-Vertrags-/Protokollprüfungen | Node-relevante Änderungen | -| `checks-fast-contracts-channels` | Gesplittete Channel-Vertragsprüfungen mit stabilem aggregiertem Prüfergebnis | Node-relevante Änderungen | -| `checks-node-core-test` | Core-Node-Test-Shards, ohne Channel-, Bundle-, Vertrags- und Erweiterungs-Lanes | Node-relevante Änderungen | -| `check` | Gesplittetes Äquivalent des lokalen Haupt-Gates: Prod-Typen, Lint, Guards, Testtypen und strenger Smoke | Node-relevante Änderungen | -| `check-additional` | Architektur-, Boundary-, Erweiterungsoberflächen-, Paket-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 Channel-Tests mit gebautem Artefakt | 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 | Für Python-Skills relevante Änderungen | -| `checks-windows` | Windows-spezifische Prozess-/Pfadtests plus Regressionen für gemeinsame Runtime-Import-Specifier | 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 Flavors plus ein Debug-APK-Build | Android-relevante Änderungen | -| `test-performance-agent` | Tägliche Codex-Optimierung langsamer Tests nach vertrauenswürdiger Aktivität | Erfolg der Main-CI oder manueller Dispatch | +| 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 | ## Fail-Fast-Reihenfolge -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. +1. `preflight` entscheidet, welche Lanes überhaupt existieren. Die Logik `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-Nutzer starten können, sobald der gemeinsame Build bereit ist. +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`. -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()`, damit sie normale Shard-Fehler weiterhin melden, aber nicht mehr in die Warteschlange gehen, nachdem der gesamte Workflow bereits überholt wurde. Der automatische CI-Concurrency-Schlüssel 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 ü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. ## Scope und Routing -Die Scope-Logik befindet sich in `scripts/ci-changed-scope.mjs` und wird 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 ob jeder gescopte Bereich geändert wurde. +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. -- **CI-Workflow-Änderungen** validieren den Node-CI-Graphen plus Workflow-Linting, erzwingen aber nicht selbst Windows-, Android- oder macOS-native Builds; diese Plattform-Lanes bleiben auf Plattform-Quelländerungen beschränkt. -- **Reine CI-Routing-Änderungen, ausgewählte günstige Core-Test-Fixture-Änderungen und schmale Plugin-Vertrags-Helper-/Test-Routing-Änderungen** verwenden einen schnellen Node-only-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, Bundled-Plugin-Shards und zusätzliche Guard-Matrizen, wenn die Änderung auf die 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, Paketmanager-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. +- **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. -Die langsamsten Node-Testfamilien werden geteilt 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 Agent-Runner-, Dispatch- und Commands-/State-Routing-Shards geteilt wird), und agentische Gateway-/Plugin-Konfigurationen werden über die bestehenden Source-only-agentischen Node-Jobs verteilt, statt auf gebaute Artefakte zu warten. Breite Browser-, QA-, Medien- und sonstige Plugin-Tests verwenden ihre 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 sind. +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. -Android-CI führt sowohl `testPlayDebugUnitTest` als auch `testThirdPartyDebugUnitTest` aus und baut danach das Play-Debug-APK. Der Third-Party-Flavor hat kein separates Source-Set oder Manifest; seine Unit-Test-Lane kompiliert den Flavor dennoch mit den SMS-/Anrufprotokoll-`BuildConfig`-Flags, während ein doppelter Debug-APK-Paketierungsjob bei jedem Android-relevanten Push vermieden wird. +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. -Der Shard `check-dependencies` führt `pnpm deadcode:dependencies` aus (einen reinen Produktions-Knip-Durchlauf für Dependencies, gepinnt auf die neueste Knip-Version, wobei pnpm's Mindest-Release-Alter für die `dlx`-Installation deaktiviert ist) sowie `pnpm deadcode:unused-files`, das Knips Produktionsbefunde zu ungenutzten 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. +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. ## Manuelle Dispatches -Manuelle CI-Dispatches führen denselben Job-Graphen wie normale CI aus, erzwingen aber jede nicht-Android-gescopte Lane: Linux-Node-Shards, Bundled-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 manuelle CI-Dispatches führen Android nur mit `include_android=true` aus; der vollständige Release-Umbrella aktiviert Android, indem er `include_android=true` übergibt. Statische Plugin-Vorabrelease-Prüfungen, der release-spezifische Shard `agentic-plugins`, der vollständige Batch-Sweep für Erweiterungen und Plugin-Vorabrelease-Docker-Lanes sind aus CI ausgeschlossen. Die Docker-Vorabrelease-Suite läuft nur, wenn `Full Release Validation` den separaten Workflow `Plugin Prerelease` mit aktiviertem Release-Validation-Gate dispatcht. +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. -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` lässt einen vertrauenswürdigen Aufrufer diesen Graphen gegen einen Branch, Tag oder vollständigen Commit-SHA ausführen, während die Workflow-Datei aus dem ausgewählten Dispatch-Ref verwendet wird. +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. ```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 Sicherheitsjobs und Aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), schnelle Protokoll-/Vertrags-/gebündelte Prüfungen, geshardete Channel-Vertragsprüfungen, `check`-Shards außer Lint, `check-additional`-Shards und -Aggregate, Node-Test-Aggregat-Verifizierer, Dokumentationsprüfungen, Python-Skills, Workflow-Sanity, Labeler, Auto-Response; Install-Smoke-Preflight nutzt ebenfalls GitHub-gehostetes Ubuntu, damit die Blacksmith-Matrix früher in die Warteschlange gestellt 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, gebündelte Plugin-Test-Shards, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (CPU-empfindlich genug, dass 8 vCPU mehr gekostet haben, als sie eingespart haben); Install-Smoke-Docker-Builds (32-vCPU-Warteschlangenzeit kostete mehr, als sie eingespart hat) | -| `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, 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 | ## 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 Umbrella-Workflow für „vor dem Release alles 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-/Paket-/statische/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 Paketspezifikation angegeben wird. +`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. `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 beratende Provider-/Medienmatrix aus. +- `full` führt die breite Advisory-Provider-/Medien-Matrix aus. -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 fügt 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 Parent-Verifiziererjob erneut aus, um das Umbrella-Ergebnis und die Timing-Zusammenfassung zu aktualisieren. +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. -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 Umbrella. Dadurch bleibt eine erneute Ausführung einer fehlgeschlagenen Release-Box nach einem fokussierten 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 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. -`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 Live/E2E-Docker-Workflow für den Release-Pfad als auch an den Package-Acceptance-Shard. Dadurch bleiben die Paket-Bytes über Release-Boxen hinweg konsistent, und derselbe Kandidat muss nicht in mehreren untergeordneten Jobs erneut gepackt werden. +`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. ## Live- und E2E-Shards -Das Release-Live/E2E-Child behält die breite native `pnpm test:live`-Abdeckung bei, führt sie aber über `scripts/test-live-shard.mjs` als benannte Shards statt als einen seriellen Job aus: +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: - `native-live-src-agents` - `native-live-src-gateway-core` @@ -145,33 +145,33 @@ Das Release-Live/E2E-Child behält die breite native `pnpm test:live`-Abdeckung - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- geteilte Medien-Audio-/Video-Shards und Provider-gefilterte Musik-Shards +- aufgeteilte Audio-/Video-Medien-Shards und Provider-gefilterte Musik-Shards -Dadurch bleibt dieselbe Dateiabdeckung erhalten, während langsame Live-Provider-Fehler einfacher 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 Ausführungen gültig. +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. -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; Medienjobs verifizieren die Binaries vor dem Setup nur noch. 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`, 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. -Docker-gestützte Live-Modell-/Backend-Shards verwenden pro ausgewähltem Commit ein separates gemeinsames Image `ghcr.io/openclaw/openclaw-live-test:`. 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 durch 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, 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. ## Package Acceptance -Verwenden Sie `Package Acceptance`, wenn die Frage lautet: „Funktioniert dieses installierbare OpenClaw-Paket als Produkt?“ Es unterscheidet sich vom normalen CI: Normales CI validiert den Quellbaum, während Package Acceptance einen einzelnen 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-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. ### Jobs -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-Step-Zusammenfassung 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 Paket aus, statt den Workflow-Checkout zu packen. Wenn ein Profil mehrere zielgerichtete `docker_lanes` auswählt, bereitet der wiederverwendbare Workflow das Paket und die gemeinsamen Images einmal vor und fächert diese Lanes dann als parallele zielgerichtete 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 Paketauflösung, Docker Acceptance oder die optionale Telegram-Lane fehlgeschlagen ist. +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. ### 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 veröffentlichte Beta-/Stable-Abnahmen. -- `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 getrennten Worktree und packt 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. +- `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. -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 gepackt wird, wenn `source=ref` ist. Dadurch kann der aktuelle Test-Harness ältere vertrauenswürdige Quell-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 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. ### Suite-Profile @@ -181,21 +181,21 @@ Halten Sie `workflow_ref` und `package_ref` getrennt. `workflow_ref` ist der ver - `full` — vollständige Docker-Release-Pfad-Chunks mit OpenWebUI - `custom` — exakte `docker_lanes`; erforderlich, wenn `suite_profile=custom` -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-Spec-Pfad für eigenständige Dispatches erhalten bleibt. +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. -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 Package-/Update-/Plugin-Lanes ab; Package Acceptance behält den artefaktnativen Kompatibilitätsnachweis für gebündelte Kanäle, das Offline-Plugin und den Telegram-Nachweis gegen denselben aufgelösten Paket-Tarball bei. Cross-OS-Release-Prüfungen decken weiterhin betriebssystemspezifisches Onboarding, Installer- und Plattformverhalten ab; die Package-/Update-Produktvalidierung sollte mit Package Acceptance beginnen. Die Windows-Packaged- und Installer-Fresh-Lanes verifizieren außerdem, dass ein installiertes Paket einen 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. +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. -### Legacy-Kompatibilitätsfenster +### Zeitfenster für Legacy-Kompatibilität -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.*`, können den Kompatibilitätspfad verwenden: +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: -- 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-Subcase `gateway install --wrapper` überspringen, wenn das Paket dieses Flag nicht bereitstellt; -- `update-channel-switch` darf fehlende `pnpm.patchedDependencies` aus der aus dem Tarball abgeleiteten Fake-Git-Fixture entfernen und fehlende persistierte `update.channel` protokollieren; -- Plugin-Smokes dürfen Legacy-Install-Record-Speicherorte lesen oder fehlende Marketplace-Install-Record-Persistenz akzeptieren; -- `plugin-update` darf die Migration von Konfigurationsmetadaten erlauben, muss aber weiterhin verlangen, dass der Install-Record und das Verhalten ohne Neuinstallation unverändert bleiben. +- 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. -Das veröffentlichte Paket `2026.4.26` darf außerdem vor lokalen Build-Metadaten-Stempeldateien warnen, die bereits ausgeliefert wurden. Spätere Pakete müssen die modernen Verträge erfüllen; dieselben Bedingungen schlagen dann fehl, statt zu warnen oder übersprungen zu werden. +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. ### Beispiele @@ -238,152 +238,152 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -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 dessen 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. +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. -## Installations-Smoke +## Install-Smoke -Der separate Workflow `Install Smoke` verwendet dasselbe Scope-Skript über seinen eigenen Job `preflight` wieder. Er teilt die Smoke-Abdeckung in `run_fast_install_smoke` und `run_full_install_smoke` auf. +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-/Package-Oberflächen, Änderungen an Paket/Manifest gebündelter Plugins oder Core-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 Shared-Workspace-CLI-Smoke für das Löschen von Agents aus, führt den 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 Szenario-Docker-Lauf ist separat begrenzt). -- **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-Call und Pull Requests bei, die wirklich Installer-/Package-/Docker-Oberflächen berühren. Im vollständigen Modus bereitet install-smoke ein GHCR-Root-Dockerfile-Smoke-Image für die Ziel-SHA vor oder verwendet es wieder und führt dann QR-Paketinstallation, Root-Dockerfile-/Gateway-Smokes, Installer-/Update-Smokes und den schnellen 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 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. -`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 Installations-Smoke der nächtlichen oder Release-Validierung. +`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. -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, aber Pull Requests und `main`-Pushes tun dies nicht. QR- und Installer-Docker-Tests behalten ihre eigenen installationsfokussierten 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 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. -## Lokaler Docker-E2E +## Lokales Docker-E2E -`pnpm test:docker:all` baut ein gemeinsames Live-Test-Image vor, packt OpenClaw einmal als npm-Tarball und baut zwei gemeinsame `scripts/e2e/Dockerfile`-Images: +`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: - 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. -Docker-Lane-Definitionen liegen in `scripts/lib/docker-e2e-scenarios.mjs`, die Planner-Logik liegt 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. +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. ### Einstellbare Parameter -| Variable | Standardwert | Zweck | -| -------------------------------------- | ------------ | ------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Slot-Anzahl des Hauptpools für normale Lanes. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Slot-Anzahl des Provider-sensiblen Tail-Pools. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limit für gleichzeitige Live-Lanes, damit Provider nicht drosseln. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limit für gleichzeitige npm-Install-Lanes. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limit 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_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 | Kommaseparierte exakte Lane-Liste; überspringt Cleanup-Smoke, damit Agents eine fehlgeschlagene Lane reproduzieren können. | +| Variable | Standard | Zweck | +| -------------------------------------- | -------- | --------------------------------------------------------------------------------------------- | +| `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_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_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. | -Eine Lane, die schwerer als ihr effektives Limit ist, kann weiterhin aus einem leeren Pool starten und läuft dann allein, bis sie Kapazität freigibt. Die lokale Aggregation prüft Docker vorab, entfernt veraltete OpenClaw-E2E-Container, gibt den Status aktiver Lanes aus, persistiert Lane-Timings für Longest-First-Sortierung und stoppt standardmäßig die Planung neuer gepoolter Lanes nach dem ersten Fehler. +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. ### Wiederverwendbarer Live-/E2E-Workflow -Der wiederverwendbare Live-/E2E-Workflow fragt `scripts/test-docker-all.mjs --plan-json`, welche Paket-, Image-Typ-, Live-Image-, Lane- und Credential-Abdeckung erforderlich ist. `scripts/docker-e2e.mjs` wandelt diesen Plan dann in GitHub-Ausgaben und Zusammenfassungen um. Er packt OpenClaw entweder über `scripts/package-openclaw-for-docker.mjs`, lädt ein Paketartefakt des aktuellen Laufs herunter oder lädt ein Paketartefakt aus `package_artifact_run_id` herunter; validiert das Tarball-Inventar; baut und pusht paket-digest-getaggte Bare-/Functional-GHCR-Docker-E2E-Images über den Docker-Layer-Cache von Blacksmith, wenn der Plan Lanes mit installiertem Paket benötigt; und verwendet bereitgestellte Eingaben `docker_e2e_bare_image`/`docker_e2e_functional_image` oder vorhandene Package-Digest-Images wieder, statt neu zu bauen. Docker-Image-Pulls werden mit einem begrenzten Timeout von 180 Sekunden pro Versuch erneut versucht, damit ein festhängender Registry-/Cache-Stream schnell erneut versucht wird, statt den Großteil des kritischen CI-Pfads zu verbrauchen. +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. ### Release-Pfad-Chunks -Release-Docker-Abdeckung läuft in kleineren gechunkten Jobs mit `OPENCLAW_SKIP_DOCKER_BUILD=1`, sodass jeder Chunk nur den benötigten Image-Typ zieht und mehrere Lanes über denselben gewichteten Scheduler ausführt: +Release-Docker-Abdeckung läuft in kleineren gechunkten Jobs mit `OPENCLAW_SKIP_DOCKER_BUILD=1`, sodass jeder Chunk nur die benötigte Image-Art zieht und mehrere Lanes über denselben gewichteten Scheduler ausführt: - `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 `bundled-channels`-Chunk 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 Alias für manuelle Wiederholungen für beide Provider-Installer-Lanes. Der `bundled-channels`-Chunk führt aufgeteilte `bundled-channel-*`- und `bundled-channel-update-*`-Lanes aus, statt der seriellen All-in-one-Lane `bundled-channel-deps`. +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`. -OpenWebUI wird in `plugins-runtime-services` integriert, wenn die vollständige Release-Pfad-Abdeckung dies anfordert, und behält einen eigenständigen `openwebui`-Chunk nur für reine OpenWebUI-Dispatches. Bundled-Channel-Update-Lanes versuchen transiente npm-Netzwerkfehler einmal erneut. +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. -Jeder Chunk lädt `.artifacts/docker-tests/` mit Lane-Logs, Zeitmessungen, `summary.json`, `failures.json`, Phasenzeiten, Scheduler-Plan-JSON, Tabellen für langsame Lanes und Wiederholungsbefehlen 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 Package-Artefakt 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 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 Package und dieselben Images aus dem fehlgeschlagenen Lauf wiederverwenden kann. +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. ```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 täglich die vollständige Docker-Suite des Release-Pfads aus. +Der geplante Live-/E2E-Workflow führt die vollständige Docker-Suite für den Release-Pfad täglich aus. ## Plugin-Vorabversion -`Plugin Prerelease` ist aufwendigere Produkt-/Package-Abdeckung und daher ein separater Workflow, der von `Full Release Validation` oder einem ausdrücklichen Operator ausgelöst wird. Normale Pull Requests, `main`-Pushes und eigenständige manuelle CI-Dispatches lassen diese Suite deaktiviert. Sie verteilt gebündelte Plugin-Tests auf acht Extension-Worker; diese Extension-Shard-Jobs führen bis zu zwei Plugin-Konfigurationsgruppen gleichzeitig mit einem Vitest-Worker pro Gruppe und einem größeren Node-Heap aus, damit importlastige Plugin-Batches keine zusätzlichen CI-Jobs erzeugen. +`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. ## QA Lab -QA Lab hat dedizierte CI-Lanes außerhalb des hauptsächlichen smart-scoped Workflows. +QA Lab hat dedizierte CI-Lanes außerhalb des zentralen smart gescopten 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-Pakete GPT-5.5 und Opus 4.6. -- Der Workflow `QA-Lab - All Lanes` läuft jede Nacht auf `main` und bei manuellem Dispatch; er fächert das Mock-Parity-Gate, die Live-Matrix-Lane sowie die Live-Telegram- und Live-Discord-Lanes 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 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. -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 Channel-Vertrag 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 Live-Modell-, nativen Provider- und Docker-Provider-Suites abgedeckt. +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. -Matrix verwendet `--profile fast` für geplante 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 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`. -`OpenClaw Release Checks` führt vor der Release-Freigabe auch die releasekritischen QA-Lab-Lanes aus; dessen QA-Parity-Gate führt Kandidaten- und Baseline-Pakete als parallele Lane-Jobs aus und lädt anschließend beide Artefakte in einen kleinen Report-Job für den abschließenden Paritätsvergleich herunter. +`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. -Legen Sie den PR-Landing-Pfad nicht hinter `Parity gate`, es sei denn, die Änderung berührt tatsächlich die QA-Runtime, Modellpaket-Parität oder eine Oberfläche, die dem Parity-Workflow gehört. Behandeln Sie ihn bei normalen Channel-, Konfigurations-, Dokumentations- oder Unit-Test-Fixes als optionales Signal und folgen Sie stattdessen der eingegrenzten CI-/Prüfnachweislage. +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. ## CodeQL -Der `CodeQL`-Workflow ist bewusst ein schmaler Security-Scanner für den ersten Durchlauf, nicht der vollständige Repository-Sweep. Tägliche, manuelle und nicht als Entwurf markierte Pull-Request-Guard-Läufe scannen Actions-Workflow-Code sowie die JavaScript-/TypeScript-Oberflächen mit dem höchsten Risiko mit hochzuverlässigen Security-Abfragen, gefiltert auf hohe/kritische `security-severity`. +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 Pull-Request-Guard bleibt leichtgewichtig: Er startet nur bei Änderungen unter `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` oder `src` und führt dieselbe hochzuverlässige Security-Matrix wie der geplante Workflow aus. Android- und macOS-CodeQL bleiben außerhalb der PR-Standards. +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. -### Security-Kategorien +### Sicherheitskategorien -| Kategorie | Oberfläche | -| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -| `/codeql-security-high/core-auth-secrets` | Authentifizierung, Secrets, Sandbox, Cron und Gateway-Baseline | -| `/codeql-security-high/channel-runtime-boundary` | Core-Channel-Implementierungsverträge plus Channel-Plugin-Runtime, Gateway, Plugin SDK, Secrets, Audit-Touchpoints | -| `/codeql-security-high/network-ssrf-boundary` | Core-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 Agent-Gates für Tool-Ausführung | -| `/codeql-security-high/plugin-trust-boundary` | Plugin-Installation, Loader, Manifest, Registry, Runtime-Abhängigkeits-Staging, Quellladevorgänge und Vertrauensoberflächen des Plugin-SDK-Package-Vertrags | +| 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 | ### Plattformspezifische Security-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 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 die Laufzeit selbst bei sauberem Lauf dominiert. +- `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. -### Critical-Quality-Kategorien +### Kategorien für kritische Qualität -`CodeQL Critical Quality` ist der passende Nicht-Security-Shard. Er führt nur JavaScript-/TypeScript-Qualitätsabfragen mit Fehler-Schweregrad und ohne Security-Bezug über schmale, besonders wertvolle Oberflächen auf dem kleineren Blacksmith-Linux-Runner aus. Sein Pull-Request-Guard ist bewusst kleiner als das geplante Profil: Nicht als Entwurf markierte PRs führen nur die passenden Shards `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 Konfigurationsschema-/Migrations-/IO-Code, Auth-/Secrets-/Sandbox-/Security-Code, Core-Channel- und gebündelter Channel-Plugin-Runtime, Gateway-Protokoll-/Servermethode, Memory-Runtime-/SDK-Glue, MCP/Prozess/ausgehender Zustellung, Provider-Runtime/Modellkatalog, Sitzungsdiagnose/Zustellwarteschlangen, Plugin-Loader, Plugin-SDK/Package-Vertrag oder Plugin-SDK-Antwort-Runtime aus. CodeQL-Konfigurations- und Quality-Workflow-Änderungen führen alle elf PR-Quality-Shards aus. +`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. Manueller Dispatch akzeptiert: ``` -profile=all|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 +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 schmalen Profile sind Lehr-/Iterations-Hooks, um einen einzelnen Quality-Shard isoliert auszuführen. +Die engen Profile sind Lern-/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-Code für Sicherheitsgrenzen | -| `/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-Kanal- und gebündelte Kanal-Plugin-Implementierungen | -| `/codeql-critical-quality/agent-runtime-boundary` | Befehlsausführung, Modell-/Provider-Dispatch, Dispatch und Warteschlangen für automatische Antworten sowie ACP-Control-Plane-Laufzeitverträge | -| `/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-Laufzeitfassaden, Memory-Plugin-SDK-Aliasse, Glue-Code zur Memory-Laufzeitaktivierung und Memory-Doctor-Befehle | -| `/codeql-critical-quality/session-diagnostics-boundary` | Interna der Antwortwarteschlange, Sitzungszustellungswarteschlangen, Hilfen für ausgehende Sitzungsbindung/-zustellung, Diagnoseereignis-/Protokollpaket-Oberflächen und Sitzungs-Doctor-CLI-Verträge | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin-SDK-Dispatch für eingehende Antworten, Hilfen für Antwort-Payloads/Chunking/Laufzeit, Kanal-Antwortoptionen, Zustellungswarteschlangen und Hilfen für Sitzungs-/Thread-Bindung | -| `/codeql-critical-quality/provider-runtime-boundary` | Modellkatalog-Normalisierung, Provider-Auth und -Erkennung, Provider-Laufzeitregistrierung, Provider-Standards/Kataloge sowie Registries für Web/Suche/Abruf/Embeddings | -| `/codeql-critical-quality/ui-control-plane` | Control-UI-Bootstrap, lokale Persistenz, Gateway-Steuerungsflüsse und Task-Control-Plane-Laufzeitverträge | -| `/codeql-critical-quality/web-media-runtime-boundary` | Core-Web-Abruf/Suche, Medien-IO, Medienverständnis, Bildgenerierung und Laufzeitverträge für Mediengenerierung | -| `/codeql-critical-quality/plugin-boundary` | Loader-, Registry-, öffentliche Oberflächen- und Plugin-SDK-Einstiegspunkt-Verträge | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Veröffentlichter paketbezogener Plugin-SDK-Quellcode und Hilfen für Plugin-Paketverträge | +| 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 | -Qualität bleibt von Sicherheit getrennt, damit Qualitätsbefunde geplant, gemessen, deaktiviert oder erweitert werden können, ohne das Sicherheitssignal zu verdecken. Swift-, Python- und gebündelte-Plugin-CodeQL-Erweiterungen sollten erst wieder als begrenzte oder geshardete Folgearbeit hinzugefügt werden, wenn die schmalen Profile eine stabile Laufzeit und ein stabiles Signal haben. +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. ## Wartungsworkflows ### Docs Agent -Der Workflow `Docs Agent` ist eine ereignisgesteuerte Codex-Wartungsspur, um vorhandene Dokumentation mit kürzlich gelandeten Änderungen abzugleichen. 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 vom vorherigen nicht übersprungenen Docs-Agent-Quell-SHA bis zum aktuellen `main`, sodass ein stündlicher Lauf alle seit dem letzten Dokumentationsdurchlauf angesammelten Änderungen auf main abdecken kann. +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. ### Test Performance Agent -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 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 Spur erstellt einen gruppierten Vitest-Performancebericht für die vollständige Suite, lässt Codex nur kleine, die Abdeckung erhaltende Test-Performance-Fixes statt breiter Refactorings vornehmen, führt anschließend den Bericht für die vollständige Suite 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 Agenten muss bestehen, bevor etwas committed 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-Sicherheitshaltung wie der Docs-Agent beibehalten kann. +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. -### Doppelte PRs nach dem Merge +### Doppelte PRs nach Merge -Der Workflow `Duplicate PRs After Merge` ist ein manueller Maintainer-Workflow zur Bereinigung doppelter PRs nach dem Landen. Er ist standardmäßig ein Dry-Run und schließt nur explizit aufgelistete PRs, wenn `apply=true` ist. Bevor GitHub verändert wird, prüft er, dass der gelandete PR gemerged wurde und dass jedes Duplikat 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 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. ```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 Routing geänderter Dateien +## Lokale Check-Gates und Änderungsrouting -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-Plattformumfang: +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: -- Änderungen an Core-Produktionscode führen Core-Prod- und Core-Test-Typecheck sowie Core-Lint/Guards aus; +- 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; -- Änderungen an Erweiterungs-Produktionscode führen Extension-Prod- und Extension-Test-Typecheck plus Extension-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 erweitern auf Extension-Typecheck, weil Extensions von diesen Core-Verträgen abhängen (Vitest-Extension-Sweeps bleiben explizite Testarbeit); -- reine Release-Metadaten-Versionsanhebungen führen gezielte Versions-/Konfigurations-/Root-Abhängigkeitsprüfungen aus; -- unbekannte Root-/Konfigurationsänderungen fallen sicher auf alle Check-Lanes zurück. +- Ä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); +- 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. -Lokales Changed-Test-Routing liegt in `scripts/test-projects.test-support.mjs` und ist absichtlich günstiger als `check:changed`: Direkte Testbearbeitungen führen sich selbst aus, Quellcodeänderungen bevorzugen explizite Zuordnungen, dann Geschwistertests und Importgraph-Abhängige. Die Shared-Group-Room-Zustellungskonfiguration ist eine der expliziten Zuordnungen: Änderungen an der für Gruppen sichtbaren Antwortkonfiguration, am Zustellungsmodus für Quellantworten oder am Systemprompt des Message-Tools laufen über die Core-Antworttests plus Discord- und Slack-Zustellungsregressionen, damit eine Änderung am gemeinsamen 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 zugeordnete Menge kein vertrauenswürdiger Proxy ist. +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. ## Testbox-Validierung -Führen Sie Testbox aus dem Repo-Root aus und bevorzugen Sie für breiten Nachweis eine frisch vorgewärmte Box. Bevor Sie ein langsames Gate für eine Box aufwenden, 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 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. -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 normalerweise, dass der Remote-Sync-Zustand keine vertrauenswürdige Kopie des PR ist; stoppen Sie diese Box und wärmen Sie eine neue auf, statt den Produkt-Testfehler 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 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`. -`pnpm testbox:run` beendet außerdem einen lokalen Blacksmith-CLI-Aufruf, der länger als fünf Minuten in der Sync-Phase bleibt, ohne Ausgabe nach dem Sync zu erzeugen. Setzen Sie `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, um diesen Guard zu deaktivieren, oder verwenden Sie einen größeren Millisekundenwert für ungewöhnlich große lokale Diffs. +`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. ## Verwandt -- [Installationsübersicht](/de/install) +- [Installationsüberblick](/de/install) - [Entwicklungskanäle](/de/install/development-channels) diff --git a/docs/de/cli/cron.md b/docs/de/cli/cron.md index af8c038ad..996f2ca2e 100644 --- a/docs/de/cli/cron.md +++ b/docs/de/cli/cron.md @@ -1,24 +1,24 @@ --- read_when: - Sie möchten geplante Jobs und Weckvorgänge - - Sie debuggen die Cron-Ausführung und -Protokolle + - Sie debuggen die Cron-Ausführung und Protokolle summary: CLI-Referenz für `openclaw cron` (Hintergrundjobs planen und ausführen) title: Cron x-i18n: - generated_at: "2026-04-30T06:44:45Z" + generated_at: "2026-04-30T09:34:47Z" model: gpt-5.5 provider: openai - source_hash: 658498b09e0f0997d0f05dcdbdbd8822284d747df932f1c51e86f97b94cd81a7 + source_hash: 03d79e0e2c71f673c900b84eb2beeab705662c1d016e1d0567323c8da73060bb source_path: cli/cron.md workflow: 16 --- # `openclaw cron` -Cron-Jobs für den Gateway-Scheduler verwalten. +Verwalten Sie Cron-Jobs für den Gateway-Scheduler. -Führen Sie `openclaw cron --help` aus, um die vollständige Befehlsoberfläche anzuzeigen. Siehe [Cron-Jobs](/de/automation/cron-jobs) für den konzeptionellen Leitfaden. +Führen Sie `openclaw cron --help` aus, um die vollständige Befehlsoberfläche zu sehen. Siehe [Cron-Jobs](/de/automation/cron-jobs) für die konzeptionelle Anleitung. ## Sitzungen @@ -27,23 +27,23 @@ Führen Sie `openclaw cron --help` aus, um die vollständige Befehlsoberfläche - - `main` bindet an die Hauptsitzung des Agents. + - `main` bindet an die Hauptsitzung des Agenten. - `isolated` erstellt für jeden Lauf ein frisches Transkript und eine Sitzungs-ID. - `current` bindet zum Erstellungszeitpunkt an die aktive Sitzung. - - `session:` fixiert einen expliziten persistenten Sitzungsschlüssel. + - `session:` pinnt an einen expliziten persistenten Sitzungsschlüssel. - Isolierte Läufe setzen den Umgebungskontext der Unterhaltung zurück. Kanal- und Gruppenrouting, Sende-/Warteschlangenrichtlinie, Erhöhung, Ursprung und ACP-Laufzeitbindung werden für den neuen Lauf zurückgesetzt. Sichere Einstellungen und explizit vom Benutzer ausgewählte Modell- oder Auth-Überschreibungen können über Läufe hinweg übernommen werden. + Isolierte Läufe setzen den umgebenden Unterhaltungskontext zurück. Kanal- und Gruppen-Routing, Sende-/Warteschlangenrichtlinie, Elevation, Ursprung und ACP-Laufzeitbindung werden für den neuen Lauf zurückgesetzt. Sichere Einstellungen und explizit vom Benutzer ausgewählte Modell- oder Auth-Overrides können über Läufe hinweg übernommen werden. ## Zustellung -`openclaw cron list` und `openclaw cron show ` zeigen eine Vorschau der aufgelösten Zustellroute. Für `channel: "last"` zeigt die Vorschau, ob die Route aus der Haupt- oder aktuellen Sitzung aufgelöst wurde oder geschlossen fehlschlagen wird. +`openclaw cron list` und `openclaw cron show ` zeigen eine Vorschau der aufgelösten Zustellroute. Bei `channel: "last"` zeigt die Vorschau, ob die Route aus der Hauptsitzung oder der aktuellen Sitzung aufgelöst wurde oder sicher fehlschlagen wird. -Isolierte `cron add`-Jobs verwenden standardmäßig `--announce`-Zustellung. Verwenden Sie `--no-deliver`, um die Ausgabe intern zu halten. `--deliver` bleibt als veralteter Alias für `--announce` erhalten. +Isolierte `cron add`-Jobs verwenden standardmäßig die `--announce`-Zustellung. Verwenden Sie `--no-deliver`, um die Ausgabe intern zu halten. `--deliver` bleibt als veralteter Alias für `--announce` erhalten. ### Zustellungsverantwortung @@ -51,56 +51,56 @@ Isolierte `cron add`-Jobs verwenden standardmäßig `--announce`-Zustellung. Ver Die Chat-Zustellung isolierter Cron-Jobs wird zwischen Agent und Runner geteilt: - Der Agent kann direkt mit dem `message`-Tool senden, wenn eine Chat-Route verfügbar ist. -- `announce` stellt die abschließende Antwort nur dann als Fallback zu, wenn der Agent nicht direkt an das aufgelöste Ziel gesendet hat. +- `announce` stellt die finale Antwort nur dann per Fallback zu, wenn der Agent nicht direkt an das aufgelöste Ziel gesendet hat. - `webhook` sendet die fertige Payload an eine URL. -- `none` deaktiviert die Fallback-Zustellung des Runners. +- `none` deaktiviert die Runner-Fallback-Zustellung. -`--announce` ist die Fallback-Zustellung des Runners für die abschließende Antwort. `--no-deliver` deaktiviert diesen Fallback, entfernt aber nicht das `message`-Tool des Agents, wenn eine Chat-Route verfügbar ist. +`--announce` ist die Runner-Fallback-Zustellung für die finale Antwort. `--no-deliver` deaktiviert diesen Fallback, entfernt aber nicht das `message`-Tool des Agenten, wenn eine Chat-Route verfügbar ist. -Erinnerungen, die aus einem aktiven Chat erstellt wurden, bewahren das Live-Chat-Zustellziel für die Fallback-Announce-Zustellung. Interne Sitzungsschlüssel können kleingeschrieben sein; verwenden Sie sie nicht als Quelle der Wahrheit für groß-/kleinschreibungssensitive Provider-IDs wie Matrix-Raum-IDs. +Erinnerungen, die aus einem aktiven Chat erstellt werden, behalten das Live-Chat-Zustellziel für die Fallback-announce-Zustellung bei. Interne Sitzungsschlüssel können kleingeschrieben sein; verwenden Sie sie nicht als maßgebliche Quelle für groß-/kleinschreibungssensitive Provider-IDs wie Matrix-Raum-IDs. ### Fehlerzustellung Fehlerbenachrichtigungen werden in dieser Reihenfolge aufgelöst: -1. `delivery.failureDestination` des Jobs. +1. `delivery.failureDestination` für den Job. 2. Globales `cron.failureDestination`. -3. Das primäre Announce-Ziel des Jobs (wenn kein explizites Fehlerziel festgelegt ist). +3. Das primäre announce-Ziel des Jobs, wenn kein explizites Fehlerziel festgelegt ist. -Jobs in der Hauptsitzung dürfen `delivery.failureDestination` nur verwenden, wenn der primäre Zustellmodus `webhook` ist. Isolierte Jobs akzeptieren es in allen Modi. +Jobs der Hauptsitzung dürfen `delivery.failureDestination` nur verwenden, wenn der primäre Zustellmodus `webhook` ist. Isolierte Jobs akzeptieren es in allen Modi. -Hinweis: Isolierte Cron-Läufe behandeln Agent-Fehler auf Laufebene als Jobfehler, auch wenn -keine Antwort-Payload erzeugt wird, sodass Modell-/Provider-Fehler weiterhin Fehlerzähler -erhöhen und Fehlerbenachrichtigungen auslösen. +Hinweis: Isolierte Cron-Läufe behandeln Agentenfehler auf Laufebene als Jobfehler, selbst wenn +keine Antwort-Payload erzeugt wird. Dadurch erhöhen Modell-/Provider-Fehler weiterhin die Fehlerzähler +und lösen Fehlerbenachrichtigungen aus. -## Zeitplanung +## Planung ### Einmalige Jobs -`--at ` plant einen einmaligen Lauf. Datums-/Zeitangaben ohne Offset werden als UTC behandelt, sofern Sie nicht zusätzlich `--tz ` übergeben; dadurch wird die Uhrzeit in der angegebenen Zeitzone interpretiert. +`--at ` plant einen einmaligen Lauf. Datums-/Zeitangaben ohne Offset werden als UTC behandelt, sofern Sie nicht zusätzlich `--tz ` übergeben; dann wird die Wanduhrzeit in der angegebenen Zeitzone interpretiert. -Einmalige Jobs werden nach erfolgreichem Abschluss standardmäßig gelöscht. Verwenden Sie `--keep-after-run`, um sie beizubehalten. +Einmalige Jobs werden nach erfolgreicher Ausführung standardmäßig gelöscht. Verwenden Sie `--keep-after-run`, um sie beizubehalten. ### Wiederkehrende Jobs -Wiederkehrende Jobs verwenden nach aufeinanderfolgenden Fehlern exponentielles Retry-Backoff: 30s, 1m, 5m, 15m, 60m. Nach dem nächsten erfolgreichen Lauf kehrt der Zeitplan zum Normalzustand zurück. +Wiederkehrende Jobs verwenden nach aufeinanderfolgenden Fehlern exponentielles Retry-Backoff: 30 s, 1 min, 5 min, 15 min, 60 min. Nach dem nächsten erfolgreichen Lauf kehrt der Zeitplan zum Normalbetrieb zurück. -Übersprungene Läufe werden getrennt von Ausführungsfehlern verfolgt. Sie beeinflussen das Retry-Backoff nicht, aber `openclaw cron edit --failure-alert-include-skipped` kann Fehlerwarnungen um wiederholte Benachrichtigungen zu übersprungenen Läufen erweitern. +Übersprungene Läufe werden getrennt von Ausführungsfehlern erfasst. Sie wirken sich nicht auf das Retry-Backoff aus, aber `openclaw cron edit --failure-alert-include-skipped` kann Fehlerwarnungen so konfigurieren, dass wiederholte Benachrichtigungen zu übersprungenen Läufen enthalten sind. -Für isolierte Jobs, die auf einen lokal konfigurierten Modell-Provider abzielen, führt Cron vor dem Start des Agent-Turns einen leichtgewichtigen Provider-Preflight aus. Loopback-, private Netzwerk- und `.local`-`api: "ollama"`-Provider werden unter `/api/tags` geprüft; lokale OpenAI-kompatible Provider wie vLLM, SGLang und LM Studio werden unter `/models` geprüft. Wenn der Endpunkt nicht erreichbar ist, wird der Lauf als `skipped` aufgezeichnet und zu einem späteren Zeitpunkt erneut versucht; passende tote Endpunkte werden 5 Minuten lang zwischengespeichert, um zu vermeiden, dass viele Jobs denselben lokalen Server überlasten. +Für isolierte Jobs, die auf einen lokal konfigurierten Modell-Provider zielen, führt Cron einen schlanken Provider-Preflight aus, bevor der Agent-Turn startet. Loopback-, Private-Network- und `.local`-Provider mit `api: "ollama"` werden unter `/api/tags` geprüft; lokale OpenAI-kompatible Provider wie vLLM, SGLang und LM Studio werden unter `/models` geprüft. Ist der Endpunkt nicht erreichbar, wird der Lauf als `skipped` aufgezeichnet und zu einem späteren Zeitplan erneut versucht; passende tote Endpunkte werden 5 Minuten zwischengespeichert, damit nicht viele Jobs denselben lokalen Server belasten. -Hinweis: Cron-Job-Definitionen liegen in `jobs.json`, während ausstehender Laufzeitstatus in `jobs-state.json` liegt. Wenn `jobs.json` extern bearbeitet wird, lädt der Gateway geänderte Zeitpläne neu und löscht veraltete ausstehende Slots; reine Formatierungsänderungen löschen den ausstehenden Slot nicht. +Hinweis: Cron-Job-Definitionen befinden sich in `jobs.json`, während ausstehender Laufzeitstatus in `jobs-state.json` liegt. Wenn `jobs.json` extern bearbeitet wird, lädt der Gateway geänderte Zeitpläne neu und löscht veraltete ausstehende Slots; reine Formatierungsänderungen löschen den ausstehenden Slot nicht. ### Manuelle Läufe `openclaw cron run` kehrt zurück, sobald der manuelle Lauf in die Warteschlange gestellt wurde. Erfolgreiche Antworten enthalten `{ ok: true, enqueued: true, runId }`. Verwenden Sie `openclaw cron runs --id `, um das spätere Ergebnis zu verfolgen. -`openclaw cron run ` erzwingt den Lauf standardmäßig. Verwenden Sie `--due`, um das ältere Verhalten „nur ausführen, wenn fällig“ beizubehalten. +`openclaw cron run ` erzwingt standardmäßig einen Lauf. Verwenden Sie `--due`, um das ältere Verhalten „nur ausführen, wenn fällig“ beizubehalten. ## Modelle @@ -108,46 +108,46 @@ Hinweis: Cron-Job-Definitionen liegen in `jobs.json`, während ausstehender Lauf `cron add|edit --model ` wählt ein zulässiges Modell für den Job aus. -Wenn das Modell nicht erlaubt ist oder nicht aufgelöst werden kann, lässt Cron den Lauf mit einem expliziten Validierungsfehler fehlschlagen, statt auf den Agent des Jobs oder die Standardmodellauswahl zurückzufallen. +Wenn das Modell nicht zulässig ist oder nicht aufgelöst werden kann, schlägt Cron den Lauf mit einem expliziten Validierungsfehler fehl, statt auf die Agenten- oder Standardmodellauswahl des Jobs zurückzufallen. -Cron `--model` ist ein **Job-Primärmodell**, keine `/model`-Überschreibung einer Chat-Sitzung. Das bedeutet: +Cron `--model` ist ein **Job-Primärmodell**, kein `/model`-Override einer Chat-Sitzung. Das bedeutet: - Konfigurierte Modell-Fallbacks gelten weiterhin, wenn das ausgewählte Jobmodell fehlschlägt. -- Die pro Job gesetzte Payload `fallbacks` ersetzt die konfigurierte Fallback-Liste, wenn sie vorhanden ist. -- Eine leere pro Job gesetzte Fallback-Liste (`fallbacks: []` in der Job-Payload/API) macht den Cron-Lauf strikt. -- Wenn ein Job `--model`, aber keine konfigurierte Fallback-Liste hat, übergibt OpenClaw eine explizit leere Fallback-Überschreibung, damit das primäre Agent-Modell nicht als verborgenes Retry-Ziel angehängt wird. +- Pro-Job-Payload `fallbacks` ersetzt die konfigurierte Fallback-Liste, wenn vorhanden. +- Eine leere Pro-Job-Fallback-Liste (`fallbacks: []` in der Job-Payload/API) macht den Cron-Lauf strikt. +- Wenn ein Job `--model`, aber keine konfigurierte Fallback-Liste hat, übergibt OpenClaw einen expliziten leeren Fallback-Override, damit das primäre Agentenmodell nicht als verstecktes Retry-Ziel angehängt wird. -### Modellpriorität isolierter Cron-Jobs +### Modellpriorität bei isoliertem Cron -Isolierte Cron-Jobs lösen das aktive Modell in dieser Reihenfolge auf: +Isolierter Cron löst das aktive Modell in dieser Reihenfolge auf: -1. Gmail-Hook-Überschreibung. -2. Pro Job gesetztes `--model`. -3. Gespeicherte Cron-Sitzungsmodellüberschreibung (wenn der Benutzer eine ausgewählt hat). -4. Agent- oder Standardmodellauswahl. +1. Gmail-Hook-Override. +2. Pro-Job-`--model`. +3. Gespeicherter Cron-Sitzungsmodell-Override, wenn der Benutzer einen ausgewählt hat. +4. Agenten- oder Standardmodellauswahl. ### Schnellmodus -Der Schnellmodus isolierter Cron-Jobs folgt der aufgelösten Live-Modellauswahl. Die Modellkonfiguration `params.fastMode` gilt standardmäßig, aber eine gespeicherte Sitzungsüberschreibung `fastMode` hat weiterhin Vorrang vor der Konfiguration. +Der Schnellmodus für isolierten Cron folgt der aufgelösten Live-Modellauswahl. Die Modellkonfiguration `params.fastMode` gilt standardmäßig, aber ein gespeicherter Sitzungs-`fastMode`-Override hat weiterhin Vorrang vor der Konfiguration. ### Retries bei Live-Modellwechseln -Wenn ein isolierter Lauf `LiveSessionModelSwitchError` auslöst, persistiert Cron den gewechselten Provider und das Modell (und die gewechselte Auth-Profil-Überschreibung, wenn vorhanden) für den aktiven Lauf, bevor erneut versucht wird. Die äußere Retry-Schleife ist nach dem ersten Versuch auf zwei Wechsel-Retries begrenzt und bricht dann ab, statt endlos zu laufen. +Wenn ein isolierter Lauf `LiveSessionModelSwitchError` auslöst, persistiert Cron den gewechselten Provider und das gewechselte Modell sowie, falls vorhanden, den gewechselten Auth-Profil-Override für den aktiven Lauf, bevor erneut versucht wird. Die äußere Retry-Schleife ist nach dem ersten Versuch auf zwei Wechsel-Retries begrenzt und bricht dann ab, statt endlos zu laufen. ## Laufausgabe und Ablehnungen ### Unterdrückung veralteter Bestätigungen -Isolierte Cron-Turns unterdrücken veraltete Antworten, die nur aus einer Bestätigung bestehen. Wenn das erste Ergebnis nur eine Zwischenstatusaktualisierung ist und kein nachgelagerter Subagent-Lauf für die spätere Antwort verantwortlich ist, fordert Cron vor der Zustellung einmal erneut das echte Ergebnis an. +Isolierte Cron-Turns unterdrücken veraltete Antworten, die nur Bestätigungen enthalten. Wenn das erste Ergebnis nur eine vorläufige Statusaktualisierung ist und kein nachgelagerter Subagent-Lauf für die spätere Antwort verantwortlich ist, fordert Cron einmal erneut das eigentliche Ergebnis an, bevor zugestellt wird. ### Unterdrückung stiller Tokens -Wenn ein isolierter Cron-Lauf nur das stille Token (`NO_REPLY` oder `no_reply`) zurückgibt, unterdrückt Cron sowohl die direkte ausgehende Zustellung als auch den Fallback-Pfad der in die Warteschlange gestellten Zusammenfassung, sodass nichts zurück in den Chat gepostet wird. +Wenn ein isolierter Cron-Lauf nur das stille Token (`NO_REPLY` oder `no_reply`) zurückgibt, unterdrückt Cron sowohl die direkte ausgehende Zustellung als auch den Fallback-Pfad für die in die Warteschlange gestellte Zusammenfassung, sodass nichts zurück in den Chat gepostet wird. ### Strukturierte Ablehnungen -Isolierte Cron-Läufe bevorzugen strukturierte Metadaten zu Ausführungsablehnungen aus dem eingebetteten Lauf und fallen dann auf bekannte Ablehnungsmarker in der finalen Ausgabe zurück, etwa `SYSTEM_RUN_DENIED`, `INVALID_REQUEST` und Ablehnungsformulierungen zur Genehmigungsbindung. +Isolierte Cron-Läufe bevorzugen strukturierte Metadaten zu Ausführungsablehnungen aus dem eingebetteten Lauf und fallen dann auf bekannte Ablehnungsmarker in der finalen Ausgabe zurück, etwa `SYSTEM_RUN_DENIED`, `INVALID_REQUEST` und Formulierungen zur Verweigerung der Approval-Bindung. `cron list` und der Laufverlauf zeigen den Ablehnungsgrund an, statt einen blockierten Befehl als `ok` zu melden. @@ -161,12 +161,12 @@ Aufbewahrung und Bereinigung werden in der Konfiguration gesteuert: ## Migration älterer Jobs -Wenn Sie Cron-Jobs aus der Zeit vor dem aktuellen Zustell- und Speicherformat haben, führen Sie `openclaw doctor --fix` aus. Doctor normalisiert Legacy-Cron-Felder (`jobId`, `schedule.cron`, Zustellfelder auf oberster Ebene einschließlich Legacy-`threadId`, Payload-`provider`-Zustellaliasse) und migriert einfache `notify: true`-Webhook-Fallback-Jobs zu expliziter Webhook-Zustellung, wenn `cron.webhook` konfiguriert ist. +Wenn Sie Cron-Jobs aus der Zeit vor dem aktuellen Zustellungs- und Speicherformat haben, führen Sie `openclaw doctor --fix` aus. Doctor normalisiert Legacy-Cron-Felder (`jobId`, `schedule.cron`, Zustellfelder auf oberster Ebene einschließlich Legacy-`threadId`, Payload-`provider`-Zustellaliasen) und migriert einfache `notify: true`-Webhook-Fallback-Jobs zu expliziter Webhook-Zustellung, wenn `cron.webhook` konfiguriert ist. ## Häufige Änderungen -Zustelleinstellungen aktualisieren, ohne die Nachricht zu ändern: +Zustellungseinstellungen aktualisieren, ohne die Nachricht zu ändern: ```bash openclaw cron edit --announce --channel telegram --to "123456789" @@ -178,25 +178,25 @@ Zustellung für einen isolierten Job deaktivieren: openclaw cron edit --no-deliver ``` -Leichtgewichtigen Bootstrap-Kontext für einen isolierten Job aktivieren: +Schlanken Bootstrap-Kontext für einen isolierten Job aktivieren: ```bash openclaw cron edit --light-context ``` -An einen bestimmten Kanal ankündigen: +In einem bestimmten Kanal ankündigen: ```bash openclaw cron edit --announce --channel slack --to "channel:C1234567890" ``` -An ein Telegram-Forumsthema ankündigen: +In einem Telegram-Forenthema ankündigen: ```bash openclaw cron edit --announce --channel telegram --to "-1001234567890" --thread-id 42 ``` -Einen isolierten Job mit leichtgewichtigem Bootstrap-Kontext erstellen: +Einen isolierten Job mit schlankem Bootstrap-Kontext erstellen: ```bash openclaw cron add \ @@ -208,11 +208,11 @@ openclaw cron add \ --no-deliver ``` -`--light-context` gilt nur für isolierte Agent-Turn-Jobs. Bei Cron-Läufen hält der leichtgewichtige Modus den Bootstrap-Kontext leer, statt den vollständigen Workspace-Bootstrap-Satz einzufügen. +`--light-context` gilt nur für isolierte Agent-Turn-Jobs. Für Cron-Läufe hält der schlanke Modus den Bootstrap-Kontext leer, statt den vollständigen Workspace-Bootstrap-Satz einzufügen. ## Häufige Admin-Befehle -Manueller Lauf und Inspektion: +Manueller Lauf und Prüfung: ```bash openclaw cron list @@ -222,9 +222,9 @@ openclaw cron run --due openclaw cron runs --id --limit 50 ``` -`cron runs`-Einträge enthalten Zustelldiagnosen mit dem beabsichtigten Cron-Ziel, dem aufgelösten Ziel, Sendevorgängen des Message-Tools, Fallback-Nutzung und Zustellstatus. +`cron runs`-Einträge enthalten Zustellungsdiagnosen mit dem beabsichtigten Cron-Ziel, dem aufgelösten Ziel, Sendungen des Message-Tools, Fallback-Nutzung und Zustellstatus. -Agent- und Sitzungsneuausrichtung: +Agenten- und Sitzungs-Neuzuweisung: ```bash openclaw cron edit --agent ops @@ -233,7 +233,9 @@ openclaw cron edit --session current openclaw cron edit --session "session:daily-brief" ``` -Zustellanpassungen: +`openclaw cron add` warnt, wenn `--agent` bei Agent-Turn-Jobs ausgelassen wird, und fällt auf den Standardagenten (`main`) zurück. Übergeben Sie `--agent ` beim Erstellen, um einen bestimmten Agenten festzulegen. + +Zustellungsanpassungen: ```bash openclaw cron edit --announce --channel slack --to "channel:C1234567890" diff --git a/docs/de/gateway/local-models.md b/docs/de/gateway/local-models.md index ae45a45a1..cb281fee2 100644 --- a/docs/de/gateway/local-models.md +++ b/docs/de/gateway/local-models.md @@ -1,30 +1,30 @@ --- read_when: - - Sie möchten Modelle von Ihrem eigenen GPU-Rechner bereitstellen - - Sie binden LM Studio oder einen OpenAI-kompatiblen Proxy an - - Sie benötigen die sicherste Anleitung für lokale Modelle + - Sie möchten Modelle auf Ihrem eigenen GPU-Rechner bereitstellen + - Sie binden LM Studio oder einen OpenAI-kompatiblen Proxy ein + - Sie benötigen die sichersten Empfehlungen für lokale Modelle summary: OpenClaw auf lokalen LLMs ausführen (LM Studio, vLLM, LiteLLM, benutzerdefinierte OpenAI-Endpunkte) title: Lokale Modelle x-i18n: - generated_at: "2026-04-30T06:54:30Z" + generated_at: "2026-04-30T09:34:50Z" model: gpt-5.5 provider: openai - source_hash: 2ec1be4eac371328c1efe80b71450019f68fb1114df90db1532a4ff72bfa0ab1 + source_hash: 283da11a7896c670d3a249eeb957a252cbda7f7457bd814bb0796f3ca9956723 source_path: gateway/local-models.md workflow: 16 --- -Lokal ist machbar, aber OpenClaw erwartet großen Kontext und starke Abwehr gegen Prompt-Injection. Kleine Karten kürzen Kontext und beeinträchtigen Sicherheit. Zielen Sie hoch: **≥2 voll ausgestattete Mac Studios oder ein vergleichbares GPU-Rig (~30.000 $+)**. Eine einzelne **24-GB**-GPU funktioniert nur für leichtere Prompts mit höherer Latenz. Verwenden Sie die **größte / vollwertige Modellvariante, die Sie ausführen können**; stark quantisierte oder „kleine“ Checkpoints erhöhen das Prompt-Injection-Risiko (siehe [Sicherheit](/de/gateway/security)). +Lokal ist machbar, aber OpenClaw erwartet großen Kontext und starke Abwehr gegen Prompt-Injection. Kleinere Karten beschneiden den Kontext und schwächen die Sicherheit. Zielen Sie hoch: **≥2 voll ausgebaute Mac Studios oder ein vergleichbares GPU-Rig (~30.000 $+)**. Eine einzelne **24-GB**-GPU funktioniert nur für leichtere Prompts mit höherer Latenz. Verwenden Sie die **größte / vollwertige Modellvariante, die Sie betreiben können**; stark quantisierte oder „kleine“ Checkpoints erhöhen das Prompt-Injection-Risiko (siehe [Sicherheit](/de/gateway/security)). -Wenn Sie die lokale Einrichtung mit dem geringsten Aufwand möchten, beginnen Sie mit [LM Studio](/de/providers/lmstudio) oder [Ollama](/de/providers/ollama) und `openclaw onboard`. Diese Seite ist der meinungsstarke Leitfaden für höherwertige lokale Stacks und benutzerdefinierte OpenAI-kompatible lokale Server. +Wenn Sie das lokale Setup mit der geringsten Reibung wünschen, beginnen Sie mit [LM Studio](/de/providers/lmstudio) oder [Ollama](/de/providers/ollama) und `openclaw onboard`. Diese Seite ist der meinungsstarke Leitfaden für höherwertige lokale Stacks und benutzerdefinierte OpenAI-kompatible lokale Server. -**Benutzer von WSL2 + Ollama + NVIDIA/CUDA:** Der offizielle Ollama-Linux-Installer aktiviert einen systemd-Dienst mit `Restart=always`. Auf WSL2-GPU-Setups kann Autostart beim Booten das zuletzt verwendete Modell erneut laden und Host-Speicher belegen. Wenn Ihre WSL2-VM nach dem Aktivieren von Ollama wiederholt neu startet, siehe [WSL2-Absturzschleife](/de/providers/ollama#wsl2-crash-loop-repeated-reboots). +**WSL2 + Ollama + NVIDIA/CUDA-Benutzer:** Der offizielle Ollama-Linux-Installer aktiviert einen systemd-Dienst mit `Restart=always`. Bei WSL2-GPU-Setups kann der Autostart beim Booten das zuletzt verwendete Modell erneut laden und Host-Speicher belegen. Wenn Ihre WSL2-VM nach dem Aktivieren von Ollama wiederholt neu startet, siehe [WSL2-Absturzschleife](/de/providers/ollama#wsl2-crash-loop-repeated-reboots). ## Empfohlen: LM Studio + großes lokales Modell (Responses API) -Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum Beispiel einen vollwertigen Qwen-, DeepSeek- oder Llama-Build), aktivieren Sie den lokalen Server (Standard `http://127.0.0.1:1234`) und verwenden Sie Responses API, um Reasoning vom finalen Text zu trennen. +Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum Beispiel einen vollwertigen Qwen-, DeepSeek- oder Llama-Build), aktivieren Sie den lokalen Server (Standard `http://127.0.0.1:1234`) und verwenden Sie die Responses API, um Reasoning von finalem Text getrennt zu halten. ```json5 { @@ -66,13 +66,13 @@ Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum B - Installieren Sie LM Studio: [https://lmstudio.ai](https://lmstudio.ai) - Laden Sie in LM Studio den **größten verfügbaren Modell-Build** herunter (vermeiden Sie „kleine“/stark quantisierte Varianten), starten Sie den Server und bestätigen Sie, dass `http://127.0.0.1:1234/v1/models` ihn auflistet. - Ersetzen Sie `my-local-model` durch die tatsächliche Modell-ID, die in LM Studio angezeigt wird. -- Halten Sie das Modell geladen; Kaltladen erhöht die Startlatenz. -- Passen Sie `contextWindow`/`maxTokens` an, wenn Ihr LM-Studio-Build abweicht. -- Bleiben Sie für WhatsApp bei Responses API, damit nur finaler Text gesendet wird. +- Lassen Sie das Modell geladen; Kaltladen erhöht die Startlatenz. +- Passen Sie `contextWindow`/`maxTokens` an, falls Ihr LM-Studio-Build abweicht. +- Bleiben Sie für WhatsApp bei der Responses API, damit nur finaler Text gesendet wird. -Lassen Sie gehostete Modelle auch dann konfiguriert, wenn Sie lokal ausführen; verwenden Sie `models.mode: "merge"`, damit Fallbacks verfügbar bleiben. +Behalten Sie gehostete Modelle auch bei lokaler Ausführung konfiguriert; verwenden Sie `models.mode: "merge"`, damit Fallbacks verfügbar bleiben. -### Hybrid-Konfiguration: gehostet primär, lokal als Fallback +### Hybridkonfiguration: gehostetes Primärmodell, lokaler Fallback ```json5 { @@ -115,11 +115,11 @@ Lassen Sie gehostete Modelle auch dann konfiguriert, wenn Sie lokal ausführen; ### Lokal zuerst mit gehostetem Sicherheitsnetz -Vertauschen Sie die Reihenfolge von primärem Modell und Fallback; behalten Sie denselben Provider-Block und `models.mode: "merge"` bei, damit Sie auf Sonnet oder Opus zurückfallen können, wenn die lokale Maschine nicht verfügbar ist. +Tauschen Sie die Reihenfolge von Primärmodell und Fallbacks; behalten Sie denselben Provider-Block und `models.mode: "merge"` bei, damit Sie auf Sonnet oder Opus zurückfallen können, wenn die lokale Maschine nicht verfügbar ist. -### Regionales Hosting / Daten-Routing +### Regionales Hosting / Datenrouting -- Gehostete MiniMax-/Kimi-/GLM-Varianten gibt es auch auf OpenRouter mit regional gebundenen Endpunkten (z. B. in den USA gehostet). Wählen Sie dort die regionale Variante, um Traffic in Ihrer gewählten Gerichtsbarkeit zu halten, während Sie weiterhin `models.mode: "merge"` für Anthropic-/OpenAI-Fallbacks verwenden. +- Gehostete MiniMax-/Kimi-/GLM-Varianten gibt es auch auf OpenRouter mit regional festgelegten Endpunkten (z. B. in den USA gehostet). Wählen Sie dort die regionale Variante aus, um Traffic in Ihrer gewünschten Jurisdiktion zu halten, während Sie weiterhin `models.mode: "merge"` für Anthropic-/OpenAI-Fallbacks verwenden. - Nur lokal bleibt der stärkste Datenschutzpfad; gehostetes regionales Routing ist der Mittelweg, wenn Sie Provider-Funktionen benötigen, aber Kontrolle über den Datenfluss wünschen. ## Andere OpenAI-kompatible lokale Proxys @@ -162,67 +162,67 @@ Endpunkt und Ihre Modell-ID: } ``` -Wenn `api` bei einem benutzerdefinierten Provider mit `baseUrl` weggelassen wird, verwendet OpenClaw standardmäßig +Wenn `api` bei einem benutzerdefinierten Provider mit `baseUrl` ausgelassen wird, verwendet OpenClaw standardmäßig `openai-completions`. Loopback-Endpunkte wie `127.0.0.1` werden -automatisch als vertrauenswürdig behandelt; LAN-, Tailnet- und private DNS-Endpunkte benötigen weiterhin +automatisch vertraut; LAN-, Tailnet- und private DNS-Endpunkte benötigen weiterhin `request.allowPrivateNetwork: true`. Der Wert `models.providers..models[].id` ist Provider-lokal. Fügen Sie dort -nicht das Provider-Präfix ein. Ein MLX-Server, der mit -`mlx_lm.server --model mlx-community/Qwen3-30B-A3B-6bit` gestartet wurde, sollte zum Beispiel diese +nicht das Provider-Präfix ein. Zum Beispiel sollte ein MLX-Server, der mit +`mlx_lm.server --model mlx-community/Qwen3-30B-A3B-6bit` gestartet wurde, diese Katalog-ID und Modellreferenz verwenden: - `models.providers.mlx.models[].id: "mlx-community/Qwen3-30B-A3B-6bit"` - `agents.defaults.model.primary: "mlx/mlx-community/Qwen3-30B-A3B-6bit"` Setzen Sie `input: ["text", "image"]` bei lokalen oder proxied Vision-Modellen, damit Bildanhänge -in Agent-Turns injiziert werden. Interaktives Onboarding für benutzerdefinierte Provider -erkennt gängige Vision-Modell-IDs und fragt nur bei unbekannten Namen nach. -Nicht-interaktives Onboarding verwendet dieselbe Erkennung; nutzen Sie `--custom-image-input` +in Agent-Turns eingefügt werden. Interaktives Onboarding für benutzerdefinierte Provider +erkennt häufige Vision-Modell-IDs und fragt nur nach unbekannten Namen. +Nicht interaktives Onboarding verwendet dieselbe Erkennung; verwenden Sie `--custom-image-input` für unbekannte Vision-IDs oder `--custom-text-input`, wenn ein bekannt wirkendes Modell hinter Ihrem Endpunkt nur Text unterstützt. Behalten Sie `models.mode: "merge"` bei, damit gehostete Modelle als Fallbacks verfügbar bleiben. -Verwenden Sie `models.providers..timeoutSeconds` für langsame lokale oder entfernte Modellserver, +Verwenden Sie `models.providers..timeoutSeconds` für langsame lokale oder Remote-Modellserver, bevor Sie `agents.defaults.timeoutSeconds` erhöhen. Das Provider-Timeout -gilt nur für Modell-HTTP-Anfragen, einschließlich Verbindungsaufbau, Headern, Body-Streaming -und dem gesamten geschützten Fetch-Abbruch. +gilt nur für Modell-HTTP-Anfragen, einschließlich Verbindungsaufbau, Header, Body-Streaming +und dem gesamten guarded-fetch-Abbruch. -Für benutzerdefinierte OpenAI-kompatible Provider wird das Speichern einer nicht geheimen lokalen Markierung wie `apiKey: "ollama-local"` akzeptiert, wenn `baseUrl` auf Loopback, ein privates LAN, `.local` oder einen bloßen Hostnamen auflöst. OpenClaw behandelt sie als gültige lokale Anmeldedaten, anstatt einen fehlenden Schlüssel zu melden. Verwenden Sie einen echten Wert für jeden Provider, der einen öffentlichen Hostnamen akzeptiert. +Für benutzerdefinierte OpenAI-kompatible Provider wird das Speichern einer nicht geheimen lokalen Markierung wie `apiKey: "ollama-local"` akzeptiert, wenn `baseUrl` zu Loopback, einem privaten LAN, `.local` oder einem bloßen Hostnamen aufgelöst wird. OpenClaw behandelt sie als gültige lokale Anmeldedaten, statt einen fehlenden Schlüssel zu melden. Verwenden Sie einen echten Wert für jeden Provider, der einen öffentlichen Hostnamen akzeptiert. Verhaltenshinweis für lokale/proxied `/v1`-Backends: -- OpenClaw behandelt diese als Proxy-artige OpenAI-kompatible Routen, nicht als native +- OpenClaw behandelt diese als proxyartige OpenAI-kompatible Routen, nicht als native OpenAI-Endpunkte -- natives OpenAI-spezifisches Request-Shaping gilt hier nicht: kein - `service_tier`, kein Responses-`store`, kein OpenAI-Reasoning-Kompatibilitäts-Payload- - Shaping und keine Prompt-Cache-Hinweise -- versteckte OpenClaw-Attribution-Header (`originator`, `version`, `User-Agent`) - werden bei diesen benutzerdefinierten Proxy-URLs nicht injiziert +- native rein OpenAI-spezifische Anfrageformung gilt hier nicht: kein + `service_tier`, kein Responses-`store`, keine OpenAI-Reasoning-Kompatibilitäts-Payload- + Formung und keine Prompt-Cache-Hinweise +- versteckte OpenClaw-Attributionsheader (`originator`, `version`, `User-Agent`) + werden bei diesen benutzerdefinierten Proxy-URLs nicht eingefügt Kompatibilitätshinweise für strengere OpenAI-kompatible Backends: -- Einige Server akzeptieren bei Chat Completions nur stringbasierten `messages[].content`, keine +- Einige Server akzeptieren bei Chat Completions nur Zeichenketten in `messages[].content`, keine strukturierten Content-Part-Arrays. Setzen Sie `models.providers..models[].compat.requiresStringContent: true` für diese Endpunkte. -- Einige lokale Modelle geben eigenständige, geklammerte Tool-Anfragen als Text aus, etwa - `[tool_name]`, gefolgt von JSON und `[END_TOOL_REQUEST]`. OpenClaw wandelt +- Einige lokale Modelle geben eigenständige geklammerte Tool-Anfragen als Text aus, etwa + `[tool_name]` gefolgt von JSON und `[END_TOOL_REQUEST]`. OpenClaw wandelt diese nur dann in echte Tool-Aufrufe um, wenn der Name exakt mit einem registrierten - Tool für den Turn übereinstimmt; andernfalls wird der Block als nicht unterstützter Text behandelt und - aus benutzersichtbaren Antworten ausgeblendet. -- Wenn ein Modell JSON, XML oder ReAct-artigen Text ausgibt, der wie ein Tool-Aufruf aussieht, - der Provider aber keinen strukturierten Aufruf ausgegeben hat, belässt OpenClaw ihn als + Tool für den Turn übereinstimmt; andernfalls wird der Block als nicht unterstützter Text behandelt und vor + benutzersichtbaren Antworten verborgen. +- Wenn ein Modell JSON, XML oder Text im ReAct-Stil ausgibt, der wie ein Tool-Aufruf aussieht, + der Provider aber keine strukturierte Invocation ausgegeben hat, belässt OpenClaw ihn als Text und protokolliert eine Warnung mit Run-ID, Provider/Modell, erkanntem Muster und - Tool-Namen, sofern verfügbar. Behandeln Sie das als Tool-Call- - Inkompatibilität von Provider/Modell, nicht als abgeschlossenen Tool-Lauf. -- Wenn Tools als Assistententext erscheinen, anstatt ausgeführt zu werden, zum Beispiel rohes JSON, + Tool-Namen, sofern verfügbar. Behandeln Sie das als Tool-Call-Inkompatibilität des + Providers/Modells, nicht als abgeschlossenen Tool-Lauf. +- Wenn Tools als Assistant-Text erscheinen, statt ausgeführt zu werden, zum Beispiel rohes JSON, XML, ReAct-Syntax oder ein leeres `tool_calls`-Array in der Provider-Antwort, - prüfen Sie zuerst, ob der Server ein Chat-Template/einen Parser mit Tool-Call-Fähigkeit verwendet. Für - OpenAI-kompatible Chat-Completions-Backends, deren Parser nur funktioniert, wenn Tool- - Nutzung erzwungen wird, setzen Sie eine Request-Überschreibung pro Modell, anstatt sich auf Text- + prüfen Sie zuerst, ob der Server ein chat template/einen Parser verwendet, der Tool-Aufrufe unterstützt. Für + OpenAI-kompatible Chat-Completions-Backends, deren Parser nur funktioniert, wenn Tool-Nutzung + erzwungen wird, setzen Sie eine Anfrageüberschreibung pro Modell, statt sich auf Text- Parsing zu verlassen: ```json5 @@ -243,8 +243,8 @@ Kompatibilitätshinweise für strengere OpenAI-kompatible Backends: } ``` - Verwenden Sie dies nur für Modelle/Sitzungen, bei denen jeder normale Turn ein Tool aufrufen sollte. - Es überschreibt den Standard-Proxy-Wert von OpenClaw für `tool_choice: "auto"`. + Verwenden Sie dies nur für Modelle/Sitzungen, bei denen jeder normale Turn ein Tool aufrufen soll. + Es überschreibt OpenClaws Standard-Proxywert `tool_choice: "auto"`. Ersetzen Sie `local/my-local-model` durch die exakte Provider/Modell-Referenz, die von `openclaw models list` angezeigt wird. @@ -252,8 +252,8 @@ Kompatibilitätshinweise für strengere OpenAI-kompatible Backends: openclaw config set agents.defaults.models '{"local/my-local-model":{"params":{"extra_body":{"tool_choice":"required"}}}}' --strict-json --merge ``` -- Wenn ein benutzerdefiniertes OpenAI-kompatibles Modell OpenAI-Reasoning-Aufwände über - das integrierte Profil hinaus akzeptiert, deklarieren Sie sie im Modell-Kompatibilitätsblock. Das Hinzufügen von `"xhigh"` +- Wenn ein benutzerdefiniertes OpenAI-kompatibles Modell OpenAI-Reasoning-Efforts über + das integrierte Profil hinaus akzeptiert, deklarieren Sie diese im Modell-Compat-Block. Das Hinzufügen von `"xhigh"` hier sorgt dafür, dass `/think xhigh`, Sitzungsauswahlen, Gateway-Validierung und `llm-task`- Validierung die Stufe für diese konfigurierte Provider/Modell-Referenz verfügbar machen: @@ -286,62 +286,62 @@ Kompatibilitätshinweise für strengere OpenAI-kompatible Backends: } ``` -- Einige kleinere oder strengere lokale Backends sind mit der vollständigen - Prompt-Form der OpenClaw-Agent-Runtime instabil, besonders wenn Tool-Schemas enthalten sind. Prüfen Sie zuerst - den Provider-Pfad mit dem schlanken lokalen Probe: +- Einige kleinere oder strengere lokale Backends sind mit OpenClaws vollständiger + Agent-Runtime-Promptform instabil, insbesondere wenn Tool-Schemas enthalten sind. Prüfen Sie zuerst + den Provider-Pfad mit dem schlanken lokalen Testlauf: ```bash openclaw infer model run --local --model --prompt "Reply with exactly: pong" --json ``` - Um die Gateway-Route ohne die vollständige Agent-Prompt-Form zu prüfen, verwenden Sie stattdessen den - Gateway-Modell-Probe: + Um die Gateway-Route ohne die vollständige Agent-Promptform zu prüfen, verwenden Sie stattdessen + den Gateway-Modelltest: ```bash openclaw infer model run --gateway --model --prompt "Reply with exactly: pong" --json ``` - Sowohl lokale als auch Gateway-Modell-Probes senden nur den bereitgestellten Prompt. Der - Gateway-Probe validiert weiterhin Gateway-Routing, Authentifizierung und Provider-Auswahl, - überspringt jedoch absichtlich vorherige Sitzungstranskripte, AGENTS/Bootstrap-Kontext, + Sowohl lokale als auch Gateway-Modelltests senden nur den angegebenen Prompt. Der + Gateway-Test validiert weiterhin Gateway-Routing, Authentifizierung und Provider-Auswahl, + überspringt jedoch absichtlich vorheriges Sitzungstranskript, AGENTS/Bootstrap-Kontext, Context-Engine-Assembly, Tools und gebündelte MCP-Server. - Wenn das gelingt, normale OpenClaw-Agent-Turns aber fehlschlagen, versuchen Sie zuerst - `agents.defaults.experimental.localModelLean: true`, um schwergewichtige + Wenn dies erfolgreich ist, normale OpenClaw-Agent-Runden aber fehlschlagen, versuchen Sie zuerst + `agents.defaults.experimental.localModelLean: true`, um umfangreiche Standard-Tools wie `browser`, `cron` und `message` wegzulassen; dies ist ein experimentelles - Flag, keine stabile Einstellung für den Standardmodus. Siehe - [Experimentelle Funktionen](/de/concepts/experimental-features). Wenn das weiterhin fehlschlägt, versuchen Sie + Flag, keine stabile Einstellung für einen Standardmodus. Siehe + [Experimentelle Funktionen](/de/concepts/experimental-features). Falls dies weiterhin fehlschlägt, versuchen Sie `models.providers..models[].compat.supportsTools: false`. - Wenn das Backend weiterhin nur bei größeren OpenClaw-Läufen fehlschlägt, ist das verbleibende Problem - in der Regel die Kapazität des Upstream-Modells/Servers oder ein Backend-Fehler, nicht die - Transportschicht von OpenClaw. + in der Regel die Kapazität des Upstream-Modells bzw. -Servers oder ein Backend-Fehler, nicht OpenClaws + Transportschicht. -## Fehlerbehebung +## Problembehebung - Kann der Gateway den Proxy erreichen? `curl http://127.0.0.1:1234/v1/models`. -- LM-Studio-Modell entladen? Neu laden; ein Kaltstart ist eine häufige Ursache für „Hängenbleiben“. -- Meldet der lokale Server `terminated`, `ECONNRESET` oder schließt er den Stream mitten im Turn? - OpenClaw zeichnet in der Diagnose ein niedrig kardinales `model.call.error.failureKind` sowie den - RSS-/Heap-Snapshot des OpenClaw-Prozesses auf. Bei Speicherdruck in LM Studio/Ollama - gleichen Sie diesen Zeitstempel mit dem Serverprotokoll oder dem macOS-Absturz- / +- LM Studio-Modell entladen? Neu laden; ein Kaltstart ist eine häufige Ursache für „Hängenbleiben“. +- Der lokale Server meldet `terminated`, `ECONNRESET` oder schließt den Stream mitten in der Runde? + OpenClaw zeichnet in der Diagnose ein `model.call.error.failureKind` mit niedriger Kardinalität sowie einen + RSS-/Heap-Snapshot des OpenClaw-Prozesses auf. Bei Speicherdruck durch LM Studio/Ollama + gleichen Sie diesen Zeitstempel mit dem Serverprotokoll oder dem macOS-Absturz-/ Jetsam-Protokoll ab, um zu bestätigen, ob der Modellserver beendet wurde. -- OpenClaw warnt, wenn das erkannte Kontextfenster unter **32k** liegt, und blockiert unter **16k**. Wenn diese Vorabprüfung ausgelöst wird, erhöhen Sie das Kontextlimit des Servers/Modells oder wählen Sie ein größeres Modell. -- Kontextfehler? Senken Sie `contextWindow` oder erhöhen Sie Ihr Serverlimit. +- OpenClaw leitet Schwellenwerte für die Vorabprüfung des Kontextfensters aus dem erkannten Modellfenster ab, oder aus dem unbegrenzten Modellfenster, wenn `agents.defaults.contextTokens` das effektive Fenster verringert. Unter 20 % wird mit einer Untergrenze von **8k** gewarnt. Harte Sperren verwenden den Schwellenwert von 10 % mit einer Untergrenze von **4k**, begrenzt auf das effektive Kontextfenster, sodass übergroße Modellmetadaten eine ansonsten gültige Benutzerbegrenzung nicht ablehnen können. Wenn Sie diese Vorabprüfung auslösen, erhöhen Sie das Kontextlimit des Servers/Modells oder wählen Sie ein größeres Modell. +- Kontextfehler? Verringern Sie `contextWindow` oder erhöhen Sie Ihr Serverlimit. - OpenAI-kompatibler Server gibt `messages[].content ... expected a string` zurück? - Fügen Sie `compat.requiresStringContent: true` für diesen Modelleintrag hinzu. + Fügen Sie `compat.requiresStringContent: true` zu diesem Modelleintag hinzu. - Direkte kleine `/v1/chat/completions`-Aufrufe funktionieren, aber `openclaw infer model run --local` - schlägt bei Gemma oder einem anderen lokalen Modell fehl? Prüfen Sie zuerst die Provider-URL, die Modellreferenz, den Auth- - Marker und die Serverprotokolle; lokales `model run` enthält keine Agent-Tools. - Wenn lokales `model run` gelingt, größere Agent-Turns aber fehlschlagen, reduzieren Sie die - Tool-Oberfläche des Agents mit `localModelLean` oder `compat.supportsTools: false`. + schlägt bei Gemma oder einem anderen lokalen Modell fehl? Prüfen Sie zuerst die Provider-URL, Modellreferenz, Authentifizierungs- + Markierung und Serverprotokolle; lokales `model run` enthält keine Agent-Tools. + Wenn lokales `model run` erfolgreich ist, größere Agent-Runden aber fehlschlagen, reduzieren Sie die + Tool-Oberfläche des Agenten mit `localModelLean` oder `compat.supportsTools: false`. - Tool-Aufrufe erscheinen als roher JSON-/XML-/ReAct-Text, oder der Provider gibt ein leeres `tool_calls`-Array zurück? Fügen Sie keinen Proxy hinzu, der Assistant- - Text blind in Tool-Ausführung umwandelt. Beheben Sie zuerst die Chat-Vorlage/den Parser des Servers. Wenn das + Text blind in Tool-Ausführung umwandelt. Korrigieren Sie zuerst das Chat-Template/den Parser des Servers. Wenn das Modell nur funktioniert, wenn Tool-Nutzung erzwungen wird, fügen Sie die obige modellbezogene - Überschreibung `params.extra_body.tool_choice: "required"` hinzu und verwenden Sie diesen Modelleintrag - nur für Sitzungen, in denen bei jedem Turn ein Tool-Aufruf erwartet wird. -- Sicherheit: Lokale Modelle überspringen Provider-seitige Filter; halten Sie Agents eng begrenzt und Compaction aktiviert, um den Wirkungsbereich von Prompt Injection zu begrenzen. + Überschreibung `params.extra_body.tool_choice: "required"` hinzu und verwenden Sie diesen Modelleintag + nur für Sitzungen, in denen in jeder Runde ein Tool-Aufruf erwartet wird. +- Sicherheit: Lokale Modelle überspringen Provider-seitige Filter; halten Sie Agenten eng begrenzt und Compaction aktiviert, um den Wirkungsbereich von Prompt Injection zu begrenzen. ## Verwandte Themen diff --git a/docs/de/plugins/community.md b/docs/de/plugins/community.md index e0660cddb..f04fcace7 100644 --- a/docs/de/plugins/community.md +++ b/docs/de/plugins/community.md @@ -1,27 +1,28 @@ --- read_when: - Sie möchten OpenClaw-Plugins von Drittanbietern finden - - Sie möchten Ihr eigenes Plugin veröffentlichen oder auflisten -summary: 'Von der Community gepflegte OpenClaw-Plugins: durchsuchen, installieren und Ihre eigenen einreichen' + - Sie möchten Ihr eigenes Plugin veröffentlichen oder eintragen +summary: 'Von der Community gepflegte OpenClaw-Plugins: durchsuchen, installieren und eigene einreichen' title: Community-Plugins x-i18n: - generated_at: "2026-04-30T07:04:45Z" + generated_at: "2026-04-30T09:34:48Z" model: gpt-5.5 provider: openai - source_hash: a54130fefc55042d53270e5f7f4b49a4aad715570743013fbfe06b0e2fa067d0 + source_hash: 9685aaf141b739a2a745a6184201ac86689e4284bec6eb068ffbd0d53fb4ecf1 source_path: plugins/community.md workflow: 16 --- Community-Plugins sind Drittanbieterpakete, die OpenClaw um neue Kanäle, Tools, Provider oder andere Funktionen erweitern. Sie werden von der -Community erstellt und gepflegt, üblicherweise auf [ClawHub](/de/tools/clawhub) -veröffentlicht und lassen sich mit einem einzigen Befehl installieren. npm bleibt -ein unterstützter Fallback für Pakete, die noch nicht zu ClawHub gewechselt sind. +Community entwickelt und gepflegt, in der Regel auf [ClawHub](/de/tools/clawhub) +veröffentlicht und können mit einem einzigen Befehl installiert werden. npm +bleibt ein unterstützter Fallback für Pakete, die noch nicht zu ClawHub +umgezogen sind. -ClawHub ist die maßgebliche Oberfläche zum Auffinden von Community-Plugins. -Öffnen Sie keine rein dokumentationsbezogenen PRs, nur um Ihr Plugin hier -auffindbar zu machen; veröffentlichen Sie es stattdessen auf ClawHub. +ClawHub ist die maßgebliche Oberfläche zum Entdecken von Community-Plugins. Öffnen +Sie keine reinen Dokumentations-PRs, nur um Ihr Plugin hier für bessere +Auffindbarkeit hinzuzufügen; veröffentlichen Sie es stattdessen auf ClawHub. ```bash openclaw plugins install @@ -29,17 +30,16 @@ openclaw plugins install OpenClaw prüft zuerst ClawHub und fällt automatisch auf npm zurück. -## Aufgeführte Plugins +## Aufgelistete Plugins ### Apify -Scrapen Sie Daten von beliebigen Websites mit mehr als 20.000 vorgefertigten -Scrapern. Lassen Sie Ihren Agent Daten aus Instagram, Facebook, TikTok, YouTube, -Google Maps, Google Search, E-Commerce-Websites und mehr extrahieren — einfach -per Anfrage. +Extrahieren Sie Daten von jeder Website mit über 20.000 vorgefertigten Scrapern. Lassen Sie Ihren Agent +Daten aus Instagram, Facebook, TikTok, YouTube, Google Maps, Google +Search, E-Commerce-Websites und mehr extrahieren — einfach durch Nachfragen. - **npm:** `@apify/apify-openclaw-plugin` -- **Repo:** [github.com/apify/apify-openclaw-plugin](https://github.com/apify/apify-openclaw-plugin) +- **Repository:** [github.com/apify/apify-openclaw-plugin](https://github.com/apify/apify-openclaw-plugin) ```bash openclaw plugins install @apify/apify-openclaw-plugin @@ -47,13 +47,12 @@ openclaw plugins install @apify/apify-openclaw-plugin ### Codex App Server Bridge -Unabhängige OpenClaw-Bridge für Unterhaltungen mit Codex App Server. Binden Sie -einen Chat an einen Codex-Thread, kommunizieren Sie per Klartext damit und -steuern Sie ihn mit chat-nativen Befehlen für Fortsetzen, Planung, Review, -Modellauswahl, Compaction und mehr. +Unabhängige OpenClaw-Bridge für Codex App Server-Konversationen. Binden Sie einen Chat an +einen Codex-Thread, kommunizieren Sie mit einfachem Text und steuern Sie ihn mit chat-nativen +Befehlen für Fortsetzen, Planung, Review, Modellauswahl, Compaction und mehr. - **npm:** `openclaw-codex-app-server` -- **Repo:** [github.com/pwrdrvr/openclaw-codex-app-server](https://github.com/pwrdrvr/openclaw-codex-app-server) +- **Repository:** [github.com/pwrdrvr/openclaw-codex-app-server](https://github.com/pwrdrvr/openclaw-codex-app-server) ```bash openclaw plugins install openclaw-codex-app-server @@ -61,11 +60,11 @@ openclaw plugins install openclaw-codex-app-server ### DingTalk -Enterprise-Robot-Integration im Stream-Modus. Unterstützt Text-, Bild- und +Integration von Enterprise-Robotern im Stream-Modus. Unterstützt Text-, Bild- und Dateinachrichten über jeden DingTalk-Client. - **npm:** `@largezhou/ddingtalk` -- **Repo:** [github.com/largezhou/openclaw-dingtalk](https://github.com/largezhou/openclaw-dingtalk) +- **Repository:** [github.com/largezhou/openclaw-dingtalk](https://github.com/largezhou/openclaw-dingtalk) ```bash openclaw plugins install @largezhou/ddingtalk @@ -73,12 +72,12 @@ openclaw plugins install @largezhou/ddingtalk ### Lossless Claw (LCM) -Lossless-Context-Management-Plugin für OpenClaw. DAG-basierte -Unterhaltungszusammenfassung mit inkrementeller Compaction — bewahrt die volle -Kontexttreue und reduziert gleichzeitig die Token-Nutzung. +Lossless-Context-Management-Plugin für OpenClaw. DAG-basierte Zusammenfassung von +Konversationen mit inkrementeller Compaction — bewahrt die vollständige Kontexttreue +und reduziert gleichzeitig die Token-Nutzung. - **npm:** `@martian-engineering/lossless-claw` -- **Repo:** [github.com/Martian-Engineering/lossless-claw](https://github.com/Martian-Engineering/lossless-claw) +- **Repository:** [github.com/Martian-Engineering/lossless-claw](https://github.com/Martian-Engineering/lossless-claw) ```bash openclaw plugins install @martian-engineering/lossless-claw @@ -86,11 +85,11 @@ openclaw plugins install @martian-engineering/lossless-claw ### Opik -Offizielles Plugin, das Agent-Traces nach Opik exportiert. Überwachen Sie -Agent-Verhalten, Kosten, Tokens, Fehler und mehr. +Offizielles Plugin, das Agent-Traces nach Opik exportiert. Überwachen Sie Agent-Verhalten, +Kosten, Tokens, Fehler und mehr. - **npm:** `@opik/opik-openclaw` -- **Repo:** [github.com/comet-ml/opik-openclaw](https://github.com/comet-ml/opik-openclaw) +- **Repository:** [github.com/comet-ml/opik-openclaw](https://github.com/comet-ml/opik-openclaw) ```bash openclaw plugins install @opik/opik-openclaw @@ -98,13 +97,12 @@ openclaw plugins install @opik/opik-openclaw ### Prometheus Avatar -Geben Sie Ihrem OpenClaw-Agent einen Live2D-Avatar mit Echtzeit-Lippensynchronität, -Emotionsausdrücken und Text-to-Speech. Enthält Creator-Tools für -KI-Asset-Generierung und Ein-Klick-Bereitstellung im Prometheus Marketplace. -Derzeit in Alpha. +Geben Sie Ihrem OpenClaw-Agent einen Live2D-Avatar mit Echtzeit-Lippensynchronisation, +Emotionsausdrücken und Text-to-Speech. Enthält Creator-Tools für KI-Asset-Generierung +und Ein-Klick-Deployment in den Prometheus Marketplace. Derzeit in Alpha. - **npm:** `@prometheusavatar/openclaw-plugin` -- **Repo:** [github.com/myths-labs/prometheus-avatar](https://github.com/myths-labs/prometheus-avatar) +- **Repository:** [github.com/myths-labs/prometheus-avatar](https://github.com/myths-labs/prometheus-avatar) ```bash openclaw plugins install @prometheusavatar/openclaw-plugin @@ -112,17 +110,16 @@ openclaw plugins install @prometheusavatar/openclaw-plugin ### QQbot -Verbinden Sie OpenClaw über die QQ Bot API mit QQ. Unterstützt private Chats, -Gruppenerwähnungen, Kanalnachrichten und Rich Media einschließlich Sprache, -Bildern, Videos und Dateien. +Verbinden Sie OpenClaw über die QQ Bot API mit QQ. Unterstützt private Chats, Gruppen- +Erwähnungen, Kanalnachrichten und Rich Media einschließlich Sprache, Bilder, Videos +und Dateien. -Aktuelle OpenClaw-Versionen bündeln QQ Bot. Verwenden Sie für normale -Installationen die gebündelte Einrichtung unter [QQ Bot](/de/channels/qqbot); -installieren Sie dieses externe Plugin nur, wenn Sie bewusst das von Tencent -gepflegte eigenständige Paket verwenden möchten. +Aktuelle OpenClaw-Releases bündeln QQ Bot. Verwenden Sie die gebündelte Einrichtung in +[QQ Bot](/de/channels/qqbot) für normale Installationen; installieren Sie dieses externe Plugin nur, +wenn Sie ausdrücklich das eigenständige, von Tencent gepflegte Paket verwenden möchten. - **npm:** `@tencent-connect/openclaw-qqbot` -- **Repo:** [github.com/tencent-connect/openclaw-qqbot](https://github.com/tencent-connect/openclaw-qqbot) +- **Repository:** [github.com/tencent-connect/openclaw-qqbot](https://github.com/tencent-connect/openclaw-qqbot) ```bash openclaw plugins install @tencent-connect/openclaw-qqbot @@ -130,14 +127,13 @@ openclaw plugins install @tencent-connect/openclaw-qqbot ### wecom -WeCom-Kanal-Plugin für OpenClaw vom Tencent WeCom-Team. Gestützt auf -persistente WeCom Bot WebSocket-Verbindungen unterstützt es Direktnachrichten -und Gruppenchats, Streaming-Antworten, proaktive Nachrichten, Bild- und -Dateiverarbeitung, Markdown-Formatierung, integrierte Zugriffskontrolle sowie -Dokument-, Meeting- und Messaging-Skills. +WeCom-Kanal-Plugin für OpenClaw vom Tencent WeCom-Team. Basierend auf +persistenten WeCom Bot-WebSocket-Verbindungen unterstützt es Direktnachrichten und Gruppen- +Chats, Streaming-Antworten, proaktives Messaging, Bild-/Dateiverarbeitung, Markdown- +Formatierung, integrierte Zugriffskontrolle sowie Dokument-/Meeting-/Messaging-Skills. - **npm:** `@wecom/wecom-openclaw-plugin` -- **Repo:** [github.com/WecomTeam/wecom-openclaw-plugin](https://github.com/WecomTeam/wecom-openclaw-plugin) +- **Repository:** [github.com/WecomTeam/wecom-openclaw-plugin](https://github.com/WecomTeam/wecom-openclaw-plugin) ```bash openclaw plugins install @wecom/wecom-openclaw-plugin @@ -145,14 +141,13 @@ openclaw plugins install @wecom/wecom-openclaw-plugin ### Yuanbao -Yuanbao-Kanal-Plugin für OpenClaw vom Tencent Yuanbao-Team. Gestützt auf -persistente WebSocket-Verbindungen unterstützt es Direktnachrichten und -Gruppenchats, Streaming-Antworten, proaktive Nachrichten, Bild-/Datei-/Audio-/ -Videoverarbeitung, Markdown-Formatierung, integrierte Zugriffskontrolle und -Slash-Command-Menüs. +Yuanbao-Kanal-Plugin für OpenClaw vom Tencent Yuanbao-Team. Basierend auf +persistenten WebSocket-Verbindungen unterstützt es Direktnachrichten und Gruppen-Chats, +Streaming-Antworten, proaktives Messaging, Bild-/Datei-/Audio-/Videoverarbeitung, +Markdown-Formatierung, integrierte Zugriffskontrolle und Slash-Command-Menüs. - **npm:** `openclaw-plugin-yuanbao` -- **Repo:** [github.com/yb-claw/openclaw-plugin-yuanbao](https://github.com/yb-claw/openclaw-plugin-yuanbao) +- **Repository:** [github.com/YuanbaoTeam/yuanbao-openclaw-plugin](https://github.com/YuanbaoTeam/yuanbao-openclaw-plugin) ```bash openclaw plugins install openclaw-plugin-yuanbao @@ -160,49 +155,46 @@ openclaw plugins install openclaw-plugin-yuanbao ## Ihr Plugin einreichen -Wir begrüßen Community-Plugins, die nützlich, dokumentiert und sicher zu -betreiben sind. +Wir begrüßen Community-Plugins, die nützlich, dokumentiert und sicher zu betreiben sind. Ihr Plugin muss über `openclaw plugins install \` installierbar sein. - Veröffentlichen Sie es auf [ClawHub](/de/tools/clawhub), sofern Sie nicht - ausdrücklich eine reine npm-Distribution benötigen. - Die vollständige Anleitung finden Sie unter [Plugins erstellen](/de/plugins/building-plugins). + Veröffentlichen Sie auf [ClawHub](/de/tools/clawhub), es sei denn, Sie benötigen ausdrücklich + eine reine npm-Distribution. + Siehe [Plugins erstellen](/de/plugins/building-plugins) für die vollständige Anleitung. - Der Quellcode muss sich in einem öffentlichen Repository mit - Einrichtungsdokumentation und Issue-Tracker befinden. + Der Quellcode muss in einem öffentlichen Repository mit Einrichtungsdokumentation und einem Issue- + Tracker liegen. - - Sie benötigen keinen Docs-PR, nur um Ihr Plugin auffindbar zu machen. - Veröffentlichen Sie es stattdessen auf ClawHub. + + Sie benötigen keinen Dokumentations-PR, nur um Ihr Plugin auffindbar zu machen. Veröffentlichen Sie es + stattdessen auf ClawHub. - Öffnen Sie einen Docs-PR nur, wenn die Quelldokumentation von OpenClaw eine - tatsächliche Inhaltsänderung benötigt, etwa zur Korrektur von - Installationshinweisen oder zum Hinzufügen repo-übergreifender Dokumentation, - die in den Hauptdokumentationssatz gehört. + Öffnen Sie einen Dokumentations-PR nur, wenn die Quelldokumentation von OpenClaw eine tatsächliche inhaltliche + Änderung benötigt, etwa zur Korrektur von Installationshinweisen oder zum Hinzufügen von Cross-Repo- + Dokumentation, die in die Hauptdokumentation gehört. -## Qualitätsanforderungen +## Qualitätsmaßstab -| Anforderung | Warum | -| ------------------------------ | ----------------------------------------------------- | +| Anforderung | Warum | +| ------------------------------ | ------------------------------------------------- | | Auf ClawHub oder npm veröffentlicht | Benutzer benötigen funktionierendes `openclaw plugins install` | -| Öffentliches GitHub-Repo | Quellcode-Review, Issue-Tracking, Transparenz | -| Einrichtungs- und Nutzungsdokumentation | Benutzer müssen wissen, wie sie es konfigurieren | +| Öffentliches GitHub-Repository | Quellcode-Review, Issue-Tracking, Transparenz | +| Einrichtungs- und Nutzungsdokumentation | Benutzer müssen wissen, wie es konfiguriert wird | | Aktive Wartung | Aktuelle Updates oder reaktionsschnelle Issue-Bearbeitung | -Wrapper mit geringem Aufwand, unklare Zuständigkeit oder ungepflegte Pakete -können abgelehnt werden. +Wrapper mit geringem Aufwand, unklare Zuständigkeit oder nicht gepflegte Pakete können abgelehnt werden. -## Verwandte Themen +## Verwandt - [Plugins installieren und konfigurieren](/de/tools/plugin) — wie Sie ein beliebiges Plugin installieren - [Plugins erstellen](/de/plugins/building-plugins) — erstellen Sie Ihr eigenes diff --git a/docs/de/tools/skills.md b/docs/de/tools/skills.md index c4e052a40..a8186e51c 100644 --- a/docs/de/tools/skills.md +++ b/docs/de/tools/skills.md @@ -1,54 +1,62 @@ --- read_when: - Skills hinzufügen oder ändern - - Skill-Gating, Allowlisten oder Laderegeln ändern + - Ändern von Skill-Gating, Allowlisten oder Laderegeln - Skill-Priorität und Snapshot-Verhalten verstehen sidebarTitle: Skills -summary: 'Skills: verwaltet vs. Arbeitsbereich, Gate-Regeln, Allowlists für Agenten und Konfigurationsanbindung' +summary: 'Skills: verwaltet vs. Workspace, Gating-Regeln, Agent-Allowlists und Konfigurationsanbindung' title: Skills x-i18n: - generated_at: "2026-04-30T07:19:34Z" + generated_at: "2026-04-30T09:34:57Z" model: gpt-5.5 provider: openai - source_hash: f744f5e961f872cae02aa0ed77e0bbba35e4715f5762ac45ce190b74b2fd8c5e + source_hash: d7dd17f52119bf0a0bb197025070abb68f7667a7d22c3d5fa6ef2f666110a45a source_path: tools/skills.md workflow: 16 --- -OpenClaw verwendet **[AgentSkills](https://agentskills.io)-kompatible** Skill-Ordner, um dem Agenten die Verwendung von Tools beizubringen. Jeder Skill ist ein Verzeichnis, das eine `SKILL.md` mit YAML-Frontmatter und Anweisungen enthält. OpenClaw lädt gebündelte Skills plus optionale lokale Überschreibungen und filtert sie zur Ladezeit basierend auf Umgebung, Konfiguration und vorhandenen Binärdateien. +OpenClaw verwendet **[AgentSkills](https://agentskills.io)-kompatible** Skill- +Ordner, um dem Agenten die Nutzung von Tools beizubringen. Jeder Skill ist ein Verzeichnis +mit einer `SKILL.md` mit YAML-Frontmatter und Anweisungen. OpenClaw +lädt gebündelte Skills plus optionale lokale Overrides und filtert sie zur +Ladezeit anhand von Umgebung, Konfiguration und vorhandenen Binärdateien. ## Speicherorte und Rangfolge OpenClaw lädt Skills aus diesen Quellen, **höchste Rangfolge zuerst**: -| # | Quelle | Pfad | -| --- | ----------------------- | -------------------------------- | -| 1 | Arbeitsbereich-Skills | `/skills` | -| 2 | Projekt-Agent-Skills | `/.agents/skills` | -| 3 | Persönliche Agent-Skills | `~/.agents/skills` | -| 4 | Verwaltete/lokale Skills | `~/.openclaw/skills` | -| 5 | Gebündelte Skills | mit der Installation ausgeliefert | -| 6 | Zusätzliche Skill-Ordner | `skills.load.extraDirs` (config) | +| # | Quelle | Pfad | +| --- | --------------------- | -------------------------------- | +| 1 | Workspace-Skills | `/skills` | +| 2 | Projekt-Agent-Skills | `/.agents/skills` | +| 3 | Persönliche Agent-Skills | `~/.agents/skills` | +| 4 | Verwaltete/lokale Skills | `~/.openclaw/skills` | +| 5 | Gebündelte Skills | mit der Installation ausgeliefert | +| 6 | Zusätzliche Skill-Ordner | `skills.load.extraDirs` (Konfiguration) | -Wenn ein Skill-Name in Konflikt steht, gewinnt die Quelle mit der höchsten Rangfolge. +Wenn ein Skill-Name kollidiert, gewinnt die Quelle mit der höchsten Rangfolge. -## Agent-spezifische vs. geteilte Skills +## Pro-Agent- vs. gemeinsame Skills -In **Multi-Agent**-Setups hat jeder Agent seinen eigenen Arbeitsbereich: +In **Multi-Agent**-Setups hat jeder Agent seinen eigenen Workspace: -| Geltungsbereich | Pfad | Sichtbar für | -| ---------------------- | ------------------------------------------- | ------------------------------------ | -| Agent-spezifisch | `/skills` | Nur diesen Agenten | -| Projekt-Agent | `/.agents/skills` | Nur den Agenten dieses Arbeitsbereichs | -| Persönlicher Agent | `~/.agents/skills` | Alle Agenten auf dieser Maschine | -| Gemeinsam verwaltet/lokal | `~/.openclaw/skills` | Alle Agenten auf dieser Maschine | -| Gemeinsame Zusatzverzeichnisse | `skills.load.extraDirs` (niedrigste Rangfolge) | Alle Agenten auf dieser Maschine | +| Geltungsbereich | Pfad | Sichtbar für | +| -------------------- | ------------------------------------------- | --------------------------- | +| Pro Agent | `/skills` | Nur diesen Agenten | +| Projekt-Agent | `/.agents/skills` | Nur den Agenten dieses Workspace | +| Persönlicher Agent | `~/.agents/skills` | Alle Agenten auf diesem Rechner | +| Gemeinsam verwaltet/lokal | `~/.openclaw/skills` | Alle Agenten auf diesem Rechner | +| Gemeinsame zusätzliche Verzeichnisse | `skills.load.extraDirs` (niedrigste Rangfolge) | Alle Agenten auf diesem Rechner | -Gleicher Name an mehreren Orten → die Quelle mit der höchsten Rangfolge gewinnt. Arbeitsbereich schlägt Projekt-Agent, schlägt persönlichen Agenten, schlägt verwaltet/lokal, schlägt gebündelt, schlägt Zusatzverzeichnisse. +Gleicher Name an mehreren Stellen → die Quelle mit der höchsten Rangfolge gewinnt. Workspace schlägt +Projekt-Agent, schlägt persönlichen Agent, schlägt verwaltet/lokal, schlägt gebündelt, +schlägt zusätzliche Verzeichnisse. -## Agent-Skill-Zulassungslisten +## Skill-Zulassungslisten für Agenten -Skill-**Speicherort** und Skill-**Sichtbarkeit** sind getrennte Steuerungen. Speicherort/Rangfolge entscheidet, welche Kopie eines gleichnamigen Skills gewinnt; Agent-Zulassungslisten entscheiden, welche Skills ein Agent tatsächlich verwenden kann. +Skill-**Speicherort** und Skill-**Sichtbarkeit** sind getrennte Steuerungen. +Speicherort/Rangfolge entscheidet, welche Kopie eines gleichnamigen Skills gewinnt; Agent- +Zulassungslisten entscheiden, welche Skills ein Agent tatsächlich nutzen kann. ```json5 { @@ -66,58 +74,93 @@ Skill-**Speicherort** und Skill-**Sichtbarkeit** sind getrennte Steuerungen. Spe ``` - - - Lassen Sie `agents.defaults.skills` weg, um Skills standardmäßig uneingeschränkt zuzulassen. + + - Lassen Sie `agents.defaults.skills` weg, um standardmäßig uneingeschränkte Skills zu erlauben. - Lassen Sie `agents.list[].skills` weg, um `agents.defaults.skills` zu erben. - - Setzen Sie `agents.list[].skills: []`, um keine Skills zuzulassen. - - Eine nicht leere Liste `agents.list[].skills` ist die **endgültige** Menge für diesen Agenten — sie wird nicht mit Defaults zusammengeführt. - - Die effektive Zulassungsliste gilt für Prompt-Erstellung, Skill-Slash-Befehl-Erkennung, Sandbox-Synchronisierung und Skill-Snapshots. - + - Setzen Sie `agents.list[].skills: []` für keine Skills. + - Eine nicht leere Liste `agents.list[].skills` ist die **endgültige** Menge für diesen + Agenten — sie wird nicht mit Defaults zusammengeführt. + - Die wirksame Zulassungsliste gilt für Prompt-Erstellung, Skill- + Slash-Command-Erkennung, Sandbox-Synchronisierung und Skill-Snapshots. ## Plugins und Skills -Plugins können eigene Skills mitliefern, indem sie `skills`-Verzeichnisse in `openclaw.plugin.json` auflisten (Pfade relativ zum Plugin-Stammverzeichnis). Plugin-Skills werden geladen, wenn das Plugin aktiviert ist. Dies ist der richtige Ort für Tool-spezifische Bedienungsanleitungen, die zu lang für die Tool-Beschreibung sind, aber verfügbar sein sollten, sobald das Plugin installiert ist — zum Beispiel liefert das Browser-Plugin einen `browser-automation`-Skill für mehrstufige Browsersteuerung mit. +Plugins können eigene Skills ausliefern, indem sie `skills`-Verzeichnisse in +`openclaw.plugin.json` auflisten (Pfade relativ zum Plugin-Stamm). Plugin-Skills +werden geladen, wenn das Plugin aktiviert ist. Dies ist der richtige Ort für tool-spezifische +Betriebsanleitungen, die für die Tool-Beschreibung zu lang sind, aber +verfügbar sein sollten, sobald das Plugin installiert ist — zum Beispiel liefert das Browser- +Plugin einen `browser-automation`-Skill für mehrstufige Browser-Steuerung mit. -Plugin-Skill-Verzeichnisse werden in denselben Pfad mit niedriger Rangfolge wie `skills.load.extraDirs` zusammengeführt, daher überschreibt ein gleichnamiger gebündelter, verwalteter, Agent- oder Arbeitsbereich-Skill sie. Sie können sie über `metadata.openclaw.requires.config` im Konfigurationseintrag des Plugins steuern. +Plugin-Skill-Verzeichnisse werden in denselben Pfad mit niedriger Rangfolge wie +`skills.load.extraDirs` zusammengeführt, sodass ein gleichnamiger gebündelter, verwalteter, Agent- oder +Workspace-Skill sie überschreibt. Sie können sie über +`metadata.openclaw.requires.config` im Konfigurationseintrag des Plugins steuern. -Siehe [Plugins](/de/tools/plugin) für Erkennung/Konfiguration und [Tools](/de/tools) für die Tool-Oberfläche, die diese Skills vermitteln. +Siehe [Plugins](/de/tools/plugin) für Erkennung/Konfiguration und [Tools](/de/tools) für +die Tool-Oberfläche, die diese Skills vermitteln. ## Skill Workshop -Das optionale, experimentelle **Skill Workshop**-Plugin kann Arbeitsbereich-Skills aus wiederverwendbaren Verfahren erstellen oder aktualisieren, die während der Agent-Arbeit beobachtet wurden. Es ist standardmäßig deaktiviert und muss explizit über `plugins.entries.skill-workshop` aktiviert werden. +Das optionale, experimentelle **Skill Workshop**-Plugin kann +Workspace-Skills aus wiederverwendbaren Verfahren erstellen oder aktualisieren, die während der Agent-Arbeit beobachtet wurden. Es +ist standardmäßig deaktiviert und muss explizit über +`plugins.entries.skill-workshop` aktiviert werden. -Skill Workshop schreibt nur nach `/skills`, scannt generierte Inhalte, unterstützt ausstehende Genehmigung oder automatische sichere Schreibvorgänge, stellt unsichere Vorschläge unter Quarantäne und aktualisiert den Skill-Snapshot nach erfolgreichen Schreibvorgängen, damit neue Skills ohne Gateway-Neustart verfügbar werden. +Skill Workshop schreibt nur nach `/skills`, scannt generierte +Inhalte, unterstützt ausstehende Freigabe oder automatische sichere Schreibvorgänge, quarantänisiert +unsichere Vorschläge und aktualisiert den Skill-Snapshot nach erfolgreichen +Schreibvorgängen, damit neue Skills ohne Gateway-Neustart verfügbar werden. -Verwenden Sie es für Korrekturen wie _„nächstes Mal GIF-Zuordnung prüfen“_ oder hart erarbeitete Arbeitsabläufe wie Medien-QA-Checklisten. Beginnen Sie mit ausstehender Genehmigung; verwenden Sie automatische Schreibvorgänge nur in vertrauenswürdigen Arbeitsbereichen, nachdem Sie die Vorschläge geprüft haben. Vollständige Anleitung: [Skill Workshop-Plugin](/de/plugins/skill-workshop). +Verwenden Sie es für Korrekturen wie _„nächstes Mal GIF-Zuordnung prüfen“_ oder +mühsam erarbeitete Workflows wie Checklisten für Medien-QA. Beginnen Sie mit ausstehender +Freigabe; verwenden Sie automatische Schreibvorgänge nur in vertrauenswürdigen Workspaces, nachdem Sie +die Vorschläge geprüft haben. Vollständige Anleitung: [Skill Workshop-Plugin](/de/plugins/skill-workshop). -## ClawHub (installieren und synchronisieren) +## ClawHub (Installation und Synchronisierung) -[ClawHub](https://clawhub.ai) ist die öffentliche Skills-Registry für OpenClaw. Verwenden Sie native `openclaw skills`-Befehle zum Entdecken/Installieren/Aktualisieren oder die separate `clawhub`-CLI für Publish-/Sync-Workflows. Vollständige Anleitung: [ClawHub](/de/tools/clawhub). +[ClawHub](https://clawhub.ai) ist die öffentliche Skills-Registry für OpenClaw. +Verwenden Sie native `openclaw skills`-Befehle für Erkennung/Installation/Aktualisierung oder die +separate `clawhub`-CLI für Veröffentlichungs-/Synchronisierungs-Workflows. Vollständige Anleitung: +[ClawHub](/de/tools/clawhub). -| Aktion | Befehl | -| ------------------------------------------- | ------------------------------------- | -| Einen Skill im Arbeitsbereich installieren | `openclaw skills install ` | -| Alle installierten Skills aktualisieren | `openclaw skills update --all` | -| Synchronisieren (scannen + Updates veröffentlichen) | `clawhub sync --all` | +| Aktion | Befehl | +| ---------------------------------- | -------------------------------------- | +| Einen Skill im Workspace installieren | `openclaw skills install ` | +| Alle installierten Skills aktualisieren | `openclaw skills update --all` | +| Synchronisieren (scannen + Updates veröffentlichen) | `clawhub sync --all` | -Das native `openclaw skills install` installiert in das `skills/`-Verzeichnis des aktiven Arbeitsbereichs. Die separate `clawhub`-CLI installiert ebenfalls in `./skills` unter Ihrem aktuellen Arbeitsverzeichnis (oder greift auf den konfigurierten OpenClaw-Arbeitsbereich zurück). OpenClaw greift dies in der nächsten Sitzung als `/skills` auf. +Native `openclaw skills install` installiert in das aktive Workspace- +Verzeichnis `skills/`. Die separate `clawhub`-CLI installiert ebenfalls nach +`./skills` unter Ihrem aktuellen Arbeitsverzeichnis (oder fällt auf den +konfigurierten OpenClaw-Workspace zurück). OpenClaw greift dies in der +nächsten Sitzung als `/skills` auf. +Konfigurierte Skill-Roots unterstützen außerdem eine Gruppierungsebene, etwa +`skills///SKILL.md`, sodass verwandte Drittanbieter-Skills +unter einem gemeinsamen Ordner gehalten werden können, ohne breit rekursiv zu scannen. -ClawHub-Skill-Seiten zeigen vor der Installation den neuesten Sicherheits-Scanstatus an, mit Scanner-Detailseiten für VirusTotal, ClawScan und statische Analyse. `openclaw skills install ` bleibt nur der Installationspfad; Herausgeber beheben falsch positive Ergebnisse über das ClawHub-Dashboard oder `clawhub skill rescan `. +ClawHub-Skill-Seiten zeigen vor der Installation den neuesten Sicherheits-Scanstatus +mit Scanner-Detailseiten für VirusTotal, ClawScan und statische Analyse. +`openclaw skills install ` bleibt ausschließlich der Installationspfad; Herausgeber +beheben False Positives über das ClawHub-Dashboard oder +`clawhub skill rescan `. ## Sicherheit -Behandeln Sie Drittanbieter-Skills als **nicht vertrauenswürdigen Code**. Lesen Sie sie, bevor Sie sie aktivieren. Bevorzugen Sie Sandbox-Ausführungen für nicht vertrauenswürdige Eingaben und riskante Tools. Siehe [Sandboxing](/de/gateway/sandboxing) für die agentseitigen Steuerungen. +Behandeln Sie Drittanbieter-Skills als **nicht vertrauenswürdigen Code**. Lesen Sie sie, bevor Sie sie aktivieren. +Bevorzugen Sie Sandbox-Läufe für nicht vertrauenswürdige Eingaben und riskante Tools. Siehe +[Sandboxing](/de/gateway/sandboxing) für die agentenseitigen Steuerungen. -- Die Skill-Erkennung in Arbeitsbereichs- und Zusatzverzeichnissen akzeptiert nur Skill-Stammverzeichnisse und `SKILL.md`-Dateien, deren aufgelöster Realpath innerhalb des konfigurierten Stammverzeichnisses bleibt. -- Gateway-gestützte Installationen von Skill-Abhängigkeiten (`skills.install`, Onboarding und die Skills-Einstellungsoberfläche) führen den eingebauten Dangerous-Code-Scanner aus, bevor Installationsmetadaten ausgeführt werden. `critical`-Funde blockieren standardmäßig, sofern der Aufrufer nicht ausdrücklich die gefährliche Überschreibung setzt; verdächtige Funde warnen weiterhin nur. -- `openclaw skills install ` ist anders — es lädt einen ClawHub-Skill-Ordner in den Arbeitsbereich herunter und verwendet nicht den oben beschriebenen Installationsmetadatenpfad. -- `skills.entries.*.env` und `skills.entries.*.apiKey` injizieren Geheimnisse in den **Host**-Prozess für diesen Agent-Durchlauf (nicht in die Sandbox). Halten Sie Geheimnisse aus Prompts und Logs heraus. +- Die Erkennung von Workspace- und Extra-Dir-Skills akzeptiert nur Skill-Roots und `SKILL.md`-Dateien, deren aufgelöster Realpath innerhalb des konfigurierten Roots bleibt. +- Gateway-gestützte Skill-Abhängigkeitsinstallationen (`skills.install`, Onboarding und die Skills-Einstellungen-UI) führen den eingebauten Scanner für gefährlichen Code aus, bevor Installer-Metadaten ausgeführt werden. `critical`-Befunde blockieren standardmäßig, sofern der Aufrufer nicht explizit den Dangerous-Override setzt; verdächtige Befunde warnen weiterhin nur. +- `openclaw skills install ` ist anders — es lädt einen ClawHub-Skill-Ordner in den Workspace herunter und verwendet nicht den oben genannten Installer-Metadatenpfad. +- `skills.entries.*.env` und `skills.entries.*.apiKey` injizieren Secrets in den **Host**-Prozess für diesen Agent-Turn (nicht in die Sandbox). Halten Sie Secrets aus Prompts und Logs heraus. -Für ein umfassenderes Bedrohungsmodell und Checklisten siehe [Sicherheit](/de/gateway/security). +Ein breiteres Bedrohungsmodell und Checklisten finden Sie unter [Sicherheit](/de/gateway/security). ## SKILL.md-Format @@ -130,27 +173,30 @@ description: Generate or edit images via a provider-backed image workflow --- ``` -OpenClaw folgt der AgentSkills-Spezifikation für Layout/Absicht. Der vom eingebetteten Agenten verwendete Parser unterstützt nur **einzeilige** Frontmatter-Schlüssel; `metadata` sollte ein **einzeiliges JSON-Objekt** sein. Verwenden Sie `{baseDir}` in Anweisungen, um auf den Pfad des Skill-Ordners zu verweisen. +OpenClaw folgt der AgentSkills-Spezifikation für Layout/Intent. Der vom +eingebetteten Agenten verwendete Parser unterstützt nur **einzeilige** Frontmatter-Schlüssel; +`metadata` sollte ein **einzeiliges JSON-Objekt** sein. Verwenden Sie `{baseDir}` in +Anweisungen, um auf den Pfad des Skill-Ordners zu verweisen. ### Optionale Frontmatter-Schlüssel - URL, die in der macOS-Skills-Oberfläche als „Website“ angezeigt wird. Wird auch über `metadata.openclaw.homepage` unterstützt. + URL, die in der macOS-Skills-UI als „Website“ angezeigt wird. Wird auch über `metadata.openclaw.homepage` unterstützt. - Wenn `true`, wird der Skill als Benutzer-Slash-Befehl bereitgestellt. + Wenn `true`, wird der Skill als Benutzer-Slash-Command verfügbar gemacht. - Wenn `true`, wird der Skill vom Modell-Prompt ausgeschlossen (weiterhin per Benutzeraufruf verfügbar). + Wenn `true`, wird der Skill aus dem Modell-Prompt ausgeschlossen (bleibt über Benutzeraufruf verfügbar). - Wenn auf `tool` gesetzt, umgeht der Slash-Befehl das Modell und dispatcht direkt an ein Tool. + Wenn auf `tool` gesetzt, umgeht der Slash-Command das Modell und wird direkt an ein Tool dispatcht. Tool-Name, der aufgerufen wird, wenn `command-dispatch: tool` gesetzt ist. - Für Tool-Dispatch wird die rohe Argumentzeichenfolge an das Tool weitergereicht (kein Core-Parsing). Das Tool wird mit `{ command: "", commandName: "", skillName: "" }` aufgerufen. + Für Tool-Dispatch wird die rohe Argumentzeichenfolge an das Tool weitergeleitet (kein Core-Parsing). Das Tool wird mit `{ command: "", commandName: "", skillName: "" }` aufgerufen. ## Gating (Ladezeitfilter) @@ -175,46 +221,50 @@ metadata: Felder unter `metadata.openclaw`: - Wenn `true`, den Skill immer einschließen (andere Gates überspringen). + Wenn `true`, den Skill immer einbeziehen (andere Gates überspringen). - Optionales Emoji, das von der macOS-Skills-Oberfläche verwendet wird. + Optionales Emoji, das von der macOS-Skills-UI verwendet wird. - Optionale URL, die in der macOS-Skills-Oberfläche als „Website“ angezeigt wird. + Optionale URL, die in der macOS-Skills-UI als „Website“ angezeigt wird. - Optionale Plattformliste. Wenn gesetzt, ist der Skill nur auf diesen Betriebssystemen zulässig. + Optionale Liste von Plattformen. Wenn gesetzt, ist der Skill nur auf diesen Betriebssystemen zulässig. - Jeder Eintrag muss auf `PATH` vorhanden sein. + Jede muss auf `PATH` vorhanden sein. - Mindestens ein Eintrag muss auf `PATH` vorhanden sein. + Mindestens eine muss auf `PATH` vorhanden sein. - Env-Variable muss vorhanden sein oder in der Konfiguration bereitgestellt werden. + Env-Var muss vorhanden sein oder in der Konfiguration bereitgestellt werden. Liste von `openclaw.json`-Pfaden, die truthy sein müssen. - Name der Env-Variable, die `skills.entries..apiKey` zugeordnet ist. + Name der Env-Var, die `skills.entries..apiKey` zugeordnet ist. - Optionale Installer-Spezifikationen, die von der macOS-Skills-Oberfläche verwendet werden (brew/node/go/uv/download). + Optionale Installer-Spezifikationen, die von der macOS-Skills-UI verwendet werden (brew/node/go/uv/download). -Wenn kein `metadata.openclaw` vorhanden ist, ist der Skill immer zulässig (sofern er nicht in der Konfiguration deaktiviert oder durch `skills.allowBundled` für gebündelte Skills blockiert ist). +Wenn kein `metadata.openclaw` vorhanden ist, ist der Skill immer zulässig (sofern er nicht +in der Konfiguration deaktiviert oder durch `skills.allowBundled` für gebündelte Skills blockiert ist). -Legacy-`metadata.clawdbot`-Blöcke werden weiterhin akzeptiert, wenn `metadata.openclaw` fehlt, sodass ältere installierte Skills ihre Abhängigkeits-Gates und Installer-Hinweise behalten. Neue und aktualisierte Skills sollten `metadata.openclaw` verwenden. +Legacy-`metadata.clawdbot`-Blöcke werden weiterhin akzeptiert, wenn +`metadata.openclaw` fehlt, damit ältere installierte Skills ihre +Abhängigkeits-Gates und Installer-Hinweise behalten. Neue und aktualisierte Skills sollten +`metadata.openclaw` verwenden. ### Sandbox-Hinweise - `requires.bins` wird zur Skill-Ladezeit auf dem **Host** geprüft. -- Wenn ein Agent in einer Sandbox ausgeführt wird, muss die Binärdatei auch **innerhalb des Containers** vorhanden sein. Installieren Sie sie über `agents.defaults.sandbox.docker.setupCommand` (oder ein benutzerdefiniertes Image). `setupCommand` wird einmal ausgeführt, nachdem der Container erstellt wurde. Paketinstallationen benötigen außerdem Netzwerk-Egress, ein beschreibbares Root-Dateisystem und einen Root-Benutzer in der Sandbox. +- Wenn ein Agent in einer Sandbox läuft, muss die Binärdatei auch **innerhalb des Containers** vorhanden sein. Installieren Sie sie über `agents.defaults.sandbox.docker.setupCommand` (oder ein benutzerdefiniertes Image). `setupCommand` wird einmal ausgeführt, nachdem der Container erstellt wurde. Paketinstallationen erfordern außerdem Netzwerk-Egress, ein beschreibbares Root-FS und einen Root-Benutzer in der Sandbox. - Beispiel: Der `summarize`-Skill (`skills/summarize/SKILL.md`) benötigt die `summarize`-CLI im Sandbox-Container, um dort ausgeführt zu werden. ### Installer-Spezifikationen @@ -246,17 +296,17 @@ metadata: - - Wenn mehrere Installer aufgeführt sind, wählt der Gateway eine einzige bevorzugte Option aus (brew, wenn verfügbar, andernfalls node). + - Wenn mehrere Installer aufgeführt sind, wählt der Gateway eine einzelne bevorzugte Option aus (brew, wenn verfügbar, andernfalls node). - Wenn alle Installer `download` sind, listet OpenClaw jeden Eintrag auf, damit Sie die verfügbaren Artefakte sehen können. - Installer-Spezifikationen können `os: ["darwin"|"linux"|"win32"]` enthalten, um Optionen nach Plattform zu filtern. - Node-Installationen berücksichtigen `skills.install.nodeManager` in `openclaw.json` (Standard: npm; Optionen: npm/pnpm/yarn/bun). Dies betrifft nur Skill-Installationen; die Gateway-Laufzeit sollte weiterhin Node sein — Bun wird für WhatsApp/Telegram nicht empfohlen. - - Die Gateway-gestützte Installer-Auswahl ist präferenzgesteuert: Wenn Installationsspezifikationen verschiedene Arten mischen, bevorzugt OpenClaw Homebrew, wenn `skills.install.preferBrew` aktiviert ist und `brew` existiert, dann `uv`, dann den konfigurierten Node-Manager, dann andere Fallbacks wie `go` oder `download`. + - Die Gateway-gestützte Installer-Auswahl ist präferenzgesteuert: Wenn Installationsspezifikationen verschiedene Arten mischen, bevorzugt OpenClaw Homebrew, wenn `skills.install.preferBrew` aktiviert ist und `brew` vorhanden ist, dann `uv`, dann den konfigurierten Node-Manager, dann andere Fallbacks wie `go` oder `download`. - Wenn jede Installationsspezifikation `download` ist, zeigt OpenClaw alle Download-Optionen an, statt sie auf einen bevorzugten Installer zu reduzieren. - **Go-Installationen:** Wenn `go` fehlt und `brew` verfügbar ist, installiert der Gateway zuerst Go über Homebrew und setzt `GOBIN` nach Möglichkeit auf Homebrews `bin`. - - **Download-Installationen:** `url` (erforderlich), `archive` (`tar.gz` | `tar.bz2` | `zip`), `extract` (Standard: automatisch, wenn ein Archiv erkannt wird), `stripComponents`, `targetDir` (Standard: `~/.openclaw/tools/`). + - **Download-Installationen:** `url` (erforderlich), `archive` (`tar.gz` | `tar.bz2` | `zip`), `extract` (Standard: automatisch, wenn Archiv erkannt), `stripComponents`, `targetDir` (Standard: `~/.openclaw/tools/`). @@ -264,7 +314,8 @@ metadata: ## Konfigurationsüberschreibungen Gebündelte und verwaltete Skills können unter `skills.entries` in -`~/.openclaw/openclaw.json` aktiviert/deaktiviert und mit Umgebungswerten versehen werden: +`~/.openclaw/openclaw.json` aktiviert/deaktiviert und mit Umgebungswerten +versehen werden: ```json5 { @@ -290,13 +341,13 @@ Gebündelte und verwaltete Skills können unter `skills.entries` in `false` deaktiviert den Skill, selbst wenn er gebündelt oder installiert ist. - Der gebündelte `coding-agent`-Skill ist Opt-in: Setzen Sie - `skills.entries.coding-agent.enabled: true`, bevor Sie ihn Agents verfügbar machen, + Der gebündelte Skill `coding-agent` ist opt-in: Setzen Sie + `skills.entries.coding-agent.enabled: true`, bevor Sie ihn Agents bereitstellen, und stellen Sie dann sicher, dass eines von `claude`, `codex`, `opencode` oder `pi` installiert und - für die eigene CLI authentifiziert ist. + für seine eigene CLI authentifiziert ist. - Komfortoption für Skills, die `metadata.openclaw.primaryEnv` deklarieren. Unterstützt Klartext oder SecretRef. + Komfortfunktion für Skills, die `metadata.openclaw.primaryEnv` deklarieren. Unterstützt Klartext oder SecretRef. Wird nur injiziert, wenn die Variable im Prozess noch nicht gesetzt ist. @@ -305,21 +356,21 @@ Gebündelte und verwaltete Skills können unter `skills.entries` in Optionaler Container für benutzerdefinierte Skill-spezifische Felder. Benutzerdefinierte Schlüssel müssen hier liegen. - Optionale Allowlist nur für **gebündelte** Skills. Wenn gesetzt, kommen nur gebündelte Skills in der Liste infrage (verwaltete/Workspace-Skills bleiben unberührt). + Optionale Allowlist nur für **gebündelte** Skills. Wenn gesetzt, sind nur gebündelte Skills in der Liste zulässig (verwaltete/Workspace-Skills sind nicht betroffen). -Wenn der Skill-Name Bindestriche enthält, setzen Sie den Schlüssel in Anführungszeichen (JSON5 erlaubt -Schlüssel in Anführungszeichen). Konfigurationsschlüssel entsprechen standardmäßig dem **Skill-Namen** — wenn ein Skill +Wenn der Skill-Name Bindestriche enthält, setzen Sie den Schlüssel in Anführungszeichen (JSON5 erlaubt zitierte +Schlüssel). Konfigurationsschlüssel entsprechen standardmäßig dem **Skill-Namen** — wenn ein Skill `metadata.openclaw.skillKey` definiert, verwenden Sie diesen Schlüssel unter `skills.entries`. -Für die standardmäßige Bilderzeugung/-bearbeitung innerhalb von OpenClaw verwenden Sie das zentrale -`image_generate`-Tool mit `agents.defaults.imageGenerationModel` statt +Für serienmäßige Bilderzeugung/-bearbeitung innerhalb von OpenClaw verwenden Sie das zentrale +Tool `image_generate` mit `agents.defaults.imageGenerationModel` statt eines gebündelten Skills. Die Skill-Beispiele hier sind für benutzerdefinierte oder Drittanbieter- -Workflows gedacht. Für native Bildanalyse verwenden Sie das `image`-Tool mit +Workflows gedacht. Für native Bildanalyse verwenden Sie das Tool `image` mit `agents.defaults.imageModel`. Wenn Sie `openai/*`, `google/*`, -`fal/*` oder ein anderes providerspezifisches Bildmodell auswählen, fügen Sie auch den -Auth-/API-Schlüssel dieses Providers hinzu. +`fal/*` oder ein anderes Provider-spezifisches Bildmodell auswählen, fügen Sie auch den +Authentifizierungs-/API-Schlüssel dieses Providers hinzu. ## Umgebungsinjektion @@ -328,39 +379,39 @@ Wenn ein Agent-Lauf startet, führt OpenClaw Folgendes aus: 1. Skill-Metadaten lesen. 2. `skills.entries..env` und `skills.entries..apiKey` auf `process.env` anwenden. -3. Den System-Prompt mit **berechtigten** Skills erstellen. -4. Die ursprüngliche Umgebung nach Ende des Laufs wiederherstellen. +3. Den System-Prompt mit **zulässigen** Skills erstellen. +4. Die ursprüngliche Umgebung wiederherstellen, nachdem der Lauf endet. Die Umgebungsinjektion ist **auf den Agent-Lauf beschränkt**, nicht auf eine globale Shell- Umgebung. -Für das gebündelte `claude-cli`-Backend materialisiert OpenClaw denselben -berechtigten Snapshot zusätzlich als temporäres Claude Code-Plugin und übergibt ihn mit +Für das gebündelte Backend `claude-cli` materialisiert OpenClaw außerdem denselben +zulässigen Snapshot als temporäres Claude Code-Plugin und übergibt ihn mit `--plugin-dir`. Claude Code kann dann seinen nativen Skill-Resolver verwenden, während -OpenClaw weiterhin Vorrang, Agent-spezifische Allowlists, Gating und die -`skills.entries.*`-Injektion von Umgebungsvariablen/API-Schlüsseln steuert. Andere CLI-Backends verwenden nur den +OpenClaw weiterhin Vorrang, Agent-spezifische Allowlists, Gating und +`skills.entries.*`-Umgebungs-/API-Schlüssel-Injektion steuert. Andere CLI-Backends verwenden nur den Prompt-Katalog. ## Snapshots und Aktualisierung -OpenClaw erstellt einen Snapshot der berechtigten Skills **beim Start einer Sitzung** und +OpenClaw erstellt Snapshots der zulässigen Skills **beim Start einer Sitzung** und verwendet diese Liste für nachfolgende Turns in derselben Sitzung wieder. Änderungen an Skills oder Konfiguration werden in der nächsten neuen Sitzung wirksam. -Skills können während einer Sitzung in zwei Fällen aktualisiert werden: +Skills können in zwei Fällen mitten in einer Sitzung aktualisiert werden: - Der Skills-Watcher ist aktiviert. -- Ein neuer berechtigter Remote-Node erscheint. +- Ein neuer zulässiger Remote-Node erscheint. Betrachten Sie dies als **Hot Reload**: Die aktualisierte Liste wird beim -nächsten Agent-Turn übernommen. Wenn sich die effektive Skill-Allowlist des Agents für diese -Sitzung ändert, aktualisiert OpenClaw den Snapshot, sodass sichtbare Skills mit dem -aktuellen Agent abgeglichen bleiben. +nächsten Agent-Turn übernommen. Wenn sich die effektive Agent-Skill-Allowlist für diese +Sitzung ändert, aktualisiert OpenClaw den Snapshot, damit sichtbare Skills mit dem +aktuellen Agent übereinstimmen. ### Skills-Watcher Standardmäßig überwacht OpenClaw Skill-Ordner und erhöht den Skills-Snapshot, -wenn sich `SKILL.md`-Dateien ändern. Konfiguration unter `skills.load`: +wenn sich `SKILL.md`-Dateien ändern. Konfigurieren Sie dies unter `skills.load`: ```json5 { @@ -375,26 +426,26 @@ wenn sich `SKILL.md`-Dateien ändern. Konfiguration unter `skills.load`: ### Remote-macOS-Nodes (Linux-Gateway) -Wenn der Gateway unter Linux läuft, aber ein **macOS-Node** mit erlaubtem -`system.run` verbunden ist (Exec-Approvals-Sicherheit nicht auf `deny` gesetzt), -kann OpenClaw macOS-exklusive Skills als berechtigt behandeln, wenn die erforderlichen +Wenn der Gateway unter Linux läuft, aber ein **macOS-Node** verbunden ist und +`system.run` erlaubt ist (Exec-Approvals-Sicherheit nicht auf `deny` gesetzt), +kann OpenClaw macOS-only Skills als zulässig behandeln, wenn die erforderlichen Binärdateien auf diesem Node vorhanden sind. Der Agent sollte diese Skills -über das `exec`-Tool mit `host=node` ausführen. +über das Tool `exec` mit `host=node` ausführen. Dies hängt davon ab, dass der Node seine Befehlsunterstützung meldet, sowie von einer Binärdatei-Prüfung -über `system.which` oder `system.run`. Offline-Nodes machen **keine** -Remote-exklusiven Skills sichtbar. Wenn ein verbundener Node nicht mehr auf Binärdatei- +über `system.which` oder `system.run`. Offline-Nodes machen +Remote-only Skills **nicht** sichtbar. Wenn ein verbundener Node nicht mehr auf Binärdatei- Prüfungen antwortet, löscht OpenClaw seine zwischengespeicherten Binärdatei-Treffer, sodass Agents keine Skills mehr sehen, die dort aktuell nicht ausgeführt werden können. ## Token-Auswirkung -Wenn Skills berechtigt sind, injiziert OpenClaw eine kompakte XML-Liste verfügbarer +Wenn Skills zulässig sind, injiziert OpenClaw eine kompakte XML-Liste verfügbarer Skills in den System-Prompt (über `formatSkillsForPrompt` in `pi-coding-agent`). Die Kosten sind deterministisch: -- **Basis-Overhead** (nur wenn ≥1 Skill): 195 Zeichen. -- **Pro Skill:** 97 Zeichen + die Länge der XML-escaped Werte für ``, `` und ``. +- **Basis-Overhead** (nur bei ≥1 Skill): 195 Zeichen. +- **Pro Skill:** 97 Zeichen + die Länge der XML-escaped Werte ``, `` und ``. Formel (Zeichen): @@ -403,26 +454,25 @@ total = 195 + Σ (97 + len(name_escaped) + len(description_escaped) + len(locati ``` XML-Escaping erweitert `& < > " '` zu Entitäten (`&`, `<` usw.), -was die Länge erhöht. Token-Zahlen variieren je nach Modell-Tokenizer. Eine grobe -OpenAI-ähnliche Schätzung liegt bei etwa 4 Zeichen/Token, also **97 Zeichen ≈ 24 Token** pro +wodurch die Länge steigt. Token-Zahlen variieren je nach Modell-Tokenizer. Eine grobe +OpenAI-artige Schätzung liegt bei ~4 Zeichen/Token, also **97 Zeichen ≈ 24 Token** pro Skill plus Ihre tatsächlichen Feldlängen. ## Lebenszyklus verwalteter Skills -OpenClaw liefert eine Baseline-Auswahl von Skills als **gebündelte Skills** mit der -Installation aus (npm-Paket oder OpenClaw.app). `~/.openclaw/skills` ist für -lokale Überschreibungen vorgesehen — zum Beispiel, um einen Skill zu pinnen oder zu patchen, ohne +OpenClaw liefert mit der Installation (npm-Paket oder OpenClaw.app) einen Basissatz von Skills als **gebündelte Skills** aus. `~/.openclaw/skills` dient für +lokale Überschreibungen — zum Beispiel zum Pinnen oder Patchen eines Skills, ohne die gebündelte Kopie zu ändern. Workspace-Skills gehören dem Benutzer und überschreiben -bei Namenskonflikten beide. +beide bei Namenskonflikten. -## Suchen Sie nach weiteren Skills? +## Suchen Sie weitere Skills? -Durchsuchen Sie [https://clawhub.ai](https://clawhub.ai). Vollständiges Konfigurationsschema: -[Skills-Konfiguration](/de/tools/skills-config). +Durchsuchen Sie [https://clawhub.ai](https://clawhub.ai). Vollständiges Konfigurations- +Schema: [Skills-Konfiguration](/de/tools/skills-config). -## Verwandt +## Verwandte Themen -- [ClawHub](/de/tools/clawhub) — öffentliches Skills-Register +- [ClawHub](/de/tools/clawhub) — öffentliches Skills-Registry - [Skills erstellen](/de/tools/creating-skills) — benutzerdefinierte Skills erstellen - [Plugins](/de/tools/plugin) — Überblick über das Plugin-System - [Skill-Workshop-Plugin](/de/plugins/skill-workshop) — Skills aus Agent-Arbeit generieren