chore(i18n): refresh de translations

Author: openclaw-docs-i18n[bot]

docs/de/concepts/qa-e2e-automation.md

@@ -1,50 +1,50 @@
 ---
 read_when:
     - Erweitern von qa-lab oder qa-channel
-    - Hinzufügen repo-gestützter QA-Szenarien
-    - Erstellen von QA-Automatisierung mit höherem Realitätsgrad rund um das Gateway-Dashboard
-summary: Private QA-Automatisierungsstruktur für qa-lab, qa-channel, Seeded Scenarios und Protokollberichte
-title: QA-E2E-Automatisierung
+    - Hinzufügen von repository-gestützten QA-Szenarien
+    - Aufbau einer realistischeren QA-Automatisierung rund um das Gateway-Dashboard
+summary: Private QA-Automatisierungsstruktur für qa-lab, qa-channel, vordefinierte Szenarien und Protokollberichte
+title: QA-End-to-End-Automatisierung
 x-i18n:
-    generated_at: "2026-04-12T23:28:12Z"
+    generated_at: "2026-04-13T06:29:41Z"
     model: gpt-5.4
     provider: openai
-    source_hash: b9fe27dc049823d5e3eb7ae1eac6aad21ed9e917425611fb1dbcb28ab9210d5e
+    source_hash: a4a4f5c765163565c95c2a071f201775fd9d8d60cad4ff25d71e4710559c1570
     source_path: concepts/qa-e2e-automation.md
     workflow: 15
 ---
 
-# QA-E2E-Automatisierung
+# QA-End-to-End-Automatisierung
 
-Der private QA-Stack soll OpenClaw auf realistischere, kanalähnliche Weise testen,
-als es ein einzelner Unit-Test kann.
+Der private QA-Stack ist dafür gedacht, OpenClaw auf eine realistischere,
+kanalähnliche Weise zu prüfen, als es ein einzelner Unit-Test kann.
 
-Aktuelle Bausteine:
+Aktuelle Bestandteile:
 
-- `extensions/qa-channel`: synthetischer Nachrichtenkanal mit DM-, Kanal-, Thread-,
-  Reaktions-, Bearbeitungs- und Löschoberflächen.
+- `extensions/qa-channel`: synthetischer Nachrichtenkanal mit Oberflächen für DM, Kanal, Thread,
+  Reaktion, Bearbeiten und Löschen.
 - `extensions/qa-lab`: Debugger-UI und QA-Bus zum Beobachten des Transkripts,
-  Einspielen eingehender Nachrichten und Exportieren eines Markdown-Berichts.
-- `qa/`: repo-gestützte Seed-Assets für die Startaufgabe und grundlegende QA-
+  Einfügen eingehender Nachrichten und Exportieren eines Markdown-Berichts.
+- `qa/`: repository-gestützte Seed-Assets für die Startaufgabe und grundlegende QA-
   Szenarien.
 
-Der aktuelle QA-Operator-Ablauf ist eine QA-Site mit zwei Bereichen:
+Der aktuelle QA-Operator-Workflow ist eine QA-Site mit zwei Bereichen:
 
 - Links: Gateway-Dashboard (Control UI) mit dem Agenten.
-- Rechts: QA Lab mit dem Slack-ähnlichen Transkript und dem Szenarioplan.
+- Rechts: QA Lab, das das Slack-ähnliche Transkript und den Szenarioplan anzeigt.
 
-Führen Sie es aus mit:
+Starten Sie sie mit:
 
 ```bash
 pnpm qa:lab:up
 ```
 
-Dadurch wird die QA-Site gebaut, die 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 blockiert geblieben ist.
+Dadurch wird die QA-Site gebaut, die Docker-gestützte Gateway-Umgebung 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
+blockiert geblieben ist.
 
-Für schnellere QA-Lab-UI-Iterationen, ohne das Docker-Image jedes Mal neu zu bauen,
+Für schnellere QA-Lab-UI-Iteration, ohne das Docker-Image jedes Mal neu zu bauen,
 starten Sie den Stack mit einem bind-gemounteten QA-Lab-Bundle:
 
 ```bash
@@ -54,130 +54,134 @@ 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. `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-Dienste auf einem vorgefertigten 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 QA-Lab-
+Asset-Hash ändert.
 
-Für eine Matrix-Smoke-Lane mit echtem Transport führen Sie aus:
+Für eine transportechte Matrix-Smoke-Umgebung führen Sie aus:
 
 ```bash
 pnpm openclaw qa matrix
 ```
 
-Diese Lane stellt einen flüchtigen Tuwunel-Homeserver in Docker bereit, registriert
-temporäre Driver-, SUT- und Observer-Benutzer, erstellt einen privaten Raum und führt
-dann das echte Matrix-Plugin innerhalb eines QA-Gateway-Child-Prozesses aus. Die Live-
-Transport-Lane hält die Child-Konfiguration auf den getesteten Transport begrenzt, sodass
-Matrix ohne `qa-channel` in der Child-Konfiguration läuft.
+Diese Umgebung stellt in Docker einen temporären Tuwunel-Homeserver bereit, registriert
+temporäre Driver-, SUT- und Observer-Benutzer, erstellt einen privaten Raum und führt dann
+das echte Matrix-Plugin innerhalb eines untergeordneten QA-Gateway-Prozesses aus. Die Live-Transportumgebung hält
+die Konfiguration des untergeordneten Prozesses auf den getesteten Transport beschränkt, sodass Matrix ohne
+`qa-channel` in der Konfiguration des untergeordneten Prozesses läuft.
 
-Für eine Telegram-Smoke-Lane mit echtem Transport führen Sie aus:
+Für eine transportechte Telegram-Smoke-Umgebung führen Sie aus:
 
 ```bash
 pnpm openclaw qa telegram
 ```
 
-Diese Lane zielt auf eine echte private Telegram-Gruppe, anstatt einen flüchtigen Server
-bereitzustellen. Erforderlich sind `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
+Diese Umgebung zielt auf eine echte private Telegram-Gruppe, anstatt einen temporären
+Server bereitzustellen. Sie erfordert `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
 `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` und
 `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN` sowie zwei unterschiedliche Bots in derselben
 privaten Gruppe. Der SUT-Bot muss einen Telegram-Benutzernamen haben, und die Bot-zu-Bot-
-Beobachtung funktioniert am besten, wenn bei beiden Bots der Bot-to-Bot Communication Mode
+Beobachtung funktioniert am besten, wenn bei beiden Bots der Modus für Bot-zu-Bot-Kommunikation
 in `@BotFather` aktiviert ist.
 
-Live-Transport-Lanes verwenden jetzt einen kleineren gemeinsamen Vertrag, statt dass jede
-ihre eigene Form der Szenarioliste erfindet:
+Live-Transportumgebungen verwenden jetzt einen gemeinsamen kleineren Vertrag, statt jeweils
+eine eigene Form für die Szenarioliste zu definieren:
 
-`qa-channel` bleibt die breite synthetische Suite für Produktverhalten und ist nicht Teil
+`qa-channel` bleibt die umfassende synthetische Suite für Produktverhalten und ist nicht Teil
 der Live-Transport-Abdeckungsmatrix.
 
-| Lane     | Canary | Mention-Gating | Allowlist-Block | Antwort auf oberster Ebene | Nach Neustart fortsetzen | Thread-Follow-up | Thread-Isolation | Reaktionsbeobachtung | Help-Befehl |
-| -------- | ------ | -------------- | --------------- | -------------------------- | ------------------------ | ---------------- | ---------------- | -------------------- | ------------ |
-| Matrix   | x      | x              | x               | x                          | x                        | x                | x                | x                    |              |
-| Telegram | x      |                |                 |                            |                          |                  |                  |                      | x            |
+| Umgebung | Canary | Erwähnungs-Gating | Allowlist-Blockierung | Antwort auf oberster Ebene | Fortsetzen nach Neustart | Thread-Nachverfolgung | Thread-Isolation | Reaktionsbeobachtung | Hilfebefehl |
+| -------- | ------ | ----------------- | --------------------- | -------------------------- | ------------------------ | --------------------- | ---------------- | -------------------- | ----------- |
+| Matrix   | x      | x                 | x                     | x                          | x                        | x                     | x                | x                    |             |
+| Telegram | x      |                   |                       |                            |                          |                       |                  |                      | x           |
 
-Dadurch bleibt `qa-channel` die breite Suite für Produktverhalten, während Matrix,
-Telegram und künftige Live-Transporte eine explizite Checkliste für Transportverträge
-gemeinsam nutzen.
+Dadurch bleibt `qa-channel` die umfassende Suite für Produktverhalten, während Matrix,
+Telegram und zukünftige Live-Transporte sich eine explizite Checkliste für Transportverträge teilen.
 
-Für eine flüchtige Linux-VM-Lane, ohne Docker in den QA-Pfad einzubringen, führen Sie aus:
+Für eine temporäre Linux-VM-Umgebung, ohne Docker in den QA-Pfad einzubeziehen, führen Sie aus:
 
 ```bash
 pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 ```
 
 Dadurch wird ein frischer Multipass-Gast gestartet, Abhängigkeiten installiert, OpenClaw
-innerhalb des Gasts gebaut, `qa suite` ausgeführt und anschließend der normale QA-Bericht
-sowie die Zusammenfassung zurück nach `.artifacts/qa-e2e/...` auf dem Host kopiert.
-Es verwendet dasselbe Szenarioauswahlverhalten wie `qa suite` auf dem Host.
-Host- und Multipass-Suite-Ausführungen führen standardmäßig mehrere ausgewählte Szenarien
-parallel mit isolierten Gateway-Workern aus, bis zu 64 Workern oder der Anzahl der
-ausgewählten Szenarien. Verwenden Sie `--concurrency <count>`, um die Anzahl der Worker
-anzupassen, oder `--concurrency 1` für serielle Ausführung.
-Live-Ausführungen leiten die unterstützten QA-Authentifizierungseingaben weiter, die für
-den Gast praktikabel sind: Provider-Schlüssel über Umgebungsvariablen, den QA-Live-
-Provider-Konfigurationspfad und `CODEX_HOME`, falls vorhanden. Halten Sie `--output-dir`
-unterhalb der Repo-Wurzel, damit der Gast über den gemounteten Workspace zurückschreiben kann.
-
-## Repo-gestützte Seeds
-
-Seed-Assets befinden sich in `qa/`:
+innerhalb des Gasts gebaut, `qa suite` ausgeführt und dann der normale QA-Bericht sowie die
+Zusammenfassung zurück nach `.artifacts/qa-e2e/...` auf dem Host kopiert.
+Es verwendet dasselbe Verhalten bei der Szenarioauswahl wie `qa suite` auf dem Host.
+Host- und Multipass-Suite-Läufe führen standardmäßig mehrere ausgewählte Szenarien parallel
+mit isolierten Gateway-Workern aus, bis zu 64 Worker oder bis zur Anzahl der ausgewählten
+Szenarien. Verwenden Sie `--concurrency <count>`, um die Anzahl der Worker anzupassen, oder
+`--concurrency 1` für serielle Ausführung.
+Live-Läufe leiten die unterstützten QA-Authentifizierungseingaben weiter, die für den
+Gast praktikabel sind: Provider-Schlüssel per Umgebungsvariable, den Konfigurationspfad für den QA-Live-Provider und
+`CODEX_HOME`, falls vorhanden. Halten Sie `--output-dir` unter dem Repository-Root, damit der Gast
+über den gemounteten Workspace zurückschreiben kann.
+
+## Repository-gestützte Seeds
+
+Seed-Assets liegen in `qa/`:
 
 - `qa/scenarios/index.md`
 - `qa/scenarios/*.md`
 
-Diese liegen absichtlich in Git, 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.
 
-`qa-lab` sollte ein generischer Markdown-Runner bleiben. Jede Markdown-Datei für ein
-Szenario ist die Quelle der Wahrheit für einen Testlauf und sollte Folgendes definieren:
+`qa-lab` sollte ein generischer Markdown-Runner bleiben. Jede Markdown-Datei für ein Szenario ist
+die Quelle der Wahrheit für einen Testlauf und sollte Folgendes definieren:
 
-- Szenariometadaten
+- Szenario-Metadaten
 - Dokumentations- und Code-Referenzen
 - optionale Plugin-Anforderungen
-- optionalen Gateway-Konfigurations-Patch
-- den ausführbaren `qa-flow`
+- optionaler Gateway-Konfigurations-Patch
+- der ausführbare `qa-flow`
 
-Die grundlegende Liste sollte breit genug bleiben, um Folgendes abzudecken:
+Die wiederverwendbare Laufzeitoberfläche, die `qa-flow` unterstützt, darf generisch
+und querschnittlich bleiben. Markdown-Szenarien können zum Beispiel
+transportseitige Hilfsfunktionen mit browserseitigen Hilfsfunktionen kombinieren, die die eingebettete Control UI über die
+Gateway-`browser.request`-Schnittstelle steuern, ohne einen Spezialfall-Runner hinzuzufügen.
+
+Die Basisliste sollte breit genug bleiben, um Folgendes abzudecken:
 
 - DM- und Kanal-Chat
 - Thread-Verhalten
 - Lebenszyklus von Nachrichtenaktionen
 - Cron-Callbacks
-- Memory-Abruf
+- Speicherabruf
 - Modellwechsel
 - Subagent-Übergabe
-- Lesen des Repo und Lesen der Dokumentation
+- Lesen von Repository und Dokumentation
 - eine kleine Build-Aufgabe wie Lobster Invaders
 
-## Transport-Adapter
+## Transportadapter
 
-`qa-lab` besitzt eine generische Transport-Nahtstelle für Markdown-QA-Szenarien.
-`qa-channel` ist der erste Adapter auf dieser Nahtstelle, aber das Designziel ist breiter:
-Künftige echte oder synthetische Kanäle sollten sich in dieselbe Suite-Ausführung einklinken,
-anstatt einen transportspezifischen QA-Runner hinzuzufügen.
+`qa-lab` besitzt eine generische Transportschnittstelle für Markdown-QA-Szenarien.
+`qa-channel` ist der erste Adapter auf dieser Schnittstelle, aber das Designziel ist breiter:
+zukünftige echte oder synthetische Kanäle sollten in denselben Suite-Runner eingebunden werden, statt einen
+transportspezifischen QA-Runner hinzuzufügen.
 
 Auf Architekturebene ist die Aufteilung wie folgt:
 
-- `qa-lab` besitzt die generische Szenarioausführung, Worker-Parallelität, Artefaktschreibung und Berichterstattung.
-- Der Transport-Adapter besitzt Gateway-Konfiguration, Bereitschaft, Ein- und Ausgangsbeobachtung, Transportaktionen und normalisierten Transportzustand.
-- Markdown-Szenariodateien unter `qa/scenarios/` definieren den Testlauf; `qa-lab` stellt die wiederverwendbare Laufzeitoberfläche bereit, die sie ausführt.
+- `qa-lab` übernimmt generische Szenarioausführung, Worker-Parallelität, Schreiben von Artefakten und Berichterstellung.
+- der Transportadapter übernimmt Gateway-Konfiguration, Bereitschaft, Beobachtung eingehender und ausgehender Daten, Transportaktionen und normalisierten Transportzustand.
+- Markdown-Szenariodateien unter `qa/scenarios/` definieren den Testlauf; `qa-lab` stellt die wiederverwendbare Laufzeitoberfläche bereit, die ihn ausführt.
 
-Die maintainer-orientierte Anleitung zur Einführung neuer Kanal-Adapter steht in
+Maintainer-orientierte Hinweise zur Einführung neuer Kanaladapter finden Sie unter
 [Testing](/de/help/testing#adding-a-channel-to-qa).
 
-## Berichterstattung
+## Berichterstellung
 
 `qa-lab` exportiert einen Markdown-Protokollbericht aus der beobachteten Bus-Zeitleiste.
-Der Bericht sollte folgende Fragen beantworten:
+Der Bericht sollte Folgendes beantworten:
 
-- Was hat funktioniert
-- Was ist fehlgeschlagen
-- Was ist blockiert geblieben
-- Welche Folge-Szenarien es sich lohnt hinzuzufügen
+- Was funktioniert hat
+- Was fehlgeschlagen ist
+- Was blockiert geblieben ist
+- Welche Folgeszenarien sich hinzuzufügen lohnen
 
-Für Zeichen- und Stilprüfungen führen Sie dasselbe Szenario über mehrere Live-
-Modell-Referenzen hinweg aus und schreiben einen bewerteten Markdown-Bericht:
+Für Zeichen- und Stilprüfungen führen Sie dasselbe Szenario über mehrere Live-Modell-
+Referenzen aus und schreiben einen bewerteten Markdown-Bericht:
 
 ```bash
 pnpm openclaw qa character-eval \
@@ -196,38 +200,35 @@ pnpm openclaw qa character-eval \
   --judge-concurrency 16
 ```
 
-Der Befehl führt lokale QA-Gateway-Child-Prozesse aus, nicht Docker. Character-eval-
-Szenarien sollten die Persona über `SOUL.md` setzen und dann gewöhnliche Benutzerzüge
-wie Chat, Workspace-Hilfe und kleine Dateiaufgaben ausführen. Dem Kandidatenmodell sollte
-nicht mitgeteilt werden, dass es bewertet wird. Der Befehl bewahrt jedes vollständige
-Transkript, erfasst grundlegende Laufstatistiken und bittet dann die Bewertungsmodelle im
-schnellen Modus mit `xhigh`-Reasoning, die Läufe nach Natürlichkeit, Vibe und Humor zu
-bewerten.
-Verwenden Sie `--blind-judge-models`, wenn Sie Provider vergleichen: Der Bewertungs-Prompt
-erhält weiterhin jedes Transkript und jeden Laufstatus, aber Kandidaten-Refs werden durch
-neutrale Bezeichnungen wie `candidate-01` ersetzt; der Bericht ordnet die Ranglisten nach
-dem Parsen wieder den echten Refs zu.
-Kandidatenläufe verwenden standardmäßig `high` thinking, mit `xhigh` für OpenAI-Modelle,
-die dies unterstützen. Überschreiben Sie einen bestimmten Kandidaten inline mit
+Der Befehl führt lokale untergeordnete QA-Gateway-Prozesse aus, nicht Docker. Character-Eval-
+Szenarien sollten die Persona über `SOUL.md` setzen und dann gewöhnliche Benutzerinteraktionen
+wie Chat, Workspace-Hilfe und kleine Dateiaufgaben ausführen. Dem Kandidatenmodell
+sollte nicht gesagt werden, dass es bewertet wird. Der Befehl bewahrt jedes vollständige
+Transkript auf, erfasst grundlegende Laufstatistiken und bittet dann die Bewertungsmodelle im schnellen Modus mit
+`xhigh`-Reasoning, die Läufe nach Natürlichkeit, Stimmung und Humor zu ordnen.
+Verwenden Sie `--blind-judge-models`, wenn Sie Provider vergleichen: Der Bewertungs-Prompt erhält weiterhin
+jedes Transkript und jeden Laufstatus, aber Kandidaten-Referenzen werden durch neutrale
+Bezeichnungen wie `candidate-01` ersetzt; der Bericht ordnet die Rangfolgen nach dem
+Parsen wieder den echten Referenzen zu.
+Kandidatenläufe verwenden standardmäßig `high` Thinking, mit `xhigh` für OpenAI-Modelle, die dies
+unterstützen. Überschreiben Sie einen bestimmten Kandidaten inline mit
 `--model provider/model,thinking=<level>`. `--thinking <level>` setzt weiterhin einen
-globalen Fallback, und die ältere Form `--model-thinking <provider/model=level>` bleibt
-aus Kompatibilitätsgründen erhalten.
-OpenAI-Kandidaten-Refs verwenden standardmäßig den schnellen Modus, damit Prioritätsverarbeitung
-genutzt wird, sofern der Provider dies unterstützt. Fügen Sie inline `,fast`, `,no-fast`
-oder `,fast=false` hinzu, wenn ein einzelner Kandidat oder Bewertungsmodell eine
-Überschreibung benötigt. Übergeben Sie `--fast` nur, wenn Sie den schnellen Modus für jedes
-Kandidatenmodell erzwingen möchten. Kandidaten- und Bewertungsdauer werden im Bericht für
-Benchmark-Analysen erfasst, aber in den Bewertungs-Prompts wird ausdrücklich darauf
-hingewiesen, nicht nach Geschwindigkeit zu bewerten.
-Kandidaten- und Bewertungsmodellläufe verwenden beide standardmäßig eine Parallelität von 16.
-Senken Sie `--concurrency` oder `--judge-concurrency`, wenn Provider-Limits oder lokaler
-Gateway-Druck einen Lauf zu unruhig machen.
-Wenn kein Kandidaten-`--model` übergeben wird, verwendet character eval standardmäßig
+globalen Fallback, und die ältere Form `--model-thinking <provider/model=level>` bleibt aus
+Kompatibilitätsgründen erhalten.
+OpenAI-Kandidaten-Referenzen verwenden standardmäßig den schnellen Modus, sodass Prioritätsverarbeitung genutzt wird, wo
+der Provider dies unterstützt. Fügen Sie inline `,fast`, `,no-fast` oder `,fast=false` hinzu, wenn ein
+einzelner Kandidat oder Bewerter eine Überschreibung benötigt. Übergeben Sie `--fast` nur, wenn Sie
+den schnellen Modus für jedes Kandidatenmodell erzwingen möchten. Kandidaten- und Bewerterlaufzeiten werden
+für Benchmark-Analysen im Bericht aufgezeichnet, aber in den Bewertungs-Prompts wird ausdrücklich darauf hingewiesen,
+nicht nach Geschwindigkeit zu bewerten.
+Kandidaten- und Bewertungsmodellläufe verwenden standardmäßig beide eine Parallelität von 16. Verringern Sie
+`--concurrency` oder `--judge-concurrency`, wenn Provider-Limits oder lokaler Gateway-Druck einen Lauf zu unruhig machen.
+Wenn kein Kandidat mit `--model` übergeben wird, verwendet die Character-Eval standardmäßig
 `openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
 `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
 `moonshot/kimi-k2.5` und
 `google/gemini-3.1-pro-preview`, wenn kein `--model` übergeben wird.
-Wenn kein `--judge-model` übergeben wird, verwenden die Bewertungsmodelle standardmäßig
+Wenn kein `--judge-model` übergeben wird, verwenden die Bewerter standardmäßig
 `openai/gpt-5.4,thinking=xhigh,fast` und
 `anthropic/claude-opus-4-6,thinking=high`.