chore(i18n): refresh de translations

2026-04-08 06:06:53 +00:00 · 2026-04-08 06:06:53 +00:00 · 314c37e5de
commit 314c37e5de
parent 4f17a36946
13 changed files with 1994 additions and 1709 deletions
--- a/docs/de/channels/slack.md
+++ b/docs/de/channels/slack.md
@ -1,20 +1,20 @@
 ---
 read_when:
-    - Slack einrichten oder Fehler bei Slack Socket/HTTP-Modus beheben
+    - Slack einrichten oder den Slack-Socket-/HTTP-Modus debuggen
 summary: Slack-Einrichtung und Laufzeitverhalten (Socket Mode + HTTP-Request-URLs)
 title: Slack
 x-i18n:
-    generated_at: "2026-04-07T06:14:53Z"
+    generated_at: "2026-04-08T06:02:07Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 2b8fd2cc6c638ee82069f0af2c2b6f6f49c87da709b941433a0343724a9907ea
+    source_hash: cad132131ddce688517def7c14703ad314441c67aacc4cc2a2a721e1d1c01942
    source_path: channels/slack.md
    workflow: 15
 ---

 # Slack

-Status: produktionsreif für DMs + Kanäle über Slack-App-Integrationen. Der Standardmodus ist Socket Mode; HTTP-Request-URLs werden ebenfalls unterstützt.
+Status: produktionsbereit für DMs und Channels über Slack-App-Integrationen. Der Standardmodus ist Socket Mode; HTTP-Request-URLs werden ebenfalls unterstützt.

 <CardGroup cols={3}>
  <Card title="Kopplung" icon="link" href="/de/channels/pairing">
@ -23,7 +23,7 @@ Status: produktionsreif für DMs + Kanäle über Slack-App-Integrationen. Der St
  <Card title="Slash-Befehle" icon="terminal" href="/de/tools/slash-commands">
    Natives Befehlsverhalten und Befehlskatalog.
  </Card>
-  <Card title="Fehlerbehebung für Kanäle" icon="wrench" href="/de/channels/troubleshooting">
+  <Card title="Fehlerbehebung für Channels" icon="wrench" href="/de/channels/troubleshooting">
    Kanalübergreifende Diagnose- und Reparaturleitfäden.
  </Card>
 </CardGroup>
@ -33,12 +33,12 @@ Status: produktionsreif für DMs + Kanäle über Slack-App-Integrationen. Der St
 <Tabs>
  <Tab title="Socket Mode (Standard)">
    <Steps>
-      <Step title="Neue Slack-App erstellen">
-        Klicken Sie in den Slack-App-Einstellungen auf die Schaltfläche **[Create New App](https://api.slack.com/apps/new)**:
+      <Step title="Eine neue Slack-App erstellen">
+        Drücken Sie in den Slack-App-Einstellungen auf die Schaltfläche **[Create New App](https://api.slack.com/apps/new)**:

-        - wählen Sie **from a manifest** und dann einen Workspace für Ihre App aus
-        - fügen Sie das [Beispielmanifest](#manifest-and-scope-checklist) unten ein und fahren Sie mit der Erstellung fort
-        - erstellen Sie ein **App-Level Token** (`xapp-...`) mit `connections:write`
+        - wählen Sie **from a manifest** und wählen Sie einen Workspace für Ihre App aus
+        - fügen Sie das [Beispiel-Manifest](#manifest-and-scope-checklist) von unten ein und fahren Sie mit der Erstellung fort
+        - erzeugen Sie ein **App-Level Token** (`xapp-...`) mit `connections:write`
        - installieren Sie die App und kopieren Sie das angezeigte **Bot Token** (`xoxb-...`)
      </Step>

@ -79,12 +79,12 @@ openclaw gateway

  <Tab title="HTTP-Request-URLs">
    <Steps>
-      <Step title="Neue Slack-App erstellen">
-        Klicken Sie in den Slack-App-Einstellungen auf die Schaltfläche **[Create New App](https://api.slack.com/apps/new)**:
+      <Step title="Eine neue Slack-App erstellen">
+        Drücken Sie in den Slack-App-Einstellungen auf die Schaltfläche **[Create New App](https://api.slack.com/apps/new)**:

-        - wählen Sie **from a manifest** und dann einen Workspace für Ihre App aus
-        - fügen Sie das [Beispielmanifest](#manifest-and-scope-checklist) ein und aktualisieren Sie vor dem Erstellen die URLs
-        - speichern Sie das **Signing Secret** zur Anfrageverifizierung
+        - wählen Sie **from a manifest** und wählen Sie einen Workspace für Ihre App aus
+        - fügen Sie das [Beispiel-Manifest](#manifest-and-scope-checklist) ein und aktualisieren Sie die URLs vor dem Erstellen
+        - speichern Sie das **Signing Secret** zur Verifizierung von Anfragen
        - installieren Sie die App und kopieren Sie das angezeigte **Bot Token** (`xoxb-...`)

      </Step>
@ -290,13 +290,13 @@ openclaw gateway
 </Tabs>

 <AccordionGroup>
-  <Accordion title="Optionale Urheberschafts-Scopes (Schreibvorgänge)">
-    Fügen Sie den Bot-Scope `chat:write.customize` hinzu, wenn ausgehende Nachrichten die Identität des aktiven Agenten (benutzerdefinierter Nutzername und Symbol) statt der Standardidentität der Slack-App verwenden sollen.
+  <Accordion title="Optionale Scope-Berechtigungen für Autorschaft (Schreibvorgänge)">
+    Fügen Sie die Bot-Scope-Berechtigung `chat:write.customize` hinzu, wenn ausgehende Nachrichten die aktive Agentenidentität (benutzerdefinierter Benutzername und Symbol) statt der Standardidentität der Slack-App verwenden sollen.

    Wenn Sie ein Emoji-Symbol verwenden, erwartet Slack die Syntax `:emoji_name:`.
  </Accordion>
  <Accordion title="Optionale User-Token-Scopes (Lesevorgänge)">
-    Wenn Sie `channels.slack.userToken` konfigurieren, sind typische Lesescopes:
+    Wenn Sie `channels.slack.userToken` konfigurieren, sind typische Lese-Scopes:

    - `channels:history`, `groups:history`, `im:history`, `mpim:history`
    - `channels:read`, `groups:read`, `im:read`, `mpim:read`
@ -304,7 +304,7 @@ openclaw gateway
    - `reactions:read`
    - `pins:read`
    - `emoji:read`
-    - `search:read` (wenn Sie auf Slack-Suchlesevorgänge angewiesen sind)
+    - `search:read` (wenn Sie von Slack-Such-Lesezugriffen abhängen)

  </Accordion>
 </AccordionGroup>
@ -312,29 +312,24 @@ openclaw gateway
 ## Token-Modell

 - `botToken` + `appToken` sind für Socket Mode erforderlich.
- HTTP-Modus erfordert `botToken` + `signingSecret`.
- `botToken`, `appToken`, `signingSecret` und `userToken` akzeptieren Klartextzeichenfolgen
-  oder SecretRef-Objekte.
- Konfigurationstoken überschreiben das Env-Fallback.
+- Der HTTP-Modus erfordert `botToken` + `signingSecret`.
+- `botToken`, `appToken`, `signingSecret` und `userToken` akzeptieren Klartextzeichenfolgen oder SecretRef-Objekte.
+- Konfigurations-Token überschreiben das Env-Fallback.
 - Das Env-Fallback `SLACK_BOT_TOKEN` / `SLACK_APP_TOKEN` gilt nur für das Standardkonto.
 - `userToken` (`xoxp-...`) ist nur in der Konfiguration verfügbar (kein Env-Fallback) und verwendet standardmäßig schreibgeschütztes Verhalten (`userTokenReadOnly: true`).

-Verhalten der Statusaufnahme:
+Verhalten der Statusübersicht:

- Die Slack-Kontoinspektion verfolgt pro Anmeldedaten `*Source`- und `*Status`-
-  Felder (`botToken`, `appToken`, `signingSecret`, `userToken`).
+- Die Slack-Kontoinspektion verfolgt pro Zugangsdaten `*Source`- und `*Status`-Felder (`botToken`, `appToken`, `signingSecret`, `userToken`).
 - Status ist `available`, `configured_unavailable` oder `missing`.
- `configured_unavailable` bedeutet, dass das Konto über SecretRef
-  oder eine andere nicht inline angegebene Geheimnisquelle konfiguriert ist, der aktuelle Befehls-/Laufzeitpfad
-  den tatsächlichen Wert aber nicht auflösen konnte.
- Im HTTP-Modus ist `signingSecretStatus` enthalten; im Socket Mode ist das
-  erforderliche Paar `botTokenStatus` + `appTokenStatus`.
+- `configured_unavailable` bedeutet, dass das Konto über SecretRef oder eine andere nicht-inline Secret-Quelle konfiguriert ist, der aktuelle Befehls-/Laufzeitpfad den tatsächlichen Wert jedoch nicht auflösen konnte.
+- Im HTTP-Modus wird `signingSecretStatus` eingeschlossen; im Socket Mode ist das erforderliche Paar `botTokenStatus` + `appTokenStatus`.

 <Tip>
-Für Aktionen/Verzeichnislesevorgänge kann das User-Token bevorzugt werden, wenn es konfiguriert ist. Für Schreibvorgänge bleibt das Bot-Token bevorzugt; Schreibvorgänge mit User-Token sind nur zulässig, wenn `userTokenReadOnly: false` gesetzt ist und kein Bot-Token verfügbar ist.
+Für Aktionen/Verzeichnislesevorgänge kann das User-Token bevorzugt werden, wenn es konfiguriert ist. Für Schreibvorgänge bleibt das Bot-Token bevorzugt; Schreibvorgänge mit User-Token sind nur erlaubt, wenn `userTokenReadOnly: false` und das Bot-Token nicht verfügbar ist.
 </Tip>

-## Aktionen und Einschränkungen
+## Aktionen und Gates

 Slack-Aktionen werden über `channels.slack.actions.*` gesteuert.

@ -348,7 +343,7 @@ Verfügbare Aktionsgruppen in den aktuellen Slack-Tools:
 | memberInfo | enabled |
 | emojiList  | enabled |

-Die aktuellen Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-file`, `read`, `edit`, `delete`, `pin`, `unpin`, `list-pins`, `member-info` und `emoji-list`.
+Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-file`, `read`, `edit`, `delete`, `pin`, `unpin`, `list-pins`, `member-info` und `emoji-list`.

 ## Zugriffskontrolle und Routing

@ -363,13 +358,13 @@ Die aktuellen Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `downloa

    DM-Flags:

-    - `dm.enabled` (standardmäßig true)
+    - `dm.enabled` (Standard true)
    - `channels.slack.allowFrom` (bevorzugt)
    - `dm.allowFrom` (veraltet)
    - `dm.groupEnabled` (Gruppen-DMs standardmäßig false)
    - `dm.groupChannels` (optionale MPIM-Allowlist)

-    Vorrang bei mehreren Konten:
+    Priorität bei mehreren Konten:

    - `channels.slack.accounts.default.allowFrom` gilt nur für das Konto `default`.
    - Benannte Konten übernehmen `channels.slack.allowFrom`, wenn ihr eigenes `allowFrom` nicht gesetzt ist.
@ -379,35 +374,35 @@ Die aktuellen Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `downloa

  </Tab>

-  <Tab title="Kanalrichtlinie">
-    `channels.slack.groupPolicy` steuert die Kanalbehandlung:
+  <Tab title="Channel-Richtlinie">
+    `channels.slack.groupPolicy` steuert die Channel-Behandlung:

    - `open`
    - `allowlist`
    - `disabled`

-    Die Kanal-Allowlist befindet sich unter `channels.slack.channels` und sollte stabile Kanal-IDs verwenden.
+    Die Channel-Allowlist befindet sich unter `channels.slack.channels` und sollte stabile Channel-IDs verwenden.

-    Laufzeithinweis: Wenn `channels.slack` vollständig fehlt (nur Env-Setup), fällt die Laufzeit auf `groupPolicy="allowlist"` zurück und protokolliert eine Warnung (selbst wenn `channels.defaults.groupPolicy` gesetzt ist).
+    Laufzeithinweis: Wenn `channels.slack` vollständig fehlt (nur Env-Einrichtung), fällt die Laufzeit auf `groupPolicy="allowlist"` zurück und protokolliert eine Warnung (auch wenn `channels.defaults.groupPolicy` gesetzt ist).

    Auflösung von Namen/IDs:

-    - Einträge in Kanal-Allowlists und DM-Allowlists werden beim Start aufgelöst, wenn der Tokenzugriff dies erlaubt
-    - nicht aufgelöste Einträge mit Kanalnamen bleiben wie konfiguriert erhalten, werden aber standardmäßig für das Routing ignoriert
-    - eingehende Autorisierung und Kanalrouting sind standardmäßig ID-orientiert; direktes Matching von Nutzernamen/Slugs erfordert `channels.slack.dangerouslyAllowNameMatching: true`
+    - Einträge in der Channel-Allowlist und der DM-Allowlist werden beim Start aufgelöst, wenn der Token-Zugriff dies zulässt
+    - nicht aufgelöste Channel-Namenseinträge bleiben wie konfiguriert erhalten, werden für das Routing aber standardmäßig ignoriert
+    - eingehende Autorisierung und Channel-Routing sind standardmäßig ID-first; direkte Benutzername-/Slug-Abgleiche erfordern `channels.slack.dangerouslyAllowNameMatching: true`

  </Tab>

-  <Tab title="Erwähnungen und Kanalnutzer">
-    Kanalnachrichten sind standardmäßig durch Erwähnungen eingeschränkt.
+  <Tab title="Erwähnungen und Channel-Benutzer">
+    Channel-Nachrichten sind standardmäßig durch Erwähnungen begrenzt.

    Quellen für Erwähnungen:

    - explizite App-Erwähnung (`<@botId>`)
    - Regex-Muster für Erwähnungen (`agents.list[].groupChat.mentionPatterns`, Fallback `messages.groupChat.mentionPatterns`)
-    - implizites Antwortverhalten in Bot-Threads (deaktiviert, wenn `thread.requireExplicitMention` `true` ist)
+    - implizites Antwort-im-Bot-Thread-Verhalten (deaktiviert, wenn `thread.requireExplicitMention` `true` ist)

-    Steuerung pro Kanal (`channels.slack.channels.<id>`; Namen nur über Auflösung beim Start oder `dangerouslyAllowNameMatching`):
+    Steuerelemente pro Channel (`channels.slack.channels.<id>`; Namen nur über Auflösung beim Start oder `dangerouslyAllowNameMatching`):

    - `requireMention`
    - `users` (Allowlist)
@ -421,28 +416,28 @@ Die aktuellen Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `downloa
  </Tab>
 </Tabs>

-## Threading, Sitzungen und Antwort-Tags
+## Threading, Sessions und Antwort-Tags

- DMs werden als `direct` geroutet; Kanäle als `channel`; MPIMs als `group`.
- Mit dem Standard `session.dmScope=main` werden Slack-DMs in der Hauptsitzung des Agenten zusammengeführt.
- Kanalsitzungen: `agent:<agentId>:slack:channel:<channelId>`.
- Thread-Antworten können bei Bedarf Thread-Sitzungssuffixe (`:thread:<threadTs>`) erstellen.
- Der Standardwert von `channels.slack.thread.historyScope` ist `thread`; der Standardwert von `thread.inheritParent` ist `false`.
- `channels.slack.thread.initialHistoryLimit` steuert, wie viele vorhandene Thread-Nachrichten abgerufen werden, wenn eine neue Thread-Sitzung startet (Standard `20`; setzen Sie `0`, um dies zu deaktivieren).
- `channels.slack.thread.requireExplicitMention` (Standard `false`): Wenn `true`, werden implizite Thread-Erwähnungen unterdrückt, sodass der Bot in Threads nur auf explizite `@bot`-Erwähnungen antwortet, selbst wenn der Bot bereits am Thread beteiligt war. Ohne diese Einstellung umgehen Antworten in einem Thread mit Bot-Beteiligung die Einschränkung `requireMention`.
+- DMs werden als `direct` geroutet, Channels als `channel`, MPIMs als `group`.
+- Mit dem Standard `session.dmScope=main` werden Slack-DMs zur Hauptsession des Agenten zusammengefasst.
+- Channel-Sessions: `agent:<agentId>:slack:channel:<channelId>`.
+- Thread-Antworten können bei Bedarf Thread-Session-Suffixe (`:thread:<threadTs>`) erzeugen.
+- Standard für `channels.slack.thread.historyScope` ist `thread`; Standard für `thread.inheritParent` ist `false`.
+- `channels.slack.thread.initialHistoryLimit` steuert, wie viele vorhandene Thread-Nachrichten abgerufen werden, wenn eine neue Thread-Session startet (Standard `20`; auf `0` setzen, um dies zu deaktivieren).
+- `channels.slack.thread.requireExplicitMention` (Standard `false`): Wenn `true`, werden implizite Thread-Erwähnungen unterdrückt, sodass der Bot in Threads nur auf explizite `@bot`-Erwähnungen antwortet, selbst wenn der Bot bereits am Thread teilgenommen hat. Ohne dies umgehen Antworten in einem Thread mit Bot-Beteiligung das `requireMention`-Gate.

-Steuerung für Antwort-Threads:
+Steuerung für Antwort-Threading:

 - `channels.slack.replyToMode`: `off|first|all|batched` (Standard `off`)
 - `channels.slack.replyToModeByChatType`: pro `direct|group|channel`
- veraltetes Fallback für direkte Chats: `channels.slack.dm.replyToMode`
+- veralteter Fallback für direkte Chats: `channels.slack.dm.replyToMode`

 Manuelle Antwort-Tags werden unterstützt:

 - `[[reply_to_current]]`
 - `[[reply_to:<id>]]`

-Hinweis: `replyToMode="off"` deaktiviert **jegliches** Antwort-Threading in Slack, einschließlich expliziter `[[reply_to_*]]`-Tags. Dies unterscheidet sich von Telegram, wo explizite Tags auch im Modus `"off"` weiterhin berücksichtigt werden. Der Unterschied spiegelt die Threading-Modelle der Plattformen wider: Slack-Threads verbergen Nachrichten im Kanal, während Telegram-Antworten im Hauptchatverlauf sichtbar bleiben.
+Hinweis: `replyToMode="off"` deaktiviert **jegliches** Antwort-Threading in Slack, einschließlich expliziter `[[reply_to_*]]`-Tags. Dies unterscheidet sich von Telegram, wo explizite Tags im Modus `"off"` weiterhin berücksichtigt werden. Der Unterschied spiegelt die Threading-Modelle der Plattformen wider: Slack-Threads verbergen Nachrichten im Channel, während Telegram-Antworten im Haupt-Chatverlauf sichtbar bleiben.

 ## Bestätigungsreaktionen

@ -453,7 +448,7 @@ Reihenfolge der Auflösung:
 - `channels.slack.accounts.<accountId>.ackReaction`
 - `channels.slack.ackReaction`
 - `messages.ackReaction`
- Fallback auf Agentenidentitäts-Emoji (`agents.list[].identity.emoji`, andernfalls "👀")
+- Emoji-Fallback der Agentenidentität (`agents.list[].identity.emoji`, sonst "👀")

 Hinweise:

@ -462,18 +457,20 @@ Hinweise:

 ## Text-Streaming

-`channels.slack.streaming` steuert das Verhalten der Livevorschau:
+`channels.slack.streaming` steuert das Verhalten der Live-Vorschau:

- `off`: Livevorschau-Streaming deaktivieren.
+- `off`: Live-Vorschau-Streaming deaktivieren.
 - `partial` (Standard): Vorschautext durch die neueste Teilausgabe ersetzen.
 - `block`: Chunkweise Vorschauaktualisierungen anhängen.
 - `progress`: Fortschrittsstatustext während der Generierung anzeigen und dann den endgültigen Text senden.

-`channels.slack.nativeStreaming` steuert das native Text-Streaming von Slack, wenn `streaming` auf `partial` steht (Standard: `true`).
+`channels.slack.streaming.nativeTransport` steuert das native Slack-Text-Streaming, wenn `channels.slack.streaming.mode` auf `partial` gesetzt ist (Standard: `true`).

- Ein Antwort-Thread muss verfügbar sein, damit natives Text-Streaming angezeigt wird. Die Thread-Auswahl folgt weiterhin `replyToMode`. Ohne Thread wird die normale Entwurfsvorschau verwendet.
- Medien und Nicht-Text-Payloads greifen auf die normale Zustellung zurück.
- Wenn das Streaming mitten in der Antwort fehlschlägt, greift OpenClaw für verbleibende Payloads auf die normale Zustellung zurück.
+- Für natives Text-Streaming und die Anzeige des Slack-Assistenten-Thread-Status muss ein Antwort-Thread verfügbar sein. Die Auswahl des Threads folgt weiterhin `replyToMode`.
+- Wurzeln von Channel- und Gruppen-Chats können weiterhin die normale Entwurfsvorschau verwenden, wenn natives Streaming nicht verfügbar ist.
+- Slack-DMs auf oberster Ebene bleiben standardmäßig außerhalb von Threads und zeigen daher keine Thread-ähnliche Vorschau an; verwenden Sie Thread-Antworten oder `typingReaction`, wenn dort sichtbarer Fortschritt angezeigt werden soll.
+- Medien und Nicht-Text-Payloads fallen auf die normale Zustellung zurück.
+- Wenn das Streaming mitten in einer Antwort fehlschlägt, fällt OpenClaw für verbleibende Payloads auf die normale Zustellung zurück.

 Verwenden Sie die Entwurfsvorschau anstelle des nativen Slack-Text-Streamings:

@ -481,8 +478,10 @@ Verwenden Sie die Entwurfsvorschau anstelle des nativen Slack-Text-Streamings:
 {
  channels: {
    slack: {
-      streaming: "partial",
-      nativeStreaming: false,
+      streaming: {
+        mode: "partial",
+        nativeTransport: false,
+      },
    },
  },
 }
@ -490,12 +489,13 @@ Verwenden Sie die Entwurfsvorschau anstelle des nativen Slack-Text-Streamings:

 Veraltete Schlüssel:

- `channels.slack.streamMode` (`replace | status_final | append`) wird automatisch zu `channels.slack.streaming` migriert.
- boolesches `channels.slack.streaming` wird automatisch zu `channels.slack.nativeStreaming` migriert.
+- `channels.slack.streamMode` (`replace | status_final | append`) wird automatisch zu `channels.slack.streaming.mode` migriert.
+- boolesches `channels.slack.streaming` wird automatisch zu `channels.slack.streaming.mode` und `channels.slack.streaming.nativeTransport` migriert.
+- das veraltete `channels.slack.nativeStreaming` wird automatisch zu `channels.slack.streaming.nativeTransport` migriert.

 ## Fallback für Tippreaktion

-`typingReaction` fügt der eingehenden Slack-Nachricht vorübergehend eine Reaktion hinzu, während OpenClaw eine Antwort verarbeitet, und entfernt sie wieder, wenn der Lauf abgeschlossen ist. Das ist besonders nützlich außerhalb von Thread-Antworten, die standardmäßig einen Statusindikator "is typing..." verwenden.
+`typingReaction` fügt der eingehenden Slack-Nachricht vorübergehend eine Reaktion hinzu, während OpenClaw eine Antwort verarbeitet, und entfernt sie, wenn der Durchlauf abgeschlossen ist. Dies ist besonders nützlich außerhalb von Thread-Antworten, die standardmäßig einen Statusindikator "is typing..." verwenden.

 Reihenfolge der Auflösung:

@ -505,66 +505,66 @@ Reihenfolge der Auflösung:
 Hinweise:

 - Slack erwartet Shortcodes (zum Beispiel `"hourglass_flowing_sand"`).
- Die Reaktion erfolgt nach bestem Bemühen, und die Bereinigung wird nach Abschluss der Antwort oder des Fehlerpfads automatisch versucht.
+- Die Reaktion erfolgt nach Best Effort, und die Bereinigung wird nach Abschluss der Antwort oder des Fehlerpfads automatisch versucht.

 ## Medien, Chunking und Zustellung

 <AccordionGroup>
  <Accordion title="Eingehende Anhänge">
-    Slack-Dateianhänge werden von von Slack gehosteten privaten URLs heruntergeladen (tokenauthentifizierter Anfragefluss) und in den Medienspeicher geschrieben, wenn der Abruf erfolgreich ist und Größenbeschränkungen dies zulassen.
+    Slack-Dateianhänge werden von privaten, bei Slack gehosteten URLs heruntergeladen (anfrageauthentifizierter Token-Flow) und bei erfolgreichem Abruf und zulässiger Größe in den Medienspeicher geschrieben.

-    Die Standardobergrenze für eingehende Laufzeitgrößen ist `20MB`, sofern sie nicht durch `channels.slack.mediaMaxMb` überschrieben wird.
+    Die Standardobergrenze für eingehende Daten zur Laufzeit beträgt `20MB`, sofern sie nicht durch `channels.slack.mediaMaxMb` überschrieben wird.

  </Accordion>

  <Accordion title="Ausgehender Text und Dateien">
    - Text-Chunks verwenden `channels.slack.textChunkLimit` (Standard 4000)
-    - `channels.slack.chunkMode="newline"` aktiviert eine absatzorientierte Aufteilung
-    - Dateisendungen verwenden Slack-Upload-APIs und können Thread-Antworten (`thread_ts`) einschließen
-    - die Obergrenze für ausgehende Medien folgt `channels.slack.mediaMaxMb`, wenn konfiguriert; andernfalls verwenden Kanalsendungen die Standardwerte nach MIME-Art aus der Medienpipeline
+    - `channels.slack.chunkMode="newline"` aktiviert das Aufteilen nach Absätzen zuerst
+    - Dateisendungen verwenden die Slack-Upload-APIs und können Thread-Antworten (`thread_ts`) einschließen
+    - die Obergrenze für ausgehende Medien folgt `channels.slack.mediaMaxMb`, wenn konfiguriert; andernfalls verwenden Channel-Sendungen die standardmäßigen MIME-Art-Vorgaben aus der Medienpipeline
  </Accordion>

-  <Accordion title="Zustellungsziele">
+  <Accordion title="Zustellziele">
    Bevorzugte explizite Ziele:

    - `user:<id>` für DMs
-    - `channel:<id>` für Kanäle
+    - `channel:<id>` für Channels

-    Slack-DMs werden beim Senden an Nutzerziele über die Slack-Konversations-APIs geöffnet.
+    Slack-DMs werden über die Slack-Conversation-APIs geöffnet, wenn an Benutzerziele gesendet wird.

  </Accordion>
 </AccordionGroup>

 ## Befehle und Slash-Verhalten

- Der Auto-Modus für native Befehle ist für Slack **deaktiviert** (`commands.native: "auto"` aktiviert keine nativen Slack-Befehle).
+- Der native Befehls-Automodus ist für Slack **deaktiviert** (`commands.native: "auto"` aktiviert keine nativen Slack-Befehle).
 - Aktivieren Sie native Slack-Befehlshandler mit `channels.slack.commands.native: true` (oder global `commands.native: true`).
 - Wenn native Befehle aktiviert sind, registrieren Sie passende Slash-Befehle in Slack (`/<command>`-Namen), mit einer Ausnahme:
  - registrieren Sie `/agentstatus` für den Statusbefehl (Slack reserviert `/status`)
- Wenn native Befehle nicht aktiviert sind, können Sie einen einzelnen konfigurierten Slash-Befehl über `channels.slack.slashCommand` ausführen.
- Native Argumentmenüs passen ihre Renderstrategie nun an:
+- Wenn native Befehle nicht aktiviert sind, können Sie mit `channels.slack.slashCommand` einen einzelnen konfigurierten Slash-Befehl ausführen.
+- Native Argumentmenüs passen ihre Rendering-Strategie jetzt an:
  - bis zu 5 Optionen: Button-Blöcke
  - 6-100 Optionen: statisches Auswahlmenü
  - mehr als 100 Optionen: externe Auswahl mit asynchroner Optionsfilterung, wenn Handler für Interaktivitätsoptionen verfügbar sind
-  - wenn codierte Optionswerte die Slack-Limits überschreiten, fällt der Ablauf auf Buttons zurück
- Für lange Options-Payloads verwenden Slash-Befehlsargumentmenüs einen Bestätigungsdialog, bevor ein ausgewählter Wert gesendet wird.
+  - wenn codierte Optionswerte die Slack-Grenzen überschreiten, fällt der Ablauf auf Buttons zurück
+- Für lange Options-Payloads verwenden Slash-Befehlsargumentmenüs vor dem Senden eines ausgewählten Werts einen Bestätigungsdialog.

-Standard-Slash-Befehlseinstellungen:
+Standardeinstellungen für Slash-Befehle:

 - `enabled: false`
 - `name: "openclaw"`
 - `sessionPrefix: "slack:slash"`
 - `ephemeral: true`

-Slash-Sitzungen verwenden isolierte Schlüssel:
+Slash-Sessions verwenden isolierte Schlüssel:

 - `agent:<agentId>:slack:slash:<userId>`

-und führen die Befehlsausführung weiterhin gegen die Sitzung der Zielkonversation aus (`CommandTargetSessionKey`).
+und routen die Befehlsausführung weiterhin gegen die Ziel-Conversation-Session (`CommandTargetSessionKey`).

 ## Interaktive Antworten

-Slack kann vom Agenten verfasste interaktive Antwortsteuerungen rendern, aber diese Funktion ist standardmäßig deaktiviert.
+Slack kann interaktive, von Agenten verfasste Antwortsteuerelemente rendern, diese Funktion ist jedoch standardmäßig deaktiviert.

 Global aktivieren:

@ -598,44 +598,43 @@ Oder nur für ein Slack-Konto aktivieren:
 }
 ```

-Wenn aktiviert, können Agenten nur für Slack bestimmte Antwortdirektiven ausgeben:
+Wenn aktiviert, können Agenten nur für Slack geltende Antwortdirektiven ausgeben:

 - `[[slack_buttons: Approve:approve, Reject:reject]]`
 - `[[slack_select: Choose a target | Canary:canary, Production:production]]`

-Diese Direktiven werden in Slack Block Kit kompiliert und leiten Klicks oder Auswahlen über den vorhandenen Slack-Interaktionsereignispfad zurück.
+Diese Direktiven werden in Slack Block Kit kompiliert und leiten Klicks oder Auswahlen über den bestehenden Slack-Interaktionsereignispfad zurück.

 Hinweise:

- Dies ist eine Slack-spezifische UI. Andere Kanäle übersetzen Slack-Block-Kit-Direktiven nicht in ihre eigenen Button-Systeme.
- Die interaktiven Callback-Werte sind von OpenClaw erzeugte undurchsichtige Token, keine unverarbeiteten vom Agenten verfassten Werte.
- Wenn generierte interaktive Blöcke die Grenzen von Slack Block Kit überschreiten würden, greift OpenClaw auf die ursprüngliche Textantwort zurück, anstatt eine ungültige Blocks-Payload zu senden.
+- Dies ist Slack-spezifische UI. Andere Channels übersetzen Slack-Block-Kit-Direktiven nicht in ihre eigenen Button-Systeme.
+- Die interaktiven Callback-Werte sind von OpenClaw erzeugte undurchsichtige Token, keine rohen, vom Agenten verfassten Werte.
+- Wenn erzeugte interaktive Blöcke die Slack-Block-Kit-Grenzen überschreiten würden, fällt OpenClaw auf die ursprüngliche Textantwort zurück, anstatt eine ungültige Blocks-Payload zu senden.

-## Exec-Freigaben in Slack
+## Exec-Genehmigungen in Slack

-Slack kann als nativer Freigabeclient mit interaktiven Buttons und Interaktionen fungieren, anstatt auf die Web-UI oder das Terminal zurückzufallen.
+Slack kann als nativer Genehmigungs-Client mit interaktiven Buttons und Interaktionen fungieren, statt auf die Web-UI oder das Terminal zurückzufallen.

- Exec-Freigaben verwenden `channels.slack.execApprovals.*` für natives DM-/Kanalrouting.
- Plugin-Freigaben können weiterhin über dieselbe native Slack-Button-Oberfläche aufgelöst werden, wenn die Anfrage bereits in Slack landet und die Freigabe-ID-Art `plugin:` ist.
- Die Autorisierung von Freigebenden wird weiterhin erzwungen: Nur als Freigebende identifizierte Nutzer können Anfragen über Slack genehmigen oder ablehnen.
+- Exec-Genehmigungen verwenden `channels.slack.execApprovals.*` für natives DM-/Channel-Routing.
+- Plugin-Genehmigungen können weiterhin über dieselbe native Slack-Button-Oberfläche aufgelöst werden, wenn die Anfrage bereits in Slack landet und die Art der Genehmigungs-ID `plugin:` ist.
+- Die Autorisierung des Genehmigers wird weiterhin erzwungen: Nur Benutzer, die als Genehmiger identifiziert wurden, können Anfragen über Slack genehmigen oder ablehnen.

-Dies verwendet dieselbe gemeinsam genutzte Oberfläche für Freigabebuttons wie andere Kanäle. Wenn `interactivity` in Ihren Slack-App-Einstellungen aktiviert ist, werden Freigabeaufforderungen direkt als Block-Kit-Buttons in der Unterhaltung gerendert.
-Wenn diese Buttons vorhanden sind, sind sie die primäre UX für Freigaben; OpenClaw
-sollte einen manuellen `/approve`-Befehl nur einfügen, wenn das Toolergebnis angibt, dass Chat-
-Freigaben nicht verfügbar sind oder die manuelle Freigabe der einzige Weg ist.
+Dies verwendet dieselbe gemeinsame Oberfläche für Genehmigungsbuttons wie andere Channels. Wenn `interactivity` in Ihren Slack-App-Einstellungen aktiviert ist, werden Genehmigungsaufforderungen direkt in der Konversation als Block-Kit-Buttons gerendert.
+Wenn diese Buttons vorhanden sind, sind sie die primäre UX für Genehmigungen; OpenClaw
+sollte einen manuellen `/approve`-Befehl nur dann einschließen, wenn das Tool-Ergebnis angibt, dass Chat-Genehmigungen nicht verfügbar sind oder eine manuelle Genehmigung der einzige Weg ist.

 Konfigurationspfad:

 - `channels.slack.execApprovals.enabled`
- `channels.slack.execApprovals.approvers` (optional; greift nach Möglichkeit auf `commands.ownerAllowFrom` zurück)
+- `channels.slack.execApprovals.approvers` (optional; fällt nach Möglichkeit auf `commands.ownerAllowFrom` zurück)
 - `channels.slack.execApprovals.target` (`dm` | `channel` | `both`, Standard: `dm`)
 - `agentFilter`, `sessionFilter`

-Slack aktiviert native Exec-Freigaben automatisch, wenn `enabled` nicht gesetzt oder `"auto"` ist und sich mindestens ein
-Freigebender auflösen lässt. Setzen Sie `enabled: false`, um Slack ausdrücklich als nativen Freigabeclient zu deaktivieren.
-Setzen Sie `enabled: true`, um native Freigaben zu erzwingen, wenn sich Freigebende auflösen lassen.
+Slack aktiviert native Exec-Genehmigungen automatisch, wenn `enabled` nicht gesetzt oder `"auto"` ist und mindestens ein
+Genehmiger aufgelöst wird. Setzen Sie `enabled: false`, um Slack ausdrücklich als nativen Genehmigungs-Client zu deaktivieren.
+Setzen Sie `enabled: true`, um native Genehmigungen zu erzwingen, wenn Genehmiger aufgelöst werden.

-Standardverhalten ohne explizite Slack-Exec-Freigabekonfiguration:
+Standardverhalten ohne explizite Slack-Exec-Genehmigungskonfiguration:

 ```json5
 {
@ -645,8 +644,8 @@ Standardverhalten ohne explizite Slack-Exec-Freigabekonfiguration:
 }
 ```

-Eine explizite Slack-native Konfiguration ist nur erforderlich, wenn Sie Freigebende überschreiben, Filter hinzufügen oder
-die Zustellung im Ursprungschat aktivieren möchten:
+Eine explizite Slack-native Konfiguration ist nur erforderlich, wenn Sie Genehmiger überschreiben, Filter hinzufügen oder
+die Zustellung im Ursprungs-Chat aktivieren möchten:

 ```json5
 {
@ -662,50 +661,50 @@ die Zustellung im Ursprungschat aktivieren möchten:
 }
 ```

-Die gemeinsame Weiterleitung `approvals.exec` ist separat. Verwenden Sie sie nur, wenn Exec-Freigabeaufforderungen zusätzlich
-an andere Chats oder explizite Ziele außerhalb des Bandes weitergeleitet werden müssen. Die gemeinsame Weiterleitung `approvals.plugin` ist ebenfalls
-separat; native Slack-Buttons können Plugin-Freigaben weiterhin auflösen, wenn diese Anfragen bereits
+Gemeinsame `approvals.exec`-Weiterleitung ist davon getrennt. Verwenden Sie sie nur, wenn Aufforderungen für Exec-Genehmigungen zusätzlich
+an andere Chats oder explizite Ziele außerhalb des Bands weitergeleitet werden müssen. Gemeinsame `approvals.plugin`-Weiterleitung ist ebenfalls
+getrennt; native Slack-Buttons können Plugin-Genehmigungen weiterhin auflösen, wenn diese Anfragen bereits
 in Slack landen.

-`/approve` im selben Chat funktioniert auch in Slack-Kanälen und DMs, die bereits Befehle unterstützen. Siehe [Exec approvals](/de/tools/exec-approvals) für das vollständige Weiterleitungsmodell für Freigaben.
+Dasselbe Chat-`/approve` funktioniert auch in Slack-Channels und DMs, die bereits Befehle unterstützen. Siehe [Exec approvals](/de/tools/exec-approvals) für das vollständige Modell zur Weiterleitung von Genehmigungen.

 ## Ereignisse und Betriebsverhalten

 - Nachrichtenbearbeitungen/-löschungen/Thread-Broadcasts werden in Systemereignisse abgebildet.
 - Ereignisse zum Hinzufügen/Entfernen von Reaktionen werden in Systemereignisse abgebildet.
- Ereignisse zum Beitreten/Verlassen von Mitgliedern, zum Erstellen/Umbenennen von Kanälen sowie zum Hinzufügen/Entfernen von Pins werden in Systemereignisse abgebildet.
- `channel_id_changed` kann Kanal-Konfigurationsschlüssel migrieren, wenn `configWrites` aktiviert ist.
- Kanalthemen/-zwecke gelten als nicht vertrauenswürdiger Kontext und können in den Routing-Kontext eingefügt werden.
- Der Starter des Threads und das anfängliche Einspeisen des Thread-Verlaufs in den Kontext werden bei Bedarf durch konfigurierte Absender-Allowlists gefiltert.
- Block-Aktionen und modale Interaktionen erzeugen strukturierte `Slack interaction: ...`-Systemereignisse mit umfangreichen Payload-Feldern:
+- Ereignisse zu Beitritt/Verlassen von Mitgliedern, erstellten/umbenannten Channels und Hinzufügen/Entfernen von Pins werden in Systemereignisse abgebildet.
+- `channel_id_changed` kann Channel-Konfigurationsschlüssel migrieren, wenn `configWrites` aktiviert ist.
+- Channel-Topic-/Purpose-Metadaten werden als nicht vertrauenswürdiger Kontext behandelt und können in den Routing-Kontext eingespeist werden.
+- Thread-Starter und anfängliche Kontextvorbelegung mit Thread-Verlauf werden bei Bedarf anhand konfigurierter Sender-Allowlists gefiltert.
+- Block-Aktionen und Modal-Interaktionen erzeugen strukturierte `Slack interaction: ...`-Systemereignisse mit umfangreichen Payload-Feldern:
  - Block-Aktionen: ausgewählte Werte, Labels, Picker-Werte und `workflow_*`-Metadaten
-  - modale Ereignisse `view_submission` und `view_closed` mit gerouteten Kanalmetadaten und Formulareingaben
+  - modale `view_submission`- und `view_closed`-Ereignisse mit gerouteten Channel-Metadaten und Formulareingaben

 ## Verweise auf die Konfigurationsreferenz

 Primäre Referenz:

- [Configuration reference - Slack](/de/gateway/configuration-reference#slack)
+- [Konfigurationsreferenz - Slack](/de/gateway/configuration-reference#slack)

  Wichtige Slack-Felder:
  - Modus/Auth: `mode`, `botToken`, `appToken`, `signingSecret`, `webhookPath`, `accounts.*`
  - DM-Zugriff: `dm.enabled`, `dmPolicy`, `allowFrom` (veraltet: `dm.policy`, `dm.allowFrom`), `dm.groupEnabled`, `dm.groupChannels`
-  - Kompatibilitätsschalter: `dangerouslyAllowNameMatching` (nur im Notfall; deaktiviert lassen, sofern nicht erforderlich)
-  - Kanalzugriff: `groupPolicy`, `channels.*`, `channels.*.users`, `channels.*.requireMention`
+  - Kompatibilitätsschalter: `dangerouslyAllowNameMatching` (Break-Glass; ausgeschaltet lassen, sofern nicht benötigt)
+  - Channel-Zugriff: `groupPolicy`, `channels.*`, `channels.*.users`, `channels.*.requireMention`
  - Threading/Verlauf: `replyToMode`, `replyToModeByChatType`, `thread.*`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit`
-  - Zustellung: `textChunkLimit`, `chunkMode`, `mediaMaxMb`, `streaming`, `nativeStreaming`
+  - Zustellung: `textChunkLimit`, `chunkMode`, `mediaMaxMb`, `streaming`, `streaming.nativeTransport`
  - Betrieb/Funktionen: `configWrites`, `commands.native`, `slashCommand.*`, `actions.*`, `userToken`, `userTokenReadOnly`

 ## Fehlerbehebung

 <AccordionGroup>
-  <Accordion title="Keine Antworten in Kanälen">
+  <Accordion title="Keine Antworten in Channels">
    Prüfen Sie in dieser Reihenfolge:

    - `groupPolicy`
-    - Kanal-Allowlist (`channels.slack.channels`)
+    - Channel-Allowlist (`channels.slack.channels`)
    - `requireMention`
-    - `users`-Allowlist pro Kanal
+    - `users`-Allowlist pro Channel

    Nützliche Befehle:

@ -730,37 +729,37 @@ openclaw pairing list slack

  </Accordion>

-  <Accordion title="Socket Mode verbindet sich nicht">
-    Prüfen Sie Bot- und App-Token sowie die Aktivierung von Socket Mode in den Slack-App-Einstellungen.
+  <Accordion title="Socket-Modus verbindet sich nicht">
+    Validieren Sie Bot- und App-Token sowie die Aktivierung von Socket Mode in den Slack-App-Einstellungen.

    Wenn `openclaw channels status --probe --json` `botTokenStatus` oder
    `appTokenStatus: "configured_unavailable"` anzeigt, ist das Slack-Konto
-    konfiguriert, aber die aktuelle Laufzeit konnte den durch SecretRef gestützten
-    Wert nicht auflösen.
+    konfiguriert, aber die aktuelle Laufzeit konnte den durch SecretRef
+    gesicherten Wert nicht auflösen.

  </Accordion>

  <Accordion title="HTTP-Modus empfängt keine Ereignisse">
-    Prüfen Sie:
+    Validieren Sie:

    - Signing Secret
    - Webhook-Pfad
-    - Slack-Request-URLs (Events + Interaktivität + Slash-Befehle)
-    - eindeutigen `webhookPath` pro HTTP-Konto
+    - Slack-Request-URLs (Events + Interactivity + Slash Commands)
+    - eindeutiger `webhookPath` pro HTTP-Konto

    Wenn `signingSecretStatus: "configured_unavailable"` in Konto-
-    Aufnahmen erscheint, ist das HTTP-Konto konfiguriert, aber die aktuelle Laufzeit konnte das
-    durch SecretRef gestützte Signing Secret nicht auflösen.
+    Übersichten erscheint, ist das HTTP-Konto konfiguriert, aber die aktuelle Laufzeit konnte das durch SecretRef
+    gesicherte Signing Secret nicht auflösen.

  </Accordion>

  <Accordion title="Native/Slash-Befehle werden nicht ausgelöst">
-    Prüfen Sie, ob beabsichtigt war:
+    Prüfen Sie, ob Sie Folgendes beabsichtigt haben:

-    - nativer Befehlsmodus (`channels.slack.commands.native: true`) mit passenden in Slack registrierten Slash-Befehlen
-    - oder Einzel-Slash-Befehlsmodus (`channels.slack.slashCommand.enabled: true`)
+    - nativen Befehlsmodus (`channels.slack.commands.native: true`) mit passenden in Slack registrierten Slash-Befehlen
+    - oder den Modus für einen einzelnen Slash-Befehl (`channels.slack.slashCommand.enabled: true`)

-    Prüfen Sie außerdem `commands.useAccessGroups` sowie Kanal-/Nutzer-Allowlists.
+    Prüfen Sie außerdem `commands.useAccessGroups` sowie Channel-/Benutzer-Allowlists.

  </Accordion>
 </AccordionGroup>
@ -770,7 +769,7 @@ openclaw pairing list slack
 - [Kopplung](/de/channels/pairing)
 - [Gruppen](/de/channels/groups)
 - [Sicherheit](/de/gateway/security)
- [Kanalrouting](/de/channels/channel-routing)
+- [Channel-Routing](/de/channels/channel-routing)
 - [Fehlerbehebung](/de/channels/troubleshooting)
 - [Konfiguration](/de/gateway/configuration)
 - [Slash-Befehle](/de/tools/slash-commands)
--- a/docs/de/concepts/memory.md
+++ b/docs/de/concepts/memory.md
@ -1,23 +1,23 @@
 ---
 read_when:
-    - Sie möchten verstehen, wie der Speicher funktioniert
+    - Sie möchten verstehen, wie Speicher funktioniert
    - Sie möchten wissen, welche Speicherdateien geschrieben werden
 summary: Wie OpenClaw sich Dinge sitzungsübergreifend merkt
-title: Speicherüberblick
+title: Überblick über den Speicher
 x-i18n:
-    generated_at: "2026-04-06T03:06:36Z"
+    generated_at: "2026-04-08T06:01:19Z"
    model: gpt-5.4
    provider: openai
-    source_hash: d19d4fa9c4b3232b7a97f7a382311d2a375b562040de15e9fe4a0b1990b825e7
+    source_hash: 3bb8552341b0b651609edaaae826a22fdc535d240aed4fad4af4b069454004af
    source_path: concepts/memory.md
    workflow: 15
 ---

-# Speicherüberblick
+# Überblick über den Speicher

-OpenClaw merkt sich Dinge, indem es **einfache Markdown-Dateien** im Workspace
-Ihres Agenten schreibt. Das Modell „erinnert“ sich nur an das, was auf der
-Festplatte gespeichert wird -- es gibt keinen versteckten Zustand.
+OpenClaw merkt sich Dinge, indem **einfache Markdown-Dateien** im Workspace
+Ihres Agenten geschrieben werden. Das Modell „erinnert“ sich nur an das, was
+auf der Festplatte gespeichert wird – es gibt keinen versteckten Zustand.

 ## So funktioniert es

@ -30,43 +30,60 @@ Ihr Agent hat drei speicherbezogene Dateien:
 - **`DREAMS.md`** (experimentell, optional) -- Dream Diary und Zusammenfassungen
  von Dreaming-Durchläufen zur menschlichen Überprüfung.

-Diese Dateien befinden sich im Workspace des Agenten (Standard:
-`~/.openclaw/workspace`).
+Diese Dateien befinden sich im Agent-Workspace (standardmäßig `~/.openclaw/workspace`).

 <Tip>
-Wenn Sie möchten, dass Ihr Agent sich etwas merkt, sagen Sie es ihm einfach:
-„Merke dir, dass ich TypeScript bevorzuge.“ Er schreibt es dann in die passende
-Datei.
+Wenn Sie möchten, dass sich Ihr Agent etwas merkt, bitten Sie ihn einfach darum: „Merke dir, dass ich
+TypeScript bevorzuge.“ Er schreibt es in die passende Datei.
 </Tip>

 ## Speicher-Tools

-Der Agent hat zwei Tools für die Arbeit mit Speicher:
+Der Agent verfügt über zwei Tools für die Arbeit mit Speicher:

 - **`memory_search`** -- findet relevante Notizen mithilfe semantischer Suche,
  auch wenn die Formulierung vom Original abweicht.
 - **`memory_get`** -- liest eine bestimmte Speicherdatei oder einen
  Zeilenbereich.

-Beide Tools werden vom aktiven Speicher-Plugin bereitgestellt (Standard:
-`memory-core`).
+Beide Tools werden vom aktiven Speicher-Plugin bereitgestellt (standardmäßig: `memory-core`).
+
+## Begleit-Plugin Memory Wiki
+
+Wenn sich dauerhafter Speicher eher wie eine gepflegte Wissensdatenbank als
+nur wie rohe Notizen verhalten soll, verwenden Sie das gebündelte Plugin `memory-wiki`.
+
+`memory-wiki` kompiliert dauerhaftes Wissen in einen Wiki-Tresor mit:
+
+- deterministischer Seitenstruktur
+- strukturierten Aussagen und Belegen
+- Verfolgung von Widersprüchen und Aktualität
+- generierten Dashboards
+- kompilierten Digests für Agent-/Runtime-Konsumenten
+- wiki-nativen Tools wie `wiki_search`, `wiki_get`, `wiki_apply` und `wiki_lint`
+
+Es ersetzt nicht das aktive Speicher-Plugin. Das aktive Speicher-Plugin ist
+weiterhin für Abruf, Promotion und Dreaming zuständig. `memory-wiki` ergänzt es
+um eine wissensbezogene Ebene mit Herkunftsnachweisen.
+
+Siehe [Memory Wiki](/de/plugins/memory-wiki).

 ## Speichersuche

 Wenn ein Embedding-Anbieter konfiguriert ist, verwendet `memory_search` eine
-**hybride Suche** -- eine Kombination aus Vektorähnlichkeit (semantische
+**hybride Suche** – eine Kombination aus Vektorähnlichkeit (semantische
 Bedeutung) und Schlüsselwortabgleich (exakte Begriffe wie IDs und Codesymbole).
-Dies funktioniert sofort, sobald Sie einen API-Schlüssel für einen unterstützten
+Das funktioniert sofort, sobald Sie einen API-Schlüssel für einen unterstützten
 Anbieter haben.

 <Info>
-OpenClaw erkennt Ihren Embedding-Anbieter automatisch anhand verfügbarer
-API-Schlüssel. Wenn Sie einen konfigurierten OpenAI-, Gemini-, Voyage- oder
-Mistral-Schlüssel haben, ist die Speichersuche automatisch aktiviert.
+OpenClaw erkennt Ihren Embedding-Anbieter automatisch anhand verfügbarer API-Schlüssel. Wenn Sie
+einen OpenAI-, Gemini-, Voyage- oder Mistral-Schlüssel konfiguriert haben, ist
+die Speichersuche automatisch aktiviert.
 </Info>

-Details dazu, wie die Suche funktioniert, zu Tuning-Optionen und zur
-Anbietereinrichtung finden Sie unter
+Ausführliche Informationen zur Funktionsweise der Suche, zu
+Optimierungsoptionen und zur Einrichtung von Anbietern finden Sie unter
 [Memory Search](/de/concepts/memory-search).

 ## Speicher-Backends
@ -77,64 +94,73 @@ SQLite-basiert. Funktioniert sofort mit Schlüsselwortsuche, Vektorähnlichkeit
 hybrider Suche. Keine zusätzlichen Abhängigkeiten.
 </Card>
 <Card title="QMD" icon="search" href="/de/concepts/memory-qmd">
-Local-first-Sidecar mit Reranking, Query Expansion und der Möglichkeit,
+Lokaler Sidecar mit Reranking, Query-Erweiterung und der Möglichkeit,
 Verzeichnisse außerhalb des Workspace zu indizieren.
 </Card>
 <Card title="Honcho" icon="brain" href="/de/concepts/memory-honcho">
-AI-native sitzungsübergreifender Speicher mit Benutzermodellierung,
+KI-nativer sitzungsübergreifender Speicher mit Benutzermodellierung,
 semantischer Suche und Multi-Agent-Bewusstsein. Plugin-Installation.
 </Card>
 </CardGroup>

-## Automatischer Speicher-Flush
+## Wissens-Wiki-Ebene
+
+<CardGroup cols={1}>
+<Card title="Memory Wiki" icon="book" href="/de/plugins/memory-wiki">
+Kompiliert dauerhaften Speicher in einen Wiki-Tresor mit Herkunftsnachweisen,
+Dashboards, Bridge-Modus und Obsidian-freundlichen Workflows.
+</Card>
+</CardGroup>
+
+## Automatische Speicherleerung

 Bevor [Kompaktierung](/de/concepts/compaction) Ihre Unterhaltung zusammenfasst,
-führt OpenClaw einen stillen Durchlauf aus, der den Agenten daran erinnert,
-wichtigen Kontext in Speicherdateien zu speichern. Dies ist standardmäßig
-aktiviert -- Sie müssen nichts konfigurieren.
+führt OpenClaw einen stillen Turn aus, der den Agenten daran erinnert, wichtigen
+Kontext in Speicherdateien zu sichern. Dies ist standardmäßig aktiviert – Sie
+müssen nichts konfigurieren.

 <Tip>
-Der Speicher-Flush verhindert Kontextverlust während der Kompaktierung. Wenn Ihr
-Agent wichtige Fakten in der Unterhaltung hat, die noch nicht in eine Datei
-geschrieben wurden, werden sie automatisch gespeichert, bevor die Zusammenfassung
-erfolgt.
+Die Speicherleerung verhindert Kontextverlust während der Kompaktierung. Wenn Ihr Agent wichtige
+Fakten in der Unterhaltung hat, die noch nicht in eine Datei geschrieben wurden,
+werden sie automatisch gespeichert, bevor die Zusammenfassung erfolgt.
 </Tip>

 ## Dreaming (experimentell)

-Dreaming ist ein optionaler Konsolidierungsdurchlauf im Hintergrund für den
-Speicher. Er sammelt kurzfristige Signale, bewertet Kandidaten und übernimmt nur
-qualifizierte Einträge in den Langzeitspeicher (`MEMORY.md`).
+Dreaming ist ein optionaler Hintergrunddurchlauf zur Konsolidierung von
+Speicher. Dabei werden kurzfristige Signale gesammelt, Kandidaten bewertet und
+nur qualifizierte Elemente in den Langzeitspeicher (`MEMORY.md`) übernommen.

-Es ist darauf ausgelegt, den Langzeitspeicher signalstark zu halten:
+Es soll dafür sorgen, dass der Langzeitspeicher ein starkes Signal-Rausch-Verhältnis behält:

 - **Opt-in**: standardmäßig deaktiviert.
- **Geplant**: Wenn aktiviert, verwaltet `memory-core` automatisch einen
+- **Geplant**: wenn aktiviert, verwaltet `memory-core` automatisch einen
  wiederkehrenden Cron-Job für einen vollständigen Dreaming-Durchlauf.
- **Schwellenwertbasiert**: Übernahmen müssen Schranken für Bewertung,
-  Erinnerungsfrequenz und Query-Diversität bestehen.
+- **Schwellenwertbasiert**: Übernahmen müssen Grenzwerte für Bewertung,
+  Abruffrequenz und Query-Diversität erfüllen.
 - **Überprüfbar**: Phasenzusammenfassungen und Tagebucheinträge werden zur
  menschlichen Überprüfung in `DREAMS.md` geschrieben.

-Zum Phasenverhalten, zu Bewertungssignalen und zu Details des Dream Diary siehe
-[Dreaming (experimental)](/concepts/dreaming).
+Informationen zum Phasenverhalten, zu Bewertungssignalen und Details zum Dream Diary finden Sie unter
+[Dreaming (experimental)](/de/concepts/dreaming).

 ## CLI

 ```bash
-openclaw memory status          # Indexstatus und Anbieter prüfen
-openclaw memory search "query"  # Über die Befehlszeile suchen
-openclaw memory index --force   # Den Index neu aufbauen
+openclaw memory status          # Check index status and provider
+openclaw memory search "query"  # Search from the command line
+openclaw memory index --force   # Rebuild the index
 ```

 ## Weiterführende Informationen

- [Builtin Memory Engine](/de/concepts/memory-builtin) -- Standard-Backend auf SQLite-Basis
- [QMD Memory Engine](/de/concepts/memory-qmd) -- erweitertes Local-first-Sidecar
- [Honcho Memory](/de/concepts/memory-honcho) -- AI-native sitzungsübergreifender Speicher
+- [Builtin Memory Engine](/de/concepts/memory-builtin) -- standardmäßiges SQLite-Backend
+- [QMD Memory Engine](/de/concepts/memory-qmd) -- fortgeschrittener lokaler Sidecar
+- [Honcho Memory](/de/concepts/memory-honcho) -- KI-nativer sitzungsübergreifender Speicher
+- [Memory Wiki](/de/plugins/memory-wiki) -- kompilierter Wissens-Tresor und wiki-native Tools
 - [Memory Search](/de/concepts/memory-search) -- Suchpipeline, Anbieter und
-  Tuning
- [Dreaming (experimental)](/concepts/dreaming) -- Hintergrundübernahme
+  Optimierung
+- [Dreaming (experimental)](/de/concepts/dreaming) -- Hintergrund-Promotion
  von kurzfristigem Abruf in den Langzeitspeicher
 - [Referenz zur Speicherkonfiguration](/de/reference/memory-config) -- alle Konfigurationsoptionen
 - [Kompaktierung](/de/concepts/compaction) -- wie Kompaktierung mit Speicher interagiert
--- a/docs/de/concepts/model-providers.md
+++ b/docs/de/concepts/model-providers.md
@ -1,14 +1,14 @@
 ---
 read_when:
-    - Sie benötigen eine Referenz zur Modelleinrichtung pro Anbieter
+    - Sie benötigen eine Referenz zur Modelleinrichtung für einzelne Anbieter
    - Sie möchten Beispielkonfigurationen oder CLI-Onboarding-Befehle für Modellanbieter
-summary: Überblick über Modellanbieter mit Beispielkonfigurationen + CLI-Abläufen
+summary: Übersicht über Modellanbieter mit Beispielkonfigurationen und CLI-Abläufen
 title: Modellanbieter
 x-i18n:
-    generated_at: "2026-04-08T02:15:50Z"
+    generated_at: "2026-04-08T06:03:09Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 26b36a2bc19a28a7ef39aa8e81a0050fea1d452ac4969122e5cdf8755e690258
+    source_hash: 558ac9e34b67fcc3dd6791a01bebc17e1c34152fa6c5611593d681e8cfa532d9
    source_path: concepts/model-providers.md
    workflow: 15
 ---
@ -16,25 +16,24 @@ x-i18n:
 # Modellanbieter

 Diese Seite behandelt **LLM-/Modellanbieter** (keine Chat-Kanäle wie WhatsApp/Telegram).
-Informationen zu Regeln für die Modellauswahl finden Sie unter [/concepts/models](/de/concepts/models).
+Regeln zur Modellauswahl finden Sie unter [/concepts/models](/de/concepts/models).

 ## Schnellregeln

- Modell-Refs verwenden `provider/model` (Beispiel: `opencode/claude-opus-4-6`).
+- Modellreferenzen verwenden `provider/model` (Beispiel: `opencode/claude-opus-4-6`).
 - Wenn Sie `agents.defaults.models` festlegen, wird es zur Allowlist.
 - CLI-Helfer: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
- Fallback-Laufzeitregeln, Cooldown-Sonden und Persistenz von Sitzungsüberschreibungen
-  sind unter [/concepts/model-failover](/de/concepts/model-failover)
-  dokumentiert.
+- Fallback-Laufzeitregeln, Cooldown-Prüfungen und die Persistenz von Sitzungsüberschreibungen sind in [/concepts/model-failover](/de/concepts/model-failover) dokumentiert.
 - `models.providers.*.models[].contextWindow` sind native Modellmetadaten;
-  `models.providers.*.models[].contextTokens` ist die effektive Laufzeitobergrenze.
- Anbieter-Plugins können Modellkataloge über `registerProvider({ catalog })` einspeisen;
+  `models.providers.*.models[].contextTokens` ist die effektive Laufzeitgrenze.
+- Anbieter-Plugins können Modellkataloge über `registerProvider({ catalog })` einfügen;
  OpenClaw führt diese Ausgabe in `models.providers` zusammen, bevor
  `models.json` geschrieben wird.
- Anbieter-Manifeste können `providerAuthEnvVars` deklarieren, damit generische
-  umgebungsvariablenbasierte Auth-Sonden die Plugin-Laufzeit nicht laden müssen. Die verbleibende Core-Env-Var-Zuordnung
-  ist jetzt nur noch für Nicht-Plugin-/Core-Anbieter und einige Fälle mit generischer Priorität
-  gedacht, etwa Anthropic-Onboarding mit API-Schlüssel zuerst.
+- Anbieter-Manifeste können `providerAuthEnvVars` deklarieren, sodass generische
+  umgebungsvariablenbasierte Auth-Prüfungen die Plugin-Laufzeit nicht laden
+  müssen. Die verbleibende Core-Umgebungsvariablenzuordnung ist jetzt nur noch
+  für Nicht-Plugin-/Core-Anbieter und einige generische Vorrangfälle da, etwa
+  Anthropic-Onboarding mit API-Schlüssel zuerst.
 - Anbieter-Plugins können auch das Laufzeitverhalten des Anbieters über
  `normalizeModelId`, `normalizeTransport`, `normalizeConfig`,
  `applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
@ -52,218 +51,143 @@ Informationen zu Regeln für die Modellauswahl finden Sie unter [/concepts/model
  `augmentModelCatalog`, `isBinaryThinking`, `supportsXHighThinking`,
  `resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`,
  `prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot` und
-  `onModelSelected` besitzen.
- Hinweis: Laufzeit-`capabilities` des Anbieters sind gemeinsame Runner-Metadaten (Anbieterfamilie,
-  Transcript-/Tooling-Besonderheiten, Transport-/Cache-Hinweise). Sie sind nicht
-  dasselbe wie das [öffentliche Fähigkeitsmodell](/de/plugins/architecture#public-capability-model),
-  das beschreibt, was ein Plugin registriert (Text-Inferenz, Sprache usw.).
+  `onModelSelected` steuern.
+- Hinweis: Laufzeit-`capabilities` des Anbieters sind gemeinsame Runner-Metadaten (Anbieterfamilie, Besonderheiten bei Transkripten/Tools, Transport-/Cache-Hinweise). Sie sind nicht dasselbe wie das [öffentliche Fähigkeitsmodell](/de/plugins/architecture#public-capability-model),
+  das beschreibt, was ein Plugin registriert (Textinferenz, Sprache usw.).

 ## Plugin-eigenes Anbieterverhalten

-Anbieter-Plugins können jetzt den Großteil der anbieterbezogenen Logik besitzen, während OpenClaw
-die generische Inferenzschleife beibehält.
+Anbieter-Plugins können jetzt den Großteil der anbieterspezifischen Logik
+übernehmen, während OpenClaw die generische Inferenzschleife beibehält.

 Typische Aufteilung:

- `auth[].run` / `auth[].runNonInteractive`: Der Anbieter besitzt die Onboarding-/Login-
-  Abläufe für `openclaw onboard`, `openclaw models auth` und Headless-Einrichtung
- `wizard.setup` / `wizard.modelPicker`: Der Anbieter besitzt Labels für Auth-Auswahl,
-  Legacy-Aliase, Hinweise zur Allowlist im Onboarding und Einrichtungseinträge in Onboarding-/Modellwählern
+- `auth[].run` / `auth[].runNonInteractive`: Der Anbieter übernimmt Onboarding-/Login-Abläufe für `openclaw onboard`, `openclaw models auth` und Headless-Einrichtung
+- `wizard.setup` / `wizard.modelPicker`: Der Anbieter übernimmt Beschriftungen für Auth-Auswahl, Legacy-Aliasse, Hinweise zur Onboarding-Allowlist und Einrichtungseinträge in Onboarding-/Modellauswahlen
 - `catalog`: Der Anbieter erscheint in `models.providers`
 - `normalizeModelId`: Der Anbieter normalisiert Legacy-/Vorschau-Modell-IDs vor
  Lookup oder Kanonisierung
- `normalizeTransport`: Der Anbieter normalisiert für die Transportfamilie `api` / `baseUrl`
-  vor der generischen Modellzusammenstellung; OpenClaw prüft zuerst den zugeordneten Anbieter,
-  dann andere anbieterpluginfähige Plugins, bis eines den
-  Transport tatsächlich ändert
- `normalizeConfig`: Der Anbieter normalisiert die Konfiguration `models.providers.<id>` vor
-  der Nutzung zur Laufzeit; OpenClaw prüft zuerst den zugeordneten Anbieter, dann andere
-  anbieterpluginfähige Plugins, bis eines die Konfiguration tatsächlich ändert. Wenn kein
-  Anbieter-Hook die Konfiguration umschreibt, normalisieren gebündelte Helfer der Google-Familie weiterhin
-  unterstützte Google-Anbietereinträge.
- `applyNativeStreamingUsageCompat`: Der Anbieter wendet endpunktgesteuerte Kompatibilitäts-Umschreibungen für native Streaming-Nutzung auf Konfigurationsanbieter an
- `resolveConfigApiKey`: Der Anbieter löst Auth über Umgebungsmarker für Konfigurationsanbieter auf,
-  ohne das vollständige Laufzeit-Auth laden zu müssen. `amazon-bedrock` hat hier außerdem einen
-  eingebauten AWS-Umgebungsmarker-Resolver, obwohl die Bedrock-Laufzeit-Auth
-  die Standardkette des AWS SDK verwendet.
- `resolveSyntheticAuth`: Der Anbieter kann Verfügbarkeit für lokale/self-hosted oder andere
-  konfigurationsgestützte Auth bereitstellen, ohne Klartext-Geheimnisse zu speichern
- `shouldDeferSyntheticProfileAuth`: Der Anbieter kann gespeicherte synthetische Profil-
-  Platzhalter mit niedrigerer Priorität markieren als env-/konfigurationsgestützte Auth
- `resolveDynamicModel`: Der Anbieter akzeptiert Modell-IDs, die noch nicht im lokalen
-  statischen Katalog vorhanden sind
- `prepareDynamicModel`: Der Anbieter benötigt vor einem erneuten Versuch der
-  dynamischen Auflösung eine Metadatenaktualisierung
- `normalizeResolvedModel`: Der Anbieter benötigt Umschreibungen für Transport oder Basis-URL
- `contributeResolvedModelCompat`: Der Anbieter liefert Kompatibilitäts-Flags für seine
-  Herstellermodelle, selbst wenn sie über einen anderen kompatiblen Transport ankommen
- `capabilities`: Der Anbieter veröffentlicht Besonderheiten zu Transcript/Tooling/Anbieterfamilie
- `normalizeToolSchemas`: Der Anbieter bereinigt Tool-Schemas, bevor der eingebettete
-  Runner sie sieht
- `inspectToolSchemas`: Der Anbieter stellt transportbezogene Schemawarnungen
-  nach der Normalisierung bereit
- `resolveReasoningOutputMode`: Der Anbieter wählt native oder getaggte
-  Verträge für Reasoning-Ausgaben
- `prepareExtraParams`: Der Anbieter setzt Standardwerte oder normalisiert anfragespezifische Parameter pro Modell
- `createStreamFn`: Der Anbieter ersetzt den normalen Stream-Pfad durch einen
-  vollständig benutzerdefinierten Transport
- `wrapStreamFn`: Der Anbieter wendet Wrapper für Anfrage-Header/Body/Modell-Kompatibilität an
- `resolveTransportTurnState`: Der Anbieter liefert native Transport-
-  Header oder Metadaten pro Turn
- `resolveWebSocketSessionPolicy`: Der Anbieter liefert native WebSocket-Sitzungs-
-  Header oder eine Cooldown-Richtlinie für Sitzungen
- `createEmbeddingProvider`: Der Anbieter besitzt das Verhalten für Memory-Embeddings, wenn es
-  beim Anbieter-Plugin statt beim Core-Embedding-Switchboard liegen soll
- `formatApiKey`: Der Anbieter formatiert gespeicherte Auth-Profile in die zur Laufzeit
-  vom Transport erwartete Zeichenfolge `apiKey`
- `refreshOAuth`: Der Anbieter besitzt die OAuth-Aktualisierung, wenn die gemeinsamen
-  `pi-ai`-Refresher nicht ausreichen
- `buildAuthDoctorHint`: Der Anbieter hängt Reparaturhinweise an, wenn die OAuth-Aktualisierung
-  fehlschlägt
- `matchesContextOverflowError`: Der Anbieter erkennt anbieterspezifische
-  Fehler bei Überschreitung des Kontextfensters, die generische Heuristiken übersehen würden
- `classifyFailoverReason`: Der Anbieter ordnet anbieterspezifische rohe Transport-/API-
-  Fehler Failover-Gründen wie Ratenbegrenzung oder Überlastung zu
+- `normalizeTransport`: Der Anbieter normalisiert `api` / `baseUrl` der
+  Transportfamilie vor der generischen Modellerstellung; OpenClaw prüft zuerst
+  den passenden Anbieter, dann andere hook-fähige Anbieter-Plugins, bis eines
+  den Transport tatsächlich ändert
+- `normalizeConfig`: Der Anbieter normalisiert die Konfiguration
+  `models.providers.<id>`, bevor die Laufzeit sie verwendet; OpenClaw prüft
+  zuerst den passenden Anbieter, dann andere hook-fähige Anbieter-Plugins, bis
+  eines die Konfiguration tatsächlich ändert. Wenn kein Anbieter-Hook die
+  Konfiguration umschreibt, normalisieren gebündelte Google-Familien-Helfer
+  weiterhin unterstützte Google-Anbietereinträge.
+- `applyNativeStreamingUsageCompat`: Der Anbieter wendet endpointgesteuerte native Streaming-Usage-Kompatibilitätsanpassungen für Konfigurationsanbieter an
+- `resolveConfigApiKey`: Der Anbieter löst umgebungsmarkierungsbasierte Auth für Konfigurationsanbieter auf, ohne das vollständige Laufzeit-Auth laden zu müssen. `amazon-bedrock` hat hier außerdem einen eingebauten AWS-Umgebungsmarkierungs-Resolver, obwohl die Bedrock-Laufzeit-Auth die Standardkette des AWS SDK verwendet.
+- `resolveSyntheticAuth`: Der Anbieter kann lokale/self-hosted oder andere
+  konfigurationsgestützte Auth-Verfügbarkeit bereitstellen, ohne Klartext-Geheimnisse zu speichern
+- `shouldDeferSyntheticProfileAuth`: Der Anbieter kann gespeicherte synthetische Profilplatzhalter als nachrangig gegenüber umgebungs-/konfigurationsgestützter Auth markieren
+- `resolveDynamicModel`: Der Anbieter akzeptiert Modell-IDs, die noch nicht im
+  lokalen statischen Katalog vorhanden sind
+- `prepareDynamicModel`: Der Anbieter benötigt eine Metadatenaktualisierung,
+  bevor die dynamische Auflösung erneut versucht wird
+- `normalizeResolvedModel`: Der Anbieter benötigt Umschreibungen für Transport
+  oder Basis-URL
+- `contributeResolvedModelCompat`: Der Anbieter steuert Kompatibilitätsflags für seine Anbietermodelle bei, selbst wenn sie über einen anderen kompatiblen Transport ankommen
+- `capabilities`: Der Anbieter veröffentlicht Besonderheiten bei Transkripten/Tools/Anbieterfamilien
+- `normalizeToolSchemas`: Der Anbieter bereinigt Toolschemas, bevor der eingebettete Runner sie sieht
+- `inspectToolSchemas`: Der Anbieter gibt transportspezifische Schemawarnungen nach der Normalisierung aus
+- `resolveReasoningOutputMode`: Der Anbieter wählt native gegenüber getaggten Reasoning-Ausgabeverträgen
+- `prepareExtraParams`: Der Anbieter legt pro-Modell-Anfrageparameter standardmäßig fest oder normalisiert sie
+- `createStreamFn`: Der Anbieter ersetzt den normalen Stream-Pfad durch einen vollständig benutzerdefinierten Transport
+- `wrapStreamFn`: Der Anbieter wendet Wrapper für Anfrageheader/-body/Modellkompatibilität an
+- `resolveTransportTurnState`: Der Anbieter liefert native Transportheader
+  oder Metadaten pro Zug
+- `resolveWebSocketSessionPolicy`: Der Anbieter liefert native WebSocket-Sitzungsheader oder eine Sitzungs-Cooldown-Richtlinie
+- `createEmbeddingProvider`: Der Anbieter besitzt das Verhalten für Memory-Embeddings, wenn es besser zum Anbieter-Plugin als zur Core-Embedding-Switchboard gehört
+- `formatApiKey`: Der Anbieter formatiert gespeicherte Auth-Profile in den zur Laufzeit erwarteten `apiKey`-String des Transports
+- `refreshOAuth`: Der Anbieter übernimmt OAuth-Aktualisierung, wenn die gemeinsamen `pi-ai`-Refresher nicht ausreichen
+- `buildAuthDoctorHint`: Der Anbieter hängt Reparaturhinweise an, wenn die OAuth-Aktualisierung fehlschlägt
+- `matchesContextOverflowError`: Der Anbieter erkennt anbieterspezifische Fehler bei Kontextfensterüberläufen, die generische Heuristiken übersehen würden
+- `classifyFailoverReason`: Der Anbieter ordnet anbieterspezifische rohe Transport-/API-Fehler Failover-Gründen wie Ratenlimit oder Überlastung zu
 - `isCacheTtlEligible`: Der Anbieter entscheidet, welche Upstream-Modell-IDs Prompt-Cache-TTL unterstützen
- `buildMissingAuthMessage`: Der Anbieter ersetzt den generischen Fehler des Auth-Speichers
-  durch einen anbieterspezifischen Wiederherstellungshinweis
- `suppressBuiltInModel`: Der Anbieter blendet veraltete Upstream-Zeilen aus und kann einen
-  herstellereigenen Fehler für direkte Auflösungsfehler zurückgeben
- `augmentModelCatalog`: Der Anbieter hängt nach
-  Erkennung und Konfigurationszusammenführung synthetische/finale Katalogzeilen an
- `isBinaryThinking`: Der Anbieter besitzt die UX für binäres Denken an/aus
- `supportsXHighThinking`: Der Anbieter aktiviert für ausgewählte Modelle `xhigh`
- `resolveDefaultThinkingLevel`: Der Anbieter besitzt die Standardrichtlinie von `/think` für eine
-  Modellfamilie
- `applyConfigDefaults`: Der Anbieter wendet anbieterspezifische globale Standardwerte
-  bei der Materialisierung der Konfiguration auf Basis von Auth-Modus, Umgebung oder Modellfamilie an
- `isModernModelRef`: Der Anbieter besitzt die Zuordnung bevorzugter Modelle für Live-/Smoke-Tests
- `prepareRuntimeAuth`: Der Anbieter wandelt ein konfiguriertes Credential in ein kurzlebiges
-  Laufzeit-Token um
- `resolveUsageAuth`: Der Anbieter löst Credentials für Nutzung/Quota für `/usage`
-  und verwandte Status-/Berichtsoberflächen auf
- `fetchUsageSnapshot`: Der Anbieter besitzt das Abrufen/Parsen des Nutzungsendpunkts, während
-  der Core weiterhin die Zusammenfassungs-Shell und Formatierung besitzt
- `onModelSelected`: Der Anbieter führt nach der Auswahl Nebeneffekte wie
-  Telemetrie oder anbieterbezogene Sitzungsbuchhaltung aus
+- `buildMissingAuthMessage`: Der Anbieter ersetzt den generischen Fehler des Auth-Speichers durch einen anbieterspezifischen Wiederherstellungshinweis
+- `suppressBuiltInModel`: Der Anbieter blendet veraltete Upstream-Zeilen aus und kann für direkte Auflösungsfehler einen anbieterdefinierten Fehler zurückgeben
+- `augmentModelCatalog`: Der Anbieter hängt nach Erkennung und Konfigurationszusammenführung synthetische/abschließende Katalogzeilen an
+- `isBinaryThinking`: Der Anbieter besitzt die binäre Ein/Aus-Thinking-UX
+- `supportsXHighThinking`: Der Anbieter aktiviert `xhigh` für ausgewählte Modelle
+- `resolveDefaultThinkingLevel`: Der Anbieter besitzt die standardmäßige `/think`-Richtlinie für eine Modellfamilie
+- `applyConfigDefaults`: Der Anbieter wendet anbieterspezifische globale Standardwerte während der Konfigurationsmaterialisierung anhand von Auth-Modus, Umgebung oder Modellfamilie an
+- `isModernModelRef`: Der Anbieter besitzt die Zuordnung bevorzugter Modelle für live/smoke
+- `prepareRuntimeAuth`: Der Anbieter wandelt konfigurierte Anmeldedaten in ein kurzlebiges Laufzeittoken um
+- `resolveUsageAuth`: Der Anbieter löst Nutzungs-/Kontingent-Anmeldedaten für `/usage` und verwandte Status-/Berichtsoberflächen auf
+- `fetchUsageSnapshot`: Der Anbieter übernimmt Abruf/Parsing des Nutzungsendpunkts, während der Core weiterhin die Zusammenfassungs-Hülle und Formatierung übernimmt
+- `onModelSelected`: Der Anbieter führt Seiteneffekte nach der Modellauswahl aus, etwa Telemetrie oder anbieterdefinierte Sitzungsbuchhaltung

 Aktuelle gebündelte Beispiele:

- `anthropic`: Vorwärtskompatibler Claude-4.6-Fallback, Hinweise zur Auth-Reparatur, Abruf von Nutzungsendpunkten,
-  Cache-TTL-/Anbieterfamilien-Metadaten und Auth-bewusste globale
-  Konfigurationsstandardwerte
- `amazon-bedrock`: Anbieter-eigene Erkennung von Kontextüberläufen und
-  Klassifizierung von Failover-Gründen für Bedrock-spezifische Throttle-/Not-ready-Fehler sowie
-  die gemeinsame Replay-Familie `anthropic-by-model` für Claude-exklusive Replay-Richtlinien-
-  Schutzmaßnahmen auf Anthropic-Datenverkehr
- `anthropic-vertex`: Claude-exklusive Replay-Richtlinien-Schutzmaßnahmen auf Anthropic-Message-
-  Datenverkehr
- `openrouter`: Durchgereichte Modell-IDs, Anfrage-Wrapper, Hinweise zu Anbieterfähigkeiten,
-  Bereinigung von Gemini-Thought-Signatures bei proxy-basiertem Gemini-Datenverkehr,
-  Proxy-Reasoning-Injektion über die Stream-Familie `openrouter-thinking`, Weiterleitung
-  von Routing-Metadaten und Cache-TTL-Richtlinie
- `github-copilot`: Onboarding/Geräte-Login, vorwärtskompatibler Modell-Fallback,
-  Hinweise zu Claude-Thinking-Transcripts, Austausch von Laufzeit-Tokens und Abruf von Nutzungsendpunkten
- `openai`: Vorwärtskompatibler GPT-5.4-Fallback, direkte OpenAI-Transport-
-  Normalisierung, Codex-bewusste Hinweise bei fehlender Auth, Unterdrückung von Spark, synthetische
-  OpenAI-/Codex-Katalogzeilen, Thinking-/Live-Modell-Richtlinie, Normalisierung von Aliasen für
-  Usage-Token (`input` / `output` und `prompt` / `completion`-Familien), die
-  gemeinsame Stream-Familie `openai-responses-defaults` für native OpenAI-/Codex-
-  Wrapper, Metadaten zur Anbieterfamilie, gebündelte Registrierung von Bildgenerierungsanbietern
-  für `gpt-image-1` und gebündelte Registrierung von Videogenerierungsanbietern
-  für `sora-2`
- `google` und `google-gemini-cli`: Vorwärtskompatibler Gemini-3.1-Fallback,
-  native Gemini-Replay-Validierung, Bereinigung von Bootstrap-Replays, getaggter
-  Modus für Reasoning-Ausgaben, Modern-Model-Matching, gebündelte Registrierung von Bildgenerierungs-
-  anbietern für Gemini-Bildvorschau-Modelle und gebündelte
-  Registrierung von Videogenerierungsanbietern für Veo-Modelle; Gemini-CLI-OAuth besitzt außerdem
-  Tokenformatierung für Auth-Profile, Parsing von Usage-Token und Abruf von Quota-Endpunkten
-  für Nutzungsoberflächen
- `moonshot`: Gemeinsamer Transport, plugin-eigene Normalisierung von Thinking-Payloads
- `kilocode`: Gemeinsamer Transport, plugin-eigene Anfrage-Header, Reasoning-Payload-
-  Normalisierung, Bereinigung von Thought-Signatures bei Proxy-Gemini und Cache-TTL-
-  Richtlinie
- `zai`: Vorwärtskompatibler GLM-5-Fallback, Standardwerte für `tool_stream`, Cache-TTL-
-  Richtlinie, Richtlinie für binäres Denken/Live-Modelle sowie Auth + Quota-Abruf für Nutzung;
-  unbekannte `glm-5*`-IDs werden aus der gebündelten Vorlage `glm-4.7` synthetisiert
- `xai`: Native Responses-Transport-Normalisierung, Umschreibungen von `/fast`-Aliasen für
-  schnelle Grok-Varianten, Standardwert für `tool_stream`, xAI-spezifische Bereinigung von Tool-Schemas /
-  Reasoning-Payloads und gebündelte Registrierung von Videogenerierungsanbietern
-  für `grok-imagine-video`
- `mistral`: Plugin-eigene Fähigkeitsmetadaten
- `opencode` und `opencode-go`: Plugin-eigene Fähigkeitsmetadaten plus
-  Bereinigung von Thought-Signatures bei Proxy-Gemini
- `alibaba`: Plugin-eigener Videogenerierungskatalog für direkte Wan-Modell-Refs
-  wie `alibaba/wan2.6-t2v`
- `byteplus`: Plugin-eigene Kataloge plus gebündelte Registrierung von Videogenerierungsanbietern
-  für Seedance-Modelle für Text-zu-Video/Bild-zu-Video
- `fal`: gebündelte Registrierung von Videogenerierungsanbietern für gehostete Drittanbieter-
-  Registrierung von Bildgenerierungsanbietern für FLUX-Bildmodelle plus gebündelte
-  Registrierung von Videogenerierungsanbietern für gehostete Drittanbieter-Videomodelle
+- `anthropic`: Claude-4.6-Vorwärtskompatibilitäts-Fallback, Auth-Reparaturhinweise, Abruf des Nutzungsendpunkts, Cache-TTL-/Anbieterfamilien-Metadaten und auth-bewusste globale Konfigurationsstandards
+- `amazon-bedrock`: anbieterdefinierte Erkennung von Kontextüberlauf und Klassifizierung von Failover-Gründen für Bedrock-spezifische Throttle-/Not-ready-Fehler sowie die gemeinsame Replay-Familie `anthropic-by-model` für Claude-spezifische Replay-Richtlinienwächter auf Anthropic-Datenverkehr
+- `anthropic-vertex`: Claude-spezifische Replay-Richtlinienwächter für Anthropic-Messages-Datenverkehr
+- `openrouter`: Durchreichen von Modell-IDs, Anfrage-Wrapper, Hinweise zu Anbieterfähigkeiten, Bereinigung von Gemini-Thought-Signatures bei Proxy-Gemini-Datenverkehr, Proxy-Reasoning-Injektion über die Stream-Familie `openrouter-thinking`, Weiterleitung von Routing-Metadaten und Cache-TTL-Richtlinie
+- `github-copilot`: Onboarding/Gerätelogin, Vorwärtskompatibilitäts-Fallback für Modelle, Claude-Thinking-Transkripthinweise, Laufzeit-Token-Austausch und Abruf des Nutzungsendpunkts
+- `openai`: GPT-5.4-Vorwärtskompatibilitäts-Fallback, direkte OpenAI-Transportnormalisierung, Codex-bewusste Missing-Auth-Hinweise, Spark-Unterdrückung, synthetische OpenAI-/Codex-Katalogzeilen, Thinking-/Live-Modell-Richtlinie, Alias-Normalisierung von Usage-Token (`input` / `output` und `prompt` / `completion`-Familien), die gemeinsame Stream-Familie `openai-responses-defaults` für native OpenAI-/Codex-Wrapper, Anbieterfamilien-Metadaten, gebündelte Registrierung des Bildgenerierungsanbieters für `gpt-image-1` und gebündelte Registrierung des Videogenerierungsanbieters für `sora-2`
+- `google` und `google-gemini-cli`: Gemini-3.1-Vorwärtskompatibilitäts-Fallback, native Gemini-Replay-Validierung, Bereinigung von Bootstrap-Replays, getaggter Reasoning-Ausgabemodus, Modern-Model-Matching, gebündelte Registrierung des Bildgenerierungsanbieters für Gemini-Image-Preview-Modelle und gebündelte Registrierung des Videogenerierungsanbieters für Veo-Modelle; Gemini CLI OAuth besitzt außerdem die Formatierung von Auth-Profil-Token, Parsing von Usage-Token und Abruf des Kontingentendpunkts für Nutzungsoberflächen
+- `moonshot`: gemeinsamer Transport, plugin-eigene Normalisierung von Thinking-Payloads
+- `kilocode`: gemeinsamer Transport, plugin-eigene Anfrageheader, Normalisierung von Reasoning-Payloads, Bereinigung von Proxy-Gemini-Thought-Signatures und Cache-TTL-Richtlinie
+- `zai`: GLM-5-Vorwärtskompatibilitäts-Fallback, Standardwerte für `tool_stream`, Cache-TTL-Richtlinie, Richtlinie für binäres Thinking/live-Modelle sowie Usage-Auth und Abruf von Kontingenten; unbekannte `glm-5*`-IDs werden aus der gebündelten Vorlage `glm-4.7` synthetisiert
+- `xai`: native Normalisierung des Responses-Transports, Umschreibungen des Alias `/fast` für schnelle Grok-Varianten, Standard-`tool_stream`, xAI-spezifische Bereinigung von Toolschemas / Reasoning-Payloads und gebündelte Registrierung des Videogenerierungsanbieters für `grok-imagine-video`
+- `mistral`: plugin-eigene Fähigkeitsmetadaten
+- `opencode` und `opencode-go`: plugin-eigene Fähigkeitsmetadaten sowie Bereinigung von Proxy-Gemini-Thought-Signatures
+- `alibaba`: plugin-eigener Videogenerierungskatalog für direkte Wan-Modellreferenzen wie `alibaba/wan2.6-t2v`
+- `byteplus`: plugin-eigene Kataloge sowie gebündelte Registrierung des Videogenerierungsanbieters für Seedance-Text-zu-Video-/Bild-zu-Video-Modelle
+- `fal`: gebündelte Registrierung des Videogenerierungsanbieters für gehostete Drittanbieter-Registrierung des Bildgenerierungsanbieters für FLUX-Bildmodelle sowie gebündelte Registrierung des Videogenerierungsanbieters für gehostete Drittanbieter-Videomodelle
 - `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`,
  `stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` und `volcengine`:
  nur plugin-eigene Kataloge
- `qwen`: Plugin-eigene Kataloge für Textmodelle plus gemeinsame
-  Registrierungen von Media-Understanding- und Videogenerierungsanbietern für seine
-  multimodalen Oberflächen; Qwen-Videogenerierung verwendet die Standard-DashScope-Video-
-  Endpunkte mit gebündelten Wan-Modellen wie `wan2.6-t2v` und `wan2.7-r2v`
- `runway`: Plugin-eigene Registrierung von Videogenerierungsanbietern für native,
-  auf Aufgaben basierende Runway-Modelle wie `gen4.5`
- `minimax`: Plugin-eigene Kataloge, gebündelte Registrierung von Videogenerierungsanbietern
-  für Hailuo-Videomodelle, gebündelte Registrierung von Bildgenerierungsanbietern
-  für `image-01`, hybride Auswahl von Anthropic-/OpenAI-Replay-Richtlinien
-  sowie Auth-/Snapshot-Logik für Nutzung
- `together`: Plugin-eigene Kataloge plus gebündelte Registrierung von Videogenerierungsanbietern
-  für Wan-Videomodelle
- `xiaomi`: Plugin-eigene Kataloge plus Auth-/Snapshot-Logik für Nutzung
+- `qwen`: plugin-eigene Kataloge für Textmodelle sowie gemeinsame Registrierungen von Media-Understanding- und Videogenerierungsanbietern für seine multimodalen Oberflächen; Qwen-Videogenerierung verwendet die Standard-DashScope-Videoendpunkte mit gebündelten Wan-Modellen wie `wan2.6-t2v` und `wan2.7-r2v`
+- `runway`: plugin-eigene Registrierung des Videogenerierungsanbieters für native aufgabenbasierte Runway-Modelle wie `gen4.5`
+- `minimax`: plugin-eigene Kataloge, gebündelte Registrierung des Videogenerierungsanbieters für Hailuo-Videomodelle, gebündelte Registrierung des Bildgenerierungsanbieters für `image-01`, hybride Auswahl von Anthropic-/OpenAI-Replay-Richtlinien sowie Usage-Auth-/Snapshot-Logik
+- `together`: plugin-eigene Kataloge sowie gebündelte Registrierung des Videogenerierungsanbieters für Wan-Videomodelle
+- `xiaomi`: plugin-eigene Kataloge sowie Usage-Auth-/Snapshot-Logik

 Das gebündelte Plugin `openai` besitzt jetzt beide Anbieter-IDs: `openai` und
 `openai-codex`.

-Damit sind Anbieter abgedeckt, die weiterhin in die normalen Transporte von OpenClaw passen. Ein Anbieter,
-der einen vollständig benutzerdefinierten Anfrage-Executor benötigt, ist eine separate, tiefergehende
-Erweiterungsoberfläche.
+Damit sind Anbieter abgedeckt, die noch in die normalen Transporte von OpenClaw passen. Ein Anbieter, der einen vollständig benutzerdefinierten Anfrage-Executor benötigt, ist eine separate, tiefere Erweiterungsoberfläche.

 ## API-Schlüsselrotation

- Unterstützt generische Rotation für ausgewählte Anbieter.
+- Unterstützt generische Anbieterrotation für ausgewählte Anbieter.
 - Konfigurieren Sie mehrere Schlüssel über:
  - `OPENCLAW_LIVE_<PROVIDER>_KEY` (einzelne Live-Überschreibung, höchste Priorität)
  - `<PROVIDER>_API_KEYS` (durch Komma oder Semikolon getrennte Liste)
  - `<PROVIDER>_API_KEY` (primärer Schlüssel)
  - `<PROVIDER>_API_KEY_*` (nummerierte Liste, z. B. `<PROVIDER>_API_KEY_1`)
 - Für Google-Anbieter wird `GOOGLE_API_KEY` zusätzlich als Fallback einbezogen.
- Die Schlüsselreihenfolge bewahrt die Priorität und entfernt doppelte Werte.
- Anfragen werden nur bei Antworten mit Ratenbegrenzung mit dem nächsten Schlüssel erneut versucht (zum
-  Beispiel `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
+- Die Reihenfolge der Schlüsselauswahl bewahrt die Priorität und dedupliziert Werte.
+- Anfragen werden nur bei Antworten mit Ratenlimit mit dem nächsten Schlüssel wiederholt (zum Beispiel `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
 concurrent requests`, `ThrottlingException`, `concurrency limit reached`,
-  `workers_ai ... quota limit exceeded` oder periodische Meldungen über Nutzungslimits).
- Fehler ohne Ratenbegrenzung schlagen sofort fehl; es wird keine Schlüsselrotation versucht.
- Wenn alle Kandidatenschlüssel fehlschlagen, wird der letzte Fehler aus dem letzten Versuch zurückgegeben.
+  `workers_ai ... quota limit exceeded` oder periodische Usage-Limit-Meldungen).
+- Fehler ohne Ratenlimit schlagen sofort fehl; es wird keine Schlüsselrotation versucht.
+- Wenn alle Kandidatenschlüssel fehlschlagen, wird der letzte Fehler des letzten Versuchs zurückgegeben.

 ## Integrierte Anbieter (pi-ai-Katalog)

-OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **keine**
-`models.providers`-Konfiguration; setzen Sie einfach Auth und wählen Sie ein Modell aus.
+OpenClaw wird mit dem pi‑ai-Katalog ausgeliefert. Diese Anbieter erfordern **keine**
+`models.providers`-Konfiguration; legen Sie einfach Auth fest und wählen Sie ein Modell aus.

 ### OpenAI

 - Anbieter: `openai`
 - Auth: `OPENAI_API_KEY`
- Optionale Rotation: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2`, plus `OPENCLAW_LIVE_OPENAI_KEY` (einzelne Überschreibung)
+- Optionale Rotation: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2` sowie `OPENCLAW_LIVE_OPENAI_KEY` (einzelne Überschreibung)
 - Beispielmodelle: `openai/gpt-5.4`, `openai/gpt-5.4-pro`
 - CLI: `openclaw onboard --auth-choice openai-api-key`
- Standardtransport ist `auto` (WebSocket zuerst, SSE-Fallback)
+- Der Standardtransport ist `auto` (zuerst WebSocket, dann SSE als Fallback)
 - Pro Modell überschreiben über `agents.defaults.models["openai/<model>"].params.transport` (`"sse"`, `"websocket"` oder `"auto"`)
- Aufwärmen für OpenAI Responses WebSocket ist standardmäßig über `params.openaiWsWarmup` (`true`/`false`) aktiviert
- Priority Processing von OpenAI kann über `agents.defaults.models["openai/<model>"].params.serviceTier` aktiviert werden
- `/fast` und `params.fastMode` ordnen direkte `openai/*`-Responses-Anfragen auf `service_tier=priority` bei `api.openai.com` zu
- Verwenden Sie `params.serviceTier`, wenn Sie statt des gemeinsamen Schalters `/fast` einen expliziten Tier-Wert möchten
- Versteckte OpenClaw-Attributionsheader (`originator`, `version`,
-  `User-Agent`) gelten nur für nativen OpenAI-Datenverkehr zu `api.openai.com`, nicht
-  für generische OpenAI-kompatible Proxys
- Native OpenAI-Routen behalten außerdem Responses-`store`, Prompt-Cache-Hinweise und
-  OpenAI-Reasoning-kompatible Payload-Anpassung bei; Proxy-Routen nicht
+- OpenAI-Responses-WebSocket-Aufwärmen ist standardmäßig über `params.openaiWsWarmup` aktiviert (`true`/`false`)
+- OpenAI-Prioritätsverarbeitung kann über `agents.defaults.models["openai/<model>"].params.serviceTier` aktiviert werden
+- `/fast` und `params.fastMode` ordnen direkte `openai/*`-Responses-Anfragen auf `api.openai.com` `service_tier=priority` zu
+- Verwenden Sie `params.serviceTier`, wenn Sie einen expliziten Tier statt des gemeinsamen `/fast`-Schalters möchten
+- Versteckte OpenClaw-Zuordnungsheader (`originator`, `version`,
+  `User-Agent`) werden nur auf nativem OpenAI-Datenverkehr zu `api.openai.com` angewendet, nicht auf generischen OpenAI-kompatiblen Proxys
+- Native OpenAI-Routen behalten auch Responses-`store`, Prompt-Cache-Hinweise und OpenAI-Reasoning-Kompatibilitäts-Payload-Shaping bei; Proxy-Routen nicht
 - `openai/gpt-5.3-codex-spark` wird in OpenClaw absichtlich unterdrückt, weil die Live-OpenAI-API es ablehnt; Spark wird als nur für Codex behandelt

 ```json5
@ -276,12 +200,12 @@ OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **ke

 - Anbieter: `anthropic`
 - Auth: `ANTHROPIC_API_KEY`
- Optionale Rotation: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2`, plus `OPENCLAW_LIVE_ANTHROPIC_KEY` (einzelne Überschreibung)
+- Optionale Rotation: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2` sowie `OPENCLAW_LIVE_ANTHROPIC_KEY` (einzelne Überschreibung)
 - Beispielmodell: `anthropic/claude-opus-4-6`
 - CLI: `openclaw onboard --auth-choice apiKey`
- Direkte öffentliche Anthropic-Anfragen unterstützen den gemeinsamen Schalter `/fast` und `params.fastMode`, einschließlich per API-Schlüssel und OAuth authentifiziertem Datenverkehr an `api.anthropic.com`; OpenClaw ordnet dies Anthropic-`service_tier` zu (`auto` vs `standard_only`)
- Hinweis zu Anthropic: Mitarbeiter von Anthropic haben uns mitgeteilt, dass die Nutzung im Stil von OpenClaw Claude CLI wieder erlaubt ist, daher behandelt OpenClaw die Wiederverwendung von Claude CLI und die Nutzung von `claude -p` für diese Integration als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht.
- Das Anthropic-Setup-Token bleibt als unterstützter OpenClaw-Tokenpfad verfügbar, OpenClaw bevorzugt nun jedoch die Wiederverwendung von Claude CLI und `claude -p`, wenn verfügbar.
+- Direkte öffentliche Anthropic-Anfragen unterstützen den gemeinsamen `/fast`-Schalter und `params.fastMode`, einschließlich per API-Schlüssel und OAuth authentifiziertem Datenverkehr an `api.anthropic.com`; OpenClaw ordnet dies Anthropic-`service_tier` zu (`auto` vs `standard_only`)
+- Anthropic-Hinweis: Anthropic-Mitarbeiter haben uns mitgeteilt, dass OpenClaw-artige Claude-CLI-Nutzung wieder erlaubt ist, daher behandelt OpenClaw die Wiederverwendung von Claude CLI und die Nutzung von `claude -p` für diese Integration als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht.
+- Anthropic-Setup-Token bleibt als unterstützter OpenClaw-Tokenpfad verfügbar, aber OpenClaw bevorzugt jetzt, wenn verfügbar, die Wiederverwendung von Claude CLI und `claude -p`.

 ```json5
 {
@ -295,16 +219,16 @@ OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **ke
 - Auth: OAuth (ChatGPT)
 - Beispielmodell: `openai-codex/gpt-5.4`
 - CLI: `openclaw onboard --auth-choice openai-codex` oder `openclaw models auth login --provider openai-codex`
- Standardtransport ist `auto` (WebSocket zuerst, SSE-Fallback)
+- Der Standardtransport ist `auto` (zuerst WebSocket, dann SSE als Fallback)
 - Pro Modell überschreiben über `agents.defaults.models["openai-codex/<model>"].params.transport` (`"sse"`, `"websocket"` oder `"auto"`)
- `params.serviceTier` wird ebenfalls bei nativen Codex-Responses-Anfragen (`chatgpt.com/backend-api`) weitergeleitet
- Versteckte OpenClaw-Attributionsheader (`originator`, `version`,
-  `User-Agent`) werden nur an nativen Codex-Datenverkehr zu
-  `chatgpt.com/backend-api` angehängt, nicht an generische OpenAI-kompatible Proxys
- Verwendet denselben Schalter `/fast` und dieselbe Konfiguration `params.fastMode` wie direktes `openai/*`; OpenClaw ordnet dies `service_tier=priority` zu
- `openai-codex/gpt-5.3-codex-spark` bleibt verfügbar, wenn der Codex-OAuth-Katalog es anbietet; abhängig von Berechtigungen
- `openai-codex/gpt-5.4` behält das native `contextWindow = 1050000` und ein standardmäßiges Laufzeit-`contextTokens = 272000`; überschreiben Sie die Laufzeitobergrenze mit `models.providers.openai-codex.models[].contextTokens`
- Richtlinienhinweis: OpenAI-Codex-OAuth wird ausdrücklich für externe Tools/Workflows wie OpenClaw unterstützt.
+- `params.serviceTier` wird auch bei nativen Codex-Responses-Anfragen (`chatgpt.com/backend-api`) weitergeleitet
+- Versteckte OpenClaw-Zuordnungsheader (`originator`, `version`,
+  `User-Agent`) werden nur auf nativem Codex-Datenverkehr zu
+  `chatgpt.com/backend-api` angehängt, nicht auf generischen OpenAI-kompatiblen Proxys
+- Verwendet denselben `/fast`-Schalter und dieselbe `params.fastMode`-Konfiguration wie direktes `openai/*`; OpenClaw ordnet dies `service_tier=priority` zu
+- `openai-codex/gpt-5.3-codex-spark` bleibt verfügbar, wenn der Codex-OAuth-Katalog es bereitstellt; abhängig von Berechtigungen
+- `openai-codex/gpt-5.4` behält natives `contextWindow = 1050000` und ein Standard-Laufzeit-`contextTokens = 272000`; überschreiben Sie die Laufzeitgrenze mit `models.providers.openai-codex.models[].contextTokens`
+- Richtlinienhinweis: OpenAI-Codex-OAuth wird explizit für externe Tools/Workflows wie OpenClaw unterstützt.

 ```json5
 {
@ -324,11 +248,11 @@ OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **ke
 }
 ```

-### Andere gehostete Optionen im Abonnementstil
+### Andere abonnementsbasierte gehostete Optionen

- [Qwen Cloud](/de/providers/qwen): Oberfläche des Qwen-Cloud-Anbieters plus Zuordnung von Endpunkten für Alibaba DashScope und Coding Plan
- [MiniMax](/de/providers/minimax): OAuth- oder API-Schlüsselzugriff für MiniMax Coding Plan
- [GLM Models](/de/providers/glm): Z.AI Coding Plan oder allgemeine API-Endpunkte
+- [Qwen Cloud](/de/providers/qwen): Qwen-Cloud-Anbieteroberfläche sowie Alibaba-DashScope- und Coding-Plan-Endpunktzuordnung
+- [MiniMax](/de/providers/minimax): MiniMax-Coding-Plan-OAuth- oder API-Schlüsselzugriff
+- [GLM Models](/de/providers/glm): Z.AI-Coding-Plan oder allgemeine API-Endpunkte

 ### OpenCode

@ -348,29 +272,28 @@ OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **ke

 - Anbieter: `google`
 - Auth: `GEMINI_API_KEY`
- Optionale Rotation: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, `GOOGLE_API_KEY` als Fallback und `OPENCLAW_LIVE_GEMINI_KEY` (einzelne Überschreibung)
+- Optionale Rotation: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, `GOOGLE_API_KEY` als Fallback sowie `OPENCLAW_LIVE_GEMINI_KEY` (einzelne Überschreibung)
 - Beispielmodelle: `google/gemini-3.1-pro-preview`, `google/gemini-3-flash-preview`
 - Kompatibilität: Legacy-OpenClaw-Konfiguration mit `google/gemini-3.1-flash-preview` wird zu `google/gemini-3-flash-preview` normalisiert
 - CLI: `openclaw onboard --auth-choice gemini-api-key`
- Direkte Gemini-Ausführungen akzeptieren außerdem `agents.defaults.models["google/<model>"].params.cachedContent`
-  (oder das Legacy-`cached_content`), um einen anbieter-nativen
-  Handle `cachedContents/...` weiterzuleiten; Gemini-Cache-Treffer erscheinen in OpenClaw als `cacheRead`
+- Direkte Gemini-Läufe akzeptieren außerdem `agents.defaults.models["google/<model>"].params.cachedContent`
+  (oder das Legacy-`cached_content`), um einen anbieterinternen
+  `cachedContents/...`-Handle weiterzuleiten; Gemini-Cache-Treffer erscheinen als OpenClaw-`cacheRead`

 ### Google Vertex und Gemini CLI

 - Anbieter: `google-vertex`, `google-gemini-cli`
- Auth: Vertex verwendet gcloud ADC; Gemini CLI verwendet seinen OAuth-Flow
- Achtung: Gemini-CLI-OAuth in OpenClaw ist eine inoffizielle Integration. Einige Nutzer haben nach der Verwendung von Drittanbieter-Clients von Einschränkungen ihres Google-Kontos berichtet. Prüfen Sie die Google-Bedingungen und verwenden Sie ein nicht kritisches Konto, wenn Sie sich dafür entscheiden.
- Gemini-CLI-OAuth wird als Teil des gebündelten Plugins `google` ausgeliefert.
+- Auth: Vertex verwendet gcloud ADC; Gemini CLI verwendet seinen OAuth-Ablauf
+- Vorsicht: Gemini-CLI-OAuth in OpenClaw ist eine inoffizielle Integration. Einige Nutzer haben von Einschränkungen ihres Google-Kontos nach der Nutzung von Drittanbieter-Clients berichtet. Prüfen Sie die Google-Nutzungsbedingungen und verwenden Sie ein nicht kritisches Konto, wenn Sie sich dafür entscheiden.
+- Gemini-CLI-OAuth wird als Teil des gebündelten `google`-Plugins ausgeliefert.
  - Installieren Sie zuerst Gemini CLI:
    - `brew install gemini-cli`
    - oder `npm install -g @google/gemini-cli`
  - Aktivieren: `openclaw plugins enable google`
-  - Anmelden: `openclaw models auth login --provider google-gemini-cli --set-default`
+  - Login: `openclaw models auth login --provider google-gemini-cli --set-default`
  - Standardmodell: `google-gemini-cli/gemini-3-flash-preview`
-  - Hinweis: Sie fügen **keine** Client-ID oder kein Secret in `openclaw.json` ein. Der CLI-Login-Flow speichert
-    Tokens in Auth-Profilen auf dem Gateway-Host.
-  - Wenn Anfragen nach der Anmeldung fehlschlagen, setzen Sie `GOOGLE_CLOUD_PROJECT` oder `GOOGLE_CLOUD_PROJECT_ID` auf dem Gateway-Host.
+  - Hinweis: Sie fügen **keine** Client-ID oder kein Secret in `openclaw.json` ein. Der CLI-Login-Ablauf speichert Tokens in Auth-Profilen auf dem Gateway-Host.
+  - Wenn Anfragen nach dem Login fehlschlagen, setzen Sie `GOOGLE_CLOUD_PROJECT` oder `GOOGLE_CLOUD_PROJECT_ID` auf dem Gateway-Host.
  - Gemini-CLI-JSON-Antworten werden aus `response` geparst; die Nutzung fällt auf
    `stats` zurück, wobei `stats.cached` zu OpenClaw-`cacheRead` normalisiert wird.

@ -378,10 +301,10 @@ OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **ke

 - Anbieter: `zai`
 - Auth: `ZAI_API_KEY`
- Beispielmodell: `zai/glm-5`
+- Beispielmodell: `zai/glm-5.1`
 - CLI: `openclaw onboard --auth-choice zai-api-key`
-  - Aliase: `z.ai/*` und `z-ai/*` werden zu `zai/*` normalisiert
-  - `zai-api-key` erkennt automatisch den passenden Z.AI-Endpunkt; `zai-coding-global`, `zai-coding-cn`, `zai-global` und `zai-cn` erzwingen eine bestimmte Oberfläche
+  - Aliasse: `z.ai/*` und `z-ai/*` werden zu `zai/*` normalisiert
+  - `zai-api-key` erkennt den passenden Z.AI-Endpunkt automatisch; `zai-coding-global`, `zai-coding-cn`, `zai-global` und `zai-cn` erzwingen eine bestimmte Oberfläche

 ### Vercel AI Gateway

@ -397,38 +320,31 @@ OpenClaw wird mit dem pi-ai-Katalog ausgeliefert. Diese Anbieter benötigen **ke
 - Beispielmodell: `kilocode/kilo/auto`
 - CLI: `openclaw onboard --auth-choice kilocode-api-key`
 - Basis-URL: `https://api.kilo.ai/api/gateway/`
- Der statische Fallback-Katalog enthält `kilocode/kilo/auto`; die Live-
-  Erkennung über `https://api.kilo.ai/api/gateway/models` kann den Laufzeit-
-  Katalog weiter erweitern.
+- Der statische Fallback-Katalog enthält `kilocode/kilo/auto`; die Live-Erkennung unter
+  `https://api.kilo.ai/api/gateway/models` kann den Laufzeitkatalog weiter
+  erweitern.
 - Das genaue Upstream-Routing hinter `kilocode/kilo/auto` gehört zu Kilo Gateway
-  und ist nicht fest in OpenClaw codiert.
+  und ist nicht in OpenClaw fest codiert.

-Einzelheiten zur Einrichtung finden Sie unter [/providers/kilocode](/de/providers/kilocode).
+Siehe [/providers/kilocode](/de/providers/kilocode) für Einrichtungsdetails.

 ### Andere gebündelte Anbieter-Plugins

 - OpenRouter: `openrouter` (`OPENROUTER_API_KEY`)
 - Beispielmodell: `openrouter/auto`
- OpenClaw wendet die von OpenRouter dokumentierten App-Attributionsheader nur an,
-  wenn die Anfrage tatsächlich an `openrouter.ai` geht
- OpenRouter-spezifische Anthropic-`cache_control`-Marker sind ebenso auf
-  verifizierte OpenRouter-Routen beschränkt, nicht auf beliebige Proxy-URLs
- OpenRouter bleibt auf dem Proxy-Stil-Pfad für OpenAI-Kompatibilität, daher wird keine
-  native, nur für OpenAI bestimmte Anfrageanpassung (`serviceTier`, Responses-`store`,
-  Prompt-Cache-Hinweise, OpenAI-Reasoning-kompatible Payloads) weitergeleitet
- Gemini-basierte OpenRouter-Refs behalten nur die Bereinigung von Thought-Signatures bei Proxy-Gemini
-  bei; native Gemini-Replay-Validierung und Bootstrap-Umschreibungen bleiben deaktiviert
+- OpenClaw wendet die dokumentierten App-Zuordnungsheader von OpenRouter nur an, wenn die Anfrage tatsächlich an `openrouter.ai` geht
+- OpenRouter-spezifische Anthropic-`cache_control`-Marker werden entsprechend nur für verifizierte OpenRouter-Routen aktiviert, nicht für beliebige Proxy-URLs
+- OpenRouter bleibt auf dem proxyartigen OpenAI-kompatiblen Pfad, daher wird natives nur-OpenAI-Request-Shaping (`serviceTier`, Responses-`store`,
+  Prompt-Cache-Hinweise, OpenAI-Reasoning-Kompatibilitäts-Payloads) nicht weitergeleitet
+- Gemini-gestützte OpenRouter-Referenzen behalten nur die Bereinigung von Proxy-Gemini-Thought-Signatures; native Gemini-Replay-Validierung und Bootstrap-Umschreibungen bleiben deaktiviert
 - Kilo Gateway: `kilocode` (`KILOCODE_API_KEY`)
 - Beispielmodell: `kilocode/kilo/auto`
- Gemini-basierte Kilo-Refs behalten denselben Pfad zur Bereinigung von Thought-Signatures bei Proxy-Gemini;
-  `kilocode/kilo/auto` und andere Hinweise ohne Unterstützung für Proxy-Reasoning
-  überspringen die Proxy-Reasoning-Injektion
+- Gemini-gestützte Kilo-Referenzen behalten denselben Bereinigungspfad für Proxy-Gemini-Thought-Signatures; `kilocode/kilo/auto` und andere Hinweise auf nicht unterstütztes Proxy-Reasoning überspringen die Proxy-Reasoning-Injektion
 - MiniMax: `minimax` (API-Schlüssel) und `minimax-portal` (OAuth)
 - Auth: `MINIMAX_API_KEY` für `minimax`; `MINIMAX_OAUTH_TOKEN` oder `MINIMAX_API_KEY` für `minimax-portal`
 - Beispielmodell: `minimax/MiniMax-M2.7` oder `minimax-portal/MiniMax-M2.7`
- Onboarding/Einrichtung per API-Schlüssel für MiniMax schreibt explizite M2.7-Modelldefinitionen mit
-  `input: ["text", "image"]`; der gebündelte Anbieterkatalog hält die Chat-Refs
-  text-only, bis diese Anbieterkonfiguration materialisiert wird
+- MiniMax-Onboarding-/API-Schlüssel-Einrichtung schreibt explizite M2.7-Modell-Definitionen mit
+  `input: ["text", "image"]`; der gebündelte Anbieterkatalog hält die Chat-Referenzen text-only, bis diese Anbieterkonfiguration materialisiert wird
 - Moonshot: `moonshot` (`MOONSHOT_API_KEY`)
 - Beispielmodell: `moonshot/kimi-k2.5`
 - Kimi Coding: `kimi` (`KIMI_API_KEY` oder `KIMICODE_API_KEY`)
@ -456,7 +372,7 @@ Einzelheiten zur Einrichtung finden Sie unter [/providers/kilocode](/de/provider
 - xAI: `xai` (`XAI_API_KEY`)
  - Native gebündelte xAI-Anfragen verwenden den xAI-Responses-Pfad
  - `/fast` oder `params.fastMode: true` schreiben `grok-3`, `grok-3-mini`,
-    `grok-4` und `grok-4-0709` auf ihre `*-fast`-Varianten um
+    `grok-4` und `grok-4-0709` in ihre `*-fast`-Varianten um
  - `tool_stream` ist standardmäßig aktiviert; setzen Sie
    `agents.defaults.models["xai/<model>"].params.tool_stream` auf `false`, um
    es zu deaktivieren
@ -470,20 +386,19 @@ Einzelheiten zur Einrichtung finden Sie unter [/providers/kilocode](/de/provider
 - GitHub Copilot: `github-copilot` (`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`)
 - Beispielmodell für Hugging Face Inference: `huggingface/deepseek-ai/DeepSeek-R1`; CLI: `openclaw onboard --auth-choice huggingface-api-key`. Siehe [Hugging Face (Inference)](/de/providers/huggingface).

-## Anbieter über `models.providers` (benutzerdefiniert/Basis-URL)
+## Anbieter über `models.providers` (benutzerdefinierte/Basis-URL)

 Verwenden Sie `models.providers` (oder `models.json`), um **benutzerdefinierte** Anbieter oder
 OpenAI-/Anthropic-kompatible Proxys hinzuzufügen.

-Viele der unten aufgeführten gebündelten Anbieter-Plugins veröffentlichen bereits einen Standardkatalog.
+Viele der gebündelten Anbieter-Plugins unten veröffentlichen bereits einen Standardkatalog.
 Verwenden Sie explizite Einträge `models.providers.<id>` nur dann, wenn Sie die
-standardmäßige Basis-URL, Header oder Modellliste überschreiben möchten.
+Standard-Basis-URL, Header oder Modellliste überschreiben möchten.

 ### Moonshot AI (Kimi)

-Moonshot wird als gebündeltes Anbieter-Plugin ausgeliefert. Verwenden Sie standardmäßig den integrierten Anbieter
-und fügen Sie nur dann einen expliziten Eintrag `models.providers.moonshot` hinzu, wenn Sie die Basis-URL oder Modellmetadaten
-überschreiben müssen:
+Moonshot wird als gebündeltes Anbieter-Plugin ausgeliefert. Verwenden Sie
+standardmäßig den integrierten Anbieter und fügen Sie nur dann einen expliziten Eintrag `models.providers.moonshot` hinzu, wenn Sie die Basis-URL oder Modellmetadaten überschreiben müssen:

 - Anbieter: `moonshot`
 - Auth: `MOONSHOT_API_KEY`
@ -537,11 +452,11 @@ Kimi Coding verwendet den Anthropic-kompatiblen Endpunkt von Moonshot AI:
 }
 ```

-Das Legacy-`kimi/k2p5` bleibt als Kompatibilitäts-Modell-ID akzeptiert.
+Legacy-`kimi/k2p5` bleibt als Kompatibilitätsmodell-ID akzeptiert.

 ### Volcano Engine (Doubao)

-Volcano Engine (火山引擎) bietet Zugriff auf Doubao und andere Modelle in China.
+Volcano Engine (火山引擎) bietet in China Zugriff auf Doubao und andere Modelle.

 - Anbieter: `volcengine` (Coding: `volcengine-plan`)
 - Auth: `VOLCANO_ENGINE_API_KEY`
@ -556,13 +471,9 @@ Volcano Engine (火山引擎) bietet Zugriff auf Doubao und andere Modelle in Ch
 }
 ```

-Im Onboarding wird standardmäßig die Coding-Oberfläche verwendet, aber der allgemeine `volcengine/*`-
-Katalog wird gleichzeitig registriert.
+Onboarding verwendet standardmäßig die Coding-Oberfläche, aber der allgemeine `volcengine/*`-Katalog wird gleichzeitig registriert.

-In Modellwählern für Onboarding/Konfiguration bevorzugt die Volcengine-Auth-Auswahl sowohl
-Zeilen `volcengine/*` als auch `volcengine-plan/*`. Wenn diese Modelle noch nicht geladen sind,
-fällt OpenClaw auf den ungefilterten Katalog zurück, statt einen leeren
-anbieterspezifischen Wähler anzuzeigen.
+In Onboarding-/Modellauswahllisten für die Modellkonfiguration bevorzugt die Volcengine-Auth-Auswahl sowohl Zeilen mit `volcengine/*` als auch mit `volcengine-plan/*`. Wenn diese Modelle noch nicht geladen sind, fällt OpenClaw auf den ungefilterten Katalog zurück, statt eine leere anbieterbezogene Auswahl anzuzeigen.

 Verfügbare Modelle:

@ -597,13 +508,9 @@ BytePlus ARK bietet internationalen Nutzern Zugriff auf dieselben Modelle wie Vo
 }
 ```

-Im Onboarding wird standardmäßig die Coding-Oberfläche verwendet, aber der allgemeine `byteplus/*`-
-Katalog wird gleichzeitig registriert.
+Onboarding verwendet standardmäßig die Coding-Oberfläche, aber der allgemeine `byteplus/*`-Katalog wird gleichzeitig registriert.

-In Modellwählern für Onboarding/Konfiguration bevorzugt die BytePlus-Auth-Auswahl sowohl
-Zeilen `byteplus/*` als auch `byteplus-plan/*`. Wenn diese Modelle noch nicht geladen sind,
-fällt OpenClaw auf den ungefilterten Katalog zurück, statt einen leeren
-anbieterspezifischen Wähler anzuzeigen.
+In Onboarding-/Modellauswahllisten für die Modellkonfiguration bevorzugt die BytePlus-Auth-Auswahl sowohl Zeilen mit `byteplus/*` als auch mit `byteplus-plan/*`. Wenn diese Modelle noch nicht geladen sind, fällt OpenClaw auf den ungefilterten Katalog zurück, statt eine leere anbieterbezogene Auswahl anzuzeigen.

 Verfügbare Modelle:

@ -653,23 +560,22 @@ MiniMax wird über `models.providers` konfiguriert, da es benutzerdefinierte End

 - MiniMax OAuth (global): `--auth-choice minimax-global-oauth`
 - MiniMax OAuth (CN): `--auth-choice minimax-cn-oauth`
- MiniMax API-Schlüssel (global): `--auth-choice minimax-global-api`
- MiniMax API-Schlüssel (CN): `--auth-choice minimax-cn-api`
+- MiniMax-API-Schlüssel (global): `--auth-choice minimax-global-api`
+- MiniMax-API-Schlüssel (CN): `--auth-choice minimax-cn-api`
 - Auth: `MINIMAX_API_KEY` für `minimax`; `MINIMAX_OAUTH_TOKEN` oder
  `MINIMAX_API_KEY` für `minimax-portal`

-Einzelheiten zur Einrichtung, zu Modelloptionen und Konfigurations-Snippets finden Sie unter [/providers/minimax](/de/providers/minimax).
+Siehe [/providers/minimax](/de/providers/minimax) für Einrichtungsdetails, Modelloptionen und Konfigurationsausschnitte.

-Auf dem Anthropic-kompatiblen Streaming-Pfad von MiniMax deaktiviert OpenClaw Thinking
-standardmäßig, sofern Sie es nicht explizit festlegen, und `/fast on` schreibt
-`MiniMax-M2.7` auf `MiniMax-M2.7-highspeed` um.
+Auf dem Anthropic-kompatiblen Streaming-Pfad von MiniMax deaktiviert OpenClaw Thinking standardmäßig, sofern Sie es nicht explizit festlegen, und `/fast on` schreibt
+`MiniMax-M2.7` in `MiniMax-M2.7-highspeed` um.

-Plugin-eigene Aufteilung der Fähigkeiten:
+Aufteilung der plugin-eigenen Fähigkeiten:

 - Standardwerte für Text/Chat bleiben auf `minimax/MiniMax-M2.7`
 - Bildgenerierung ist `minimax/image-01` oder `minimax-portal/image-01`
- Bildverständnis ist das plugin-eigene `MiniMax-VL-01` auf beiden MiniMax-Auth-Pfaden
- Websuche bleibt auf der Anbieter-ID `minimax`
+- Bildverständnis ist plugin-eigenes `MiniMax-VL-01` auf beiden MiniMax-Auth-Pfaden
+- Websuche bleibt auf Anbieter-ID `minimax`

 ### Ollama

@ -681,7 +587,7 @@ Ollama wird als gebündeltes Anbieter-Plugin ausgeliefert und verwendet die nati
 - Installation: [https://ollama.com/download](https://ollama.com/download)

 ```bash
-# Installieren Sie Ollama und laden Sie dann ein Modell:
+# Install Ollama, then pull a model:
 ollama pull llama3.3
 ```

@ -693,9 +599,10 @@ ollama pull llama3.3
 }
 ```

-Ollama wird lokal unter `http://127.0.0.1:11434` erkannt, wenn Sie sich mit
-`OLLAMA_API_KEY` dafür anmelden, und das gebündelte Anbieter-Plugin fügt Ollama direkt zu
-`openclaw onboard` und dem Modellwähler hinzu. Informationen zu Onboarding, Cloud-/Lokalmodus und benutzerdefinierter Konfiguration finden Sie unter [/providers/ollama](/de/providers/ollama).
+Ollama wird lokal unter `http://127.0.0.1:11434` erkannt, wenn Sie mit
+`OLLAMA_API_KEY` optieren, und das gebündelte Anbieter-Plugin fügt Ollama direkt zu
+`openclaw onboard` und der Modellauswahl hinzu. Siehe [/providers/ollama](/de/providers/ollama)
+für Onboarding, Cloud-/lokalen Modus und benutzerdefinierte Konfiguration.

 ### vLLM

@ -706,7 +613,7 @@ Server ausgeliefert:
 - Auth: Optional (abhängig von Ihrem Server)
 - Standard-Basis-URL: `http://127.0.0.1:8000/v1`

-So aktivieren Sie die automatische lokale Erkennung (jeder Wert funktioniert, wenn Ihr Server keine Auth erzwingt):
+So aktivieren Sie lokale Auto-Erkennung (jeder Wert funktioniert, wenn Ihr Server keine Auth erzwingt):

 ```bash
 export VLLM_API_KEY="vllm-local"
@ -722,7 +629,7 @@ Legen Sie dann ein Modell fest (ersetzen Sie es durch eine der IDs, die von `/v1
 }
 ```

-Einzelheiten finden Sie unter [/providers/vllm](/de/providers/vllm).
+Siehe [/providers/vllm](/de/providers/vllm) für Details.

 ### SGLang

@ -733,8 +640,7 @@ OpenAI-kompatible Server ausgeliefert:
 - Auth: Optional (abhängig von Ihrem Server)
 - Standard-Basis-URL: `http://127.0.0.1:30000/v1`

-So aktivieren Sie die automatische lokale Erkennung (jeder Wert funktioniert, wenn Ihr Server keine
-Auth erzwingt):
+So aktivieren Sie lokale Auto-Erkennung (jeder Wert funktioniert, wenn Ihr Server keine Auth erzwingt):

 ```bash
 export SGLANG_API_KEY="sglang-local"
@ -750,7 +656,7 @@ Legen Sie dann ein Modell fest (ersetzen Sie es durch eine der IDs, die von `/v1
 }
 ```

-Einzelheiten finden Sie unter [/providers/sglang](/de/providers/sglang).
+Siehe [/providers/sglang](/de/providers/sglang) für Details.

 ### Lokale Proxys (LM Studio, vLLM, LiteLLM usw.)

@ -798,12 +704,9 @@ Hinweise:
  - `maxTokens: 8192`
 - Empfohlen: Legen Sie explizite Werte fest, die zu den Grenzen Ihres Proxys/Modells passen.
 - Für `api: "openai-completions"` auf nicht nativen Endpunkten (jede nicht leere `baseUrl`, deren Host nicht `api.openai.com` ist), erzwingt OpenClaw `compat.supportsDeveloperRole: false`, um Provider-400-Fehler für nicht unterstützte `developer`-Rollen zu vermeiden.
- Proxyartige OpenAI-kompatible Routen überspringen außerdem native, nur für OpenAI bestimmte Anfrage-
-  Anpassung: kein `service_tier`, kein Responses-`store`, keine Prompt-Cache-Hinweise, keine
-  OpenAI-Reasoning-kompatible Payload-Anpassung und keine versteckten OpenClaw-Attributions-
-  Header.
- Wenn `baseUrl` leer ist oder weggelassen wird, behält OpenClaw das Standardverhalten von OpenAI bei (das zu `api.openai.com` aufgelöst wird).
- Aus Sicherheitsgründen wird ein explizites `compat.supportsDeveloperRole: true` auf nicht nativen `openai-completions`-Endpunkten dennoch überschrieben.
+- Proxyartige OpenAI-kompatible Routen überspringen ebenfalls natives nur-OpenAI-Request-Shaping: kein `service_tier`, kein Responses-`store`, keine Prompt-Cache-Hinweise, kein OpenAI-Reasoning-Kompatibilitäts-Payload-Shaping und keine versteckten OpenClaw-Zuordnungsheader.
+- Wenn `baseUrl` leer ist oder fehlt, behält OpenClaw das Standard-OpenAI-Verhalten bei (das zu `api.openai.com` aufgelöst wird).
+- Aus Sicherheitsgründen wird ein explizites `compat.supportsDeveloperRole: true` auf nicht nativen `openai-completions`-Endpunkten weiterhin überschrieben.

 ## CLI-Beispiele

@ -817,7 +720,7 @@ Siehe auch: [/gateway/configuration](/de/gateway/configuration) für vollständi

 ## Verwandt

- [Models](/de/concepts/models) — Modellkonfiguration und Aliase
+- [Models](/de/concepts/models) — Modellkonfiguration und Aliasse
 - [Model Failover](/de/concepts/model-failover) — Fallback-Ketten und Wiederholungsverhalten
- [Configuration Reference](/de/gateway/configuration-reference#agent-defaults) — Konfigurationsschlüssel für Modelle
+- [Configuration Reference](/de/gateway/configuration-reference#agent-defaults) — Modellkonfigurationsschlüssel
 - [Providers](/de/providers) — Einrichtungsanleitungen pro Anbieter
--- a/docs/de/concepts/qa-e2e-automation.md
+++ b/docs/de/concepts/qa-e2e-automation.md
@ -2,29 +2,29 @@
 read_when:
    - Erweitern von qa-lab oder qa-channel
    - Hinzufügen repo-gestützter QA-Szenarien
-    - Aufbauen realitätsnäherer QA-Automatisierung rund um das Gateway-Dashboard
-summary: Private QA-Automatisierungsstruktur für qa-lab, qa-channel, Seed-Szenarien und Protokollberichte
-title: QA-E2E-Automatisierung
+    - Erstellen realitätsnäherer QA-Automatisierung rund um das Gateway-Dashboard
+summary: Private QA-Automatisierungsform für qa-lab, qa-channel, Seed-Szenarien und Protokollberichte
+title: QA E2E-Automatisierung
 x-i18n:
-    generated_at: "2026-04-08T02:13:58Z"
+    generated_at: "2026-04-08T06:00:59Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 3b4aa5acc8e77303f4045d4f04372494cae21b89d2fdaba856dbb4855ced9d27
+    source_hash: 57da147dc06abf9620290104e01a83b42182db1806514114fd9e8467492cda99
    source_path: concepts/qa-e2e-automation.md
    workflow: 15
 ---

-# QA-E2E-Automatisierung
+# QA E2E-Automatisierung

-Der private QA-Stack soll OpenClaw auf eine realistischere,
-kanalartige Weise testen, als es ein einzelner Unit-Test leisten kann.
+Der private QA-Stack soll OpenClaw auf realistischere, kanalähnliche Weise
+testen, als es ein einzelner Unit-Test kann.

 Aktuelle Bestandteile:

- `extensions/qa-channel`: synthetischer Nachrichtenkanal mit Oberflächen für DM, Kanal, Thread,
-  Reaktion, Bearbeiten und Löschen.
+- `extensions/qa-channel`: synthetischer Nachrichtenkanal mit Oberflächen für DMs, Kanäle, Threads,
+  Reaktionen, Bearbeitungen und Löschungen.
 - `extensions/qa-lab`: Debugger-UI und QA-Bus zum Beobachten des Transkripts,
-  Einspeisen eingehender Nachrichten und Exportieren eines Markdown-Berichts.
+  Einspielen eingehender Nachrichten und Exportieren eines Markdown-Berichts.
 - `qa/`: repo-gestützte Seed-Assets für die Startaufgabe und grundlegende QA-
  Szenarien.

@ -33,19 +33,19 @@ Der aktuelle QA-Operator-Workflow ist eine QA-Site mit zwei Bereichen:
 - Links: Gateway-Dashboard (Control UI) mit dem Agenten.
 - Rechts: QA Lab, das das Slack-ähnliche Transkript und den Szenarioplan anzeigt.

-Ausführen mit:
+Führe es aus mit:

 ```bash
 pnpm qa:lab:up
 ```

-Dadurch wird die QA-Site gebaut, die Docker-gestützte Gateway-Lane gestartet und die
+Dadurch wird die QA-Site gebaut, der Docker-gestützte Gateway-Lane gestartet und die
 QA-Lab-Seite bereitgestellt, auf der ein Operator oder eine Automatisierungsschleife dem Agenten eine QA-
-Mission geben, echtes Kanalverhalten beobachten und festhalten kann, was funktioniert hat, fehlgeschlagen ist oder
+Mission geben, echtes Kanalverhalten beobachten und aufzeichnen kann, was funktioniert hat, fehlgeschlagen ist oder
 blockiert geblieben ist.

-Für schnellere Iteration an der QA-Lab-UI, ohne das Docker-Image jedes Mal neu zu bauen,
-starten Sie den Stack mit einem per Bind-Mount eingebundenen QA-Lab-Bundle:
+Für schnellere Iterationen an der QA-Lab-UI, ohne das Docker-Image jedes Mal neu zu bauen,
+starte den Stack mit einem per Bind-Mount eingebundenen QA-Lab-Bundle:

 ```bash
 pnpm openclaw qa docker-build-image
@ -54,41 +54,41 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```

-`qa:lab:up:fast` hält die Docker-Dienste auf einem vorgebauten Image und bind-mountet
-`extensions/qa-lab/web/dist` in den `qa-lab`-Container ein. `qa:lab:watch`
-baut dieses Bundle bei Änderungen neu, und der Browser lädt automatisch neu, wenn sich der QA-Lab-
-Asset-Hash ändert.
+`qa:lab:up:fast` hält die Docker-Services auf einem vorab gebauten Image und bind-mountet
+`extensions/qa-lab/web/dist` in den Container `qa-lab`. `qa:lab:watch`
+baut dieses Bundle bei Änderungen neu, und der Browser lädt automatisch neu, wenn sich der Asset-Hash von QA Lab ändert.

 ## Repo-gestützte Seeds

-Seed-Assets befinden sich in `qa/`:
+Seed-Assets liegen in `qa/`:

- `qa/scenarios.md`
+- `qa/scenarios/index.md`
+- `qa/scenarios/*.md`

-Diese sind absichtlich in Git enthalten, damit der QA-Plan sowohl für Menschen als auch für den
+Diese liegen absichtlich in git, damit der QA-Plan sowohl für Menschen als auch für den
 Agenten sichtbar ist. Die grundlegende Liste sollte breit genug bleiben, um Folgendes abzudecken:

 - DM- und Kanal-Chat
 - Thread-Verhalten
 - Lebenszyklus von Nachrichtenaktionen
 - Cron-Callbacks
- Memory-Abruf
+- Memory Recall
 - Modellwechsel
 - Übergabe an Subagenten
- Lesen des Repos und der Dokumentation
+- Lesen des Repos und Lesen der Dokumentation
 - eine kleine Build-Aufgabe wie Lobster Invaders

 ## Berichterstellung

 `qa-lab` exportiert einen Markdown-Protokollbericht aus der beobachteten Bus-Zeitleiste.
-Der Bericht sollte beantworten:
+Der Bericht sollte Folgendes beantworten:

 - Was funktioniert hat
 - Was fehlgeschlagen ist
 - Was blockiert geblieben ist
- Welche Folge-Szenarien sich hinzuzufügen lohnen
+- Welche Folgeszenarien sich hinzuzufügen lohnen

-## Zugehörige Dokumentation
+## Verwandte Dokumentation

 - [Testing](/de/help/testing)
 - [QA Channel](/de/channels/qa-channel)
--- a/docs/de/concepts/streaming.md
+++ b/docs/de/concepts/streaming.md
@ -1,31 +1,31 @@
 ---
 read_when:
-    - Erklären, wie Streaming oder Chunking in Channels funktioniert
-    - Verhalten von Block-Streaming oder Channel-Chunking ändern
-    - Doppelte/frühe Block-Antworten oder Channel-Vorschau-Streaming debuggen
-summary: Verhalten von Streaming + Chunking (Block-Antworten, Channel-Vorschau-Streaming, Moduszuordnung)
+    - Erklärung, wie Streaming oder Chunking auf Kanälen funktioniert
+    - Ändern des Block-Streamings oder des Kanal-Chunking-Verhaltens
+    - Debuggen von doppelten/frühen Blockantworten oder Kanal-Vorschau-Streaming
+summary: Verhalten von Streaming + Chunking (Blockantworten, Kanal-Vorschau-Streaming, Moduszuordnung)
 title: Streaming und Chunking
 x-i18n:
-    generated_at: "2026-04-05T12:41:23Z"
+    generated_at: "2026-04-08T06:01:12Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 44b0d08c7eafcb32030ef7c8d5719c2ea2d34e4bac5fdad8cc8b3f4e9e9fad97
+    source_hash: a8e847bb7da890818cd79dec7777f6ae488e6d6c0468e948e56b6b6c598e0000
    source_path: concepts/streaming.md
    workflow: 15
 ---

 # Streaming + Chunking

-OpenClaw hat zwei separate Streaming-Ebenen:
+OpenClaw hat zwei getrennte Streaming-Ebenen:

- **Block-Streaming (Channels):** abgeschlossene **Blöcke** ausgeben, während der Assistant schreibt. Das sind normale Channel-Nachrichten (keine Token-Deltas).
- **Vorschau-Streaming (Telegram/Discord/Slack):** eine temporäre **Vorschau-Nachricht** während der Generierung aktualisieren.
+- **Block-Streaming (Kanäle):** sendet abgeschlossene **Blöcke**, während der Assistent schreibt. Das sind normale Kanalnachrichten (keine Token-Deltas).
+- **Vorschau-Streaming (Telegram/Discord/Slack):** aktualisiert während der Generierung eine temporäre **Vorschau-Nachricht**.

-Es gibt heute **kein echtes Token-Delta-Streaming** zu Channel-Nachrichten. Vorschau-Streaming ist nachrichtenbasiert (Senden + Bearbeitungen/Anhängen).
+Es gibt heute **kein echtes Token-Delta-Streaming** für Kanalnachrichten. Vorschau-Streaming ist nachrichtenbasiert (Senden + Bearbeitungen/Anhänge).

-## Block-Streaming (Channel-Nachrichten)
+## Block-Streaming (Kanalnachrichten)

-Block-Streaming sendet Assistant-Ausgaben in groben Chunks, sobald sie verfügbar werden.
+Block-Streaming sendet Assistent-Ausgaben in groben Chunks, sobald sie verfügbar werden.

 ```
 Model output
@ -39,80 +39,80 @@ Model output

 Legende:

- `text_delta/events`: Modell-Stream-Ereignisse (können bei nicht streamenden Modellen spärlich sein).
- `chunker`: `EmbeddedBlockChunker`, der Min-/Max-Grenzen + Umbruchpräferenz anwendet.
- `channel send`: tatsächliche ausgehende Nachrichten (Block-Antworten).
+- `text_delta/events`: Stream-Ereignisse des Modells (bei nicht-streamenden Modellen möglicherweise spärlich).
+- `chunker`: `EmbeddedBlockChunker`, der Mindest-/Höchstgrenzen + Trennpräferenz anwendet.
+- `channel send`: tatsächliche ausgehende Nachrichten (Blockantworten).

 **Steuerungen:**

- `agents.defaults.blockStreamingDefault`: `"on"`/`"off"` (Standard: aus).
- Channel-Überschreibungen: `*.blockStreaming` (und Varianten pro Konto), um pro Channel `"on"`/`"off"` zu erzwingen.
+- `agents.defaults.blockStreamingDefault`: `"on"`/`"off"` (standardmäßig aus).
+- Kanalüberschreibungen: `*.blockStreaming` (und Varianten pro Konto), um `"on"`/`"off"` pro Kanal zu erzwingen.
 - `agents.defaults.blockStreamingBreak`: `"text_end"` oder `"message_end"`.
 - `agents.defaults.blockStreamingChunk`: `{ minChars, maxChars, breakPreference? }`.
- `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (gestreamte Blöcke vor dem Senden zusammenführen).
- Harte Channel-Grenze: `*.textChunkLimit` (z. B. `channels.whatsapp.textChunkLimit`).
- Channel-Chunk-Modus: `*.chunkMode` (`length` standardmäßig, `newline` trennt an Leerzeilen (Absatzgrenzen) vor dem Chunking nach Länge).
- Discord-Soft-Grenze: `channels.discord.maxLinesPerMessage` (Standard 17) teilt hohe Antworten, um UI-Abschneiden zu vermeiden.
+- `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (zusammengeführte gestreamte Blöcke vor dem Senden).
+- Feste Kanalobergrenze: `*.textChunkLimit` (z. B. `channels.whatsapp.textChunkLimit`).
+- Kanal-Chunk-Modus: `*.chunkMode` (`length` standardmäßig, `newline` teilt an Leerzeilen (Absatzgrenzen), bevor nach Länge gechunked wird).
+- Discord-Softlimit: `channels.discord.maxLinesPerMessage` (standardmäßig 17) teilt hohe Antworten, um UI-Abschneiden zu vermeiden.

-**Semantik der Grenzen:**
+**Grenzsemantik:**

 - `text_end`: Blöcke streamen, sobald der Chunker sie ausgibt; bei jedem `text_end` flushen.
- `message_end`: warten, bis die Assistant-Nachricht abgeschlossen ist, dann gepufferte Ausgabe flushen.
+- `message_end`: warten, bis die Assistent-Nachricht fertig ist, dann gepufferte Ausgabe flushen.

 `message_end` verwendet weiterhin den Chunker, wenn der gepufferte Text `maxChars` überschreitet, sodass am Ende mehrere Chunks ausgegeben werden können.

 ## Chunking-Algorithmus (untere/obere Grenzen)

-Block-Chunking wird durch `EmbeddedBlockChunker` implementiert:
+Block-Chunking wird von `EmbeddedBlockChunker` implementiert:

 - **Untere Grenze:** nichts ausgeben, bis der Puffer >= `minChars` ist (außer wenn erzwungen).
 - **Obere Grenze:** Trennungen vor `maxChars` bevorzugen; wenn erzwungen, bei `maxChars` trennen.
- **Umbruchpräferenz:** `paragraph` → `newline` → `sentence` → `whitespace` → harter Umbruch.
+- **Trennpräferenz:** `paragraph` → `newline` → `sentence` → `whitespace` → harter Umbruch.
 - **Code-Fences:** niemals innerhalb von Fences trennen; wenn bei `maxChars` erzwungen, die Fence schließen + erneut öffnen, damit Markdown gültig bleibt.

-`maxChars` wird auf das Channel-`textChunkLimit` begrenzt, sodass per-Channel-Grenzen nicht überschritten werden können.
+`maxChars` wird auf das kanalbezogene `textChunkLimit` begrenzt, sodass per-Kanal-Limits nicht überschritten werden können.

-## Zusammenführen (gestreamte Blöcke zusammenführen)
+## Coalescing (gestreamte Blöcke zusammenführen)

 Wenn Block-Streaming aktiviert ist, kann OpenClaw **aufeinanderfolgende Block-Chunks zusammenführen**,
-bevor sie gesendet werden. Das reduziert „Einzeilen-Spam“, liefert aber weiterhin
-schrittweise Ausgabe.
+bevor sie gesendet werden. Das reduziert „Einzelzeilen-Spam“ und liefert trotzdem
+eine schrittweise Ausgabe.

- Das Zusammenführen wartet vor dem Flush auf **Leerlaufabstände** (`idleMs`).
+- Coalescing wartet vor dem Flushen auf **Leerlauf-Lücken** (`idleMs`).
 - Puffer sind durch `maxChars` begrenzt und werden geflusht, wenn sie diesen Wert überschreiten.
- `minChars` verhindert, dass winzige Fragmente gesendet werden, bevor genug Text zusammengekommen ist
-  (der finale Flush sendet immer verbleibenden Text).
- Das Verbindungszeichen wird aus `blockStreamingChunk.breakPreference`
+- `minChars` verhindert, dass winzige Fragmente gesendet werden, bevor genug Text zusammenkommt
+  (der abschließende Flush sendet immer den restlichen Text).
+- Der Verknüpfer wird aus `blockStreamingChunk.breakPreference`
  abgeleitet (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → Leerzeichen).
- Channel-Überschreibungen sind über `*.blockStreamingCoalesce` verfügbar (einschließlich Konfigurationen pro Konto).
- Der Standardwert für `minChars` beim Zusammenführen wird für Signal/Slack/Discord auf 1500 erhöht, sofern nicht überschrieben.
+- Kanalüberschreibungen sind über `*.blockStreamingCoalesce` verfügbar (einschließlich Konfigurationen pro Konto).
+- Das standardmäßige Coalesce-`minChars` wird für Signal/Slack/Discord auf 1500 erhöht, sofern nicht überschrieben.

-## Menschlich wirkendes Tempo zwischen Blöcken
+## Menschlich wirkendes Timing zwischen Blöcken

 Wenn Block-Streaming aktiviert ist, können Sie eine **zufällige Pause** zwischen
-Block-Antworten hinzufügen (nach dem ersten Block). Dadurch wirken Antworten mit mehreren
-Sprechblasen natürlicher.
+Blockantworten hinzufügen (nach dem ersten Block). Dadurch wirken Antworten mit
+mehreren Blasen natürlicher.

 - Konfiguration: `agents.defaults.humanDelay` (Überschreibung pro Agent über `agents.list[].humanDelay`).
- Modi: `off` (Standard), `natural` (800–2500 ms), `custom` (`minMs`/`maxMs`).
- Gilt nur für **Block-Antworten**, nicht für finale Antworten oder Tool-Zusammenfassungen.
+- Modi: `off` (Standard), `natural` (800–2500ms), `custom` (`minMs`/`maxMs`).
+- Gilt nur für **Blockantworten**, nicht für endgültige Antworten oder Tool-Zusammenfassungen.

-## „Chunks streamen oder alles“
+## "Chunks streamen oder alles"

-Dies entspricht:
+Dies wird wie folgt zugeordnet:

- **Chunks streamen:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (währenddessen ausgeben). Nicht-Telegram-Channels benötigen außerdem `*.blockStreaming: true`.
- **Alles am Ende streamen:** `blockStreamingBreak: "message_end"` (einmal flushen, bei sehr langer Ausgabe eventuell mehrere Chunks).
- **Kein Block-Streaming:** `blockStreamingDefault: "off"` (nur finale Antwort).
+- **Chunks streamen:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (während der Ausgabe senden). Nicht-Telegram-Kanäle benötigen zusätzlich `*.blockStreaming: true`.
+- **Alles am Ende streamen:** `blockStreamingBreak: "message_end"` (einmal flushen, möglicherweise mehrere Chunks, wenn sehr lang).
+- **Kein Block-Streaming:** `blockStreamingDefault: "off"` (nur endgültige Antwort).

-**Channel-Hinweis:** Block-Streaming ist **deaktiviert, sofern**
-`*.blockStreaming` nicht explizit auf `true` gesetzt ist. Channels können eine Live-Vorschau streamen
-(`channels.<channel>.streaming`) ohne Block-Antworten.
+**Hinweis zu Kanälen:** Block-Streaming ist **deaktiviert, solange nicht**
+`*.blockStreaming` explizit auf `true` gesetzt ist. Kanäle können eine Live-Vorschau
+(`channels.<channel>.streaming`) streamen, ohne Blockantworten zu senden.

-Hinweis zum Konfigurationsort: Die Standardwerte `blockStreaming*` liegen unter
+Zur Erinnerung zum Konfigurationsort: Die `blockStreaming*`-Standards befinden sich unter
 `agents.defaults`, nicht in der Root-Konfiguration.

-## Modi für Vorschau-Streaming
+## Vorschau-Streaming-Modi

 Kanonischer Schlüssel: `channels.<channel>.streaming`

@ -121,48 +121,49 @@ Modi:
 - `off`: Vorschau-Streaming deaktivieren.
 - `partial`: einzelne Vorschau, die durch den neuesten Text ersetzt wird.
 - `block`: Vorschau-Aktualisierungen in gechunkten/angehängten Schritten.
- `progress`: Fortschritts-/Statusvorschau während der Generierung, finale Antwort nach Abschluss.
+- `progress`: Fortschritts-/Statusvorschau während der Generierung, endgültige Antwort nach Abschluss.

-### Channel-Zuordnung
+### Kanalzuordnung

-| Channel  | `off` | `partial` | `block` | `progress`        |
+| Kanal    | `off` | `partial` | `block` | `progress`        |
 | -------- | ----- | --------- | ------- | ----------------- |
-| Telegram | ✅    | ✅        | ✅      | wird zu `partial` zugeordnet |
-| Discord  | ✅    | ✅        | ✅      | wird zu `partial` zugeordnet |
+| Telegram | ✅    | ✅        | ✅      | wird `partial` zugeordnet |
+| Discord  | ✅    | ✅        | ✅      | wird `partial` zugeordnet |
 | Slack    | ✅    | ✅        | ✅      | ✅                |

 Nur Slack:

- `channels.slack.nativeStreaming` schaltet native Slack-Streaming-API-Aufrufe um, wenn `streaming=partial` gesetzt ist (Standard: `true`).
+- `channels.slack.streaming.nativeTransport` schaltet Slack-native Streaming-API-Aufrufe um, wenn `channels.slack.streaming.mode="partial"` (Standard: `true`).
+- Slack-natives Streaming und der Slack-Assistent-Thread-Status erfordern ein Antwort-Thread-Ziel; DMs auf oberster Ebene zeigen diese Thread-Vorschau nicht an.

 Migration von Legacy-Schlüsseln:

- Telegram: `streamMode` + boolesches `streaming` werden automatisch auf das Enum `streaming` migriert.
- Discord: `streamMode` + boolesches `streaming` werden automatisch auf das Enum `streaming` migriert.
- Slack: `streamMode` wird automatisch auf das Enum `streaming` migriert; boolesches `streaming` wird automatisch auf `nativeStreaming` migriert.
+- Telegram: `streamMode` + boolesches `streaming` werden automatisch zur `streaming`-Enum migriert.
+- Discord: `streamMode` + boolesches `streaming` werden automatisch zur `streaming`-Enum migriert.
+- Slack: `streamMode` wird automatisch zu `streaming.mode` migriert; boolesches `streaming` wird automatisch zu `streaming.mode` plus `streaming.nativeTransport` migriert; Legacy-`nativeStreaming` wird automatisch zu `streaming.nativeTransport` migriert.

 ### Laufzeitverhalten

 Telegram:

- Verwendet `sendMessage` + `editMessageText` für Vorschau-Aktualisierungen in DMs und Gruppen/Themen.
+- Verwendet `sendMessage` + `editMessageText` für Vorschau-Aktualisierungen in DMs sowie Gruppen/Themen.
 - Vorschau-Streaming wird übersprungen, wenn Telegram-Block-Streaming explizit aktiviert ist (um doppeltes Streaming zu vermeiden).
- `/reasoning stream` kann Begründungen in die Vorschau schreiben.
+- `/reasoning stream` kann Reasoning in die Vorschau schreiben.

 Discord:

- Verwendet Senden + Bearbeiten von Vorschau-Nachrichten.
- Der Modus `block` verwendet Entwurfs-Chunking (`draftChunk`).
+- Verwendet Vorschau-Nachrichten mit Senden + Bearbeiten.
+- Der Modus `block` verwendet Draft-Chunking (`draftChunk`).
 - Vorschau-Streaming wird übersprungen, wenn Discord-Block-Streaming explizit aktiviert ist.

 Slack:

- `partial` kann natives Slack-Streaming (`chat.startStream`/`append`/`stop`) verwenden, wenn verfügbar.
- `block` verwendet Entwurfsvorschauen im Append-Stil.
- `progress` verwendet Statusvorschautext und danach die finale Antwort.
+- `partial` kann Slack-natives Streaming (`chat.startStream`/`append`/`stop`) verwenden, wenn verfügbar.
+- `block` verwendet Vorschauen im Anhänge-Stil für Entwürfe.
+- `progress` verwendet Statusvorschautext und danach die endgültige Antwort.

 ## Verwandt

- [Messages](/concepts/messages) — Nachrichten-Lifecycle und Zustellung
- [Retry](/concepts/retry) — Retry-Verhalten bei Zustellfehlern
- [Channels](/channels) — Streaming-Unterstützung pro Channel
+- [Nachrichten](/de/concepts/messages) — Nachrichtenlebenszyklus und Zustellung
+- [Wiederholung](/de/concepts/retry) — Wiederholungsverhalten bei Zustellungsfehlern
+- [Kanäle](/de/channels) — Streaming-Unterstützung pro Kanal
--- a/docs/de/gateway/configuration-reference.md
+++ b/docs/de/gateway/configuration-reference.md
--- a/docs/de/gateway/configuration.md
+++ b/docs/de/gateway/configuration.md
@ -1,33 +1,33 @@
 ---
 read_when:
-    - Sie richten OpenClaw zum ersten Mal ein
-    - Sie suchen nach häufigen Konfigurationsmustern
-    - Sie navigieren zu bestimmten Konfigurationsabschnitten
-summary: 'Konfigurationsüberblick: häufige Aufgaben, schnelle Einrichtung und Links zur vollständigen Referenz'
+    - OpenClaw zum ersten Mal einrichten
+    - Nach häufigen Konfigurationsmustern suchen
+    - Zu bestimmten Konfigurationsabschnitten navigieren
+summary: 'Konfigurationsübersicht: häufige Aufgaben, schnelle Einrichtung und Links zur vollständigen Referenz'
 title: Konfiguration
 x-i18n:
-    generated_at: "2026-04-05T12:43:23Z"
+    generated_at: "2026-04-08T06:02:06Z"
    model: gpt-5.4
    provider: openai
-    source_hash: a39a7de09c5f9540785ec67f37d435a7a86201f0f5f640dae663054f35976712
+    source_hash: 199a1e515bd4003319e71593a2659bb883299a76ff67e273d92583df03c96604
    source_path: gateway/configuration.md
    workflow: 15
 ---

 # Konfiguration

-OpenClaw liest eine optionale <Tooltip tip="JSON5 unterstützt Kommentare und nachgestellte Kommas">**JSON5**</Tooltip>-Konfiguration aus `~/.openclaw/openclaw.json`.
+OpenClaw liest optional eine <Tooltip tip="JSON5 unterstützt Kommentare und nachgestellte Kommas">**JSON5**</Tooltip>-Konfiguration aus `~/.openclaw/openclaw.json`.

 Wenn die Datei fehlt, verwendet OpenClaw sichere Standardwerte. Häufige Gründe, eine Konfiguration hinzuzufügen:

 - Kanäle verbinden und steuern, wer dem Bot Nachrichten senden kann
- Modelle, Tools, Sandboxing oder Automatisierung festlegen (Cron, Hooks)
- Sitzungen, Medien, Netzwerk oder UI anpassen
+- Modelle, Tools, Sandboxing oder Automatisierung einrichten (Cron, Hooks)
+- Sitzungen, Medien, Netzwerk oder UI abstimmen

-In der [vollständigen Referenz](/gateway/configuration-reference) finden Sie jedes verfügbare Feld.
+Siehe die [vollständige Referenz](/de/gateway/configuration-reference) für jedes verfügbare Feld.

 <Tip>
-**Neu bei der Konfiguration?** Beginnen Sie mit `openclaw onboard` für die interaktive Einrichtung oder sehen Sie sich die Anleitung [Configuration Examples](/gateway/configuration-examples) für vollständige Copy-and-paste-Konfigurationen an.
+**Neu bei der Konfiguration?** Beginnen Sie mit `openclaw onboard` für die interaktive Einrichtung oder sehen Sie sich den Leitfaden [Konfigurationsbeispiele](/de/gateway/configuration-examples) für vollständige Copy-and-Paste-Konfigurationen an.
 </Tip>

 ## Minimale Konfiguration
@ -58,39 +58,29 @@ In der [vollständigen Referenz](/gateway/configuration-reference) finden Sie je
  </Tab>
  <Tab title="Control UI">
    Öffnen Sie [http://127.0.0.1:18789](http://127.0.0.1:18789) und verwenden Sie den Tab **Config**.
-    Die Control UI rendert ein Formular aus dem Live-Konfigurationsschema, einschließlich der Docs-Metadaten
-    `title` / `description` der Felder sowie Plugin- und Kanalschemata, sofern
-    verfügbar, mit einem **Raw JSON**-Editor als Ausweichmöglichkeit. Für Drill-down-
-    UIs und andere Tools stellt das Gateway außerdem `config.schema.lookup` bereit, um
-    einen einzelnen pfadbezogenen Schemaknoten plus unmittelbare Zusammenfassungen der Unterelemente abzurufen.
+    Die Control UI rendert ein Formular aus dem Live-Konfigurationsschema, einschließlich der Dokumentationsmetadaten der Felder `title` und `description` sowie Plugin- und Kanalschemata, sofern verfügbar, mit einem Editor für **Raw JSON** als Ausweichmöglichkeit. Für Drill-down-UIs und andere Tools stellt das Gateway außerdem `config.schema.lookup` bereit, um einen pfadbezogenen Schemaknoten plus Zusammenfassungen der direkten Unterelemente abzurufen.
  </Tab>
  <Tab title="Direkt bearbeiten">
-    Bearbeiten Sie `~/.openclaw/openclaw.json` direkt. Das Gateway überwacht die Datei und wendet Änderungen automatisch an (siehe [Hot Reload](#config-hot-reload)).
+    Bearbeiten Sie `~/.openclaw/openclaw.json` direkt. Das Gateway überwacht die Datei und übernimmt Änderungen automatisch (siehe [Hot Reload](#config-hot-reload)).
  </Tab>
 </Tabs>

 ## Strikte Validierung

 <Warning>
-OpenClaw akzeptiert nur Konfigurationen, die vollständig dem Schema entsprechen. Unbekannte Schlüssel, fehlerhafte Typen oder ungültige Werte führen dazu, dass das Gateway den Start **verweigert**. Die einzige Ausnahme auf Root-Ebene ist `$schema` (string), damit Editoren JSON-Schema-Metadaten anhängen können.
+OpenClaw akzeptiert nur Konfigurationen, die vollständig dem Schema entsprechen. Unbekannte Schlüssel, fehlerhafte Typen oder ungültige Werte führen dazu, dass das Gateway den **Start verweigert**. Die einzige Ausnahme auf Root-Ebene ist `$schema` (string), damit Editoren JSON-Schema-Metadaten anhängen können.
 </Warning>

 Hinweise zu Schema-Tools:

- `openclaw config schema` gibt dieselbe JSON-Schema-Familie aus, die von Control UI
-  und der Konfigurationsvalidierung verwendet wird.
- Feldwerte für `title` und `description` werden in die Schema-Ausgabe für
-  Editor- und Formular-Tools übernommen.
- Verschachtelte Objekt-, Wildcard- (`*`) und Array-Item- (`[]`) Einträge übernehmen dieselben
-  Docs-Metadaten, wenn passende Felddokumentation vorhanden ist.
- Auch Kompositionszweige mit `anyOf` / `oneOf` / `allOf` übernehmen dieselben Docs-
-  Metadaten, sodass Union-/Intersection-Varianten dieselbe Feldhilfe behalten.
- `config.schema.lookup` gibt einen normalisierten Konfigurationspfad mit einem flachen
-  Schemaknoten (`title`, `description`, `type`, `enum`, `const`, häufige Grenzen
-  und ähnliche Validierungsfelder), zugeordneten UI-Hinweis-Metadaten sowie unmittelbaren Zusammenfassungen
-  der Unterelemente für Drill-down-Tools zurück.
- Runtime-Plugin-/Kanalschemata werden zusammengeführt, wenn das Gateway die
-  aktuelle Manifest-Registry laden kann.
+- `openclaw config schema` gibt dieselbe JSON-Schema-Familie aus, die von der Control UI und der Konfigurationsvalidierung verwendet wird.
+- Betrachten Sie diese Schema-Ausgabe als den kanonischen maschinenlesbaren Vertrag für `openclaw.json`; diese Übersicht und die Konfigurationsreferenz fassen ihn zusammen.
+- Die Feldwerte `title` und `description` werden in die Schema-Ausgabe für Editor- und Formular-Tools übernommen.
+- Verschachtelte Objekt-, Wildcard- (`*`) und Array-Element-Einträge (`[]`) übernehmen dieselben Dokumentationsmetadaten, wenn passende Felddokumentation vorhanden ist.
+- `anyOf`- / `oneOf`- / `allOf`-Kompositionszweige übernehmen diese Dokumentationsmetadaten ebenfalls, sodass Union-/Intersection-Varianten dieselbe Feldhilfe beibehalten.
+- `config.schema.lookup` gibt einen normalisierten Konfigurationspfad mit einem flachen Schemaknoten (`title`, `description`, `type`, `enum`, `const`, allgemeine Grenzen und ähnliche Validierungsfelder), passenden UI-Hinweismetadaten und Zusammenfassungen der direkten Unterelemente für Drill-down-Tools zurück.
+- Laufzeit-Plugin-/Kanalschemata werden zusammengeführt, wenn das Gateway die aktuelle Manifest-Registry laden kann.
+- `pnpm config:docs:check` erkennt Abweichungen zwischen dokumentationsbezogenen Konfigurations-Baseline-Artefakten und der aktuellen Schemaoberfläche.

 Wenn die Validierung fehlschlägt:

@ -103,18 +93,18 @@ Wenn die Validierung fehlschlägt:

 <AccordionGroup>
  <Accordion title="Einen Kanal einrichten (WhatsApp, Telegram, Discord usw.)">
-    Jeder Kanal hat einen eigenen Konfigurationsabschnitt unter `channels.<provider>`. Die Einrichtungsschritte finden Sie auf der jeweiligen Kanalseite:
+    Jeder Kanal hat seinen eigenen Konfigurationsabschnitt unter `channels.<provider>`. Schritte zur Einrichtung finden Sie auf der jeweiligen Kanalseite:

-    - [WhatsApp](/channels/whatsapp) — `channels.whatsapp`
-    - [Telegram](/channels/telegram) — `channels.telegram`
-    - [Discord](/channels/discord) — `channels.discord`
-    - [Feishu](/channels/feishu) — `channels.feishu`
-    - [Google Chat](/channels/googlechat) — `channels.googlechat`
-    - [Microsoft Teams](/channels/msteams) — `channels.msteams`
-    - [Slack](/channels/slack) — `channels.slack`
-    - [Signal](/channels/signal) — `channels.signal`
-    - [iMessage](/channels/imessage) — `channels.imessage`
-    - [Mattermost](/channels/mattermost) — `channels.mattermost`
+    - [WhatsApp](/de/channels/whatsapp) — `channels.whatsapp`
+    - [Telegram](/de/channels/telegram) — `channels.telegram`
+    - [Discord](/de/channels/discord) — `channels.discord`
+    - [Feishu](/de/channels/feishu) — `channels.feishu`
+    - [Google Chat](/de/channels/googlechat) — `channels.googlechat`
+    - [Microsoft Teams](/de/channels/msteams) — `channels.msteams`
+    - [Slack](/de/channels/slack) — `channels.slack`
+    - [Signal](/de/channels/signal) — `channels.signal`
+    - [iMessage](/de/channels/imessage) — `channels.imessage`
+    - [Mattermost](/de/channels/mattermost) — `channels.mattermost`

    Alle Kanäle verwenden dasselbe DM-Richtlinienmuster:

@ -154,29 +144,29 @@ Wenn die Validierung fehlschlägt:
    ```

    - `agents.defaults.models` definiert den Modellkatalog und dient als Allowlist für `/model`.
-    - Modell-Refs verwenden das Format `provider/model` (z. B. `anthropic/claude-opus-4-6`).
-    - `agents.defaults.imageMaxDimensionPx` steuert das Downscaling von Bildern in Transkripten/Tools (Standard `1200`); niedrigere Werte reduzieren in der Regel den Verbrauch von Vision-Tokens bei screenshotlastigen Ausführungen.
-    - Siehe [Models CLI](/concepts/models) zum Wechseln von Modellen im Chat und [Model Failover](/concepts/model-failover) für Auth-Rotation und Fallback-Verhalten.
-    - Für benutzerdefinierte/selbst gehostete Provider siehe [Custom providers](/gateway/configuration-reference#custom-providers-and-base-urls) in der Referenz.
+    - Modellreferenzen verwenden das Format `provider/model` (z. B. `anthropic/claude-opus-4-6`).
+    - `agents.defaults.imageMaxDimensionPx` steuert die Größenanpassung von Bildern in Transkripten/Tools (Standard `1200`); niedrigere Werte reduzieren in der Regel die Vision-Token-Nutzung bei screenshotlastigen Abläufen.
+    - Siehe [Models CLI](/de/concepts/models) zum Wechseln von Modellen im Chat und [Model Failover](/de/concepts/model-failover) für Auth-Rotation und Fallback-Verhalten.
+    - Für benutzerdefinierte/selbst gehostete Provider siehe [Benutzerdefinierte Provider](/de/gateway/configuration-reference#custom-providers-and-base-urls) in der Referenz.

  </Accordion>

-  <Accordion title="Steuern, wer dem Bot Nachrichten senden darf">
+  <Accordion title="Steuern, wer dem Bot Nachrichten senden kann">
    Der DM-Zugriff wird pro Kanal über `dmPolicy` gesteuert:

-    - `"pairing"` (Standard): unbekannte Absender erhalten einen einmaligen Pairing-Code zur Genehmigung
+    - `"pairing"` (Standard): unbekannte Absender erhalten einen einmaligen Pairing-Code zur Freigabe
    - `"allowlist"`: nur Absender in `allowFrom` (oder im gepaarten Allow-Store)
-    - `"open"`: erlaubt alle eingehenden DMs (erfordert `allowFrom: ["*"]`)
-    - `"disabled"`: ignoriert alle DMs
+    - `"open"`: alle eingehenden DMs zulassen (erfordert `allowFrom: ["*"]`)
+    - `"disabled"`: alle DMs ignorieren

    Für Gruppen verwenden Sie `groupPolicy` + `groupAllowFrom` oder kanalspezifische Allowlists.

-    In der [vollständigen Referenz](/gateway/configuration-reference#dm-and-group-access) finden Sie kanalspezifische Details.
+    Siehe die [vollständige Referenz](/de/gateway/configuration-reference#dm-and-group-access) für Details pro Kanal.

  </Accordion>

-  <Accordion title="Mention-Gating für Gruppenchats einrichten">
-    Gruppennachrichten erfordern standardmäßig eine **Erwähnung**. Konfigurieren Sie Muster pro Agent:
+  <Accordion title="Erwähnungs-Gating für Gruppenchats einrichten">
+    Gruppen-Nachrichten erfordern standardmäßig **eine Erwähnung**. Konfigurieren Sie Muster pro Agent:

    ```json5
    {
@ -198,15 +188,14 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    - **Metadaten-Erwähnungen**: native @-Erwähnungen (WhatsApp Tap-to-mention, Telegram @bot usw.)
+    - **Metadaten-Erwähnungen**: native @-Erwähnungen (WhatsApp Tap-to-Mention, Telegram @bot usw.)
    - **Textmuster**: sichere Regex-Muster in `mentionPatterns`
-    - Siehe [vollständige Referenz](/gateway/configuration-reference#group-chat-mention-gating) für kanalspezifische Überschreibungen und den Self-Chat-Modus.
+    - Siehe [vollständige Referenz](/de/gateway/configuration-reference#group-chat-mention-gating) für Überschreibungen pro Kanal und den Selbstchat-Modus.

  </Accordion>

  <Accordion title="Skills pro Agent einschränken">
-    Verwenden Sie `agents.defaults.skills` für eine gemeinsame Baseline und überschreiben Sie dann bestimmte
-    Agenten mit `agents.list[].skills`:
+    Verwenden Sie `agents.defaults.skills` für eine gemeinsame Basis und überschreiben Sie dann bestimmte Agents mit `agents.list[].skills`:

    ```json5
    {
@ -223,15 +212,14 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    - Lassen Sie `agents.defaults.skills` weg, damit Skills standardmäßig nicht eingeschränkt sind.
+    - Lassen Sie `agents.defaults.skills` weg, wenn Skills standardmäßig nicht eingeschränkt sein sollen.
    - Lassen Sie `agents.list[].skills` weg, um die Standardwerte zu übernehmen.
-    - Setzen Sie `agents.list[].skills: []`, um keine Skills zu erlauben.
-    - Siehe [Skills](/tools/skills), [Skills config](/tools/skills-config) und
-      die [Configuration Reference](/gateway/configuration-reference#agentsdefaultsskills).
+    - Setzen Sie `agents.list[].skills: []` für keine Skills.
+    - Siehe [Skills](/de/tools/skills), [Skills-Konfiguration](/de/tools/skills-config) und die [Konfigurationsreferenz](/de/gateway/configuration-reference#agentsdefaultsskills).

  </Accordion>

-  <Accordion title="Gateway-Kanalzustandsüberwachung anpassen">
+  <Accordion title="Gateway-Kanal-Gesundheitsüberwachung abstimmen">
    Steuern Sie, wie aggressiv das Gateway Kanäle neu startet, die veraltet wirken:

    ```json5
@ -254,14 +242,14 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    - Setzen Sie `gateway.channelHealthCheckMinutes: 0`, um Neustarts durch den Health Monitor global zu deaktivieren.
+    - Setzen Sie `gateway.channelHealthCheckMinutes: 0`, um Neustarts durch die Gesundheitsüberwachung global zu deaktivieren.
    - `channelStaleEventThresholdMinutes` sollte größer oder gleich dem Prüfintervall sein.
-    - Verwenden Sie `channels.<provider>.healthMonitor.enabled` oder `channels.<provider>.accounts.<id>.healthMonitor.enabled`, um automatische Neustarts für einen einzelnen Kanal oder ein einzelnes Konto zu deaktivieren, ohne den globalen Monitor auszuschalten.
-    - Siehe [Health Checks](/gateway/health) für operative Fehlerbehebung und die [vollständige Referenz](/gateway/configuration-reference#gateway) für alle Felder.
+    - Verwenden Sie `channels.<provider>.healthMonitor.enabled` oder `channels.<provider>.accounts.<id>.healthMonitor.enabled`, um automatische Neustarts für einen Kanal oder ein Konto zu deaktivieren, ohne die globale Überwachung auszuschalten.
+    - Siehe [Health Checks](/de/gateway/health) für die operative Fehlersuche und die [vollständige Referenz](/de/gateway/configuration-reference#gateway) für alle Felder.

  </Accordion>

-  <Accordion title="Sitzungen und Resets konfigurieren">
+  <Accordion title="Sitzungen und Zurücksetzungen konfigurieren">
    Sitzungen steuern Gesprächskontinuität und Isolation:

    ```json5
@ -282,15 +270,15 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    - `dmScope`: `main` (geteilt) | `per-peer` | `per-channel-peer` | `per-account-channel-peer`
+    - `dmScope`: `main` (gemeinsam) | `per-peer` | `per-channel-peer` | `per-account-channel-peer`
    - `threadBindings`: globale Standardwerte für threadgebundenes Sitzungsrouting (Discord unterstützt `/focus`, `/unfocus`, `/agents`, `/session idle` und `/session max-age`).
-    - Siehe [Session Management](/concepts/session) für Scoping, Identitätsverknüpfungen und Sende-Richtlinien.
-    - Siehe [vollständige Referenz](/gateway/configuration-reference#session) für alle Felder.
+    - Siehe [Session Management](/de/concepts/session) für Scoping, Identitätsverknüpfungen und Send-Richtlinien.
+    - Siehe [vollständige Referenz](/de/gateway/configuration-reference#session) für alle Felder.

  </Accordion>

  <Accordion title="Sandboxing aktivieren">
-    Führen Sie Agentensitzungen in isolierten Docker-Containern aus:
+    Führen Sie Agent-Sitzungen in isolierten Docker-Containern aus:

    ```json5
    {
@ -305,9 +293,9 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    Erstellen Sie zuerst das Image: `scripts/sandbox-setup.sh`
+    Erstellen Sie das Image zuerst: `scripts/sandbox-setup.sh`

-    Siehe [Sandboxing](/gateway/sandboxing) für die vollständige Anleitung und die [vollständige Referenz](/gateway/configuration-reference#agentsdefaultssandbox) für alle Optionen.
+    Siehe [Sandboxing](/de/gateway/sandboxing) für die vollständige Anleitung und die [vollständige Referenz](/de/gateway/configuration-reference#agentsdefaultssandbox) für alle Optionen.

  </Accordion>

@ -338,37 +326,37 @@ Wenn die Validierung fehlschlägt:
    openclaw config set gateway.push.apns.relay.baseUrl https://relay.example.com
    ```

-    Was dies bewirkt:
+    Das bewirkt Folgendes:

    - Ermöglicht dem Gateway, `push.test`, Wake-Nudges und Reconnect-Wakes über das externe Relay zu senden.
    - Verwendet eine registrierungsbezogene Sendeberechtigung, die von der gepaarten iOS-App weitergeleitet wird. Das Gateway benötigt kein Relay-Token für die gesamte Bereitstellung.
-    - Bindet jede relaygestützte Registrierung an die Gateway-Identität, mit der die iOS-App gepaart wurde, sodass ein anderes Gateway die gespeicherte Registrierung nicht wiederverwenden kann.
-    - Lässt lokale/manuelle iOS-Builds bei direktem APNs. Relay-gestützte Sendungen gelten nur für offiziell verteilte Builds, die sich über das Relay registriert haben.
-    - Muss mit der Relay-Basis-URL übereinstimmen, die in den offiziellen/TestFlight-iOS-Build eingebettet ist, damit Registrierungs- und Sendetraffic dieselbe Relay-Bereitstellung erreichen.
+    - Bindet jede Relay-gestützte Registrierung an die Gateway-Identität, mit der die iOS-App gekoppelt wurde, sodass ein anderes Gateway die gespeicherte Registrierung nicht wiederverwenden kann.
+    - Behält lokale/manuelle iOS-Builds bei direktem APNs. Relay-gestützte Sendungen gelten nur für offiziell verteilte Builds, die sich über das Relay registriert haben.
+    - Muss mit der Relay-Basis-URL übereinstimmen, die in den offiziellen/TestFlight-iOS-Build eingebettet ist, damit Registrierungs- und Sendedatenverkehr dieselbe Relay-Bereitstellung erreicht.

-    Ende-zu-Ende-Ablauf:
+    End-to-End-Ablauf:

    1. Installieren Sie einen offiziellen/TestFlight-iOS-Build, der mit derselben Relay-Basis-URL kompiliert wurde.
    2. Konfigurieren Sie `gateway.push.apns.relay.baseUrl` auf dem Gateway.
-    3. Pairen Sie die iOS-App mit dem Gateway und lassen Sie sowohl Node- als auch Operator-Sitzungen verbinden.
-    4. Die iOS-App ruft die Gateway-Identität ab, registriert sich beim Relay mit App Attest plus dem App-Receipt und veröffentlicht dann die relaygestützte `push.apns.register`-Payload an das gepaarte Gateway.
+    3. Koppeln Sie die iOS-App mit dem Gateway und lassen Sie sowohl Node- als auch Operatorsitzungen verbinden.
+    4. Die iOS-App ruft die Gateway-Identität ab, registriert sich mit dem Relay unter Verwendung von App Attest plus dem App-Beleg und veröffentlicht anschließend die Relay-gestützte `push.apns.register`-Payload an das gekoppelte Gateway.
    5. Das Gateway speichert den Relay-Handle und die Sendeberechtigung und verwendet sie dann für `push.test`, Wake-Nudges und Reconnect-Wakes.

    Betriebshinweise:

-    - Wenn Sie die iOS-App auf ein anderes Gateway umstellen, verbinden Sie die App erneut, damit sie eine neue, an dieses Gateway gebundene Relay-Registrierung veröffentlichen kann.
+    - Wenn Sie die iOS-App auf ein anderes Gateway umstellen, verbinden Sie die App erneut, damit sie eine neue Relay-Registrierung veröffentlichen kann, die an dieses Gateway gebunden ist.
    - Wenn Sie einen neuen iOS-Build ausliefern, der auf eine andere Relay-Bereitstellung verweist, aktualisiert die App ihre zwischengespeicherte Relay-Registrierung, anstatt den alten Relay-Ursprung wiederzuverwenden.

    Kompatibilitätshinweis:

-    - `OPENCLAW_APNS_RELAY_BASE_URL` und `OPENCLAW_APNS_RELAY_TIMEOUT_MS` funktionieren weiterhin als temporäre Env-Überschreibungen.
-    - `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` bleibt eine nur für loopback gedachte Entwicklungs-Ausweichmöglichkeit; speichern Sie keine HTTP-Relay-URLs dauerhaft in der Konfiguration.
+    - `OPENCLAW_APNS_RELAY_BASE_URL` und `OPENCLAW_APNS_RELAY_TIMEOUT_MS` funktionieren weiterhin als temporäre Env-Overrides.
+    - `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` bleibt eine nur für loopback gedachte Entwicklungsausnahme; persistieren Sie keine HTTP-Relay-URLs in der Konfiguration.

-    Siehe [iOS App](/platforms/ios#relay-backed-push-for-official-builds) für den Ende-zu-Ende-Ablauf und [Authentication and trust flow](/platforms/ios#authentication-and-trust-flow) für das Relay-Sicherheitsmodell.
+    Siehe [iOS App](/de/platforms/ios#relay-backed-push-for-official-builds) für den End-to-End-Ablauf und [Authentifizierungs- und Vertrauensablauf](/de/platforms/ios#authentication-and-trust-flow) für das Relay-Sicherheitsmodell.

  </Accordion>

-  <Accordion title="Heartbeat einrichten (periodische Check-ins)">
+  <Accordion title="Heartbeat einrichten (regelmäßige Check-ins)">
    ```json5
    {
      agents: {
@ -382,10 +370,10 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    - `every`: Duration-String (`30m`, `2h`). Setzen Sie `0m`, um zu deaktivieren.
+    - `every`: Dauer-String (`30m`, `2h`). Setzen Sie `0m`, um zu deaktivieren.
    - `target`: `last` | `none` | `<channel-id>` (zum Beispiel `discord`, `matrix`, `telegram` oder `whatsapp`)
    - `directPolicy`: `allow` (Standard) oder `block` für DM-artige Heartbeat-Ziele
-    - Siehe [Heartbeat](/gateway/heartbeat) für die vollständige Anleitung.
+    - Siehe [Heartbeat](/de/gateway/heartbeat) für die vollständige Anleitung.

  </Accordion>

@ -404,14 +392,14 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    - `sessionRetention`: bereinigt abgeschlossene isolierte Ausführungssitzungen aus `sessions.json` (Standard `24h`; setzen Sie `false`, um zu deaktivieren).
-    - `runLog`: bereinigt `cron/runs/<jobId>.jsonl` nach Größe und beibehaltenen Zeilen.
-    - Siehe [Cron jobs](/automation/cron-jobs) für Funktionsüberblick und CLI-Beispiele.
+    - `sessionRetention`: abgeschlossene isolierte Ausführungssitzungen aus `sessions.json` entfernen (Standard `24h`; setzen Sie `false`, um zu deaktivieren).
+    - `runLog`: `cron/runs/<jobId>.jsonl` nach Größe und beibehaltenen Zeilen kürzen.
+    - Siehe [Cron jobs](/de/automation/cron-jobs) für die Funktionsübersicht und CLI-Beispiele.

  </Accordion>

-  <Accordion title="Webhooks einrichten (Hooks)">
-    Aktivieren Sie HTTP-Webhook-Endpunkte im Gateway:
+  <Accordion title="Webhooks (Hooks) einrichten">
+    Aktivieren Sie HTTP-Webhook-Endpunkte auf dem Gateway:

    ```json5
    {
@ -435,20 +423,20 @@ Wenn die Validierung fehlschlägt:
    ```

    Sicherheitshinweis:
-    - Behandeln Sie alle Hook-/Webhook-Payload-Inhalte als nicht vertrauenswürdige Eingabe.
-    - Verwenden Sie ein dediziertes `hooks.token`; verwenden Sie nicht das gemeinsame Gateway-Token erneut.
-    - Hook-Authentifizierung ist nur Header-basiert (`Authorization: Bearer ...` oder `x-openclaw-token`); Tokens in Query-Strings werden abgelehnt.
-    - `hooks.path` darf nicht `/` sein; halten Sie den Webhook-Eingang auf einem dedizierten Unterpfad wie `/hooks`.
-    - Lassen Sie Bypass-Flags für unsichere Inhalte deaktiviert (`hooks.gmail.allowUnsafeExternalContent`, `hooks.mappings[].allowUnsafeExternalContent`), außer für eng begrenztes Debugging.
+    - Behandeln Sie alle Hook-/Webhook-Payload-Inhalte als nicht vertrauenswürdige Eingaben.
+    - Verwenden Sie ein dediziertes `hooks.token`; verwenden Sie nicht das gemeinsame Gateway-Token wieder.
+    - Hook-Authentifizierung erfolgt nur per Header (`Authorization: Bearer ...` oder `x-openclaw-token`); Tokens in Query-Strings werden abgelehnt.
+    - `hooks.path` darf nicht `/` sein; belassen Sie den Webhook-Eingang auf einem dedizierten Unterpfad wie `/hooks`.
+    - Lassen Sie Unsicherer-Inhalt-Bypass-Flags deaktiviert (`hooks.gmail.allowUnsafeExternalContent`, `hooks.mappings[].allowUnsafeExternalContent`), außer bei eng begrenztem Debugging.
    - Wenn Sie `hooks.allowRequestSessionKey` aktivieren, setzen Sie auch `hooks.allowedSessionKeyPrefixes`, um vom Aufrufer gewählte Sitzungsschlüssel zu begrenzen.
-    - Für Hook-gesteuerte Agenten bevorzugen Sie starke moderne Modellstufen und eine strikte Tool-Richtlinie (zum Beispiel nur Messaging plus nach Möglichkeit Sandboxing).
+    - Für hookgesteuerte Agents sollten Sie starke moderne Modell-Tiers und eine strikte Tool-Richtlinie bevorzugen (zum Beispiel nur Messaging plus Sandboxing, wenn möglich).

-    Siehe [vollständige Referenz](/gateway/configuration-reference#hooks) für alle Mapping-Optionen und die Gmail-Integration.
+    Siehe die [vollständige Referenz](/de/gateway/configuration-reference#hooks) für alle Mapping-Optionen und die Gmail-Integration.

  </Accordion>

  <Accordion title="Multi-Agent-Routing konfigurieren">
-    Führen Sie mehrere isolierte Agenten mit separaten Workspaces und Sitzungen aus:
+    Führen Sie mehrere isolierte Agents mit getrennten Workspaces und Sitzungen aus:

    ```json5
    {
@ -465,11 +453,11 @@ Wenn die Validierung fehlschlägt:
    }
    ```

-    Siehe [Multi-Agent](/concepts/multi-agent) und die [vollständige Referenz](/gateway/configuration-reference#multi-agent-routing) für Binding-Regeln und agentenspezifische Zugriffsprofile.
+    Siehe [Multi-Agent](/de/concepts/multi-agent) und die [vollständige Referenz](/de/gateway/configuration-reference#multi-agent-routing) für Binding-Regeln und Zugriffsprofile pro Agent.

  </Accordion>

-  <Accordion title="Konfiguration auf mehrere Dateien aufteilen ($include)">
+  <Accordion title="Konfiguration in mehrere Dateien aufteilen ($include)">
    Verwenden Sie `$include`, um große Konfigurationen zu organisieren:

    ```json5
@ -484,27 +472,27 @@ Wenn die Validierung fehlschlägt:
    ```

    - **Einzelne Datei**: ersetzt das enthaltende Objekt
-    - **Array von Dateien**: wird der Reihe nach tief zusammengeführt (spätere gewinnt)
-    - **Nebenschlüssel**: werden nach Includes zusammengeführt (überschreiben inkludierte Werte)
+    - **Array von Dateien**: wird in Reihenfolge tief zusammengeführt (spätere gewinnt)
+    - **Nebenschlüssel**: werden nach den Includes zusammengeführt (überschreiben eingeschlossene Werte)
    - **Verschachtelte Includes**: werden bis zu 10 Ebenen tief unterstützt
-    - **Relative Pfade**: werden relativ zur inkludierenden Datei aufgelöst
+    - **Relative Pfade**: werden relativ zur einbindenden Datei aufgelöst
    - **Fehlerbehandlung**: klare Fehler bei fehlenden Dateien, Parse-Fehlern und zirkulären Includes

  </Accordion>
 </AccordionGroup>

-## Hot Reload der Konfiguration
+## Konfigurations-Hot-Reload

-Das Gateway überwacht `~/.openclaw/openclaw.json` und wendet Änderungen automatisch an — für die meisten Einstellungen ist kein manueller Neustart erforderlich.
+Das Gateway überwacht `~/.openclaw/openclaw.json` und übernimmt Änderungen automatisch — für die meisten Einstellungen ist kein manueller Neustart erforderlich.

 ### Reload-Modi

-| Modus                  | Verhalten                                                                                |
-| ---------------------- | ---------------------------------------------------------------------------------------- |
-| **`hybrid`** (Standard) | Wendet sichere Änderungen sofort hot an. Startet bei kritischen Änderungen automatisch neu. |
-| **`hot`**              | Wendet nur sichere Änderungen hot an. Protokolliert eine Warnung, wenn ein Neustart erforderlich ist — Sie kümmern sich darum. |
-| **`restart`**          | Startet das Gateway bei jeder Konfigurationsänderung neu, sicher oder nicht.             |
-| **`off`**              | Deaktiviert die Dateibeobachtung. Änderungen werden beim nächsten manuellen Neustart wirksam. |
+| Modus                  | Verhalten                                                                              |
+| ---------------------- | -------------------------------------------------------------------------------------- |
+| **`hybrid`** (Standard) | Wendet sichere Änderungen sofort per Hot-Apply an. Startet bei kritischen Änderungen automatisch neu. |
+| **`hot`**              | Wendet nur sichere Änderungen per Hot-Apply an. Protokolliert eine Warnung, wenn ein Neustart erforderlich ist — Sie kümmern sich darum. |
+| **`restart`**          | Startet das Gateway bei jeder Konfigurationsänderung neu, sicher oder nicht.           |
+| **`off`**              | Deaktiviert die Dateiüberwachung. Änderungen werden beim nächsten manuellen Neustart wirksam. |

 ```json5
 {
@ -514,49 +502,47 @@ Das Gateway überwacht `~/.openclaw/openclaw.json` und wendet Änderungen automa
 }
 ```

-### Was hot angewendet wird und was einen Neustart erfordert
+### Was per Hot-Apply übernommen wird und was einen Neustart erfordert

-Die meisten Felder werden ohne Ausfallzeit hot angewendet. Im Modus `hybrid` werden Änderungen, die einen Neustart erfordern, automatisch verarbeitet.
+Die meisten Felder werden ohne Ausfallzeit per Hot-Apply übernommen. Im `hybrid`-Modus werden Änderungen, die einen Neustart erfordern, automatisch verarbeitet.

-| Kategorie           | Felder                                                               | Neustart erforderlich? |
-| ------------------- | -------------------------------------------------------------------- | ---------------------- |
-| Kanäle              | `channels.*`, `web` (WhatsApp) — alle integrierten und Erweiterungskanäle | Nein                   |
-| Agent & Modelle     | `agent`, `agents`, `models`, `routing`                               | Nein                   |
-| Automatisierung     | `hooks`, `cron`, `agent.heartbeat`                                   | Nein                   |
-| Sitzungen & Nachrichten | `session`, `messages`                                            | Nein                   |
-| Tools & Medien      | `tools`, `browser`, `skills`, `audio`, `talk`                        | Nein                   |
-| UI & Sonstiges      | `ui`, `logging`, `identity`, `bindings`                              | Nein                   |
-| Gateway-Server      | `gateway.*` (Port, Bind, Auth, Tailscale, TLS, HTTP)                 | **Ja**                 |
-| Infrastruktur       | `discovery`, `canvasHost`, `plugins`                                 | **Ja**                 |
+| Kategorie            | Felder                                                               | Neustart erforderlich? |
+| -------------------- | -------------------------------------------------------------------- | ---------------------- |
+| Kanäle              | `channels.*`, `web` (WhatsApp) — alle integrierten und Erweiterungskanäle | Nein               |
+| Agent & Modelle     | `agent`, `agents`, `models`, `routing`                               | Nein                  |
+| Automatisierung     | `hooks`, `cron`, `agent.heartbeat`                                   | Nein                  |
+| Sitzungen & Nachrichten | `session`, `messages`                                            | Nein                  |
+| Tools & Medien      | `tools`, `browser`, `skills`, `audio`, `talk`                        | Nein                  |
+| UI & Sonstiges      | `ui`, `logging`, `identity`, `bindings`                              | Nein                  |
+| Gateway-Server      | `gateway.*` (port, bind, auth, tailscale, TLS, HTTP)                 | **Ja**                |
+| Infrastruktur       | `discovery`, `canvasHost`, `plugins`                                 | **Ja**                |

 <Note>
-`gateway.reload` und `gateway.remote` sind Ausnahmen — Änderungen daran lösen **keinen** Neustart aus.
+`gateway.reload` und `gateway.remote` sind Ausnahmen — ihre Änderung löst **keinen** Neustart aus.
 </Note>

-## Config-RPC (programmatische Updates)
+## Config RPC (programmatische Aktualisierungen)

 <Note>
-Control-Plane-Schreib-RPCs (`config.apply`, `config.patch`, `update.run`) sind auf **3 Anfragen pro 60 Sekunden** pro `deviceId+clientIp` begrenzt. Bei Begrenzung gibt der RPC `UNAVAILABLE` mit `retryAfterMs` zurück.
+Control-Plane-Schreib-RPCs (`config.apply`, `config.patch`, `update.run`) sind auf **3 Anfragen pro 60 Sekunden** pro `deviceId+clientIp` begrenzt. Bei Begrenzung gibt die RPC `UNAVAILABLE` mit `retryAfterMs` zurück.
 </Note>

 Sicherer/standardmäßiger Ablauf:

- `config.schema.lookup`: untersucht einen pfadbezogenen Konfigurationsunterbaum mit einem flachen
-  Schemaknoten, zugeordneten Hinweis-Metadaten und unmittelbaren Zusammenfassungen der Unterelemente
- `config.get`: ruft den aktuellen Snapshot + Hash ab
- `config.patch`: bevorzugter Pfad für Teilaktualisierungen
- `config.apply`: nur für vollständigen Konfigurationsersatz
- `update.run`: explizites Selbst-Update + Neustart
+- `config.schema.lookup`: einen pfadbezogenen Konfigurations-Teilbaum mit einem flachen Schemaknoten, passenden Hinweismetadaten und Zusammenfassungen der direkten Unterelemente untersuchen
+- `config.get`: den aktuellen Snapshot + Hash abrufen
+- `config.patch`: bevorzugter Pfad für partielle Aktualisierungen
+- `config.apply`: nur vollständiger Ersatz der gesamten Konfiguration
+- `update.run`: explizites Self-Update + Neustart

-Wenn Sie nicht die gesamte Konfiguration ersetzen, bevorzugen Sie `config.schema.lookup`
-und dann `config.patch`.
+Wenn Sie nicht die gesamte Konfiguration ersetzen, sollten Sie `config.schema.lookup` und dann `config.patch` bevorzugen.

 <AccordionGroup>
  <Accordion title="config.apply (vollständiger Ersatz)">
    Validiert + schreibt die vollständige Konfiguration und startet das Gateway in einem Schritt neu.

    <Warning>
-    `config.apply` ersetzt die **gesamte Konfiguration**. Verwenden Sie `config.patch` für Teilaktualisierungen oder `openclaw config set` für einzelne Schlüssel.
+    `config.apply` ersetzt die **gesamte Konfiguration**. Verwenden Sie `config.patch` für partielle Aktualisierungen oder `openclaw config set` für einzelne Schlüssel.
    </Warning>

    Parameter:
@ -564,10 +550,10 @@ und dann `config.patch`.
    - `raw` (string) — JSON5-Payload für die gesamte Konfiguration
    - `baseHash` (optional) — Konfigurations-Hash aus `config.get` (erforderlich, wenn Konfiguration vorhanden ist)
    - `sessionKey` (optional) — Sitzungsschlüssel für den Wake-up-Ping nach dem Neustart
-    - `note` (optional) — Hinweis für das Neustart-Sentinel
+    - `note` (optional) — Hinweis für den Neustart-Sentinel
    - `restartDelayMs` (optional) — Verzögerung vor dem Neustart (Standard 2000)

-    Neustartanfragen werden zusammengefasst, während bereits eine aussteht/läuft, und zwischen Neustartzyklen gilt eine Abkühlzeit von 30 Sekunden.
+    Neustartanfragen werden zusammengefasst, solange bereits eine Anfrage aussteht/in Bearbeitung ist, und zwischen Neustartzyklen gilt eine Abklingzeit von 30 Sekunden.

    ```bash
    openclaw gateway call config.get --params '{}'  # payload.hash erfassen
@ -580,8 +566,8 @@ und dann `config.patch`.

  </Accordion>

-  <Accordion title="config.patch (Teilaktualisierung)">
-    Führt eine Teilaktualisierung in die bestehende Konfiguration zusammen (JSON-Merge-Patch-Semantik):
+  <Accordion title="config.patch (partielle Aktualisierung)">
+    Führt eine partielle Aktualisierung mit der vorhandenen Konfiguration zusammen (Semantik von JSON Merge Patch):

    - Objekte werden rekursiv zusammengeführt
    - `null` löscht einen Schlüssel
@ -593,7 +579,7 @@ und dann `config.patch`.
    - `baseHash` (erforderlich) — Konfigurations-Hash aus `config.get`
    - `sessionKey`, `note`, `restartDelayMs` — wie bei `config.apply`

-    Das Neustartverhalten entspricht `config.apply`: zusammengefasste ausstehende Neustarts plus eine Abkühlzeit von 30 Sekunden zwischen Neustartzyklen.
+    Das Neustartverhalten entspricht `config.apply`: Zusammenfassung ausstehender Neustarts plus eine Abklingzeit von 30 Sekunden zwischen Neustartzyklen.

    ```bash
    openclaw gateway call config.patch --params '{
@ -607,7 +593,7 @@ und dann `config.patch`.

 ## Umgebungsvariablen

-OpenClaw liest Umgebungsvariablen aus dem Elternprozess sowie aus:
+OpenClaw liest Umgebungsvariablen aus dem übergeordneten Prozess sowie aus:

 - `.env` aus dem aktuellen Arbeitsverzeichnis (falls vorhanden)
 - `~/.openclaw/.env` (globaler Fallback)
@ -624,7 +610,7 @@ Keine der beiden Dateien überschreibt bestehende Umgebungsvariablen. Sie könne
 ```

 <Accordion title="Shell-Env-Import (optional)">
-  Wenn aktiviert und erwartete Schlüssel nicht gesetzt sind, führt OpenClaw Ihre Login-Shell aus und importiert nur die fehlenden Schlüssel:
+  Falls aktiviert und erwartete Schlüssel nicht gesetzt sind, führt OpenClaw Ihre Login-Shell aus und importiert nur die fehlenden Schlüssel:

 ```json5
 {
@ -634,11 +620,11 @@ Keine der beiden Dateien überschreibt bestehende Umgebungsvariablen. Sie könne
 }
 ```

-Entsprechende Env-Variable: `OPENCLAW_LOAD_SHELL_ENV=1`
+Env-Var-Äquivalent: `OPENCLAW_LOAD_SHELL_ENV=1`
 </Accordion>

-<Accordion title="Env-Variablenersetzung in Konfigurationswerten">
-  Verweisen Sie in jedem Stringwert der Konfiguration mit `${VAR_NAME}` auf Umgebungsvariablen:
+<Accordion title="Env-Var-Substitution in Konfigurationswerten">
+  Verweisen Sie in beliebigen Stringwerten der Konfiguration mit `${VAR_NAME}` auf Umgebungsvariablen:

 ```json5
 {
@ -649,15 +635,15 @@ Entsprechende Env-Variable: `OPENCLAW_LOAD_SHELL_ENV=1`

 Regeln:

- Es werden nur Großbuchstabennamen abgeglichen: `[A-Z_][A-Z0-9_]*`
- Fehlende/leere Variablen lösen beim Laden einen Fehler aus
- Escapen Sie mit `$${VAR}` für eine wörtliche Ausgabe
+- Es werden nur großgeschriebene Namen abgeglichen: `[A-Z_][A-Z0-9_]*`
+- Fehlende/leere Variablen werfen beim Laden einen Fehler
+- Mit `$${VAR}` für wörtliche Ausgabe maskieren
 - Funktioniert auch in `$include`-Dateien
- Inline-Ersetzung: `"${BASE}/v1"` → `"https://api.example.com/v1"`
+- Inline-Substitution: `"${BASE}/v1"` → `"https://api.example.com/v1"`

 </Accordion>

-<Accordion title="SecretRefs (env, file, exec)">
+<Accordion title="Secret-Refs (env, file, exec)">
  Für Felder, die SecretRef-Objekte unterstützen, können Sie Folgendes verwenden:

 ```json5
@ -690,16 +676,16 @@ Regeln:
 }
 ```

-Details zu SecretRef (einschließlich `secrets.providers` für `env`/`file`/`exec`) finden Sie unter [Secrets Management](/gateway/secrets).
-Unterstützte Anmeldedatenpfade sind unter [SecretRef Credential Surface](/reference/secretref-credential-surface) aufgeführt.
+Details zu SecretRef (einschließlich `secrets.providers` für `env`/`file`/`exec`) finden Sie unter [Secrets Management](/de/gateway/secrets).
+Unterstützte Credential-Pfade sind unter [SecretRef Credential Surface](/de/reference/secretref-credential-surface) aufgeführt.
 </Accordion>

-Siehe [Environment](/help/environment) für vollständige Vorrangregeln und Quellen.
+Siehe [Environment](/de/help/environment) für vollständige Priorität und Quellen.

 ## Vollständige Referenz

-Die vollständige Referenz für alle Felder finden Sie unter **[Configuration Reference](/gateway/configuration-reference)**.
+Für die vollständige Feld-für-Feld-Referenz siehe **[Configuration Reference](/de/gateway/configuration-reference)**.

 ---

-_Verwandt: [Configuration Examples](/gateway/configuration-examples) · [Configuration Reference](/gateway/configuration-reference) · [Doctor](/gateway/doctor)_
+_Verwandt: [Konfigurationsbeispiele](/de/gateway/configuration-examples) · [Configuration Reference](/de/gateway/configuration-reference) · [Doctor](/de/gateway/doctor)_
--- a/docs/de/plugins/memory-wiki.md
+++ b/docs/de/plugins/memory-wiki.md
@ -0,0 +1,343 @@
+---
+read_when:
+    - Sie möchten dauerhaftes Wissen über einfache MEMORY.md-Notizen hinaus
+    - Sie konfigurieren das gebündelte memory-wiki-Plugin
+    - Sie möchten wiki_search, wiki_get oder den Bridge-Modus verstehen
+summary: 'memory-wiki: kompilierter Wissensspeicher mit Herkunftsnachweisen, Claims, Dashboards und Bridge-Modus'
+title: Memory Wiki
+x-i18n:
+    generated_at: "2026-04-08T06:01:25Z"
+    model: gpt-5.4
+    provider: openai
+    source_hash: b78dd6a4ef4451dae6b53197bf0c7c2a2ba846b08e4a3a93c1026366b1598d82
+    source_path: plugins/memory-wiki.md
+    workflow: 15
+---
+
+# Memory Wiki
+
+`memory-wiki` ist ein gebündeltes Plugin, das dauerhaften Speicher in einen kompilierten Wissensspeicher verwandelt.
+
+Es ersetzt **nicht** das aktive Speicher-Plugin. Das aktive Speicher-Plugin ist weiterhin für Recall, Promotion, Indizierung und Dreaming zuständig. `memory-wiki` steht daneben und kompiliert dauerhaftes Wissen in ein navigierbares Wiki mit deterministischen Seiten, strukturierten Claims, Herkunftsnachweisen, Dashboards und maschinenlesbaren Digests.
+
+Verwenden Sie es, wenn sich Speicher eher wie eine gepflegte Wissensebene und weniger wie ein Haufen Markdown-Dateien verhalten soll.
+
+## Was es hinzufügt
+
+- Einen dedizierten Wiki-Speicher mit deterministischem Seitenlayout
+- Strukturierte Claim- und Evidenzmetadaten statt nur Fließtext
+- Herkunftsnachweise, Konfidenz, Widersprüche und offene Fragen auf Seitenebene
+- Kompilierte Digests für Agenten- und Laufzeit-Consumer
+- Wiki-native Search-/Get-/Apply-/Lint-Tools
+- Optionalen Bridge-Modus, der öffentliche Artefakte aus dem aktiven Speicher-Plugin importiert
+- Optionalen Obsidian-freundlichen Rendermodus und CLI-Integration
+
+## Wie es mit Speicher zusammenpasst
+
+Stellen Sie sich die Aufteilung so vor:
+
+| Ebene                                                   | Zuständig für                                                                              |
+| ------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
+| Aktives Speicher-Plugin (`memory-core`, QMD, Honcho usw.) | Recall, semantische Suche, Promotion, Dreaming, Speicher-Laufzeit                          |
+| `memory-wiki`                                           | Kompilierte Wiki-Seiten, Synthesen mit Herkunftsnachweisen, Dashboards, wiki-spezifische Search/Get/Apply |
+
+Wenn das aktive Speicher-Plugin gemeinsame Recall-Artefakte bereitstellt, kann OpenClaw mit `memory_search corpus=all` beide Ebenen in einem Durchlauf durchsuchen.
+
+Wenn Sie wiki-spezifisches Ranking, Herkunftsnachweise oder direkten Seitenzugriff benötigen, verwenden Sie stattdessen die wiki-nativen Tools.
+
+## Speicher-Modi
+
+`memory-wiki` unterstützt drei Speicher-Modi:
+
+### `isolated`
+
+Eigener Speicher, eigene Quellen, keine Abhängigkeit von `memory-core`.
+
+Verwenden Sie diesen Modus, wenn das Wiki ein eigener kuratierter Wissensspeicher sein soll.
+
+### `bridge`
+
+Liest öffentliche Speicher-Artefakte und Speicher-Ereignisse aus dem aktiven Speicher-Plugin über öffentliche Plugin-SDK-Schnittstellen.
+
+Verwenden Sie diesen Modus, wenn das Wiki die exportierten Artefakte des Speicher-Plugins kompilieren und organisieren soll, ohne auf private Plugin-Interna zuzugreifen.
+
+Der Bridge-Modus kann Folgendes indizieren:
+
+- exportierte Speicher-Artefakte
+- Dreaming-Berichte
+- tägliche Notizen
+- Dateien im Speicher-Stammverzeichnis
+- Speicher-Ereignisprotokolle
+
+### `unsafe-local`
+
+Expliziter Escape Hatch auf demselben Rechner für lokale private Pfade.
+
+Dieser Modus ist absichtlich experimentell und nicht portabel. Verwenden Sie ihn nur, wenn Sie die Vertrauensgrenze verstehen und ausdrücklich lokalen Dateisystemzugriff benötigen, den der Bridge-Modus nicht bereitstellen kann.
+
+## Speicher-Layout
+
+Das Plugin initialisiert einen Speicher wie diesen:
+
+```text
+<vault>/
+  AGENTS.md
+  WIKI.md
+  index.md
+  inbox.md
+  entities/
+  concepts/
+  syntheses/
+  sources/
+  reports/
+  _attachments/
+  _views/
+  .openclaw-wiki/
+```
+
+Verwaltete Inhalte bleiben innerhalb generierter Blöcke. Von Menschen erstellte Notizblöcke bleiben erhalten.
+
+Die wichtigsten Seitengruppen sind:
+
+- `sources/` für importiertes Rohmaterial und Bridge-gestützte Seiten
+- `entities/` für dauerhafte Dinge, Personen, Systeme, Projekte und Objekte
+- `concepts/` für Ideen, Abstraktionen, Muster und Richtlinien
+- `syntheses/` für kompilierte Zusammenfassungen und gepflegte Übersichten
+- `reports/` für generierte Dashboards
+
+## Strukturierte Claims und Evidenz
+
+Seiten können strukturiertes `claims`-Frontmatter tragen, nicht nur Freitext.
+
+Jeder Claim kann Folgendes enthalten:
+
+- `id`
+- `text`
+- `status`
+- `confidence`
+- `evidence[]`
+- `updatedAt`
+
+Evidenz-Einträge können Folgendes enthalten:
+
+- `sourceId`
+- `path`
+- `lines`
+- `weight`
+- `note`
+- `updatedAt`
+
+Dadurch verhält sich das Wiki eher wie eine Überzeugungsebene als wie eine passive Notizablage. Claims können verfolgt, bewertet, angefochten und auf Quellen zurückgeführt werden.
+
+## Kompilierungs-Pipeline
+
+Der Kompilierungsschritt liest Wiki-Seiten, normalisiert Zusammenfassungen und erzeugt stabile, maschinenorientierte Artefakte unter:
+
+- `.openclaw-wiki/cache/agent-digest.json`
+- `.openclaw-wiki/cache/claims.jsonl`
+
+Diese Digests existieren, damit Agenten und Laufzeitcode nicht Markdown-Seiten scrapen müssen.
+
+Die kompilierte Ausgabe unterstützt außerdem:
+
+- Wiki-Indizierung im ersten Durchlauf für Search/Get-Abläufe
+- Claim-ID-Lookup zurück zu den besitzenden Seiten
+- kompakte Prompt-Ergänzungen
+- Generierung von Berichten/Dashboards
+
+## Dashboards und Zustandsberichte
+
+Wenn `render.createDashboards` aktiviert ist, pflegt die Kompilierung Dashboards unter `reports/`.
+
+Integrierte Berichte umfassen:
+
+- `reports/open-questions.md`
+- `reports/contradictions.md`
+- `reports/low-confidence.md`
+- `reports/claim-health.md`
+- `reports/stale-pages.md`
+
+Diese Berichte verfolgen Dinge wie:
+
+- Cluster von Widerspruchsnotizen
+- konkurrierende Claim-Cluster
+- Claims ohne strukturierte Evidenz
+- Seiten und Claims mit niedriger Konfidenz
+- veraltete oder unbekannte Aktualität
+- Seiten mit ungelösten Fragen
+
+## Suche und Abruf
+
+`memory-wiki` unterstützt zwei Such-Backends:
+
+- `shared`: verwendet den gemeinsamen Speicher-Suchablauf, wenn verfügbar
+- `local`: durchsucht das Wiki lokal
+
+Es unterstützt außerdem drei Korpora:
+
+- `wiki`
+- `memory`
+- `all`
+
+Wichtiges Verhalten:
+
+- `wiki_search` und `wiki_get` verwenden nach Möglichkeit kompilierte Digests als ersten Durchlauf
+- Claim-IDs können zur besitzenden Seite aufgelöst werden
+- umstrittene/veraltete/aktuelle Claims beeinflussen das Ranking
+- Herkunftslabels können in die Ergebnisse übernommen werden
+
+Praktische Regel:
+
+- verwenden Sie `memory_search corpus=all` für einen breiten Recall-Durchlauf
+- verwenden Sie `wiki_search` + `wiki_get`, wenn wiki-spezifisches Ranking, Herkunftsnachweise oder Seitenstrukturen für Überzeugungen wichtig sind
+
+## Agenten-Tools
+
+Das Plugin registriert diese Tools:
+
+- `wiki_status`
+- `wiki_search`
+- `wiki_get`
+- `wiki_apply`
+- `wiki_lint`
+
+Was sie tun:
+
+- `wiki_status`: aktueller Speicher-Modus, Zustand, Verfügbarkeit der Obsidian-CLI
+- `wiki_search`: durchsucht Wiki-Seiten und, wenn konfiguriert, gemeinsame Speicher-Korpora
+- `wiki_get`: liest eine Wiki-Seite nach ID/Pfad oder greift als Fallback auf das gemeinsame Speicher-Korpus zurück
+- `wiki_apply`: enge Synthese-/Metadaten-Mutationen ohne freie Seitenbearbeitung
+- `wiki_lint`: strukturelle Prüfungen, Lücken bei Herkunftsnachweisen, Widersprüche, offene Fragen
+
+Das Plugin registriert außerdem eine nicht-exklusive Speicher-Korpus-Ergänzung, sodass gemeinsames `memory_search` und `memory_get` das Wiki erreichen können, wenn das aktive Speicher-Plugin Korpusauswahl unterstützt.
+
+## Verhalten bei Prompt und Kontext
+
+Wenn `context.includeCompiledDigestPrompt` aktiviert ist, hängen Speicher-Prompt-Abschnitte einen kompakten kompilierten Schnappschuss aus `agent-digest.json` an.
+
+Dieser Schnappschuss ist absichtlich klein und signalstark:
+
+- nur Top-Seiten
+- nur Top-Claims
+- Anzahl der Widersprüche
+- Anzahl der Fragen
+- Konfidenz-/Aktualitätsqualifikatoren
+
+Dies ist optional, weil es die Prompt-Form verändert und hauptsächlich für Kontext-Engines oder ältere Prompt-Zusammenstellung nützlich ist, die Speicher-Ergänzungen ausdrücklich verwenden.
+
+## Konfiguration
+
+Legen Sie die Konfiguration unter `plugins.entries.memory-wiki.config` ab:
+
+```json5
+{
+  plugins: {
+    entries: {
+      "memory-wiki": {
+        enabled: true,
+        config: {
+          vaultMode: "isolated",
+          vault: {
+            path: "~/.openclaw/wiki/main",
+            renderMode: "obsidian",
+          },
+          obsidian: {
+            enabled: true,
+            useOfficialCli: true,
+            vaultName: "OpenClaw Wiki",
+            openAfterWrites: false,
+          },
+          bridge: {
+            enabled: false,
+            readMemoryArtifacts: true,
+            indexDreamReports: true,
+            indexDailyNotes: true,
+            indexMemoryRoot: true,
+            followMemoryEvents: true,
+          },
+          ingest: {
+            autoCompile: true,
+            maxConcurrentJobs: 1,
+            allowUrlIngest: true,
+          },
+          search: {
+            backend: "shared",
+            corpus: "wiki",
+          },
+          context: {
+            includeCompiledDigestPrompt: false,
+          },
+          render: {
+            preserveHumanBlocks: true,
+            createBacklinks: true,
+            createDashboards: true,
+          },
+        },
+      },
+    },
+  },
+}
+```
+
+Wichtige Schalter:
+
+- `vaultMode`: `isolated`, `bridge`, `unsafe-local`
+- `vault.renderMode`: `native` oder `obsidian`
+- `bridge.readMemoryArtifacts`: öffentliche Artefakte des aktiven Speicher-Plugins importieren
+- `bridge.followMemoryEvents`: Ereignisprotokolle im Bridge-Modus einschließen
+- `search.backend`: `shared` oder `local`
+- `search.corpus`: `wiki`, `memory` oder `all`
+- `context.includeCompiledDigestPrompt`: kompakten Digest-Schnappschuss an Speicher-Prompt-Abschnitte anhängen
+- `render.createBacklinks`: deterministische Verwandt-Blöcke generieren
+- `render.createDashboards`: Dashboard-Seiten generieren
+
+## CLI
+
+`memory-wiki` stellt außerdem eine Oberfläche der obersten Ebene in der CLI bereit:
+
+```bash
+openclaw wiki status
+openclaw wiki doctor
+openclaw wiki init
+openclaw wiki ingest ./notes/alpha.md
+openclaw wiki compile
+openclaw wiki lint
+openclaw wiki search "alpha"
+openclaw wiki get entity.alpha
+openclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alpha
+openclaw wiki bridge import
+openclaw wiki obsidian status
+```
+
+Die vollständige Befehlsreferenz finden Sie unter [CLI: wiki](/cli/wiki).
+
+## Obsidian-Unterstützung
+
+Wenn `vault.renderMode` auf `obsidian` gesetzt ist, schreibt das Plugin Obsidian-freundliches Markdown und kann optional die offizielle `obsidian`-CLI verwenden.
+
+Unterstützte Abläufe umfassen:
+
+- Statusprüfung
+- Speicher-Suche
+- Öffnen einer Seite
+- Aufrufen eines Obsidian-Befehls
+- Sprung zur täglichen Notiz
+
+Dies ist optional. Das Wiki funktioniert im nativen Modus auch ohne Obsidian.
+
+## Empfohlener Workflow
+
+1. Behalten Sie Ihr aktives Speicher-Plugin für Recall/Promotion/Dreaming.
+2. Aktivieren Sie `memory-wiki`.
+3. Beginnen Sie mit dem Modus `isolated`, sofern Sie nicht ausdrücklich den Bridge-Modus möchten.
+4. Verwenden Sie `wiki_search` / `wiki_get`, wenn Herkunftsnachweise wichtig sind.
+5. Verwenden Sie `wiki_apply` für enge Synthesen oder Metadatenaktualisierungen.
+6. Führen Sie nach sinnvollen Änderungen `wiki_lint` aus.
+7. Aktivieren Sie Dashboards, wenn Sie Sichtbarkeit für veraltete Inhalte/Widersprüche möchten.
+
+## Verwandte Dokumentation
+
+- [Memory Overview](/de/concepts/memory)
+- [CLI: memory](/cli/memory)
+- [CLI: wiki](/cli/wiki)
+- [Plugin SDK overview](/de/plugins/sdk-overview)
--- a/docs/de/providers/glm.md
+++ b/docs/de/providers/glm.md
@ -1,33 +1,33 @@
 ---
 read_when:
    - Sie möchten GLM-Modelle in OpenClaw verwenden
-    - Sie benötigen die Benennungskonvention und Einrichtung für Modelle
+    - Sie benötigen die Modellbenennungskonvention und die Einrichtung
 summary: Überblick über die GLM-Modellfamilie und wie sie in OpenClaw verwendet wird
 title: GLM-Modelle
 x-i18n:
-    generated_at: "2026-04-05T12:52:59Z"
+    generated_at: "2026-04-08T06:01:07Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 59622edab5094d991987f9788fbf08b33325e737e7ff88632b0c3ac89412d4c7
+    source_hash: 79a55acfa139847b4b85dbc09f1068cbd2febb1e49f984a23ea9e3b43bc910eb
    source_path: providers/glm.md
    workflow: 15
 ---

 # GLM-Modelle

-GLM ist eine **Modellfamilie** (kein Unternehmen), die über die Plattform Z.AI verfügbar ist. In OpenClaw
-wird auf GLM-Modelle über den Provider `zai` und Modell-IDs wie `zai/glm-5` zugegriffen.
+GLM ist eine **Modellfamilie** (kein Unternehmen), die über die Z.AI-Plattform verfügbar ist. In OpenClaw werden GLM-
+Modelle über den Provider `zai` und Modell-IDs wie `zai/glm-5` aufgerufen.

 ## CLI-Einrichtung

 ```bash
-# Generische API-Key-Einrichtung mit automatischer Endpunkterkennung
+# Allgemeine API-Key-Einrichtung mit automatischer Endpunkterkennung
 openclaw onboard --auth-choice zai-api-key

-# Coding Plan Global, empfohlen für Nutzer von Coding Plan
+# Coding Plan Global, empfohlen für Coding-Plan-Benutzer
 openclaw onboard --auth-choice zai-coding-global

-# Coding Plan CN (China-Region), empfohlen für Nutzer von Coding Plan
+# Coding Plan CN (China-Region), empfohlen für Coding-Plan-Benutzer
 openclaw onboard --auth-choice zai-coding-cn

 # Allgemeine API
@ -42,17 +42,17 @@ openclaw onboard --auth-choice zai-cn
 ```json5
 {
  env: { ZAI_API_KEY: "sk-..." },
-  agents: { defaults: { model: { primary: "zai/glm-5" } } },
+  agents: { defaults: { model: { primary: "zai/glm-5.1" } } },
 }
 ```

 Mit `zai-api-key` kann OpenClaw den passenden Z.AI-Endpunkt anhand des Schlüssels erkennen und
 automatisch die richtige Basis-URL anwenden. Verwenden Sie die expliziten regionalen Optionen, wenn
-Sie gezielt eine bestimmte Oberfläche für Coding Plan oder die allgemeine API erzwingen möchten.
+Sie eine bestimmte Coding-Plan- oder allgemeine API-Oberfläche erzwingen möchten.

 ## Aktuelle gebündelte GLM-Modelle

-OpenClaw initialisiert den gebündelten Provider `zai` derzeit mit diesen GLM-Referenzen:
+OpenClaw versieht den gebündelten Provider `zai` derzeit mit diesen GLM-Referenzen:

 - `glm-5.1`
 - `glm-5`
@ -70,6 +70,6 @@ OpenClaw initialisiert den gebündelten Provider `zai` derzeit mit diesen GLM-Re

 ## Hinweise

- GLM-Versionen und Verfügbarkeit können sich ändern; prüfen Sie die Z.AI-Dokumentation auf den neuesten Stand.
- Die standardmäßige gebündelte Modellreferenz ist `zai/glm-5`.
- Details zum Provider finden Sie unter [/providers/zai](/providers/zai).
+- GLM-Versionen und -Verfügbarkeit können sich ändern; prüfen Sie die Z.AI-Dokumentation auf die neuesten Informationen.
+- Die standardmäßig gebündelte Modellreferenz ist `zai/glm-5.1`.
+- Einzelheiten zum Provider finden Sie unter [/providers/zai](/de/providers/zai).
--- a/docs/de/providers/zai.md
+++ b/docs/de/providers/zai.md
@ -1,14 +1,14 @@
 ---
 read_when:
-    - Sie möchten Z.AI-/GLM-Modelle in OpenClaw verwenden
-    - Sie benötigen eine einfache Einrichtung mit `ZAI_API_KEY`
-summary: Verwenden Sie Z.AI (GLM-Modelle) mit OpenClaw
+    - Sie möchten Z.AI / GLM-Modelle in OpenClaw verwenden
+    - Sie benötigen eine einfache Einrichtung mit ZAI_API_KEY
+summary: Z.AI (GLM-Modelle) mit OpenClaw verwenden
 title: Z.AI
 x-i18n:
-    generated_at: "2026-04-05T12:54:16Z"
+    generated_at: "2026-04-08T06:01:16Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 48006cdd580484f0c62e2877b27a6a68d7bc44795b3e97a28213d95182d9acf9
+    source_hash: 66cbd9813ee28d202dcae34debab1b0cf9927793acb00743c1c62b48d9e381f9
    source_path: providers/zai.md
    workflow: 15
 ---
@ -22,28 +22,28 @@ mit einem Z.AI-API-Schlüssel.
 ## CLI-Einrichtung

 ```bash
-# Generische Einrichtung mit API-Schlüssel und automatischer Endpunkterkennung
+# Allgemeine API-Key-Einrichtung mit automatischer Endpunkterkennung
 openclaw onboard --auth-choice zai-api-key

 # Coding Plan Global, empfohlen für Coding-Plan-Benutzer
 openclaw onboard --auth-choice zai-coding-global

-# Coding Plan CN (Region China), empfohlen für Coding-Plan-Benutzer
+# Coding Plan CN (China-Region), empfohlen für Coding-Plan-Benutzer
 openclaw onboard --auth-choice zai-coding-cn

 # Allgemeine API
 openclaw onboard --auth-choice zai-global

-# Allgemeine API CN (Region China)
+# Allgemeine API CN (China-Region)
 openclaw onboard --auth-choice zai-cn
 ```

-## Konfigurationsausschnitt
+## Konfigurationsbeispiel

 ```json5
 {
  env: { ZAI_API_KEY: "sk-..." },
-  agents: { defaults: { model: { primary: "zai/glm-5" } } },
+  agents: { defaults: { model: { primary: "zai/glm-5.1" } } },
 }
 ```

@ -53,7 +53,7 @@ Sie eine bestimmte Coding-Plan- oder allgemeine API-Oberfläche erzwingen möcht

 ## Gebündelter GLM-Katalog

-OpenClaw initialisiert den gebündelten Provider `zai` derzeit mit:
+OpenClaw versieht den gebündelten Provider `zai` derzeit mit:

 - `glm-5.1`
 - `glm-5`
@ -72,11 +72,11 @@ OpenClaw initialisiert den gebündelten Provider `zai` derzeit mit:
 ## Hinweise

 - GLM-Modelle sind als `zai/<model>` verfügbar (Beispiel: `zai/glm-5`).
- Standardreferenz des gebündelten Modells: `zai/glm-5`
- Unbekannte `glm-5*`-IDs werden auf dem Pfad des gebündelten Providers weiterhin vorwärts aufgelöst, indem
-  provider-eigene Metadaten aus der Vorlage `glm-4.7` synthetisiert werden, wenn die ID
+- Standardmäßig gebündelte Modellreferenz: `zai/glm-5.1`
+- Unbekannte `glm-5*`-IDs werden auf dem gebündelten Provider-Pfad weiterhin vorwärts aufgelöst, indem
+  Provider-eigene Metadaten aus der Vorlage `glm-4.7` synthetisiert werden, wenn die ID
  der aktuellen Form der GLM-5-Familie entspricht.
- `tool_stream` ist standardmäßig für Z.AI-Streaming von Tool-Aufrufen aktiviert. Setzen Sie
+- `tool_stream` ist standardmäßig für das Streaming von Z.AI-Tool-Aufrufen aktiviert. Setzen Sie
  `agents.defaults.models["zai/<model>"].params.tool_stream` auf `false`, um es zu deaktivieren.
- Siehe [/providers/glm](/providers/glm) für den Überblick über die Modelfamilie.
+- Siehe [/providers/glm](/de/providers/glm) für den Überblick über die Modellfamilie.
 - Z.AI verwendet Bearer-Authentifizierung mit Ihrem API-Schlüssel.
--- a/docs/de/refactor/qa.md
+++ b/docs/de/refactor/qa.md
@ -1,20 +1,21 @@
 ---
 x-i18n:
-    generated_at: "2026-04-08T02:18:30Z"
+    generated_at: "2026-04-08T06:01:53Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 0e156cc8e2fe946a0423862f937754a7caa1fe7e6863b50a80bff49a1c86e1e8
+    source_hash: 4a9066b2a939c5a9ba69141d75405f0e8097997b523164340e2f0e9a0d5060dd
    source_path: refactor/qa.md
    workflow: 15
 ---

-# QA-Refactor
+# QA-Refaktorierung

 Status: grundlegende Migration abgeschlossen.

 ## Ziel

-OpenClaw-QA von einem Modell mit geteilten Definitionen auf eine Single Source of Truth umstellen:
+QA in OpenClaw von einem Modell mit geteilten Definitionen zu einer einzigen
+Quelle der Wahrheit verschieben:

 - Szenario-Metadaten
 - an das Modell gesendete Prompts
@ -23,30 +24,36 @@ OpenClaw-QA von einem Modell mit geteilten Definitionen auf eine Single Source o
 - Assertions und Erfolgskriterien
 - Artefakte und Hinweise für Berichte

-Der gewünschte Endzustand ist ein generisches QA-Harness, das leistungsfähige Szenario-Definitionsdateien lädt, statt den Großteil des Verhaltens in TypeScript fest zu codieren.
+Der gewünschte Endzustand ist ein generisches QA-Harness, das leistungsfähige
+Szenario-Definitionsdateien lädt, anstatt den Großteil des Verhaltens in
+TypeScript fest zu codieren.

 ## Aktueller Stand

-Die primäre Single Source of Truth liegt jetzt in `qa/scenarios.md`.
+Die primäre Quelle der Wahrheit liegt jetzt in `qa/scenarios/index.md` plus
+einer Datei pro Szenario unter `qa/scenarios/*.md`.

 Implementiert:

- `qa/scenarios.md`
-  - kanonisches QA-Paket
+- `qa/scenarios/index.md`
+  - kanonische Metadaten des QA-Pakets
  - Operator-Identität
  - Startmission
+- `qa/scenarios/*.md`
+  - eine Markdown-Datei pro Szenario
  - Szenario-Metadaten
  - Handler-Bindings
+  - szenariospezifische Ausführungskonfiguration
 - `extensions/qa-lab/src/scenario-catalog.ts`
  - Markdown-Paketparser + zod-Validierung
 - `extensions/qa-lab/src/qa-agent-bootstrap.ts`
  - Plan-Rendering aus dem Markdown-Paket
 - `extensions/qa-lab/src/qa-agent-workspace.ts`
-  - stellt generierte Kompatibilitätsdateien plus `QA_SCENARIOS.md` bereit
+  - erzeugt Kompatibilitätsdateien plus `QA_SCENARIOS.md`
 - `extensions/qa-lab/src/suite.ts`
  - wählt ausführbare Szenarien über in Markdown definierte Handler-Bindings aus
 - QA-Bus-Protokoll + UI
-  - generische Inline-Anhänge für Bild-/Video-/Audio-/Datei-Rendering
+  - generische Inline-Anhänge für das Rendern von Bild/Video/Audio/Datei

 Verbleibende geteilte Oberflächen:

@ -55,80 +62,84 @@ Verbleibende geteilte Oberflächen:
 - `extensions/qa-lab/src/report.ts`
  - leitet die Berichtsstruktur weiterhin aus Laufzeitausgaben ab

-Die Aufteilung der Single Source of Truth ist damit behoben, aber die Ausführung ist weiterhin größtenteils handlergestützt statt vollständig deklarativ.
+Damit ist die Aufteilung der Quelle der Wahrheit behoben, aber die Ausführung ist
+weiterhin größtenteils handlergestützt statt vollständig deklarativ.

-## Wie die tatsächliche Szenario-Oberfläche aussieht
+## Wie die echte Szenario-Oberfläche aussieht

-Beim Lesen der aktuellen Suite zeigen sich einige unterschiedliche Szenarioklassen.
+Beim Lesen der aktuellen Suite zeigen sich einige unterschiedliche
+Szenarioklassen.

 ### Einfache Interaktion

- Kanal-Baseline
- DM-Baseline
- Threaded-Follow-up
+- Kanal-Basislinie
+- DM-Basislinie
+- Thread-Follow-up
 - Modellwechsel
- Weiterverfolgung von Genehmigungen
+- Genehmigungs-Follow-through
 - Reaktion/Bearbeiten/Löschen

-### Konfigurations- und Laufzeitmutation
+### Konfigurations- und Laufzeitmutationen

- config patch beim Deaktivieren von Skills
- config apply bei Neustart-Aufwecken
- config restart bei Fähigkeitsumschaltung
- Laufzeit-Inventar-Drift-Prüfung
+- Skill-Deaktivierung per Config-Patch
+- Weckvorgang bei Neustart nach Config-Anwendung
+- Fähigkeitsumschaltung bei Config-Neustart
+- Laufzeit-Inventardrift-Prüfung

-### Dateisystem- und Repo-Assertions
+### Dateisystem- und Repository-Assertions

- Quell-/Dokumentations-Erkennungsbericht
+- Quell-/Dokumentations-Discovery-Bericht
 - Lobster Invaders bauen
 - Suche nach generierten Bildartefakten

-### Speicher-Orchestrierung
+### Memory-Orchestrierung

- Speicherabruf
- Speicher-Tools im Kanalkontext
- Fallback bei Speicherfehlern
- Ranking von Sitzungsspeicher
- Isolierung von Thread-Speicher
- Sweep für Memory Dreaming
+- Memory-Abruf
+- Memory-Tools im Kanalkontext
+- Fallback bei Memory-Fehler
+- Ranking von Sitzungs-Memory
+- Isolation von Thread-Memory
+- Memory-Dreaming-Durchlauf

 ### Tool- und Plugin-Integration

- MCP plugin-tools-Aufruf
+- MCP-Plugin-Tools-Aufruf
 - Skill-Sichtbarkeit
 - Skill-Hot-Install
 - native Bildgenerierung
 - Bild-Roundtrip
 - Bildverständnis aus Anhang

-### Mehrere Runden und mehrere Akteure
+### Multi-Turn und Multi-Akteur

- Unter-Agent-Übergabe
- Unter-Agent-Fanout-Synthese
- Flows zur Wiederherstellung nach Neustart
+- Subagent-Übergabe
+- Subagent-Fanout-Synthese
+- Stilflüsse für Wiederherstellung nach Neustart

-Diese Kategorien sind wichtig, weil sie die DSL-Anforderungen bestimmen. Eine flache Liste aus Prompt + erwartetem Text reicht nicht aus.
+Diese Kategorien sind wichtig, weil sie die DSL-Anforderungen bestimmen. Eine
+flache Liste mit Prompt + erwartetem Text reicht nicht aus.

 ## Richtung

-### Single Source of Truth
+### Eine einzige Quelle der Wahrheit

-Verwenden Sie `qa/scenarios.md` als verfasste Single Source of Truth.
+`qa/scenarios/index.md` plus `qa/scenarios/*.md` als verfasste Quelle der
+Wahrheit verwenden.

 Das Paket sollte bleiben:

 - für Reviews menschenlesbar
 - maschinenlesbar
- reichhaltig genug, um Folgendes zu steuern:
+- reich genug, um Folgendes zu steuern:
  - Suite-Ausführung
  - Bootstrap des QA-Workspace
-  - Metadaten der QA-Lab-UI
-  - Doku-/Discovery-Prompts
-  - Berichtsgenerierung
+  - QA-Lab-UI-Metadaten
+  - Dokumentations-/Discovery-Prompts
+  - Berichtserstellung

 ### Bevorzugtes Authoring-Format

-Markdown als Top-Level-Format mit strukturierter YAML darin verwenden.
+Markdown als Top-Level-Format mit strukturiertem YAML darin verwenden.

 Empfohlene Form:

@ -139,13 +150,13 @@ Empfohlene Form:
  - tags
  - docs refs
  - code refs
-  - model/provider overrides
-  - prerequisites
+  - Modell-/Provider-Überschreibungen
+  - Voraussetzungen
 - Prosa-Abschnitte
-  - objective
-  - notes
-  - debugging hints
- YAML-Blöcke in Fences
+  - Ziel
+  - Hinweise
+  - Debugging-Hinweise
+- abgegrenzte YAML-Blöcke
  - setup
  - steps
  - assertions
@ -154,12 +165,12 @@ Empfohlene Form:
 Das bietet:

 - bessere PR-Lesbarkeit als riesiges JSON
- reichhaltigeren Kontext als reines YAML
+- mehr Kontext als reines YAML
 - striktes Parsing und zod-Validierung

-Rohes JSON ist nur als generierte Zwischenform akzeptabel.
+Rohes JSON ist nur als zwischengenerierte Form akzeptabel.

-## Vorgeschlagene Form einer Szenariodatei
+## Vorgeschlagene Form der Szenariodatei

 Beispiel:

@ -182,9 +193,9 @@ codeRefs:
  - src/gateway/chat-attachments.ts
 ---

-# Ziel
+# Objective

-Prüfen, dass generierte Medien in der Follow-up-Runde wieder angehängt werden.
+Verify generated media is reattached on the follow-up turn.

 # Setup

@ -199,33 +210,33 @@ Prüfen, dass generierte Medien in der Follow-up-Runde wieder angehängt werden.
  key: agent:qa:image-roundtrip
 ```

-# Schritte
+# Steps

 ```yaml scenario.steps
 - action: agent.send
  session: agent:qa:image-roundtrip
  message: |
-    Bildgenerierungsprüfung: Generiere ein QA-Leuchtturmbild und fasse es in einem kurzen Satz zusammen.
+    Image generation check: generate a QA lighthouse image and summarize it in one short sentence.
 - action: artifact.capture
  kind: generated-image
-  promptSnippet: Bildgenerierungsprüfung
+  promptSnippet: Image generation check
  saveAs: lighthouseImage
 - action: agent.send
  session: agent:qa:image-roundtrip
  message: |
-    Prüfung der Bildinspektion im Roundtrip: Beschreibe den generierten Leuchtturm-Anhang in einem kurzen Satz.
+    Roundtrip image inspection check: describe the generated lighthouse attachment in one short sentence.
  attachments:
    - fromArtifact: lighthouseImage
 ```

-# Erwartung
+# Expect

 ```yaml scenario.expect
 - assert: outbound.textIncludes
  value: lighthouse
 - assert: requestLog.matches
  where:
-    promptIncludes: Prüfung der Bildinspektion im Roundtrip
+    promptIncludes: Roundtrip image inspection check
  imageInputCountGte: 1
 - assert: artifact.exists
  ref: lighthouseImage
@ -234,7 +245,8 @@ Prüfen, dass generierte Medien in der Follow-up-Runde wieder angehängt werden.

 ## Runner-Fähigkeiten, die die DSL abdecken muss

-Ausgehend von der aktuellen Suite braucht der generische Runner mehr als nur Prompt-Ausführung.
+Basierend auf der aktuellen Suite benötigt der generische Runner mehr als nur
+Prompt-Ausführung.

 ### Umgebungs- und Setup-Aktionen

@ -245,7 +257,7 @@ Ausgehend von der aktuellen Suite braucht der generische Runner mehr als nur Pro
 - `thread.create`
 - `workspace.writeSkill`

-### Agent-Runden-Aktionen
+### Agent-Turn-Aktionen

 - `agent.send`
 - `agent.wait`
@ -270,7 +282,7 @@ Ausgehend von der aktuellen Suite braucht der generische Runner mehr als nur Pro
 - `artifact.captureGeneratedImage`
 - `artifact.capturePath`

-### Speicher- und cron-Aktionen
+### Memory- und Cron-Aktionen

 - `memory.indexForce`
 - `memory.searchCli`
@ -308,46 +320,48 @@ Beispiele aus der aktuellen Suite:

 - einen Thread erstellen und dann `threadId` wiederverwenden
 - eine Sitzung erstellen und dann `sessionKey` wiederverwenden
- ein Bild generieren und dann die Datei in der nächsten Runde anhängen
- einen Wake-Marker-String generieren und dann prüfen, dass er später erscheint
+- ein Bild generieren und die Datei dann im nächsten Turn anhängen
+- eine Wake-Marker-Zeichenfolge erzeugen und dann prüfen, dass sie später erscheint

 Benötigte Fähigkeiten:

 - `saveAs`
 - `${vars.name}`
 - `${artifacts.name}`
- typisierte Referenzen für Pfade, Sitzungsschlüssel, Thread-IDs, Marker, Tool-Ausgaben
+- typisierte Referenzen für Pfade, Sitzungsschlüssel, Thread-IDs, Marker,
+  Tool-Ausgaben

-Ohne Variablenunterstützung wird die Harness weiterhin Szenariologik zurück in TypeScript auslaufen lassen.
+Ohne Variablenunterstützung wird die Harness-Szenariologik weiter zurück in
+TypeScript auslaufen.

 ## Was als Escape Hatches bleiben sollte

 Ein vollständig rein deklarativer Runner ist in Phase 1 nicht realistisch.

-Einige Szenarien sind von Natur aus stark orchestrierungsintensiv:
+Einige Szenarien sind naturgemäß stark orchestrierungsorientiert:

- Sweep für Memory Dreaming
- config apply bei Neustart-Aufwecken
- config restart bei Fähigkeitsumschaltung
+- Memory-Dreaming-Durchlauf
+- Weckvorgang bei Neustart nach Config-Anwendung
+- Fähigkeitsumschaltung bei Config-Neustart
 - Auflösung generierter Bildartefakte nach Zeitstempel/Pfad
- Auswertung von Discovery-Reports
+- Auswertung von Discovery-Berichten

 Diese sollten vorerst explizite benutzerdefinierte Handler verwenden.

 Empfohlene Regel:

- 85-90 % deklarativ
+- 85–90 % deklarativ
 - explizite `customHandler`-Schritte für den schwierigen Rest
 - nur benannte und dokumentierte benutzerdefinierte Handler
 - kein anonymer Inline-Code in der Szenariodatei

-So bleibt die generische Engine sauber und Fortschritt ist trotzdem möglich.
+Das hält die generische Engine sauber und ermöglicht trotzdem Fortschritt.

 ## Architekturänderung

 ### Aktuell

-Szenario-Markdown ist bereits die Single Source of Truth für:
+Markdown für Szenarien ist bereits die Quelle der Wahrheit für:

 - Suite-Ausführung
 - Bootstrap-Dateien des Workspace
@ -355,81 +369,83 @@ Szenario-Markdown ist bereits die Single Source of Truth für:
 - Berichtsmetadaten
 - Discovery-Prompts

-Generierte Kompatibilität:
+Erzeugte Kompatibilität:

- der bereitgestellte Workspace enthält weiterhin `QA_KICKOFF_TASK.md`
- der bereitgestellte Workspace enthält weiterhin `QA_SCENARIO_PLAN.md`
- der bereitgestellte Workspace enthält jetzt außerdem `QA_SCENARIOS.md`
+- der initialisierte Workspace enthält weiterhin `QA_KICKOFF_TASK.md`
+- der initialisierte Workspace enthält weiterhin `QA_SCENARIO_PLAN.md`
+- der initialisierte Workspace enthält jetzt zusätzlich `QA_SCENARIOS.md`

-## Refactor-Plan
+## Refaktorierungsplan

 ### Phase 1: Loader und Schema

 Erledigt.

- `qa/scenarios.md` hinzugefügt
+- `qa/scenarios/index.md` hinzugefügt
+- Szenarien in `qa/scenarios/*.md` aufgeteilt
 - Parser für benannten Markdown-YAML-Paketinhalt hinzugefügt
 - mit zod validiert
 - Consumer auf das geparste Paket umgestellt
- `qa/seed-scenarios.json` und `qa/QA_KICKOFF_TASK.md` auf Repo-Ebene entfernt
+- `qa/seed-scenarios.json` und `qa/QA_KICKOFF_TASK.md` auf Repository-Ebene entfernt

 ### Phase 2: generische Engine

 - `extensions/qa-lab/src/suite.ts` aufteilen in:
  - Loader
  - Engine
-  - Action-Registry
+  - Aktions-Registry
  - Assertion-Registry
  - benutzerdefinierte Handler
- bestehende Hilfsfunktionen als Engine-Operationen beibehalten
+- vorhandene Hilfsfunktionen als Engine-Operationen beibehalten

 Ergebnis:

 - Engine führt einfache deklarative Szenarien aus

-Mit Szenarien beginnen, die größtenteils aus Prompt + Warten + Assertion bestehen:
+Mit Szenarien beginnen, die größtenteils Prompt + Warten + Assertion sind:

- Threaded-Follow-up
+- Thread-Follow-up
 - Bildverständnis aus Anhang
 - Skill-Sichtbarkeit und -Aufruf
- Kanal-Baseline
+- Kanal-Basislinie

 Ergebnis:

- erste echte in Markdown definierte Szenarien, die über die generische Engine ausgeliefert werden
+- erste echte markdowndefinierte Szenarien, die über die generische Engine ausgeliefert werden

 ### Phase 4: mittlere Szenarien migrieren

 - Bildgenerierungs-Roundtrip
- Speicher-Tools im Kanalkontext
- Ranking von Sitzungsspeicher
- Unter-Agent-Übergabe
- Unter-Agent-Fanout-Synthese
+- Memory-Tools im Kanalkontext
+- Ranking von Sitzungs-Memory
+- Subagent-Übergabe
+- Subagent-Fanout-Synthese

 Ergebnis:

- Variablen, Artefakte, Tool-Assertions und Request-Log-Assertions praxiserprobt
+- Variablen, Artefakte, Tool-Assertions und Request-Log-Assertions praktisch belegt

 ### Phase 5: schwierige Szenarien auf benutzerdefinierten Handlern belassen

- Sweep für Memory Dreaming
- config apply bei Neustart-Aufwecken
- config restart bei Fähigkeitsumschaltung
- Laufzeit-Inventar-Drift
+- Memory-Dreaming-Durchlauf
+- Weckvorgang bei Neustart nach Config-Anwendung
+- Fähigkeitsumschaltung bei Config-Neustart
+- Laufzeit-Inventardrift

 Ergebnis:

- gleiches Authoring-Format, aber mit expliziten Custom-Step-Blöcken, wo nötig
+- gleiches Authoring-Format, aber bei Bedarf mit expliziten
+  benutzerdefinierten Step-Blöcken

-### Phase 6: hart codierte Szenario-Map löschen
+### Phase 6: hartcodierte Szenario-Map löschen

 Sobald die Paketabdeckung gut genug ist:

 - den Großteil des szenariospezifischen TypeScript-Branchings aus `extensions/qa-lab/src/suite.ts` entfernen

-## Fake Slack / Unterstützung für Rich Media
+## Fake-Slack- / Rich-Media-Unterstützung

-Der aktuelle QA-Bus ist textzentriert.
+Der aktuelle QA-Bus ist textorientiert.

 Relevante Dateien:

@ -449,7 +465,7 @@ Inline-Medienanhänge werden noch nicht modelliert.

 ### Benötigter Transportvertrag

-Ein generisches Modell für QA-Bus-Anhänge hinzufügen:
+Ein generisches QA-Bus-Anhangsmodell hinzufügen:

 ```ts
 type QaBusAttachment = {
@ -476,7 +492,7 @@ Dann `attachments?: QaBusAttachment[]` hinzufügen zu:

 ### Warum zuerst generisch

-Kein nur auf Slack zugeschnittenes Medienmodell bauen.
+Kein nur für Slack bestimmtes Medienmodell bauen.

 Stattdessen:

@ -484,24 +500,27 @@ Stattdessen:
 - mehrere Renderer darauf aufbauend
  - aktueller QA-Lab-Chat
  - zukünftiges Fake-Slack-Web
-  - beliebige andere Fake-Transport-Ansichten
+  - beliebige andere Fake-Transportansichten

-Das verhindert doppelte Logik und sorgt dafür, dass Medienszenarien transportagnostisch bleiben.
+Das verhindert doppelte Logik und sorgt dafür, dass Medienszenarien
+transportagnostisch bleiben.

 ### Erforderliche UI-Arbeit

-Die QA-UI aktualisieren, um Folgendes zu rendern:
+Die QA-UI so aktualisieren, dass sie Folgendes rendert:

 - Inline-Bildvorschau
 - Inline-Audioplayer
 - Inline-Videoplayer
- Chip für Dateianhänge
+- Dateianhang-Chip

-Die aktuelle UI kann bereits Threads und Reaktionen rendern, daher sollte das Rendern von Anhängen auf demselben Nachrichtenkartenmodell aufbauen können.
+Die aktuelle UI kann bereits Threads und Reaktionen rendern, daher sollte das
+Rendern von Anhängen auf dasselbe Nachrichtenkartenmodell aufsetzen.

-### Szenarioarbeit, die durch Medientransport ermöglicht wird
+### Durch Medientransport ermöglichte Szenarioarbeit

-Sobald Anhänge durch den QA-Bus fließen, können wir reichhaltigere Fake-Chat-Szenarien hinzufügen:
+Sobald Anhänge durch den QA-Bus fließen, können wir reichhaltigere
+Fake-Chat-Szenarien hinzufügen:

 - Inline-Bildantwort in Fake Slack
 - Verständnis von Audioanhängen
@ -514,21 +533,26 @@ Sobald Anhänge durch den QA-Bus fließen, können wir reichhaltigere Fake-Chat-
 Der nächste Implementierungsblock sollte sein:

 1. Markdown-Szenario-Loader + zod-Schema hinzufügen
-2. den aktuellen Katalog aus Markdown generieren
+2. den aktuellen Katalog aus Markdown erzeugen
 3. zuerst einige einfache Szenarien migrieren
-4. generische Unterstützung für QA-Bus-Anhänge hinzufügen
-5. Inline-Bilder in der QA-UI rendern
+4. generische QA-Bus-Anhangsunterstützung hinzufügen
+5. Inline-Bild in der QA-UI rendern
 6. dann auf Audio und Video erweitern

 Das ist der kleinste Weg, der beide Ziele belegt:

- generische in Markdown definierte QA
+- generische markdowndefinierte QA
 - reichhaltigere Fake-Messaging-Oberflächen

 ## Offene Fragen

- ob Szenariodateien eingebettete Markdown-Prompt-Templates mit Variableninterpolation erlauben sollten
- ob Setup/Cleanup benannte Abschnitte oder einfach geordnete Aktionslisten sein sollten
- ob Artefakt-Referenzen im Schema stark typisiert oder stringbasiert sein sollten
- ob benutzerdefinierte Handler in einer Registry oder in Registries pro Oberfläche leben sollten
- ob die generierte JSON-Kompatibilitätsdatei während der Migration eingecheckt bleiben sollte
+- ob Szenariodateien eingebettete Markdown-Prompt-Templates mit
+  Variableninterpolation erlauben sollten
+- ob Setup/Cleanup benannte Abschnitte oder einfach geordnete Aktionslisten
+  sein sollten
+- ob Artefakt-Referenzen im Schema stark typisiert oder zeichenfolgenbasiert
+  sein sollten
+- ob benutzerdefinierte Handler in einer Registry oder in Registries pro
+  Oberfläche liegen sollten
+- ob die generierte JSON-Kompatibilitätsdatei während der Migration weiterhin
+  eingecheckt bleiben sollte
--- a/docs/de/tools/slash-commands.md
+++ b/docs/de/tools/slash-commands.md
@ -1,14 +1,14 @@
 ---
 read_when:
-    - Chat-Befehle verwenden oder konfigurieren
-    - Routing oder Berechtigungen von Befehlen debuggen
+    - Verwenden oder Konfigurieren von Chat-Befehlen
+    - Debuggen von Befehlsrouting oder Berechtigungen
 summary: 'Slash-Befehle: Text vs. nativ, Konfiguration und unterstützte Befehle'
 title: Slash-Befehle
 x-i18n:
-    generated_at: "2026-04-06T03:13:51Z"
+    generated_at: "2026-04-08T06:02:27Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 417e35b9ddd87f25f6c019111b55b741046ea11039dde89210948185ced5696d
+    source_hash: 4a7ee7f1a8012058279b9e632889b291d4e659e4ec81209ca8978afbb9ad4b96
    source_path: tools/slash-commands.md
    workflow: 15
 ---
@ -16,20 +16,20 @@ x-i18n:
 # Slash-Befehle

 Befehle werden vom Gateway verarbeitet. Die meisten Befehle müssen als **eigenständige** Nachricht gesendet werden, die mit `/` beginnt.
-Der nur für den Host verfügbare Bash-Chat-Befehl verwendet `! <cmd>` (mit `/bash <cmd>` als Alias).
+Der nur auf dem Host verfügbare Bash-Chat-Befehl verwendet `! <cmd>` (mit `/bash <cmd>` als Alias).

 Es gibt zwei verwandte Systeme:

 - **Befehle**: eigenständige `/...`-Nachrichten.
 - **Direktiven**: `/think`, `/fast`, `/verbose`, `/reasoning`, `/elevated`, `/exec`, `/model`, `/queue`.
  - Direktiven werden aus der Nachricht entfernt, bevor das Modell sie sieht.
-  - In normalen Chat-Nachrichten (nicht nur aus Direktiven bestehend) werden sie als „Inline-Hinweise“ behandelt und speichern keine Sitzungseinstellungen dauerhaft.
-  - In Nachrichten, die nur aus Direktiven bestehen (die Nachricht enthält nur Direktiven), bleiben sie für die Sitzung erhalten und antworten mit einer Bestätigung.
-  - Direktiven werden nur für **autorisierte Sender** angewendet. Wenn `commands.allowFrom` gesetzt ist, ist dies die einzige
-    verwendete Allowlist; andernfalls kommt die Autorisierung aus Kanal-Allowlists/Kopplung sowie `commands.useAccessGroups`.
-    Nicht autorisierte Sender sehen Direktiven als normalen Text behandelt.
+  - In normalen Chat-Nachrichten (nicht nur Direktiven) werden sie als „Inline-Hinweise“ behandelt und speichern **keine** Sitzungseinstellungen dauerhaft.
+  - In Nachrichten, die nur aus Direktiven bestehen (die Nachricht enthält nur Direktiven), werden sie für die Sitzung gespeichert und mit einer Bestätigung beantwortet.
+  - Direktiven werden nur für **autorisierte Absender** angewendet. Wenn `commands.allowFrom` gesetzt ist, ist dies die einzige
+    verwendete Allowlist; andernfalls kommt die Autorisierung aus Channel-Allowlists/Pairing plus `commands.useAccessGroups`.
+    Nicht autorisierte Absender sehen Direktiven als normalen Text behandelt.

-Es gibt außerdem einige **Inline-Kurzbefehle** (nur für allowlistete/autorisierte Sender): `/help`, `/commands`, `/status`, `/whoami` (`/id`).
+Es gibt auch einige **Inline-Kurzbefehle** (nur für auf der Allowlist/autorisierte Absender): `/help`, `/commands`, `/status`, `/whoami` (`/id`).
 Sie werden sofort ausgeführt, entfernt, bevor das Modell die Nachricht sieht, und der verbleibende Text läuft im normalen Ablauf weiter.

 ## Konfiguration
@ -46,7 +46,10 @@ Sie werden sofort ausgeführt, entfernt, bevor das Modell die Nachricht sieht, u
    mcp: false,
    plugins: false,
    debug: false,
-    restart: false,
+    restart: true,
+    ownerAllowFrom: ["discord:123456789012345678"],
+    ownerDisplay: "raw",
+    ownerDisplaySecret: "${OWNER_ID_HASH_SECRET}",
    allowFrom: {
      "*": ["user1"],
      discord: ["user:123"],
@ -56,143 +59,178 @@ Sie werden sofort ausgeführt, entfernt, bevor das Modell die Nachricht sieht, u
 }
 ```

- `commands.text` (Standard `true`) aktiviert das Parsen von `/...` in Chat-Nachrichten.
+- `commands.text` (Standard: `true`) aktiviert das Parsen von `/...` in Chat-Nachrichten.
  - Auf Oberflächen ohne native Befehle (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) funktionieren Textbefehle weiterhin, selbst wenn Sie dies auf `false` setzen.
- `commands.native` (Standard `"auto"`) registriert native Befehle.
+- `commands.native` (Standard: `"auto"`) registriert native Befehle.
  - Auto: an für Discord/Telegram; aus für Slack (bis Sie Slash-Befehle hinzufügen); ignoriert für Provider ohne native Unterstützung.
-  - Setzen Sie `channels.discord.commands.native`, `channels.telegram.commands.native` oder `channels.slack.commands.native`, um pro Provider zu überschreiben (bool oder `"auto"`).
-  - `false` löscht beim Start zuvor registrierte Befehle auf Discord/Telegram. Slack-Befehle werden in der Slack-App verwaltet und nicht automatisch entfernt.
- `commands.nativeSkills` (Standard `"auto"`) registriert **Skills** nativ, wenn unterstützt.
-  - Auto: an für Discord/Telegram; aus für Slack (Slack erfordert einen Slash-Befehl pro Skill).
-  - Setzen Sie `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` oder `channels.slack.commands.nativeSkills`, um pro Provider zu überschreiben (bool oder `"auto"`).
- `commands.bash` (Standard `false`) aktiviert `! <cmd>`, um Shell-Befehle auf dem Host auszuführen (`/bash <cmd>` ist ein Alias; erfordert `tools.elevated`-Allowlists).
- `commands.bashForegroundMs` (Standard `2000`) steuert, wie lange Bash wartet, bevor in den Hintergrundmodus gewechselt wird (`0` schickt sofort in den Hintergrund).
- `commands.config` (Standard `false`) aktiviert `/config` (liest/schreibt `openclaw.json`).
- `commands.mcp` (Standard `false`) aktiviert `/mcp` (liest/schreibt von OpenClaw verwaltete MCP-Konfiguration unter `mcp.servers`).
- `commands.plugins` (Standard `false`) aktiviert `/plugins` (Plugin-Erkennung/-Status sowie Steuerelemente für Installation + Aktivierung/Deaktivierung).
- `commands.debug` (Standard `false`) aktiviert `/debug` (nur Runtime-Overrides).
- `commands.allowFrom` (optional) setzt eine providerbezogene Allowlist für die Autorisierung von Befehlen. Wenn konfiguriert, ist dies die
-  einzige Autorisierungsquelle für Befehle und Direktiven (Kanal-Allowlists/Kopplung und `commands.useAccessGroups`
+  - Setzen Sie `channels.discord.commands.native`, `channels.telegram.commands.native` oder `channels.slack.commands.native`, um pro Provider zu überschreiben (Bool oder `"auto"`).
+  - `false` entfernt beim Start zuvor registrierte Befehle auf Discord/Telegram. Slack-Befehle werden in der Slack-App verwaltet und nicht automatisch entfernt.
+- `commands.nativeSkills` (Standard: `"auto"`) registriert **Skills**-Befehle nativ, wenn dies unterstützt wird.
+  - Auto: an für Discord/Telegram; aus für Slack (Slack erfordert das Erstellen eines Slash-Befehls pro Skill).
+  - Setzen Sie `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` oder `channels.slack.commands.nativeSkills`, um pro Provider zu überschreiben (Bool oder `"auto"`).
+- `commands.bash` (Standard: `false`) aktiviert `! <cmd>` zum Ausführen von Host-Shell-Befehlen (`/bash <cmd>` ist ein Alias; erfordert `tools.elevated`-Allowlists).
+- `commands.bashForegroundMs` (Standard: `2000`) steuert, wie lange Bash wartet, bevor in den Hintergrundmodus gewechselt wird (`0` verschiebt sofort in den Hintergrund).
+- `commands.config` (Standard: `false`) aktiviert `/config` (liest/schreibt `openclaw.json`).
+- `commands.mcp` (Standard: `false`) aktiviert `/mcp` (liest/schreibt von OpenClaw verwaltete MCP-Konfiguration unter `mcp.servers`).
+- `commands.plugins` (Standard: `false`) aktiviert `/plugins` (Plugin-Erkennung/-Status plus Installations- und Aktivierungs-/Deaktivierungssteuerung).
+- `commands.debug` (Standard: `false`) aktiviert `/debug` (nur Laufzeit-Overrides).
+- `commands.restart` (Standard: `true`) aktiviert `/restart` plus Tool-Aktionen zum Neustart des Gateways.
+- `commands.ownerAllowFrom` (optional) setzt die explizite Owner-Allowlist für nur für Owner verfügbare Befehls-/Tool-Oberflächen. Dies ist getrennt von `commands.allowFrom`.
+- `commands.ownerDisplay` steuert, wie Owner-IDs im System Prompt angezeigt werden: `raw` oder `hash`.
+- `commands.ownerDisplaySecret` setzt optional das HMAC-Secret, das verwendet wird, wenn `commands.ownerDisplay="hash"` ist.
+- `commands.allowFrom` (optional) setzt eine providerbezogene Allowlist für die Befehlsautorisierung. Wenn konfiguriert, ist dies die
+  einzige Autorisierungsquelle für Befehle und Direktiven (Channel-Allowlists/Pairing und `commands.useAccessGroups`
  werden ignoriert). Verwenden Sie `"*"` als globalen Standard; providerspezifische Schlüssel überschreiben ihn.
- `commands.useAccessGroups` (Standard `true`) erzwingt Allowlists/Richtlinien für Befehle, wenn `commands.allowFrom` nicht gesetzt ist.
+- `commands.useAccessGroups` (Standard: `true`) erzwingt Allowlists/Richtlinien für Befehle, wenn `commands.allowFrom` nicht gesetzt ist.

 ## Befehlsliste

-Text + nativ (wenn aktiviert):
+Aktuelle Source of Truth:

- `/help`
- `/commands`
- `/tools [compact|verbose]` (anzeigen, was der aktuelle Agent genau jetzt verwenden kann; `verbose` fügt Beschreibungen hinzu)
- `/skill <name> [input]` (einen Skill nach Name ausführen)
- `/status` (aktuellen Status anzeigen; enthält Nutzungs-/Quota-Informationen des Providers für den aktuellen Modell-Provider, wenn verfügbar)
- `/tasks` (Hintergrundaufgaben für die aktuelle Sitzung auflisten; zeigt aktive und aktuelle Aufgabendetails mit agent-lokalen Fallback-Zählwerten)
- `/allowlist` (Allowlist-Einträge auflisten/hinzufügen/entfernen)
- `/approve <id> <decision>` (Exec-Genehmigungsaufforderungen auflösen; verwenden Sie die ausstehende Genehmigungsnachricht für die verfügbaren Entscheidungen)
- `/context [list|detail|json]` („Kontext“ erklären; `detail` zeigt pro Datei + pro Tool + pro Skill + Größe des System-Prompts)
- `/btw <question>` (eine ephemere Nebenfrage zur aktuellen Sitzung stellen, ohne den zukünftigen Sitzungskontext zu ändern; siehe [/tools/btw](/de/tools/btw))
- `/export-session [path]` (Alias: `/export`) (aktuelle Sitzung als HTML mit vollständigem System-Prompt exportieren)
- `/whoami` (Ihre Sender-ID anzeigen; Alias: `/id`)
- `/session idle <duration|off>` (automatisches Entfokussieren bei Inaktivität für fokussierte Thread-Bindings verwalten)
- `/session max-age <duration|off>` (hartes Maximalalter für automatisches Entfokussieren für fokussierte Thread-Bindings verwalten)
- `/subagents list|kill|log|info|send|steer|spawn` (Sub-Agent-Läufe für die aktuelle Sitzung prüfen, steuern oder starten)
- `/acp spawn|cancel|steer|close|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|sessions` (ACP-Runtime-Sitzungen prüfen und steuern)
- `/agents` (an Threads gebundene Agenten für diese Sitzung auflisten)
- `/focus <target>` (Discord: diesen Thread oder einen neuen Thread an ein Sitzungs-/Subagent-Ziel binden)
- `/unfocus` (Discord: aktuelles Thread-Binding entfernen)
- `/kill <id|#|all>` (einen oder alle laufenden Sub-Agents für diese Sitzung sofort abbrechen; keine Bestätigungsnachricht)
- `/steer <id|#> <message>` (einen laufenden Sub-Agent sofort steuern: wenn möglich während des Laufs, andernfalls aktuelle Arbeit abbrechen und mit der Steuerungsnachricht neu starten)
- `/tell <id|#> <message>` (Alias für `/steer`)
- `/config show|get|set|unset` (Konfiguration auf Datenträger persistieren, nur owner; erfordert `commands.config: true`)
- `/mcp show|get|set|unset` (OpenClaw-MCP-Serverkonfiguration verwalten, nur owner; erfordert `commands.mcp: true`)
- `/plugins list|show|get|install|enable|disable` (erkannte Plugins prüfen, neue Plugins installieren und Aktivierung umschalten; Schreibvorgänge nur owner; erfordert `commands.plugins: true`)
-  - `/plugin` ist ein Alias für `/plugins`.
-  - `/plugin install <spec>` akzeptiert dieselben Plugin-Spezifikationen wie `openclaw plugins install`: lokaler Pfad/Archiv, npm-Paket oder `clawhub:<pkg>`.
-  - Schreibvorgänge für Aktivieren/Deaktivieren antworten weiterhin mit einem Neustart-Hinweis. Bei einem überwachten Gateway im Vordergrund kann OpenClaw diesen Neustart direkt nach dem Schreibvorgang automatisch ausführen.
- `/debug show|set|unset|reset` (Runtime-Overrides, nur owner; erfordert `commands.debug: true`)
- `/usage off|tokens|full|cost` (Nutzungs-Footer pro Antwort oder lokale Kostenzusammenfassung)
- `/tts off|always|inbound|tagged|status|provider|limit|summary|audio` (TTS steuern; siehe [/tts](/de/tools/tts))
-  - Discord: nativer Befehl ist `/voice` (Discord reserviert `/tts`); Text-`/tts` funktioniert weiterhin.
- `/stop`
- `/restart`
- `/dock-telegram` (Alias: `/dock_telegram`) (Antworten auf Telegram umschalten)
- `/dock-discord` (Alias: `/dock_discord`) (Antworten auf Discord umschalten)
- `/dock-slack` (Alias: `/dock_slack`) (Antworten auf Slack umschalten)
- `/activation mention|always` (nur Gruppen)
- `/send on|off|inherit` (nur owner)
- `/reset` oder `/new [model]` (optionaler Modellhinweis; Rest wird durchgereicht)
- `/think <off|minimal|low|medium|high|xhigh>` (dynamische Auswahl je nach Modell/Provider; Aliasse: `/thinking`, `/t`)
- `/fast status|on|off` (wenn das Argument weggelassen wird, wird der aktuell wirksame Fast-Mode-Status angezeigt)
- `/verbose on|full|off` (Alias: `/v`)
- `/reasoning on|off|stream` (Alias: `/reason`; wenn an, wird eine separate Nachricht mit Präfix `Reasoning:` gesendet; `stream` = nur Telegram-Entwurf)
- `/elevated on|off|ask|full` (Alias: `/elev`; `full` überspringt Exec-Genehmigungen)
- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` (senden Sie `/exec`, um den aktuellen Wert anzuzeigen)
- `/model <name>` (Alias: `/models`; oder `/<alias>` aus `agents.defaults.models.*.alias`)
- `/queue <mode>` (plus Optionen wie `debounce:2s cap:25 drop:summarize`; senden Sie `/queue`, um die aktuellen Einstellungen zu sehen)
- `/bash <command>` (nur Host; Alias für `! <command>`; erfordert `commands.bash: true` + `tools.elevated`-Allowlists)
- `/dreaming [on|off|status|help]` (globales Dreaming umschalten oder Status anzeigen; siehe [Dreaming](/concepts/dreaming))
+- Core-Built-ins kommen aus `src/auto-reply/commands-registry.shared.ts`
+- generierte Dock-Befehle kommen aus `src/auto-reply/commands-registry.data.ts`
+- Plugin-Befehle kommen aus Plugin-`registerCommand()`-Aufrufen
+- die tatsächliche Verfügbarkeit auf Ihrem Gateway hängt weiterhin von Konfigurations-Flags, der Channel-Oberfläche und installierten/aktivierten Plugins ab

-Nur Text:
+### Core-Built-in-Befehle

- `/compact [instructions]` (siehe [/concepts/compaction](/de/concepts/compaction))
- `! <command>` (nur Host; jeweils nur eins; verwenden Sie `!poll` + `!stop` für lang laufende Jobs)
- `!poll` (Ausgabe / Status prüfen; akzeptiert optional `sessionId`; `/bash poll` funktioniert ebenfalls)
- `!stop` (den laufenden Bash-Job stoppen; akzeptiert optional `sessionId`; `/bash stop` funktioniert ebenfalls)
+Heute verfügbare integrierte Befehle:
+
+- `/new [model]` startet eine neue Sitzung; `/reset` ist der Alias zum Zurücksetzen.
+- `/compact [instructions]` verdichtet den Sitzungskontext. Siehe [/concepts/compaction](/de/concepts/compaction).
+- `/stop` bricht den aktuellen Lauf ab.
+- `/session idle <duration|off>` und `/session max-age <duration|off>` verwalten den Ablauf der Thread-Bindung.
+- `/think <off|minimal|low|medium|high|xhigh>` setzt die Denkstufe. Aliasse: `/thinking`, `/t`.
+- `/verbose on|off|full` schaltet ausführliche Ausgabe um. Alias: `/v`.
+- `/fast [status|on|off]` zeigt den Fast-Modus an oder setzt ihn.
+- `/reasoning [on|off|stream]` schaltet die Sichtbarkeit von Reasoning um. Alias: `/reason`.
+- `/elevated [on|off|ask|full]` schaltet den Elevated-Modus um. Alias: `/elev`.
+- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` zeigt Standardwerte für exec an oder setzt sie.
+- `/model [name|#|status]` zeigt das Modell an oder setzt es.
+- `/models [provider] [page] [limit=<n>|size=<n>|all]` listet Provider oder Modelle für einen Provider auf.
+- `/queue <mode>` verwaltet das Queue-Verhalten (`steer`, `interrupt`, `followup`, `collect`, `steer-backlog`) plus Optionen wie `debounce:2s cap:25 drop:summarize`.
+- `/help` zeigt die kurze Hilfsübersicht.
+- `/commands` zeigt den generierten Befehlskatalog.
+- `/tools [compact|verbose]` zeigt, was der aktuelle Agent genau jetzt verwenden kann.
+- `/status` zeigt den Laufzeitstatus an, einschließlich Provider-Nutzung/Kontingent, wenn verfügbar.
+- `/tasks` listet aktive/aktuelle Hintergrundaufgaben für die aktuelle Sitzung auf.
+- `/context [list|detail|json]` erklärt, wie der Kontext zusammengesetzt wird.
+- `/export-session [path]` exportiert die aktuelle Sitzung als HTML. Alias: `/export`.
+- `/whoami` zeigt Ihre Absender-ID. Alias: `/id`.
+- `/skill <name> [input]` führt einen Skill nach Namen aus.
+- `/allowlist [list|add|remove] ...` verwaltet Allowlist-Einträge. Nur Text.
+- `/approve <id> <decision>` löst exec-Genehmigungsabfragen auf.
+- `/btw <question>` stellt eine Nebenfrage, ohne den zukünftigen Sitzungskontext zu ändern. Siehe [/tools/btw](/de/tools/btw).
+- `/subagents list|kill|log|info|send|steer|spawn` verwaltet Subagent-Läufe für die aktuelle Sitzung.
+- `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` verwaltet ACP-Sitzungen und Laufzeitoptionen.
+- `/focus <target>` bindet den aktuellen Discord-Thread oder das aktuelle Telegram-Thema/Gespräch an ein Sitzungsziel.
+- `/unfocus` entfernt die aktuelle Bindung.
+- `/agents` listet threadgebundene Agenten für die aktuelle Sitzung auf.
+- `/kill <id|#|all>` bricht einen oder alle laufenden Subagenten ab.
+- `/steer <id|#> <message>` sendet Steuerung an einen laufenden Subagenten. Alias: `/tell`.
+- `/config show|get|set|unset` liest oder schreibt `openclaw.json`. Nur für Owner. Erfordert `commands.config: true`.
+- `/mcp show|get|set|unset` liest oder schreibt von OpenClaw verwaltete MCP-Server-Konfiguration unter `mcp.servers`. Nur für Owner. Erfordert `commands.mcp: true`.
+- `/plugins list|inspect|show|get|install|enable|disable` prüft oder verändert den Plugin-Status. `/plugin` ist ein Alias. Schreibzugriffe nur für Owner. Erfordert `commands.plugins: true`.
+- `/debug show|set|unset|reset` verwaltet nur zur Laufzeit gültige Konfigurations-Overrides. Nur für Owner. Erfordert `commands.debug: true`.
+- `/usage off|tokens|full|cost` steuert die Nutzungsfußzeile pro Antwort oder gibt eine lokale Kostenzusammenfassung aus.
+- `/tts on|off|status|provider|limit|summary|audio|help` steuert TTS. Siehe [/tools/tts](/de/tools/tts).
+- `/restart` startet OpenClaw neu, wenn aktiviert. Standard: aktiviert; setzen Sie `commands.restart: false`, um es zu deaktivieren.
+- `/activation mention|always` setzt den Gruppenaktivierungsmodus.
+- `/send on|off|inherit` setzt die Send Policy. Nur für Owner.
+- `/bash <command>` führt einen Host-Shell-Befehl aus. Nur Text. Alias: `! <command>`. Erfordert `commands.bash: true` plus `tools.elevated`-Allowlists.
+- `!poll [sessionId]` prüft einen Bash-Hintergrundjob.
+- `!stop [sessionId]` stoppt einen Bash-Hintergrundjob.
+
+### Generierte Dock-Befehle
+
+Dock-Befehle werden aus Channel-Plugins mit Unterstützung für native Befehle generiert. Aktueller gebündelter Satz:
+
+- `/dock-discord` (Alias: `/dock_discord`)
+- `/dock-mattermost` (Alias: `/dock_mattermost`)
+- `/dock-slack` (Alias: `/dock_slack`)
+- `/dock-telegram` (Alias: `/dock_telegram`)
+
+### Befehle gebündelter Plugins
+
+Gebündelte Plugins können weitere Slash-Befehle hinzufügen. Aktuelle gebündelte Befehle in diesem Repo:
+
+- `/dreaming [on|off|status|help]` schaltet Memory Dreaming um. Siehe [Dreaming](/de/concepts/dreaming).
+- `/pair [qr|status|pending|approve|cleanup|notify]` verwaltet den Pairing-/Setup-Ablauf für Geräte. Siehe [Pairing](/de/channels/pairing).
+- `/phone status|arm <camera|screen|writes|all> [duration]|disarm` schaltet vorübergehend risikoreiche Befehle für Phone-Nodes scharf.
+- `/voice status|list [limit]|set <voiceId|name>` verwaltet die Talk-Sprachkonfiguration. Auf Discord lautet der native Befehlsname `/talkvoice`.
+- `/card ...` sendet LINE-Rich-Card-Voreinstellungen. Siehe [LINE](/de/channels/line).
+- Nur für QQBot verfügbare Befehle:
+  - `/bot-ping`
+  - `/bot-version`
+  - `/bot-help`
+  - `/bot-upgrade`
+  - `/bot-logs`
+
+### Dynamische Skill-Befehle
+
+Vom Benutzer aufrufbare Skills werden ebenfalls als Slash-Befehle bereitgestellt:
+
+- `/skill <name> [input]` funktioniert immer als generischer Einstiegspunkt.
+- Skills können auch als direkte Befehle wie `/prose` erscheinen, wenn der Skill/das Plugin sie registriert.
+- Die native Registrierung von Skill-Befehlen wird durch `commands.nativeSkills` und `channels.<provider>.commands.nativeSkills` gesteuert.

 Hinweise:

- Befehle akzeptieren optional ein `:` zwischen Befehl und Argumenten (z. B. `/think: high`, `/send: on`, `/help:`).
- `/new <model>` akzeptiert einen Modell-Alias, `provider/model` oder einen Providernamen (unscharfer Abgleich); wenn es keine Übereinstimmung gibt, wird der Text als Nachrichtentext behandelt.
- Für eine vollständige Aufschlüsselung der Provider-Nutzung verwenden Sie `openclaw status --usage`.
- `/allowlist add|remove` erfordert `commands.config=true` und beachtet kanalbezogene `configWrites`.
- In Kanälen mit mehreren Konten beachten auf Konfiguration zielende `/allowlist --account <id>` und `/config set channels.<provider>.accounts.<id>...` ebenfalls `configWrites` des Zielkontos.
- `/usage` steuert den Nutzungs-Footer pro Antwort; `/usage cost` gibt eine lokale Kostenzusammenfassung aus OpenClaw-Sitzungslogs aus.
+- Befehle akzeptieren optional ein `:` zwischen dem Befehl und den Argumenten (z. B. `/think: high`, `/send: on`, `/help:`).
+- `/new <model>` akzeptiert einen Modellalias, `provider/model` oder einen Providernamen (unscharfer Abgleich); wenn es keine Übereinstimmung gibt, wird der Text als Nachrichtentext behandelt.
+- Für die vollständige Aufschlüsselung der Provider-Nutzung verwenden Sie `openclaw status --usage`.
+- `/allowlist add|remove` erfordert `commands.config=true` und berücksichtigt Channel-`configWrites`.
+- In Channels mit mehreren Accounts berücksichtigen zielkontobezogene `/allowlist --account <id>` und `/config set channels.<provider>.accounts.<id>...` ebenfalls `configWrites` des Zielkontos.
+- `/usage` steuert die Nutzungsfußzeile pro Antwort; `/usage cost` gibt eine lokale Kostenzusammenfassung aus OpenClaw-Sitzungsprotokollen aus.
 - `/restart` ist standardmäßig aktiviert; setzen Sie `commands.restart: false`, um es zu deaktivieren.
- Nur Discord nativer Befehl: `/vc join|leave|status` steuert Sprachkanäle (erfordert `channels.discord.voice` und native Befehle; nicht als Text verfügbar).
- Discord-Befehle für Thread-Binding (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) erfordern, dass effektive Thread-Bindings aktiviert sind (`session.threadBindings.enabled` und/oder `channels.discord.threadBindings.enabled`).
- ACP-Befehlsreferenz und Runtime-Verhalten: [ACP Agents](/de/tools/acp-agents).
+- `/plugins install <spec>` akzeptiert dieselben Plugin-Spezifikationen wie `openclaw plugins install`: lokaler Pfad/Archiv, npm-Paket oder `clawhub:<pkg>`.
+- `/plugins enable|disable` aktualisiert die Plugin-Konfiguration und fordert möglicherweise zu einem Neustart auf.
+- Nur nativer Discord-Befehl: `/vc join|leave|status` steuert Sprachkanäle (erfordert `channels.discord.voice` und native Befehle; nicht als Text verfügbar).
+- Discord-Befehle für Thread-Bindung (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) erfordern, dass effektive Thread-Bindungen aktiviert sind (`session.threadBindings.enabled` und/oder `channels.discord.threadBindings.enabled`).
+- ACP-Befehlsreferenz und Laufzeitverhalten: [ACP Agents](/de/tools/acp-agents).
 - `/verbose` ist für Debugging und zusätzliche Sichtbarkeit gedacht; lassen Sie es im normalen Gebrauch **aus**.
- `/fast on|off` speichert ein Sitzungs-Override. Verwenden Sie die Option `inherit` in der Sessions-UI, um es zu löschen und auf die Standardwerte der Konfiguration zurückzufallen.
- `/fast` ist providerspezifisch: OpenAI/OpenAI Codex ordnen es auf nativen Responses-Endpunkten `service_tier=priority` zu, während direkte öffentliche Anthropic-Anfragen, einschließlich OAuth-authentifiziertem Traffic an `api.anthropic.com`, auf `service_tier=auto` oder `standard_only` abgebildet werden. Siehe [OpenAI](/de/providers/openai) und [Anthropic](/de/providers/anthropic).
+- `/fast on|off` speichert ein Sitzungs-Override. Verwenden Sie in der Sessions-UI die Option `inherit`, um es zu löschen und auf die Standardwerte aus der Konfiguration zurückzufallen.
+- `/fast` ist providerspezifisch: OpenAI/OpenAI Codex ordnen es auf nativen Responses-Endpunkten `service_tier=priority` zu, während direkte öffentliche Anthropic-Anfragen, einschließlich OAuth-authentifiziertem Traffic an `api.anthropic.com`, es `service_tier=auto` oder `standard_only` zuordnen. Siehe [OpenAI](/de/providers/openai) und [Anthropic](/de/providers/anthropic).
 - Zusammenfassungen von Tool-Fehlern werden weiterhin angezeigt, wenn relevant, aber detaillierter Fehlertext wird nur aufgenommen, wenn `/verbose` auf `on` oder `full` steht.
- `/reasoning` (und `/verbose`) sind in Gruppeneinstellungen riskant: Sie können internes Reasoning oder Tool-Ausgabe offenlegen, die Sie nicht beabsichtigt hatten preiszugeben. Lassen Sie sie vorzugsweise ausgeschaltet, besonders in Gruppenchats.
+- `/reasoning` (und `/verbose`) sind in Gruppenumgebungen riskant: Sie können internes Reasoning oder Tool-Ausgaben offenlegen, die Sie nicht beabsichtigt hatten preiszugeben. Lassen Sie sie vorzugsweise deaktiviert, insbesondere in Gruppenchats.
 - `/model` speichert das neue Sitzungsmodell sofort.
 - Wenn der Agent untätig ist, verwendet der nächste Lauf es sofort.
- Wenn bereits ein Lauf aktiv ist, markiert OpenClaw einen Live-Wechsel als ausstehend und startet erst an einem sauberen Retry-Punkt in das neue Modell neu.
- Wenn Tool-Aktivität oder Antwortausgabe bereits begonnen hat, kann der ausstehende Wechsel bis zu einer späteren Retry-Gelegenheit oder bis zum nächsten Benutzer-Turn in der Warteschlange bleiben.
- **Fast path:** Nur-Befehl-Nachrichten von allowlisteten Sendern werden sofort verarbeitet (Warteschlange + Modell werden umgangen).
- **Group mention gating:** Nur-Befehl-Nachrichten von allowlisteten Sendern umgehen Erwähnungsanforderungen.
- **Inline-Kurzbefehle (nur allowlistete Sender):** Bestimmte Befehle funktionieren auch, wenn sie in eine normale Nachricht eingebettet sind, und werden entfernt, bevor das Modell den verbleibenden Text sieht.
+- Wenn bereits ein Lauf aktiv ist, markiert OpenClaw einen Live-Wechsel als ausstehend und startet nur an einem sauberen Wiederholungspunkt in das neue Modell neu.
+- Wenn Tool-Aktivität oder Antwortausgabe bereits begonnen hat, kann der ausstehende Wechsel bis zu einer späteren Wiederholungsmöglichkeit oder bis zum nächsten Benutzerzug in der Warteschlange bleiben.
+- **Fast Path:** Nachrichten nur mit Befehlen von Absendern auf der Allowlist werden sofort verarbeitet (umgehen Queue + Modell).
+- **Gruppen-Erwähnungs-Gating:** Nachrichten nur mit Befehlen von Absendern auf der Allowlist umgehen Erwähnungsanforderungen.
+- **Inline-Kurzbefehle (nur für Absender auf der Allowlist):** bestimmte Befehle funktionieren auch, wenn sie in eine normale Nachricht eingebettet sind, und werden entfernt, bevor das Modell den verbleibenden Text sieht.
  - Beispiel: `hey /status` löst eine Statusantwort aus, und der verbleibende Text läuft im normalen Ablauf weiter.
- Derzeit: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
- Nicht autorisierte Nur-Befehl-Nachrichten werden stillschweigend ignoriert, und Inline-`/...`-Tokens werden als normaler Text behandelt.
- **Skill-Befehle:** `user-invocable` Skills werden als Slash-Befehle verfügbar gemacht. Namen werden auf `a-z0-9_` bereinigt (max. 32 Zeichen); Kollisionen erhalten numerische Suffixe (z. B. `_2`).
-  - `/skill <name> [input]` führt einen Skill nach Name aus (nützlich, wenn native Befehlslimits Befehle pro Skill verhindern).
+- Aktuell: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
+- Nicht autorisierte Nachrichten nur mit Befehlen werden stillschweigend ignoriert, und Inline-`/...`-Tokens werden als normaler Text behandelt.
+- **Skill-Befehle:** `user-invocable` Skills werden als Slash-Befehle bereitgestellt. Namen werden auf `a-z0-9_` bereinigt (max. 32 Zeichen); bei Kollisionen werden numerische Suffixe angehängt (z. B. `_2`).
+  - `/skill <name> [input]` führt einen Skill nach Namen aus (nützlich, wenn Grenzen nativer Befehle Befehle pro Skill verhindern).
  - Standardmäßig werden Skill-Befehle als normale Anfrage an das Modell weitergeleitet.
-  - Skills können optional `command-dispatch: tool` deklarieren, um den Befehl direkt an ein Tool zu routen (deterministisch, ohne Modell).
+  - Skills können optional `command-dispatch: tool` deklarieren, um den Befehl direkt an ein Tool zu leiten (deterministisch, kein Modell).
  - Beispiel: `/prose` (OpenProse-Plugin) — siehe [OpenProse](/de/prose).
- **Argumente nativer Befehle:** Discord verwendet Autocomplete für dynamische Optionen (und Button-Menüs, wenn Sie erforderliche Argumente weglassen). Telegram und Slack zeigen ein Button-Menü, wenn ein Befehl Auswahlmöglichkeiten unterstützt und Sie das Argument weglassen.
+- **Native Befehlsargumente:** Discord verwendet Autovervollständigung für dynamische Optionen (und Button-Menüs, wenn Sie erforderliche Argumente weglassen). Telegram und Slack zeigen ein Button-Menü an, wenn ein Befehl Auswahlmöglichkeiten unterstützt und Sie das Argument weglassen.

 ## `/tools`

-`/tools` beantwortet eine Runtime-Frage, keine Konfigurationsfrage: **was dieser Agent genau jetzt in
-dieser Konversation verwenden kann**.
+`/tools` beantwortet eine Laufzeitfrage, keine Konfigurationsfrage: **was dieser Agent genau jetzt in
+diesem Gespräch verwenden kann**.

- Standard-`/tools` ist kompakt und für schnelles Scannen optimiert.
+- Standardmäßig ist `/tools` kompakt und für schnelles Scannen optimiert.
 - `/tools verbose` fügt kurze Beschreibungen hinzu.
 - Oberflächen mit nativen Befehlen, die Argumente unterstützen, bieten denselben Moduswechsel als `compact|verbose`.
- Ergebnisse sind sitzungsbezogen, daher können Änderungen von Agent, Kanal, Thread, Senderautorisierung oder Modell
+- Ergebnisse sind sitzungsbezogen; ein Wechsel von Agent, Channel, Thread, Absenderautorisierung oder Modell kann
  die Ausgabe ändern.
- `/tools` enthält Tools, die zur Runtime tatsächlich erreichbar sind, einschließlich Core-Tools, verbundener
-  Plugin-Tools und kanaleigener Tools.
+- `/tools` enthält Tools, die zur Laufzeit tatsächlich erreichbar sind, einschließlich Core-Tools, verbundener
+  Plugin-Tools und channel-eigener Tools.

-Für das Bearbeiten von Profilen und Overrides verwenden Sie das Tools-Panel der Control UI oder Konfigurations-/Katalogoberflächen,
-anstatt `/tools` als statischen Katalog zu behandeln.
+Für die Bearbeitung von Profilen und Overrides verwenden Sie das Tools-Panel der Control UI oder Konfigurations-/Katalogoberflächen, anstatt
+`/tools` als statischen Katalog zu behandeln.

 ## Nutzungsoberflächen (was wo angezeigt wird)

- **Provider usage/quota** (Beispiel: „Claude 80% left“) wird in `/status` für den aktuellen Modell-Provider angezeigt, wenn Nutzungsverfolgung aktiviert ist. OpenClaw normalisiert Provider-Fenster auf `% left`; bei MiniMax werden Prozentfelder mit nur Restwert vor der Anzeige invertiert, und `model_remains`-Antworten bevorzugen den Chat-Modell-Eintrag plus ein modellmarkiertes Plan-Label.
- **Token-/Cache-Zeilen** in `/status` können auf den neuesten Usage-Eintrag des Transkripts zurückgreifen, wenn der Live-Sitzungs-Snapshot spärlich ist. Vorhandene Live-Werte ungleich null haben weiterhin Vorrang, und der Transcript-Fallback kann auch das aktive Runtime-Modell-Label plus einen größeren promptorientierten Gesamtwert wiederherstellen, wenn gespeicherte Gesamtwerte fehlen oder kleiner sind.
- **Tokens/Kosten pro Antwort** werden mit `/usage off|tokens|full` gesteuert (an normale Antworten angehängt).
+- **Provider-Nutzung/Kontingent** (Beispiel: „Claude 80 % übrig“) erscheint in `/status` für den aktuellen Modellprovider, wenn Nutzungsverfolgung aktiviert ist. OpenClaw normalisiert Provider-Fenster zu „% übrig“; bei MiniMax werden Prozentfelder, die nur den verbleibenden Anteil angeben, vor der Anzeige invertiert, und Antworten mit `model_remains` bevorzugen den Chat-Modell-Eintrag plus ein planbeschriftetes Modell-Label.
+- **Token-/Cache-Zeilen** in `/status` können auf den neuesten Nutzungseintrag im Transkript zurückfallen, wenn der Live-Sitzungs-Snapshot spärlich ist. Vorhandene von null verschiedene Live-Werte haben weiterhin Vorrang, und der Transkript-Fallback kann auch das aktive Laufzeitmodell-Label sowie eine größere promptorientierte Gesamtsumme wiederherstellen, wenn gespeicherte Summen fehlen oder kleiner sind.
+- **Tokens/Kosten pro Antwort** werden durch `/usage off|tokens|full` gesteuert (an normale Antworten angehängt).
 - `/model status` betrifft **Modelle/Auth/Endpunkte**, nicht die Nutzung.

 ## Modellauswahl (`/model`)
@ -212,14 +250,14 @@ Beispiele:

 Hinweise:

- `/model` und `/model list` zeigen einen kompakten, nummerierten Auswahlbereich (Modellfamilie + verfügbare Provider).
- Auf Discord öffnen `/model` und `/models` einen interaktiven Auswahlbereich mit Dropdowns für Provider und Modell plus einem Submit-Schritt.
- `/model <#>` wählt aus diesem Auswahlbereich aus (und bevorzugt nach Möglichkeit den aktuellen Provider).
- `/model status` zeigt die Detailansicht, einschließlich des konfigurierten Provider-Endpunkts (`baseUrl`) und des API-Modus (`api`), wenn verfügbar.
+- `/model` und `/model list` zeigen einen kompakten, nummerierten Picker an (Modellfamilie + verfügbare Provider).
+- Auf Discord öffnen `/model` und `/models` einen interaktiven Picker mit Dropdowns für Provider und Modell plus einem Submit-Schritt.
+- `/model <#>` wählt aus diesem Picker aus (und bevorzugt nach Möglichkeit den aktuellen Provider).
+- `/model status` zeigt die detaillierte Ansicht, einschließlich des konfigurierten Provider-Endpunkts (`baseUrl`) und des API-Modus (`api`), wenn verfügbar.

 ## Debug-Overrides

-`/debug` ermöglicht das Setzen von **nur zur Runtime gültigen** Konfigurations-Overrides (im Speicher, nicht auf Datenträger). Nur owner. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.debug: true`.
+`/debug` ermöglicht das Setzen von **nur zur Laufzeit gültigen** Konfigurations-Overrides (im Speicher, nicht auf Datenträger). Nur für Owner. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.debug: true`.

 Beispiele:

@ -233,12 +271,12 @@ Beispiele:

 Hinweise:

- Overrides gelten sofort für neue Konfigurationslesevorgänge, schreiben aber **nicht** in `openclaw.json`.
- Verwenden Sie `/debug reset`, um alle Overrides zu löschen und zur Konfiguration auf dem Datenträger zurückzukehren.
+- Overrides gelten sofort für neue Konfigurationslesevorgänge, schreiben jedoch **nicht** in `openclaw.json`.
+- Verwenden Sie `/debug reset`, um alle Overrides zu löschen und zur auf dem Datenträger gespeicherten Konfiguration zurückzukehren.

 ## Konfigurationsaktualisierungen

-`/config` schreibt in Ihre Konfiguration auf dem Datenträger (`openclaw.json`). Nur owner. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.config: true`.
+`/config` schreibt in Ihre auf dem Datenträger gespeicherte Konfiguration (`openclaw.json`). Nur für Owner. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.config: true`.

 Beispiele:

@ -257,7 +295,7 @@ Hinweise:

 ## MCP-Aktualisierungen

-`/mcp` schreibt von OpenClaw verwaltete MCP-Serverdefinitionen unter `mcp.servers`. Nur owner. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.mcp: true`.
+`/mcp` schreibt von OpenClaw verwaltete MCP-Serverdefinitionen unter `mcp.servers`. Nur für Owner. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.mcp: true`.

 Beispiele:

@ -270,12 +308,12 @@ Beispiele:

 Hinweise:

- `/mcp` speichert Konfiguration in der OpenClaw-Konfiguration, nicht in Pi-eigenen Projekteinstellungen.
- Runtime-Adapter entscheiden, welche Transports tatsächlich ausführbar sind.
+- `/mcp` speichert die Konfiguration in der OpenClaw-Konfiguration, nicht in Pi-eigenen Projekteinstellungen.
+- Laufzeitadapter entscheiden, welche Transporte tatsächlich ausführbar sind.

 ## Plugin-Aktualisierungen

-`/plugins` ermöglicht es Operatoren, erkannte Plugins zu prüfen und die Aktivierung in der Konfiguration umzuschalten. Read-only-Abläufe können `/plugin` als Alias verwenden. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.plugins: true`.
+`/plugins` ermöglicht es Operatoren, erkannte Plugins zu prüfen und die Aktivierung in der Konfiguration umzuschalten. Schreibgeschützte Abläufe können `/plugin` als Alias verwenden. Standardmäßig deaktiviert; aktivieren Sie es mit `commands.plugins: true`.

 Beispiele:

@ -289,20 +327,20 @@ Beispiele:

 Hinweise:

- `/plugins list` und `/plugins show` verwenden echte Plugin-Erkennung gegen den aktuellen Workspace plus die Konfiguration auf dem Datenträger.
- `/plugins enable|disable` aktualisiert nur die Plugin-Konfiguration; Plugins werden dadurch nicht installiert oder deinstalliert.
- Starten Sie das Gateway nach Änderungen an Aktivierung/Deaktivierung neu, um sie anzuwenden.
+- `/plugins list` und `/plugins show` verwenden echte Plugin-Erkennung gegen den aktuellen Workspace plus die auf dem Datenträger gespeicherte Konfiguration.
+- `/plugins enable|disable` aktualisiert nur die Plugin-Konfiguration; Plugins werden nicht installiert oder deinstalliert.
+- Starten Sie nach Änderungen an Aktivierung/Deaktivierung das Gateway neu, um sie anzuwenden.

 ## Hinweise zu Oberflächen

- **Textbefehle** laufen in der normalen Chatsitzung (DMs teilen sich `main`, Gruppen haben ihre eigene Sitzung).
+- **Textbefehle** laufen in der normalen Chat-Sitzung (DMs teilen sich `main`, Gruppen haben ihre eigene Sitzung).
 - **Native Befehle** verwenden isolierte Sitzungen:
  - Discord: `agent:<agentId>:discord:slash:<userId>`
  - Slack: `agent:<agentId>:slack:slash:<userId>` (Präfix konfigurierbar über `channels.slack.slashCommand.sessionPrefix`)
-  - Telegram: `telegram:slash:<userId>` (zielt über `CommandTargetSessionKey` auf die Chatsitzung)
- **`/stop`** zielt auf die aktive Chatsitzung, damit der aktuelle Lauf abgebrochen werden kann.
- **Slack:** `channels.slack.slashCommand` wird weiterhin für einen einzelnen Befehl im Stil `/openclaw` unterstützt. Wenn Sie `commands.native` aktivieren, müssen Sie einen Slack-Slash-Befehl pro integriertem Befehl erstellen (dieselben Namen wie `/help`). Menüs für Befehlsargumente in Slack werden als ephemere Block-Kit-Buttons ausgeliefert.
-  - Native Ausnahme in Slack: Registrieren Sie `/agentstatus` (nicht `/status`), weil Slack `/status` reserviert. Text-`/status` funktioniert in Slack-Nachrichten weiterhin.
+  - Telegram: `telegram:slash:<userId>` (zielt über `CommandTargetSessionKey` auf die Chat-Sitzung)
+- **`/stop`** zielt auf die aktive Chat-Sitzung, damit der aktuelle Lauf abgebrochen werden kann.
+- **Slack:** `channels.slack.slashCommand` wird weiterhin für einen einzelnen Befehl im Stil von `/openclaw` unterstützt. Wenn Sie `commands.native` aktivieren, müssen Sie einen Slack-Slash-Befehl pro integriertem Befehl erstellen (mit denselben Namen wie `/help`). Menüs für Befehlsargumente in Slack werden als ephemere Block-Kit-Buttons ausgeliefert.
+  - Native Slack-Ausnahme: Registrieren Sie `/agentstatus` (nicht `/status`), da Slack `/status` reserviert. Text-`/status` funktioniert in Slack-Nachrichten weiterhin.

 ## BTW-Nebenfragen

@ -310,19 +348,20 @@ Hinweise:

 Im Gegensatz zu normalem Chat:

- verwendet sie die aktuelle Sitzung als Hintergrundkontext,
- läuft sie als separater **tool-loser** One-shot-Aufruf,
- ändert sie den zukünftigen Sitzungskontext nicht,
- wird sie nicht in den Transkriptverlauf geschrieben,
- wird sie als Live-Nebenergebnis statt als normale Assistant-Nachricht ausgeliefert.
+- verwendet es die aktuelle Sitzung als Hintergrundkontext,
+- läuft es als separater **tool-loser** One-Shot-Aufruf,
+- ändert es den zukünftigen Sitzungskontext nicht,
+- wird es nicht in den Transkriptverlauf geschrieben,
+- wird es als Live-Nebenergebnis statt als normale Assistentennachricht ausgeliefert.

-Das macht `/btw` nützlich, wenn Sie eine vorübergehende Klärung möchten, während die Hauptaufgabe weiterläuft.
+Das macht `/btw` nützlich, wenn Sie eine vorübergehende Klarstellung möchten, während die Haupt-
+aufgabe weiterläuft.

 Beispiel:

 ```text
-/btw was machen wir gerade?
+/btw what are we doing right now?
 ```

-Siehe [BTW Side Questions](/de/tools/btw) für das vollständige Verhalten und
-Details zur Client-UX.
+Siehe [BTW Side Questions](/de/tools/btw) für das vollständige Verhalten und die UX-
+Details des Clients.
--- a/docs/de/tools/tts.md
+++ b/docs/de/tools/tts.md
@ -1,15 +1,15 @@
 ---
 read_when:
-    - Text-to-Speech für Antworten aktivieren
-    - TTS-Provider oder -Grenzen konfigurieren
-    - '`/tts`-Befehle verwenden'
+    - Aktivieren von Text-to-Speech für Antworten
+    - Konfigurieren von TTS-Anbietern oder Limits
+    - Verwenden von /tts-Befehlen
 summary: Text-to-Speech (TTS) für ausgehende Antworten
 title: Text-to-Speech
 x-i18n:
-    generated_at: "2026-04-05T12:59:27Z"
+    generated_at: "2026-04-08T06:02:10Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 8487c8acef7585bd4eb5e3b39e2a063ebc6b5f0103524abdcbadd3a7781ffc46
+    source_hash: 6e0fbcaf61282733c134f682e05a71f94d2169c03a85131ce9ad233c71a1e533
    source_path: tools/tts.md
    workflow: 15
 ---
@ -21,23 +21,24 @@ Es funktioniert überall dort, wo OpenClaw Audio senden kann.

 ## Unterstützte Dienste

- **ElevenLabs** (primärer oder Fallback-Provider)
- **Microsoft** (primärer oder Fallback-Provider; die aktuelle gebündelte Implementierung verwendet `node-edge-tts`)
- **MiniMax** (primärer oder Fallback-Provider; verwendet die T2A-v2-API)
- **OpenAI** (primärer oder Fallback-Provider; wird auch für Zusammenfassungen verwendet)
+- **ElevenLabs** (primärer oder Fallback-Anbieter)
+- **Microsoft** (primärer oder Fallback-Anbieter; die aktuelle gebündelte Implementierung verwendet `node-edge-tts`)
+- **MiniMax** (primärer oder Fallback-Anbieter; verwendet die T2A-v2-API)
+- **OpenAI** (primärer oder Fallback-Anbieter; wird auch für Zusammenfassungen verwendet)

 ### Hinweise zu Microsoft Speech

-Der gebündelte Microsoft-Speech-Provider verwendet derzeit den Online-
-Neural-TTS-Dienst von Microsoft Edge über die Bibliothek `node-edge-tts`. Es ist ein gehosteter Dienst (nicht
-lokal), verwendet Microsoft-Endpunkte und erfordert keinen API-Schlüssel.
-`node-edge-tts` stellt Konfigurationsoptionen für Sprache und Ausgabeformate bereit, aber
-nicht alle Optionen werden vom Dienst unterstützt. Veraltete Konfiguration und Directive-Eingaben
-mit `edge` funktionieren weiterhin und werden zu `microsoft` normalisiert.
+Der gebündelte Microsoft-Speech-Anbieter verwendet derzeit den gehosteten
+neuronalen TTS-Dienst von Microsoft Edge über die Bibliothek `node-edge-tts`. Es
+handelt sich um einen gehosteten Dienst (nicht lokal), der Microsoft-Endpunkte
+verwendet und keinen API-Schlüssel erfordert.
+`node-edge-tts` stellt Sprachkonfigurationsoptionen und Ausgabeformate bereit,
+aber nicht alle Optionen werden vom Dienst unterstützt. Alte Konfigurationen
+und Direktiveneingaben mit `edge` funktionieren weiterhin und werden zu `microsoft` normalisiert.

-Da dieser Pfad ein öffentlicher Webdienst ohne veröffentlichte SLA oder Quoten ist,
-sollte er als Best Effort behandelt werden. Wenn Sie garantierte Limits und Support benötigen, verwenden Sie OpenAI
-oder ElevenLabs.
+Da dieser Pfad ein öffentlicher Webdienst ohne veröffentlichte SLA oder Quota
+ist, sollte er als Best-Effort behandelt werden. Wenn Sie garantierte Limits
+und Support benötigen, verwenden Sie OpenAI oder ElevenLabs.

 ## Optionale Schlüssel

@ -49,34 +50,34 @@ Wenn Sie OpenAI, ElevenLabs oder MiniMax verwenden möchten:

 Microsoft Speech erfordert **keinen** API-Schlüssel.

-Wenn mehrere Provider konfiguriert sind, wird zuerst der ausgewählte Provider verwendet, die anderen dienen als Fallback-Optionen.
-Die automatische Zusammenfassung verwendet das konfigurierte `summaryModel` (oder `agents.defaults.model.primary`),
-daher muss dieser Provider ebenfalls authentifiziert sein, wenn Sie Zusammenfassungen aktivieren.
+Wenn mehrere Anbieter konfiguriert sind, wird der ausgewählte Anbieter zuerst verwendet und die anderen dienen als Fallback-Optionen.
+Auto-Zusammenfassungen verwenden das konfigurierte `summaryModel` (oder `agents.defaults.model.primary`),
+daher muss dieser Anbieter ebenfalls authentifiziert sein, wenn Sie Zusammenfassungen aktivieren.

 ## Dienst-Links

- [OpenAI Text-to-Speech-Leitfaden](https://platform.openai.com/docs/guides/text-to-speech)
- [OpenAI Audio API-Referenz](https://platform.openai.com/docs/api-reference/audio)
+- [OpenAI Text-to-Speech guide](https://platform.openai.com/docs/guides/text-to-speech)
+- [OpenAI Audio API reference](https://platform.openai.com/docs/api-reference/audio)
 - [ElevenLabs Text to Speech](https://elevenlabs.io/docs/api-reference/text-to-speech)
 - [ElevenLabs Authentication](https://elevenlabs.io/docs/api-reference/authentication)
 - [MiniMax T2A v2 API](https://platform.minimaxi.com/document/T2A%20V2)
 - [node-edge-tts](https://github.com/SchneeHertz/node-edge-tts)
- [Microsoft-Speech-Ausgabeformate](https://learn.microsoft.com/azure/ai-services/speech-service/rest-text-to-speech#audio-outputs)
+- [Microsoft Speech output formats](https://learn.microsoft.com/azure/ai-services/speech-service/rest-text-to-speech#audio-outputs)

 ## Ist es standardmäßig aktiviert?

 Nein. Auto‑TTS ist standardmäßig **deaktiviert**. Aktivieren Sie es in der Konfiguration mit
-`messages.tts.auto` oder pro Sitzung mit `/tts always` (Alias: `/tts on`).
+`messages.tts.auto` oder lokal mit `/tts on`.

 Wenn `messages.tts.provider` nicht gesetzt ist, wählt OpenClaw den ersten konfigurierten
-Speech-Provider in der Auto-Select-Reihenfolge der Registry.
+Speech-Anbieter in der Auto-Select-Reihenfolge der Registry aus.

 ## Konfiguration

 Die TTS-Konfiguration befindet sich unter `messages.tts` in `openclaw.json`.
 Das vollständige Schema finden Sie unter [Gateway-Konfiguration](/de/gateway/configuration).

-### Minimale Konfiguration (aktivieren + Provider)
+### Minimale Konfiguration (Aktivieren + Anbieter)

 ```json5
 {
@ -130,7 +131,7 @@ Das vollständige Schema finden Sie unter [Gateway-Konfiguration](/de/gateway/co
 }
 ```

-### Microsoft primär (kein API-Schlüssel)
+### Microsoft primär (ohne API-Schlüssel)

 ```json5
 {
@ -220,7 +221,7 @@ Das vollständige Schema finden Sie unter [Gateway-Konfiguration](/de/gateway/co
 }
 ```

-### Automatische Zusammenfassung für lange Antworten deaktivieren
+### Auto-Zusammenfassung für lange Antworten deaktivieren

 ```json5
 {
@ -232,7 +233,7 @@ Das vollständige Schema finden Sie unter [Gateway-Konfiguration](/de/gateway/co
 }
 ```

-Dann ausführen:
+Führen Sie dann Folgendes aus:

 ```
 /tts summary off
@ -243,25 +244,25 @@ Dann ausführen:
 - `auto`: Auto‑TTS-Modus (`off`, `always`, `inbound`, `tagged`).
  - `inbound` sendet Audio nur nach einer eingehenden Sprachnachricht.
  - `tagged` sendet Audio nur, wenn die Antwort `[[tts]]`-Tags enthält.
- `enabled`: veralteter Schalter (doctor migriert dies zu `auto`).
+- `enabled`: alter Schalter (doctor migriert dies zu `auto`).
 - `mode`: `"final"` (Standard) oder `"all"` (einschließlich Tool-/Block-Antworten).
- `provider`: Speech-Provider-ID wie `"elevenlabs"`, `"microsoft"`, `"minimax"` oder `"openai"` (Fallback erfolgt automatisch).
- Wenn `provider` **nicht gesetzt** ist, verwendet OpenClaw den ersten konfigurierten Speech-Provider in der Auto-Select-Reihenfolge der Registry.
- Das veraltete `provider: "edge"` funktioniert weiterhin und wird zu `microsoft` normalisiert.
- `summaryModel`: optionales günstiges Modell für automatische Zusammenfassungen; Standard ist `agents.defaults.model.primary`.
+- `provider`: Speech-Anbieter-ID wie `"elevenlabs"`, `"microsoft"`, `"minimax"` oder `"openai"` (Fallback erfolgt automatisch).
+- Wenn `provider` **nicht gesetzt** ist, verwendet OpenClaw den ersten konfigurierten Speech-Anbieter in der Auto-Select-Reihenfolge der Registry.
+- Das alte `provider: "edge"` funktioniert weiterhin und wird zu `microsoft` normalisiert.
+- `summaryModel`: optionales günstiges Modell für Auto-Zusammenfassungen; Standard ist `agents.defaults.model.primary`.
  - Akzeptiert `provider/model` oder einen konfigurierten Modellalias.
- `modelOverrides`: erlaubt dem Modell, TTS-Directives auszugeben (standardmäßig aktiviert).
-  - `allowProvider` ist standardmäßig `false` (Provider-Wechsel ist Opt-in).
- `providers.<id>`: provider-eigene Einstellungen, verschlüsselt nach Speech-Provider-ID.
- Veraltete direkte Provider-Blöcke (`messages.tts.openai`, `messages.tts.elevenlabs`, `messages.tts.microsoft`, `messages.tts.edge`) werden beim Laden automatisch zu `messages.tts.providers.<id>` migriert.
+- `modelOverrides`: erlaubt dem Modell, TTS-Direktiven auszugeben (standardmäßig aktiviert).
+  - `allowProvider` ist standardmäßig `false` (Anbieterwechsel ist Opt-in).
+- `providers.<id>`: anbieterbezogene Einstellungen, nach Speech-Anbieter-ID gruppiert.
+- Alte direkte Anbieterblöcke (`messages.tts.openai`, `messages.tts.elevenlabs`, `messages.tts.microsoft`, `messages.tts.edge`) werden beim Laden automatisch zu `messages.tts.providers.<id>` migriert.
 - `maxTextLength`: hartes Limit für TTS-Eingaben (Zeichen). `/tts audio` schlägt fehl, wenn es überschritten wird.
 - `timeoutMs`: Request-Timeout (ms).
- `prefsPath`: überschreibt den lokalen prefs-JSON-Pfad (Provider/Limit/Zusammenfassung).
+- `prefsPath`: überschreibt den lokalen JSON-Pfad für Einstellungen (Anbieter/Limit/Zusammenfassung).
 - `apiKey`-Werte greifen auf Umgebungsvariablen zurück (`ELEVENLABS_API_KEY`/`XI_API_KEY`, `MINIMAX_API_KEY`, `OPENAI_API_KEY`).
 - `providers.elevenlabs.baseUrl`: überschreibt die ElevenLabs-API-Basis-URL.
 - `providers.openai.baseUrl`: überschreibt den OpenAI-TTS-Endpunkt.
  - Auflösungsreihenfolge: `messages.tts.providers.openai.baseUrl` -> `OPENAI_TTS_BASE_URL` -> `https://api.openai.com/v1`
-  - Nicht standardmäßige Werte werden als OpenAI-kompatible TTS-Endpunkte behandelt, daher werden benutzerdefinierte Modell- und Stimmmnamen akzeptiert.
+  - Nicht standardmäßige Werte werden als OpenAI-kompatible TTS-Endpunkte behandelt, daher werden benutzerdefinierte Modell- und Voice-Namen akzeptiert.
 - `providers.elevenlabs.voiceSettings`:
  - `stability`, `similarityBoost`, `style`: `0..1`
  - `useSpeakerBoost`: `true|false`
@ -269,48 +270,48 @@ Dann ausführen:
 - `providers.elevenlabs.applyTextNormalization`: `auto|on|off`
 - `providers.elevenlabs.languageCode`: 2-stelliger ISO-639-1-Code (z. B. `en`, `de`)
 - `providers.elevenlabs.seed`: Ganzzahl `0..4294967295` (Best-Effort-Determinismus)
- `providers.minimax.baseUrl`: überschreibt die MiniMax-API-Basis-URL (Standard `https://api.minimax.io`, Umgebungsvariable: `MINIMAX_API_HOST`).
- `providers.minimax.model`: TTS-Modell (Standard `speech-2.8-hd`, Umgebungsvariable: `MINIMAX_TTS_MODEL`).
- `providers.minimax.voiceId`: Sprachkennung (Standard `English_expressive_narrator`, Umgebungsvariable: `MINIMAX_TTS_VOICE_ID`).
+- `providers.minimax.baseUrl`: überschreibt die MiniMax-API-Basis-URL (Standard `https://api.minimax.io`, env: `MINIMAX_API_HOST`).
+- `providers.minimax.model`: TTS-Modell (Standard `speech-2.8-hd`, env: `MINIMAX_TTS_MODEL`).
+- `providers.minimax.voiceId`: Voice-Kennung (Standard `English_expressive_narrator`, env: `MINIMAX_TTS_VOICE_ID`).
 - `providers.minimax.speed`: Wiedergabegeschwindigkeit `0.5..2.0` (Standard 1.0).
 - `providers.minimax.vol`: Lautstärke `(0, 10]` (Standard 1.0; muss größer als 0 sein).
 - `providers.minimax.pitch`: Tonhöhenverschiebung `-12..12` (Standard 0).
 - `providers.microsoft.enabled`: erlaubt die Nutzung von Microsoft Speech (Standard `true`; kein API-Schlüssel).
- `providers.microsoft.voice`: Name der Microsoft-Neural-Stimme (z. B. `en-US-MichelleNeural`).
+- `providers.microsoft.voice`: Name der Microsoft-Neural-Voice (z. B. `en-US-MichelleNeural`).
 - `providers.microsoft.lang`: Sprachcode (z. B. `en-US`).
 - `providers.microsoft.outputFormat`: Microsoft-Ausgabeformat (z. B. `audio-24khz-48kbitrate-mono-mp3`).
-  - Gültige Werte finden Sie unter Microsoft-Speech-Ausgabeformate; nicht alle Formate werden vom gebündelten Edge-basierten Transport unterstützt.
- `providers.microsoft.rate` / `providers.microsoft.pitch` / `providers.microsoft.volume`: Prozent-Strings (z. B. `+10%`, `-5%`).
+  - Gültige Werte finden Sie unter Microsoft Speech output formats; nicht alle Formate werden vom gebündelten Edge-basierten Transport unterstützt.
+- `providers.microsoft.rate` / `providers.microsoft.pitch` / `providers.microsoft.volume`: Prozentzeichenfolgen (z. B. `+10%`, `-5%`).
 - `providers.microsoft.saveSubtitles`: schreibt JSON-Untertitel neben die Audiodatei.
 - `providers.microsoft.proxy`: Proxy-URL für Microsoft-Speech-Requests.
 - `providers.microsoft.timeoutMs`: Überschreibung des Request-Timeouts (ms).
- `edge.*`: veralteter Alias für dieselben Microsoft-Einstellungen.
+- `edge.*`: alter Alias für dieselben Microsoft-Einstellungen.

 ## Modellgesteuerte Überschreibungen (standardmäßig aktiviert)

-Standardmäßig **kann** das Modell TTS-Directives für eine einzelne Antwort ausgeben.
-Wenn `messages.tts.auto` auf `tagged` gesetzt ist, sind diese Directives erforderlich, um Audio auszulösen.
+Standardmäßig **kann** das Modell TTS-Direktiven für eine einzelne Antwort ausgeben.
+Wenn `messages.tts.auto` auf `tagged` gesetzt ist, sind diese Direktiven erforderlich, um Audio auszulösen.

-Wenn aktiviert, kann das Modell `[[tts:...]]`-Directives ausgeben, um die Stimme
+Wenn aktiviert, kann das Modell `[[tts:...]]`-Direktiven ausgeben, um die Voice
 für eine einzelne Antwort zu überschreiben, sowie optional einen `[[tts:text]]...[[/tts:text]]`-Block,
 um ausdrucksstarke Tags (Lachen, Gesangshinweise usw.) bereitzustellen, die nur im
 Audio erscheinen sollen.

-`provider=...`-Directives werden ignoriert, sofern nicht `modelOverrides.allowProvider: true`.
+`provider=...`-Direktiven werden ignoriert, es sei denn, `modelOverrides.allowProvider: true`.

 Beispiel für eine Antwort-Payload:

 ```
-Hier ist sie.
+Here you go.

 [[tts:voiceId=pMsXgVXv3BLzUgSXRplE model=eleven_v3 speed=1.1]]
-[[tts:text]](lacht) Lies das Lied noch einmal.[[/tts:text]]
+[[tts:text]](laughs) Read the song once more.[[/tts:text]]
 ```

-Verfügbare Directive-Schlüssel (wenn aktiviert):
+Verfügbare Direktivenschlüssel (wenn aktiviert):

- `provider` (registrierte Speech-Provider-ID, z. B. `openai`, `elevenlabs`, `minimax` oder `microsoft`; erfordert `allowProvider: true`)
- `voice` (OpenAI-Stimme) oder `voiceId` (ElevenLabs / MiniMax)
+- `provider` (registrierte Speech-Anbieter-ID, zum Beispiel `openai`, `elevenlabs`, `minimax` oder `microsoft`; erfordert `allowProvider: true`)
+- `voice` (OpenAI-Voice) oder `voiceId` (ElevenLabs / MiniMax)
 - `model` (OpenAI-TTS-Modell, ElevenLabs-Modell-ID oder MiniMax-Modell)
 - `stability`, `similarityBoost`, `style`, `speed`, `useSpeakerBoost`
 - `vol` / `volume` (MiniMax-Lautstärke, 0-10)
@ -333,7 +334,7 @@ Alle Modellüberschreibungen deaktivieren:
 }
 ```

-Optionale Allowlist (Provider-Wechsel aktivieren, während andere Stellschrauben konfigurierbar bleiben):
+Optionale Allowlist (Anbieterwechsel aktivieren, während andere Parameter konfigurierbar bleiben):

 ```json5
 {
@ -359,35 +360,34 @@ Gespeicherte Felder:

 - `enabled`
 - `provider`
- `maxLength` (Schwellenwert für Zusammenfassungen; Standard 1500 Zeichen)
+- `maxLength` (Zusammenfassungsschwelle; Standard 1500 Zeichen)
 - `summarize` (Standard `true`)

 Diese überschreiben `messages.tts.*` für diesen Host.

 ## Ausgabeformate (fest)

- **Feishu / Matrix / Telegram / WhatsApp**: Opus-Sprachnachricht (`opus_48000_64` von ElevenLabs, `opus` von OpenAI).
-  - 48 kHz / 64 kbps ist ein guter Kompromiss für Sprachnachrichten.
+- **Feishu / Matrix / Telegram / WhatsApp**: Opus-Voice-Message (`opus_48000_64` von ElevenLabs, `opus` von OpenAI).
+  - 48 kHz / 64 kbps ist ein guter Kompromiss für Voice-Messages.
 - **Andere Kanäle**: MP3 (`mp3_44100_128` von ElevenLabs, `mp3` von OpenAI).
-  - 44,1 kHz / 128 kbps ist der Standardkompromiss für klare Sprachwiedergabe.
- **MiniMax**: MP3 (`speech-2.8-hd`-Modell, 32-kHz-Abtastrate). Das Format für Sprachnotizen wird nativ nicht unterstützt; verwenden Sie OpenAI oder ElevenLabs für garantiertes Opus bei Sprachnachrichten.
+  - 44,1 kHz / 128 kbps ist die Standardbalance für klare Sprachwiedergabe.
+- **MiniMax**: MP3 (Modell `speech-2.8-hd`, 32-kHz-Samplerate). Voice-Note-Format wird nativ nicht unterstützt; verwenden Sie OpenAI oder ElevenLabs für garantierte Opus-Voice-Messages.
 - **Microsoft**: verwendet `microsoft.outputFormat` (Standard `audio-24khz-48kbitrate-mono-mp3`).
-  - Der gebündelte Transport akzeptiert ein `outputFormat`, aber nicht alle Formate sind im Dienst verfügbar.
-  - Die Werte für Ausgabeformate folgen den Microsoft-Speech-Ausgabeformaten (einschließlich Ogg/WebM Opus).
-  - Telegram `sendVoice` akzeptiert OGG/MP3/M4A; verwenden Sie OpenAI/ElevenLabs, wenn Sie
-    garantiertes Opus für Sprachnachrichten benötigen.
+  - Der gebündelte Transport akzeptiert ein `outputFormat`, aber nicht alle Formate sind über den Dienst verfügbar.
+  - Werte für das Ausgabeformat entsprechen Microsoft Speech output formats (einschließlich Ogg/WebM Opus).
+  - Telegram `sendVoice` akzeptiert OGG/MP3/M4A; verwenden Sie OpenAI/ElevenLabs, wenn Sie garantierte Opus-Voice-Messages benötigen.
  - Wenn das konfigurierte Microsoft-Ausgabeformat fehlschlägt, versucht OpenClaw es erneut mit MP3.

-Die Ausgabeformate von OpenAI/ElevenLabs sind pro Kanal festgelegt (siehe oben).
+OpenAI-/ElevenLabs-Ausgabeformate sind pro Kanal festgelegt (siehe oben).

 ## Verhalten von Auto-TTS

 Wenn aktiviert, führt OpenClaw Folgendes aus:

- TTS wird übersprungen, wenn die Antwort bereits Medien oder eine `MEDIA:`-Directive enthält.
- Sehr kurze Antworten (< 10 Zeichen) werden übersprungen.
- Lange Antworten werden bei aktivierter Funktion mit `agents.defaults.model.primary` (oder `summaryModel`) zusammengefasst.
- Das erzeugte Audio wird an die Antwort angehängt.
+- TTS wird übersprungen, wenn die Antwort bereits Medien oder eine `MEDIA:`-Direktive enthält.
+- sehr kurze Antworten (< 10 Zeichen) werden übersprungen.
+- lange Antworten werden, wenn aktiviert, mit `agents.defaults.model.primary` (oder `summaryModel`) zusammengefasst.
+- das generierte Audio wird an die Antwort angehängt.

 Wenn die Antwort `maxLength` überschreitet und die Zusammenfassung deaktiviert ist (oder kein API-Schlüssel für das
 Zusammenfassungsmodell vorhanden ist), wird Audio
@ -396,31 +396,29 @@ Zusammenfassungsmodell vorhanden ist), wird Audio
 ## Ablaufdiagramm

 ```
-Antwort -> TTS aktiviert?
-  nein -> Text senden
-  ja   -> Medien / MEDIA: / kurz vorhanden?
-          ja   -> Text senden
-          nein -> Länge > Limit?
-                   nein -> TTS -> Audio anhängen
-                   ja   -> Zusammenfassung aktiviert?
-                            nein -> Text senden
-                            ja   -> zusammenfassen (summaryModel oder agents.defaults.model.primary)
-                                      -> TTS -> Audio anhängen
+Reply -> TTS enabled?
+  no  -> send text
+  yes -> has media / MEDIA: / short?
+          yes -> send text
+          no  -> length > limit?
+                   no  -> TTS -> attach audio
+                   yes -> summary enabled?
+                            no  -> send text
+                            yes -> summarize (summaryModel or agents.defaults.model.primary)
+                                      -> TTS -> attach audio
 ```

-## Verwendung per Slash-Befehl
+## Verwendung von Slash-Befehlen

 Es gibt einen einzelnen Befehl: `/tts`.
-Details zur Aktivierung finden Sie unter [Slash-Befehle](/tools/slash-commands).
+Details zur Aktivierung finden Sie unter [Slash-Befehle](/de/tools/slash-commands).

-Hinweis für Discord: `/tts` ist ein integrierter Discord-Befehl, daher registriert OpenClaw dort
+Hinweis zu Discord: `/tts` ist ein integrierter Discord-Befehl, daher registriert OpenClaw dort
 `/voice` als nativen Befehl. Textbasiertes `/tts ...` funktioniert weiterhin.

 ```
 /tts off
-/tts always
-/tts inbound
-/tts tagged
+/tts on
 /tts status
 /tts provider openai
 /tts limit 2000
@ -432,22 +430,24 @@ Hinweise:

 - Befehle erfordern einen autorisierten Absender (Allowlist-/Owner-Regeln gelten weiterhin).
 - `commands.text` oder die Registrierung nativer Befehle muss aktiviert sein.
- `off|always|inbound|tagged` sind Umschalter pro Sitzung (`/tts on` ist ein Alias für `/tts always`).
+- Die Konfiguration `messages.tts.auto` akzeptiert `off|always|inbound|tagged`.
+- `/tts on` schreibt die lokale TTS-Einstellung auf `always`; `/tts off` schreibt sie auf `off`.
+- Verwenden Sie die Konfiguration, wenn Sie `inbound`- oder `tagged`-Standards möchten.
 - `limit` und `summary` werden in lokalen Einstellungen gespeichert, nicht in der Hauptkonfiguration.
- `/tts audio` erzeugt eine einmalige Audio-Antwort (aktiviert TTS nicht dauerhaft).
- `/tts status` enthält Fallback-Sichtbarkeit für den letzten Versuch:
+- `/tts audio` erzeugt eine einmalige Audioantwort (aktiviert TTS nicht dauerhaft).
+- `/tts status` enthält Sichtbarkeit von Fallbacks für den neuesten Versuch:
  - erfolgreicher Fallback: `Fallback: <primary> -> <used>` plus `Attempts: ...`
  - Fehler: `Error: ...` plus `Attempts: ...`
-  - detaillierte Diagnostik: `Attempt details: provider:outcome(reasonCode) latency`
- Fehler von OpenAI- und ElevenLabs-APIs enthalten jetzt geparste Provider-Fehlerdetails und Request-IDs (wenn vom Provider zurückgegeben), was in TTS-Fehlern/Logs sichtbar gemacht wird.
+  - detaillierte Diagnose: `Attempt details: provider:outcome(reasonCode) latency`
+- OpenAI- und ElevenLabs-API-Fehler enthalten jetzt geparste Fehlerdetails des Anbieters und die Request-ID (wenn vom Anbieter zurückgegeben), die in TTS-Fehlern/Logs sichtbar gemacht werden.

 ## Agent-Tool

-Das Tool `tts` wandelt Text in Sprache um und gibt einen Audio-Anhang für
-die Antwortzustellung zurück. Wenn der Kanal Feishu, Matrix, Telegram oder WhatsApp ist,
-wird das Audio als Sprachnachricht statt als Dateianhang zugestellt.
+Das `tts`-Tool wandelt Text in Sprache um und gibt einen Audio-Anhang zur
+Auslieferung der Antwort zurück. Wenn der Kanal Feishu, Matrix, Telegram oder WhatsApp ist,
+wird das Audio als Voice-Message statt als Dateianhang gesendet.

-## Gateway RPC
+## Gateway-RPC

 Gateway-Methoden: