From 241d2273caabcf61093de4cf9d3a3b207f566494 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Mon, 13 Apr 2026 06:33:09 +0000 Subject: [PATCH] chore(i18n): refresh de translations --- docs/de/concepts/qa-e2e-automation.md | 227 ++++---- docs/de/help/testing.md | 756 ++++++++++++++------------ 2 files changed, 522 insertions(+), 461 deletions(-) diff --git a/docs/de/concepts/qa-e2e-automation.md b/docs/de/concepts/qa-e2e-automation.md index f3f8c8018..44f1c9218 100644 --- a/docs/de/concepts/qa-e2e-automation.md +++ b/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 `, 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. +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 `, 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. -## Repo-gestützte Seeds +## Repository-gestützte Seeds -Seed-Assets befinden sich in `qa/`: +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=`. `--thinking ` setzt weiterhin einen -globalen Fallback, und die ältere Form `--model-thinking ` 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 ` 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`. diff --git a/docs/de/help/testing.md b/docs/de/help/testing.md index 1e721aa7f..127f0032b 100644 --- a/docs/de/help/testing.md +++ b/docs/de/help/testing.md @@ -2,143 +2,213 @@ read_when: - Tests lokal oder in CI ausführen - Regressionstests für Modell-/Provider-Fehler hinzufügen - - Gateway- und Agent-Verhalten debuggen -summary: 'Test-Kit: Unit-/E2E-/Live-Suiten, Docker-Runner und was jeder Test abdeckt' + - Fehlersuche bei Gateway- und Agentenverhalten +summary: 'Test-Kit: Unit-/E2E-/Live-Suites, Docker-Runner und was jeder Test abdeckt' title: Testen x-i18n: - generated_at: "2026-04-12T23:28:34Z" + generated_at: "2026-04-13T06:29:38Z" model: gpt-5.4 provider: openai - source_hash: a66ea672c386094ab4a8035a082c8a85d508a14301ad44b628d2a10d9cec3a52 + source_hash: 3db91b4bc36f626cd014958ec66b08b9cecd9faaa20a5746cd3a49ad4b0b1c38 source_path: help/testing.md workflow: 15 --- # Testen -OpenClaw hat drei Vitest-Suiten (Unit/Integration, E2E, Live) und eine kleine Gruppe von Docker-Runnern. +OpenClaw hat drei Vitest-Suites (Unit/Integration, E2E, Live) und eine kleine Gruppe von Docker-Runnern. -Dieses Dokument ist ein Leitfaden dazu, „wie wir testen“: +Dieses Dokument ist ein Leitfaden dazu, **wie wir testen**: - Was jede Suite abdeckt (und was sie bewusst _nicht_ abdeckt) -- Welche Befehle Sie für typische Workflows ausführen sollten (lokal, vor dem Push, Debugging) -- Wie Live-Tests Credentials erkennen und Modelle/Provider auswählen -- Wie Sie Regressionen für reale Modell-/Provider-Probleme hinzufügen +- Welche Befehle Sie für gängige Workflows ausführen sollten (lokal, vor dem Push, Debugging) +- Wie Live-Tests Anmeldedaten erkennen und Modelle/Provider auswählen +- Wie Sie Regressionstests für reale Modell-/Provider-Probleme hinzufügen ## Schnellstart An den meisten Tagen: -- Vollständiges Gate (vor dem Push erwartet): `pnpm build && pnpm check && pnpm test` +- Vollständige Prüfkette (vor dem Push erwartet): `pnpm build && pnpm check && pnpm test` - Schnellere lokale Ausführung der vollständigen Suite auf einer leistungsfähigen Maschine: `pnpm test:max` - Direkte Vitest-Watch-Schleife: `pnpm test:watch` - Direktes Targeting von Dateien leitet jetzt auch Pfade für Erweiterungen/Kanäle weiter: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Bevorzugen Sie zunächst gezielte Ausführungen, wenn Sie an einem einzelnen Fehler iterieren. +- Bevorzugen Sie zuerst gezielte Ausführungen, wenn Sie an einem einzelnen Fehler arbeiten. - Docker-gestützte QA-Site: `pnpm qa:lab:up` - Linux-VM-gestützte QA-Lane: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Wenn Sie Tests anfassen oder zusätzliche Sicherheit möchten: +Wenn Sie Tests ändern oder zusätzliche Sicherheit möchten: -- Coverage-Gate: `pnpm test:coverage` +- Coverage-Prüfkette: `pnpm test:coverage` - E2E-Suite: `pnpm test:e2e` -Beim Debuggen echter Provider/Modelle (erfordert echte Credentials): +Beim Debuggen realer Provider/Modelle (erfordert echte Anmeldedaten): - Live-Suite (Modelle + Gateway-Tool-/Bild-Probes): `pnpm test:live` -- Eine einzelne Live-Datei ohne viel Ausgabe gezielt ausführen: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Eine einzelne Live-Datei ohne viel Ausgabe ausführen: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -Tipp: Wenn Sie nur einen einzelnen fehlschlagenden Fall brauchen, sollten Sie Live-Tests bevorzugt über die unten beschriebenen Allowlist-Umgebungsvariablen eingrenzen. +Tipp: Wenn Sie nur einen einzelnen fehlgeschlagenen Fall brauchen, grenzen Sie Live-Tests bevorzugt über die unten beschriebenen Allowlist-Umgebungsvariablen ein. ## QA-spezifische Runner -Diese Befehle stehen neben den Haupttest-Suiten zur Verfügung, wenn Sie die Realitätsnähe von qa-lab benötigen: +Diese Befehle stehen neben den Haupt-Test-Suites zur Verfügung, wenn Sie den Realismus von QA-Lab benötigen: - `pnpm openclaw qa suite` - Führt repo-gestützte QA-Szenarien direkt auf dem Host aus. - - Führt standardmäßig mehrere ausgewählte Szenarien parallel mit isolierten - Gateway-Workern aus, bis zu 64 Worker oder die Anzahl der ausgewählten Szenarien. Verwenden Sie - `--concurrency `, um die Anzahl der Worker anzupassen, oder `--concurrency 1` für - die ältere serielle Lane. + - Führt standardmäßig mehrere ausgewählte Szenarien parallel mit isolierten Gateway-Workern aus, bis zu 64 Worker oder die Anzahl der ausgewählten Szenarien. Verwenden Sie `--concurrency `, um die Anzahl der Worker anzupassen, oder `--concurrency 1` für die ältere serielle Lane. - `pnpm openclaw qa suite --runner multipass` - - Führt dieselbe QA-Suite in einer kurzlebigen Multipass-Linux-VM aus. - - Behält dasselbe Verhalten für die Szenarienauswahl wie `qa suite` auf dem Host bei. - - Verwendet dieselben Flags zur Provider-/Modellauswahl wie `qa suite`. + - Führt dieselbe QA-Suite innerhalb einer kurzlebigen Multipass-Linux-VM aus. + - Behält dasselbe Verhalten bei der Szenarioauswahl wie `qa suite` auf dem Host bei. + - Verwendet dieselben Provider-/Modellauswahl-Flags wie `qa suite`. - Live-Ausführungen leiten die unterstützten QA-Auth-Eingaben weiter, die für den Gast praktikabel sind: - umgebungsbasierte Provider-Schlüssel, den Konfigurationspfad für den QA-Live-Provider und `CODEX_HOME`, - falls vorhanden. - - Ausgabeverzeichnisse müssen unterhalb des Repo-Roots bleiben, damit der Gast über - den eingebundenen Workspace zurückschreiben kann. + env-basierte Provider-Schlüssel, der QA-Live-Provider-Konfigurationspfad und `CODEX_HOME`, falls vorhanden. + - Ausgabeverzeichnisse müssen unter dem Repo-Root bleiben, damit der Gast über den eingebundenen Workspace zurückschreiben kann. - Schreibt den normalen QA-Bericht + die Zusammenfassung sowie Multipass-Logs unter `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Startet die Docker-gestützte QA-Site für operator-artige QA-Arbeit. + - Startet die Docker-gestützte QA-Site für operatorähnliche QA-Arbeit. - `pnpm openclaw qa matrix` - Führt die Matrix-Live-QA-Lane gegen einen kurzlebigen, Docker-gestützten Tuwunel-Homeserver aus. - - Richtet drei temporäre Matrix-Benutzer (`driver`, `sut`, `observer`) sowie einen privaten Raum ein und startet dann einen QA-Gateway-Child mit dem echten Matrix-Plugin als SUT-Transport. - - Verwendet standardmäßig das angeheftete stabile Tuwunel-Image `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Überschreiben Sie dies mit `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, wenn Sie ein anderes Image testen müssen. - - Schreibt einen Matrix-QA-Bericht, eine Zusammenfassung und ein Artifact mit beobachteten Ereignissen unter `.artifacts/qa-e2e/...`. + - Stellt drei temporäre Matrix-Benutzer (`driver`, `sut`, `observer`) sowie einen privaten Raum bereit und startet dann ein untergeordnetes QA-Gateway mit dem echten Matrix-Plugin als SUT-Transport. + - Verwendet standardmäßig das angeheftete stabile Tuwunel-Image `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Überschreiben Sie es mit `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, wenn Sie ein anderes Image testen müssen. + - Matrix unterstützt derzeit nur `--credential-source env`, da die Lane temporäre Benutzer lokal bereitstellt. + - Schreibt einen Matrix-QA-Bericht, eine Zusammenfassung und ein Observed-Events-Artefakt unter `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Führt die Telegram-Live-QA-Lane gegen eine echte private Gruppe aus, wobei die Driver- und SUT-Bot-Tokens aus der Umgebung verwendet werden. + - Führt die Telegram-Live-QA-Lane gegen eine echte private Gruppe aus, wobei die Bot-Tokens für Driver und SUT aus den Umgebungsvariablen stammen. - Erfordert `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` und `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Die Gruppen-ID muss die numerische Telegram-Chat-ID sein. + - Unterstützt `--credential-source convex` für gemeinsam genutzte gepoolte Anmeldedaten. Verwenden Sie standardmäßig den env-Modus oder setzen Sie `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, um gepoolte Leases zu verwenden. - Erfordert zwei unterschiedliche Bots in derselben privaten Gruppe, wobei der SUT-Bot einen Telegram-Benutzernamen bereitstellen muss. - - Für stabile Bot-zu-Bot-Beobachtung aktivieren Sie in `@BotFather` den Modus für Bot-zu-Bot-Kommunikation für beide Bots und stellen Sie sicher, dass der Driver-Bot den Bot-Verkehr in der Gruppe beobachten kann. - - Schreibt einen Telegram-QA-Bericht, eine Zusammenfassung und ein Artifact mit beobachteten Nachrichten unter `.artifacts/qa-e2e/...`. + - Für stabile Bot-zu-Bot-Beobachtung aktivieren Sie in `@BotFather` für beide Bots den Bot-to-Bot Communication Mode und stellen Sie sicher, dass der Driver-Bot Bot-Datenverkehr in der Gruppe beobachten kann. + - Schreibt einen Telegram-QA-Bericht, eine Zusammenfassung und ein Observed-Messages-Artefakt unter `.artifacts/qa-e2e/...`. -Live-Transport-Lanes teilen sich einen einheitlichen Standardvertrag, damit neue Transporte nicht auseinanderdriften: +Live-Transport-Lanes teilen sich einen Standardvertrag, damit neue Transporte nicht auseinanderdriften: `qa-channel` bleibt die breite synthetische QA-Suite und ist nicht Teil der Live-Transport-Abdeckungsmatrix. -| Lane | Canary | Mention-Gating | Allowlist-Block | Antwort auf oberster Ebene | Fortsetzen nach Neustart | Thread-Follow-up | Thread-Isolation | Reaktionsbeobachtung | Help-Befehl | -| -------- | ------ | -------------- | --------------- | -------------------------- | ------------------------ | ---------------- | ---------------- | -------------------- | ----------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Lane | Canary | Mention gating | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help-Befehl | +| -------- | ------ | -------------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | + +### Gemeinsam genutzte Telegram-Anmeldedaten über Convex (v1) + +Wenn `--credential-source convex` (oder `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) für +`openclaw qa telegram` aktiviert ist, bezieht QA lab ein exklusives Lease aus einem Convex-gestützten Pool, sendet Heartbeat-Signale für dieses Lease, während die Lane läuft, und gibt das Lease beim Herunterfahren frei. + +Referenzgerüst für ein Convex-Projekt: + +- `qa/convex-credential-broker/` + +Erforderliche Umgebungsvariablen: + +- `OPENCLAW_QA_CONVEX_SITE_URL` (zum Beispiel `https://your-deployment.convex.site`) +- Ein Secret für die ausgewählte Rolle: + - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` für `maintainer` + - `OPENCLAW_QA_CONVEX_SECRET_CI` für `ci` +- Auswahl der Anmeldedatenrolle: + - CLI: `--credential-role maintainer|ci` + - Env-Standardwert: `OPENCLAW_QA_CREDENTIAL_ROLE` (Standard ist `maintainer`) + +Optionale Umgebungsvariablen: + +- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (Standard `1200000`) +- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (Standard `30000`) +- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (Standard `90000`) +- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (Standard `15000`) +- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (Standard `/qa-credentials/v1`) +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (optionale Trace-ID) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` erlaubt loopback-`http://`-Convex-URLs nur für lokale Entwicklung. + +`OPENCLAW_QA_CONVEX_SITE_URL` sollte im normalen Betrieb `https://` verwenden. + +Maintainer-Admin-Befehle (Pool add/remove/list) erfordern ausdrücklich +`OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. + +CLI-Hilfsbefehle für Maintainer: + +```bash +pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json +pnpm openclaw qa credentials list --kind telegram +pnpm openclaw qa credentials remove --credential-id +``` + +Verwenden Sie `--json` für maschinenlesbare Ausgabe in Skripten und CI-Hilfsprogrammen. + +Standard-Endpoint-Vertrag (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): + +- `POST /acquire` + - Anfrage: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` + - Erfolg: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` + - Erschöpft/wiederholbar: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` +- `POST /heartbeat` + - Anfrage: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` + - Erfolg: `{ status: "ok" }` (oder leeres `2xx`) +- `POST /release` + - Anfrage: `{ kind, ownerId, actorRole, credentialId, leaseToken }` + - Erfolg: `{ status: "ok" }` (oder leeres `2xx`) +- `POST /admin/add` (nur mit Maintainer-Secret) + - Anfrage: `{ kind, actorId, payload, note?, status? }` + - Erfolg: `{ status: "ok", credential }` +- `POST /admin/remove` (nur mit Maintainer-Secret) + - Anfrage: `{ credentialId, actorId }` + - Erfolg: `{ status: "ok", changed, credential }` + - Schutz bei aktivem Lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (nur mit Maintainer-Secret) + - Anfrage: `{ kind?, status?, includePayload?, limit? }` + - Erfolg: `{ status: "ok", credentials, count }` + +Payload-Form für den Telegram-Typ: + +- `{ groupId: string, driverToken: string, sutToken: string }` +- `groupId` muss eine numerische Telegram-Chat-ID als String sein. +- `admin/add` validiert diese Form für `kind: "telegram"` und weist fehlerhafte Payloads zurück. ### Einen Kanal zu QA hinzufügen Das Hinzufügen eines Kanals zum Markdown-QA-System erfordert genau zwei Dinge: 1. Einen Transport-Adapter für den Kanal. -2. Ein Szenario-Paket, das den Kanalvertrag ausübt. +2. Ein Szenario-Pack, das den Kanalvertrag testet. Fügen Sie keinen kanalspezifischen QA-Runner hinzu, wenn der gemeinsame `qa-lab`-Runner den Ablauf übernehmen kann. -`qa-lab` ist für die gemeinsamen Mechanismen zuständig: +`qa-lab` verwaltet die gemeinsamen Mechanismen: -- Starten und Beenden der Suite -- Worker-Parallelität -- Schreiben von Artifacts -- Berichtserstellung -- Szenarioausführung -- Kompatibilitäts-Aliasse für ältere `qa-channel`-Szenarien +- Start und Beendigung der Suite +- Worker-Konkurrenz +- Schreiben von Artefakten +- Berichtsgenerierung +- Ausführung von Szenarien +- Kompatibilitätsaliase für ältere `qa-channel`-Szenarien -Der Kanal-Adapter ist für den Transportvertrag zuständig: +Der Kanal-Adapter verwaltet den Transportvertrag: - wie das Gateway für diesen Transport konfiguriert wird -- wie die Bereitschaft geprüft wird +- wie Bereitschaft geprüft wird - wie eingehende Ereignisse injiziert werden - wie ausgehende Nachrichten beobachtet werden - wie Transkripte und normalisierter Transportzustand bereitgestellt werden - wie transportgestützte Aktionen ausgeführt werden -- wie transportspezifisches Zurücksetzen oder Aufräumen behandelt wird +- wie transportspezifisches Zurücksetzen oder Bereinigen gehandhabt wird Die Mindestanforderung für die Einführung eines neuen Kanals ist: -1. Implementieren Sie den Transport-Adapter auf der gemeinsamen `qa-lab`-Nahtstelle. +1. Implementieren Sie den Transport-Adapter auf der gemeinsamen `qa-lab`-Schnittstelle. 2. Registrieren Sie den Adapter in der Transport-Registry. -3. Belassen Sie transportspezifische Mechaniken im Adapter oder im Kanal-Harness. -4. Verfassen oder passen Sie Markdown-Szenarien unter `qa/scenarios/` an. -5. Verwenden Sie die generischen Szenario-Helfer für neue Szenarien. -6. Halten Sie bestehende Kompatibilitäts-Aliasse funktionsfähig, sofern das Repo keine beabsichtigte Migration durchführt. +3. Belassen Sie transportspezifische Mechanismen im Adapter oder im Kanal-Harness. +4. Erstellen oder passen Sie Markdown-Szenarien unter `qa/scenarios/` an. +5. Verwenden Sie die generischen Szenario-Hilfsfunktionen für neue Szenarien. +6. Halten Sie vorhandene Kompatibilitätsaliase funktionsfähig, sofern das Repo keine absichtliche Migration durchführt. Die Entscheidungsregel ist strikt: -- Wenn sich ein Verhalten einmalig in `qa-lab` ausdrücken lässt, platzieren Sie es in `qa-lab`. -- Wenn ein Verhalten von einem Kanaltransport abhängt, belassen Sie es in diesem Adapter oder Plugin-Harness. -- Wenn ein Szenario eine neue Fähigkeit benötigt, die mehr als ein Kanal verwenden kann, fügen Sie einen generischen Helfer hinzu statt eines kanalspezifischen Zweigs in `suite.ts`. +- Wenn ein Verhalten einmalig in `qa-lab` ausgedrückt werden kann, gehört es in `qa-lab`. +- Wenn ein Verhalten von einem einzelnen Kanaltransport abhängt, belassen Sie es in diesem Adapter oder Plugin-Harness. +- Wenn ein Szenario eine neue Fähigkeit benötigt, die von mehr als einem Kanal genutzt werden kann, fügen Sie eine generische Hilfsfunktion hinzu statt einer kanalspezifischen Verzweigung in `suite.ts`. - Wenn ein Verhalten nur für einen Transport sinnvoll ist, halten Sie das Szenario transportspezifisch und machen Sie das im Szenariovertrag explizit. -Bevorzugte generische Helfernamen für neue Szenarien sind: +Bevorzugte generische Hilfsnamen für neue Szenarien sind: - `waitForTransportReady` - `waitForChannelReady` @@ -153,7 +223,7 @@ Bevorzugte generische Helfernamen für neue Szenarien sind: - `formatTransportTranscript` - `resetTransport` -Kompatibilitäts-Aliasse bleiben für bestehende Szenarien verfügbar, darunter: +Kompatibilitätsaliase bleiben für bestehende Szenarien verfügbar, darunter: - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -161,80 +231,77 @@ Kompatibilitäts-Aliasse bleiben für bestehende Szenarien verfügbar, darunter: - `formatConversationTranscript` - `resetBus` -Neue Kanalarbeit sollte die generischen Helfernamen verwenden. -Kompatibilitäts-Aliasse existieren, um eine Flag-Day-Migration zu vermeiden, nicht als Modell für +Neue Kanalarbeit sollte die generischen Hilfsnamen verwenden. +Kompatibilitätsaliase existieren, um eine Flag-Day-Migration zu vermeiden, nicht als Modell für das Verfassen neuer Szenarien. -## Test-Suiten (was wo läuft) +## Test-Suites (was wo ausgeführt wird) -Betrachten Sie die Suiten als „zunehmenden Realismus“ (und zunehmende Instabilität/Kosten): +Stellen Sie sich die Suites als „zunehmenden Realismus“ vor (und zunehmende Flakiness/Kosten): ### Unit / Integration (Standard) - Befehl: `pnpm test` -- Konfiguration: zehn sequenzielle Shard-Läufe (`vitest.full-*.config.ts`) über die vorhandenen eingegrenzten Vitest-Projekte -- Dateien: Core-/Unit-Inventare unter `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` sowie die auf der Allowlist stehenden `ui`-Node-Tests, die von `vitest.unit.config.ts` abgedeckt werden +- Konfiguration: zehn sequentielle Shard-Läufe (`vitest.full-*.config.ts`) über die vorhandenen eingegrenzten Vitest-Projekte +- Dateien: Core-/Unit-Inventare unter `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` sowie die in `vitest.unit.config.ts` auf die Allowlist gesetzten `ui`-Node-Tests - Umfang: - Reine Unit-Tests - - In-Process-Integrationstests (Gateway-Auth, Routing, Tooling, Parsing, Konfiguration) - - Deterministische Regressionen für bekannte Fehler + - In-Process-Integrationstests (Gateway-Authentifizierung, Routing, Tooling, Parsing, Konfiguration) + - Deterministische Regressionstests für bekannte Fehler - Erwartungen: - Läuft in CI - Keine echten Schlüssel erforderlich - Sollte schnell und stabil sein - Hinweis zu Projekten: - - Nicht gezieltes `pnpm test` führt jetzt elf kleinere Shard-Konfigurationen (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) statt eines einzigen riesigen nativen Root-Projekt-Prozesses aus. Das senkt die maximale RSS auf ausgelasteten Maschinen und verhindert, dass Arbeiten an `auto-reply`/Erweiterungen nicht zusammenhängende Suiten ausbremsen. - - `pnpm test --watch` verwendet weiterhin den nativen Root-`vitest.config.ts`-Projektgraphen, weil eine Multi-Shard-Watch-Schleife nicht praktikabel ist. - - `pnpm test`, `pnpm test:watch` und `pnpm test:perf:imports` leiten explizite Datei-/Verzeichnisziele jetzt zuerst durch eingegrenzte Lanes, sodass `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` nicht den vollen Startup-Aufwand des Root-Projekts bezahlen muss. - - `pnpm test:changed` erweitert geänderte Git-Pfade auf dieselben eingegrenzten Lanes, wenn der Diff nur routbare Quell-/Testdateien berührt; Änderungen an Konfiguration/Setup fallen weiterhin auf die breite Wiederholung des Root-Projekts zurück. - - Import-leichte Unit-Tests aus Agents, Commands, Plugins, `auto-reply`-Hilfsmodulen, `plugin-sdk` und ähnlichen reinen Utility-Bereichen werden durch die `unit-fast`-Lane geleitet, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete/laufzeitschwere Dateien bleiben auf den vorhandenen Lanes. - - Ausgewählte `plugin-sdk`- und `commands`-Hilfsquelldateien ordnen Läufe im Changed-Modus in diesen leichten Lanes auch explizit benachbarten Tests zu, sodass Hilfsmodul-Änderungen nicht die gesamte schwere Suite für dieses Verzeichnis erneut ausführen. - - `auto-reply` hat jetzt drei dedizierte Buckets: Top-Level-Core-Hilfsfunktionen, Top-Level-`reply.*`-Integrationstests und den Teilbaum `src/auto-reply/reply/**`. Dadurch bleibt die schwerste Reply-Harness-Arbeit von den günstigen Status-/Chunk-/Token-Tests getrennt. + - Nicht zielgerichtetes `pnpm test` führt jetzt elf kleinere Shard-Konfigurationen (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) anstelle eines einzigen riesigen nativen Root-Project-Prozesses aus. Das reduziert den Spitzen-RSS auf ausgelasteten Maschinen und verhindert, dass `auto-reply`-/Erweiterungsarbeit unabhängige Suites ausbremst. + - `pnpm test --watch` verwendet weiterhin den nativen Root-`vitest.config.ts`-Projektgraphen, da eine Multi-Shard-Watch-Schleife nicht praktikabel ist. + - `pnpm test`, `pnpm test:watch` und `pnpm test:perf:imports` leiten explizite Datei-/Verzeichnis-Targets jetzt zuerst durch eingegrenzte Lanes, sodass `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` nicht den Startup-Overhead des vollständigen Root-Projekts bezahlen muss. + - `pnpm test:changed` erweitert geänderte Git-Pfade in dieselben eingegrenzten Lanes, wenn der Diff nur routbare Quell-/Testdateien berührt; Änderungen an Konfiguration/Setup fallen weiterhin auf einen breiten erneuten Root-Project-Lauf zurück. + - Import-leichte Unit-Tests aus `agents`, `commands`, Plugins, `auto-reply`-Hilfsfunktionen, `plugin-sdk` und ähnlichen reinen Utility-Bereichen laufen über die `unit-fast`-Lane, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete/runtime-lastige Dateien bleiben auf den bestehenden Lanes. + - Ausgewählte `plugin-sdk`- und `commands`-Hilfsquelldateien ordnen Läufe im Changed-Modus ebenfalls expliziten Nachbartests in diesen leichten Lanes zu, damit Hilfsänderungen nicht die vollständige schwere Suite für dieses Verzeichnis erneut ausführen müssen. + - `auto-reply` hat jetzt drei dedizierte Buckets: Core-Hilfsfunktionen auf oberster Ebene, Integrations-Tests der obersten Ebene `reply.*` und den Teilbaum `src/auto-reply/reply/**`. So bleibt die schwerste Reply-Harness-Arbeit von günstigen Status-/Chunk-/Token-Tests getrennt. - Hinweis zum eingebetteten Runner: - - Wenn Sie Discovery-Eingaben für Nachrichtentools oder den Laufzeitkontext von Compaction ändern, - halten Sie beide Abdeckungsebenen bei. - - Fügen Sie fokussierte Hilfsmodul-Regressionen für reine Routing-/Normalisierungsgrenzen hinzu. - - Halten Sie außerdem die eingebetteten Runner-Integrationssuiten funktionsfähig: + - Wenn Sie Eingaben für die Discovery von Message-Tools oder den Laufzeitkontext von Compaction ändern, halten Sie beide Abdeckungsebenen intakt. + - Fügen Sie fokussierte Hilfs-Regressionstests für reine Routing-/Normalisierungsgrenzen hinzu. + - Halten Sie außerdem die Integrations-Suites des eingebetteten Runners gesund: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` und `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Diese Suiten verifizieren, dass eingegrenzte IDs und Compaction-Verhalten weiterhin - durch die echten Pfade `run.ts` / `compact.ts` fließen; reine Hilfsmodul-Tests sind - kein ausreichender Ersatz für diese Integrationspfade. + - Diese Suites verifizieren, dass eingegrenzte IDs und Compaction-Verhalten weiterhin durch die echten Pfade `run.ts` / `compact.ts` fließen; reine Hilfstests sind kein ausreichender Ersatz für diese Integrationspfade. - Hinweis zum Pool: - Die Basis-Vitest-Konfiguration verwendet jetzt standardmäßig `threads`. - - Die gemeinsame Vitest-Konfiguration setzt außerdem `isolate: false` fest und verwendet den nicht isolierten Runner über die Root-Projekte, E2E- und Live-Konfigurationen hinweg. + - Die gemeinsame Vitest-Konfiguration setzt außerdem fest `isolate: false` und verwendet den nicht isolierten Runner über die Root-Projekte sowie die E2E- und Live-Konfigurationen hinweg. - Die Root-UI-Lane behält ihr `jsdom`-Setup und ihren Optimizer bei, läuft jetzt aber ebenfalls auf dem gemeinsamen nicht isolierten Runner. - Jeder `pnpm test`-Shard erbt dieselben Standardwerte `threads` + `isolate: false` aus der gemeinsamen Vitest-Konfiguration. - - Der gemeinsame Launcher `scripts/run-vitest.mjs` fügt jetzt standardmäßig auch `--no-maglev` für Vitest-Child-Node-Prozesse hinzu, um V8-Kompilierungsaufwand bei großen lokalen Läufen zu reduzieren. Setzen Sie `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, wenn Sie mit dem Standardverhalten von V8 vergleichen möchten. + - Der gemeinsame Launcher `scripts/run-vitest.mjs` fügt für Vitest-Child-Node-Prozesse jetzt standardmäßig außerdem `--no-maglev` hinzu, um V8-Kompilierungs-Churn bei großen lokalen Läufen zu reduzieren. Setzen Sie `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, wenn Sie mit dem Standardverhalten von V8 vergleichen müssen. - Hinweis zur schnellen lokalen Iteration: - - `pnpm test:changed` leitet durch eingegrenzte Lanes, wenn sich die geänderten Pfade sauber einer kleineren Suite zuordnen lassen. + - `pnpm test:changed` läuft durch eingegrenzte Lanes, wenn die geänderten Pfade sauber auf eine kleinere Suite abgebildet werden können. - `pnpm test:max` und `pnpm test:changed:max` behalten dasselbe Routing-Verhalten bei, nur mit einer höheren Worker-Obergrenze. - - Die automatische lokale Worker-Skalierung ist jetzt bewusst konservativ und fährt auch dann zurück, wenn die Host-Load-Average bereits hoch ist, sodass mehrere gleichzeitige Vitest-Läufe standardmäßig weniger Schaden anrichten. - - Die Basis-Vitest-Konfiguration markiert die Projekte/Konfigurationsdateien als `forceRerunTriggers`, damit Wiederholungen im Changed-Modus korrekt bleiben, wenn sich das Test-Wiring ändert. - - Die Konfiguration lässt `OPENCLAW_VITEST_FS_MODULE_CACHE` auf unterstützten Hosts aktiviert; setzen Sie `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, wenn Sie einen expliziten Cache-Pfad für direktes Profiling möchten. + - Die automatische lokale Worker-Skalierung ist jetzt bewusst konservativ und fährt auch zurück, wenn die Last auf dem Host bereits hoch ist, sodass mehrere gleichzeitige Vitest-Läufe standardmäßig weniger Schaden anrichten. + - Die Basis-Vitest-Konfiguration markiert die Projekte/Konfigurationsdateien als `forceRerunTriggers`, damit erneute Läufe im Changed-Modus korrekt bleiben, wenn sich die Testverdrahtung ändert. + - Die Konfiguration lässt `OPENCLAW_VITEST_FS_MODULE_CACHE` auf unterstützten Hosts aktiviert; setzen Sie `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, wenn Sie einen expliziten Cache-Speicherort für direktes Profiling möchten. - Hinweis zum Performance-Debugging: - - `pnpm test:perf:imports` aktiviert die Berichterstattung zu Vitest-Importdauer sowie die Ausgabe der Import-Aufschlüsselung. - - `pnpm test:perf:imports:changed` begrenzt dieselbe Profiling-Ansicht auf Dateien, die seit `origin/main` geändert wurden. -- `pnpm test:perf:changed:bench -- --ref ` vergleicht das geroutete `test:changed` mit dem nativen Root-Projekt-Pfad für diesen festgeschriebenen Diff und gibt Wall-Time sowie macOS-Max-RSS aus. -- `pnpm test:perf:changed:bench -- --worktree` benchmarkt den aktuellen verschmutzten Tree, indem die Liste geänderter Dateien durch `scripts/test-projects.mjs` und die Root-Vitest-Konfiguration geroutet wird. - - `pnpm test:perf:profile:main` schreibt ein CPU-Profil des Main-Threads für Vitest/Vite-Startup und Transform-Overhead. - - `pnpm test:perf:profile:runner` schreibt CPU-+Heap-Profile des Runners für die Unit-Suite bei deaktivierter Dateiparallelität. + - `pnpm test:perf:imports` aktiviert Berichte zur Vitest-Importdauer sowie Ausgaben zur Import-Aufschlüsselung. + - `pnpm test:perf:imports:changed` grenzt dieselbe Profiling-Ansicht auf seit `origin/main` geänderte Dateien ein. +- `pnpm test:perf:changed:bench -- --ref ` vergleicht geroutetes `test:changed` mit dem nativen Root-Project-Pfad für diesen festgeschriebenen Diff und gibt Wall Time sowie den maximalen RSS unter macOS aus. +- `pnpm test:perf:changed:bench -- --worktree` benchmarkt den aktuellen veränderten Baum, indem die Liste der geänderten Dateien durch `scripts/test-projects.mjs` und die Root-Vitest-Konfiguration geroutet wird. + - `pnpm test:perf:profile:main` schreibt ein CPU-Profil des Hauptthreads für Vitest-/Vite-Startup- und Transform-Overhead. + - `pnpm test:perf:profile:runner` schreibt CPU- und Heap-Profile des Runners für die Unit-Suite bei deaktivierter Dateiparallelität. ### E2E (Gateway-Smoke) - Befehl: `pnpm test:e2e` - Konfiguration: `vitest.e2e.config.ts` - Dateien: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` -- Laufzeitstandardwerte: - - Verwendet Vitest `threads` mit `isolate: false`, passend zum Rest des Repos. +- Laufzeit-Standardwerte: + - Verwendet Vitest-`threads` mit `isolate: false`, passend zum Rest des Repos. - Verwendet adaptive Worker (CI: bis zu 2, lokal: standardmäßig 1). - - Läuft standardmäßig im Silent-Modus, um den Overhead durch Konsolen-I/O zu reduzieren. + - Läuft standardmäßig im Silent-Modus, um den Console-I/O-Overhead zu reduzieren. - Nützliche Überschreibungen: - `OPENCLAW_E2E_WORKERS=`, um die Anzahl der Worker zu erzwingen (begrenzt auf 16). - `OPENCLAW_E2E_VERBOSE=1`, um ausführliche Konsolenausgabe wieder zu aktivieren. - Umfang: - - End-to-End-Verhalten von Gateway mit mehreren Instanzen + - End-to-End-Verhalten von Gateway-Mehrfachinstanzen - WebSocket-/HTTP-Oberflächen, Node-Pairing und schwereres Networking - Erwartungen: - Läuft in CI (wenn in der Pipeline aktiviert) @@ -246,134 +313,134 @@ Betrachten Sie die Suiten als „zunehmenden Realismus“ (und zunehmende Instab - Befehl: `pnpm test:e2e:openshell` - Datei: `test/openshell-sandbox.e2e.test.ts` - Umfang: - - Startet ein isoliertes OpenShell-Gateway auf dem Host über Docker + - Startet über Docker ein isoliertes OpenShell-Gateway auf dem Host - Erstellt eine Sandbox aus einem temporären lokalen Dockerfile - - Übt OpenClaws OpenShell-Backend über echtes `sandbox ssh-config` + SSH-Exec aus - - Verifiziert remote-kanonisches Dateisystemverhalten über die Sandbox-FS-Bridge + - Testet das OpenShell-Backend von OpenClaw über echtes `sandbox ssh-config` + SSH-Exec + - Verifiziert Remote-Canonical-Dateisystemverhalten über die Sandbox-FS-Bridge - Erwartungen: - - Nur opt-in; nicht Teil des standardmäßigen Laufs `pnpm test:e2e` - - Erfordert ein lokales `openshell`-CLI sowie einen funktionierenden Docker-Daemon - - Verwendet isoliertes `HOME` / `XDG_CONFIG_HOME` und zerstört dann Test-Gateway und Sandbox + - Nur Opt-in; nicht Teil des standardmäßigen Laufs `pnpm test:e2e` + - Erfordert eine lokale `openshell`-CLI sowie einen funktionierenden Docker-Daemon + - Verwendet isolierte Verzeichnisse `HOME` / `XDG_CONFIG_HOME` und zerstört anschließend das Test-Gateway und die Sandbox - Nützliche Überschreibungen: - `OPENCLAW_E2E_OPENSHELL=1`, um den Test zu aktivieren, wenn die breitere E2E-Suite manuell ausgeführt wird - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, um auf eine nicht standardmäßige CLI-Binärdatei oder ein Wrapper-Skript zu verweisen -### Live (echte Provider + echte Modelle) +### Live (reale Provider + reale Modelle) - Befehl: `pnpm test:live` - Konfiguration: `vitest.live.config.ts` - Dateien: `src/**/*.live.test.ts` -- Standard: **aktiviert** durch `pnpm test:live` (setzt `OPENCLAW_LIVE_TEST=1`) +- Standard: durch `pnpm test:live` **aktiviert** (setzt `OPENCLAW_LIVE_TEST=1`) - Umfang: - - „Funktioniert dieser Provider/dieses Modell _heute_ tatsächlich mit echten Credentials?“ - - Erkennt Provider-Formatänderungen, Tool-Calling-Eigenheiten, Auth-Probleme und Verhalten bei Rate Limits + - „Funktioniert dieser Provider/dieses Modell _heute_ tatsächlich mit echten Anmeldedaten?“ + - Erkennt Änderungen am Provider-Format, Tool-Calling-Besonderheiten, Auth-Probleme und Rate-Limit-Verhalten - Erwartungen: - - Bewusst nicht CI-stabil (echte Netzwerke, echte Provider-Richtlinien, Quoten, Ausfälle) + - Von Natur aus nicht CI-stabil (echte Netzwerke, echte Provider-Richtlinien, Quoten, Ausfälle) - Kostet Geld / verbraucht Rate Limits - - Bevorzugen Sie eingegrenzte Teilmengen statt „alles“ -- Live-Läufe sourcen `~/.profile`, um fehlende API-Schlüssel aufzugreifen. + - Führen Sie bevorzugt eingegrenzte Teilmengen statt „alles“ aus +- Live-Läufe sourcen `~/.profile`, um fehlende API-Schlüssel zu übernehmen. - Standardmäßig isolieren Live-Läufe weiterhin `HOME` und kopieren Konfigurations-/Auth-Material in ein temporäres Test-Home, damit Unit-Fixtures Ihr echtes `~/.openclaw` nicht verändern können. -- Setzen Sie `OPENCLAW_LIVE_USE_REAL_HOME=1` nur dann, wenn Live-Tests absichtlich Ihr echtes Home-Verzeichnis verwenden sollen. -- `pnpm test:live` verwendet jetzt standardmäßig einen ruhigeren Modus: Die Ausgabe des Fortschritts `[live] ...` bleibt erhalten, aber der zusätzliche Hinweis zu `~/.profile` sowie Gateway-Bootstrap-Logs/Bonjour-Ausgaben werden unterdrückt. Setzen Sie `OPENCLAW_LIVE_TEST_QUIET=0`, wenn Sie die vollständigen Startup-Logs wieder sehen möchten. -- API-Key-Rotation (providerspezifisch): Setzen Sie `*_API_KEYS` im Komma-/Semikolon-Format oder `*_API_KEY_1`, `*_API_KEY_2` (zum Beispiel `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) oder einen Live-spezifischen Override über `OPENCLAW_LIVE_*_KEY`; Tests wiederholen bei Antworten mit Rate Limit. +- Setzen Sie `OPENCLAW_LIVE_USE_REAL_HOME=1` nur, wenn Live-Tests absichtlich Ihr echtes Home-Verzeichnis verwenden sollen. +- `pnpm test:live` verwendet jetzt standardmäßig einen ruhigeren Modus: Der Fortschritt `[live] ...` bleibt sichtbar, aber der zusätzliche Hinweis zu `~/.profile` wird unterdrückt und Gateway-Bootstrap-Logs/Bonjour-Ausgaben werden stummgeschaltet. Setzen Sie `OPENCLAW_LIVE_TEST_QUIET=0`, wenn Sie die vollständigen Startup-Logs wieder sehen möchten. +- API-Schlüsselrotation (providerspezifisch): Setzen Sie `*_API_KEYS` im Komma-/Semikolon-Format oder `*_API_KEY_1`, `*_API_KEY_2` (zum Beispiel `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) oder eine Override-Variable pro Live-Lauf über `OPENCLAW_LIVE_*_KEY`; Tests versuchen es bei Rate-Limit-Antworten erneut. - Fortschritts-/Heartbeat-Ausgabe: - - Live-Suiten geben jetzt Fortschrittszeilen auf stderr aus, sodass lange Provider-Aufrufe sichtbar aktiv bleiben, selbst wenn die Konsolenerfassung von Vitest ruhig ist. - - `vitest.live.config.ts` deaktiviert die Vitest-Konsoleninterzeption, sodass Fortschrittszeilen von Provider/Gateway bei Live-Läufen sofort gestreamt werden. - - Stimmen Sie direkte Modell-Heartbeats mit `OPENCLAW_LIVE_HEARTBEAT_MS` ab. - - Stimmen Sie Gateway-/Probe-Heartbeats mit `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` ab. + - Live-Suites geben Fortschrittszeilen jetzt auf stderr aus, damit bei langen Provider-Aufrufen sichtbar bleibt, dass etwas passiert, selbst wenn die Vitest-Konsolenerfassung ruhig ist. + - `vitest.live.config.ts` deaktiviert das Abfangen der Konsole durch Vitest, sodass Provider-/Gateway-Fortschrittszeilen bei Live-Läufen sofort gestreamt werden. + - Passen Sie Heartbeats für direkte Modelle mit `OPENCLAW_LIVE_HEARTBEAT_MS` an. + - Passen Sie Gateway-/Probe-Heartbeats mit `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` an. ## Welche Suite sollte ich ausführen? Verwenden Sie diese Entscheidungstabelle: -- Logik/Tests bearbeiten: `pnpm test` ausführen (und `pnpm test:coverage`, wenn Sie viel geändert haben) -- Gateway-Networking / WS-Protokoll / Pairing anfassen: zusätzlich `pnpm test:e2e` ausführen -- „Mein Bot ist down“ / providerspezifische Fehler / Tool-Calling debuggen: ein eingegrenztes `pnpm test:live` ausführen +- Logik/Tests bearbeiten: Führen Sie `pnpm test` aus (und `pnpm test:coverage`, wenn Sie viel geändert haben) +- Gateway-Networking / WS-Protokoll / Pairing berühren: Ergänzen Sie `pnpm test:e2e` +- Debugging von „mein Bot ist down“ / providerspezifischen Fehlern / Tool-Calling: Führen Sie ein eingegrenztes `pnpm test:live` aus -## Live: Android-Node-Capability-Sweep +## Live: Android-Node-Fähigkeitssweep - Test: `src/gateway/android-node.capabilities.live.test.ts` - Skript: `pnpm android:test:integration` -- Ziel: **jeden aktuell beworbenen** Befehl eines verbundenen Android-Node aufrufen und das Vertragsverhalten des Befehls validieren. +- Ziel: **jeden aktuell beworbenen Befehl** eines verbundenen Android-Nodes aufrufen und das Vertragsverhalten des Befehls prüfen. - Umfang: - - Voraussetzungen/manuelles Setup (die Suite installiert/startet/pairt die App nicht). - - Gateway-Validierung von `node.invoke` Befehl für Befehl für den ausgewählten Android-Node. -- Erforderliches Vorab-Setup: - - Android-App bereits mit dem Gateway verbunden + gepairt. - - App im Vordergrund halten. - - Berechtigungen/Erfassungszustimmung für Capabilities erteilen, deren Bestehen Sie erwarten. -- Optionale Ziel-Overrides: + - Vorbereitete/manuelle Einrichtung (die Suite installiert/startet/pairt die App nicht). + - `node.invoke`-Validierung des Gateways Befehl für Befehl für den ausgewählten Android-Node. +- Erforderliche Voreinrichtung: + - Android-App ist bereits mit dem Gateway verbunden und gepairt. + - App bleibt im Vordergrund. + - Berechtigungen/Capture-Einwilligungen sind für die Fähigkeiten erteilt, die erfolgreich sein sollen. +- Optionale Target-Überschreibungen: - `OPENCLAW_ANDROID_NODE_ID` oder `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. -- Vollständige Android-Setup-Details: [Android-App](/de/platforms/android) +- Vollständige Details zur Android-Einrichtung: [Android-App](/de/platforms/android) ## Live: Modell-Smoke (Profilschlüssel) Live-Tests sind in zwei Ebenen aufgeteilt, damit wir Fehler isolieren können: -- „Direct model“ sagt uns, ob der Provider/das Modell mit dem angegebenen Schlüssel überhaupt antworten kann. +- „Direct model“ sagt uns, ob der Provider/das Modell mit dem gegebenen Schlüssel überhaupt antworten kann. - „Gateway smoke“ sagt uns, ob die vollständige Gateway-+Agent-Pipeline für dieses Modell funktioniert (Sitzungen, Verlauf, Tools, Sandbox-Richtlinie usw.). -### Ebene 1: Direkte Modell-Completion (ohne Gateway) +### Ebene 1: Direkte Modellvervollständigung (ohne Gateway) - Test: `src/agents/models.profiles.live.test.ts` - Ziel: - Erkannte Modelle aufzählen - - `getApiKeyForModel` verwenden, um Modelle auszuwählen, für die Sie Credentials haben - - Eine kleine Completion pro Modell ausführen (und gezielte Regressionen, wo nötig) -- Aktivierung: - - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Vitest direkt aufgerufen wird) + - Mit `getApiKeyForModel` Modelle auswählen, für die Sie Anmeldedaten haben + - Pro Modell eine kleine Vervollständigung ausführen (und gezielte Regressionen, falls nötig) +- So aktivieren Sie es: + - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Sie Vitest direkt aufrufen) - Setzen Sie `OPENCLAW_LIVE_MODELS=modern` (oder `all`, Alias für modern), um diese Suite tatsächlich auszuführen; andernfalls wird sie übersprungen, damit `pnpm test:live` auf Gateway-Smoke fokussiert bleibt -- Modellauswahl: +- So wählen Sie Modelle aus: - `OPENCLAW_LIVE_MODELS=modern`, um die moderne Allowlist auszuführen (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_MODELS=all` ist ein Alias für die moderne Allowlist - oder `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (Komma-Allowlist) - - Modern-/All-Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setzen Sie `OPENCLAW_LIVE_MAX_MODELS=0` für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze. -- Providerauswahl: + - Moderne/All-Sweeps verwenden standardmäßig eine kuratierte High-Signal-Obergrenze; setzen Sie `OPENCLAW_LIVE_MAX_MODELS=0` für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze. +- So wählen Sie Provider aus: - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (Komma-Allowlist) -- Woher Schlüssel kommen: - - Standardmäßig: Profile Store und Env-Fallbacks - - Setzen Sie `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um **nur** den Profile Store zu erzwingen +- Woher die Schlüssel kommen: + - Standardmäßig: Profilspeicher und Env-Fallbacks + - Setzen Sie `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um ausschließlich den **Profilspeicher** zu erzwingen - Warum es das gibt: - Trennt „Provider-API ist kaputt / Schlüssel ist ungültig“ von „Gateway-Agent-Pipeline ist kaputt“ - - Enthält kleine, isolierte Regressionen (Beispiel: OpenAI Responses/Codex Responses Reasoning-Replay + Tool-Call-Flows) + - Enthält kleine, isolierte Regressionen (Beispiel: OpenAI-Responses/Codex-Responses-Reasoning-Replay- und Tool-Call-Flows) ### Ebene 2: Gateway- + Dev-Agent-Smoke (das, was `@openclaw` tatsächlich tut) - Test: `src/gateway/gateway-models.profiles.live.test.ts` - Ziel: - Ein In-Process-Gateway starten - - Eine Sitzung `agent:dev:*` erstellen/patchen (Modell-Override pro Lauf) - - Modelle mit Schlüsseln durchlaufen und Folgendes prüfen: + - Eine `agent:dev:*`-Sitzung erstellen/patchen (Modell-Override pro Lauf) + - Modelle mit Schlüsseln iterieren und Folgendes prüfen: - „sinnvolle“ Antwort (ohne Tools) - - eine echte Tool-Ausführung funktioniert (Read-Probe) + - ein echter Tool-Aufruf funktioniert (Read-Probe) - optionale zusätzliche Tool-Probes (Exec+Read-Probe) - OpenAI-Regressionspfade (nur Tool-Call → Follow-up) funktionieren weiterhin - Probe-Details (damit Sie Fehler schnell erklären können): - `read`-Probe: Der Test schreibt eine Nonce-Datei in den Workspace und fordert den Agenten auf, sie zu `read`en und die Nonce zurückzugeben. - - `exec+read`-Probe: Der Test fordert den Agenten auf, per `exec` eine Nonce in eine temporäre Datei zu schreiben und sie dann per `read` wieder zurückzulesen. + - `exec+read`-Probe: Der Test fordert den Agenten auf, per `exec` eine Nonce in eine temporäre Datei zu schreiben und sie dann per `read` wieder auszulesen. - Image-Probe: Der Test hängt ein generiertes PNG an (Katze + randomisierter Code) und erwartet, dass das Modell `cat ` zurückgibt. - Implementierungsreferenz: `src/gateway/gateway-models.profiles.live.test.ts` und `src/gateway/live-image-probe.ts`. -- Aktivierung: - - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Vitest direkt aufgerufen wird) -- Modellauswahl: +- So aktivieren Sie es: + - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Sie Vitest direkt aufrufen) +- So wählen Sie Modelle aus: - Standard: moderne Allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_GATEWAY_MODELS=all` ist ein Alias für die moderne Allowlist - - Oder `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (oder Komma-Liste) setzen, um einzugrenzen - - Moderne/All-Gateway-Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setzen Sie `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze. -- Providerauswahl (vermeiden Sie „alles über OpenRouter“): + - Oder setzen Sie `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (oder eine Komma-Liste), um einzugrenzen + - Moderne/All-Gateway-Sweeps verwenden standardmäßig eine kuratierte High-Signal-Obergrenze; setzen Sie `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze. +- So wählen Sie Provider aus (vermeiden Sie „alles von OpenRouter“): - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (Komma-Allowlist) -- Tool- + Image-Probes sind in diesem Live-Test immer aktiviert: +- Tool- und Image-Probes sind in diesem Live-Test immer aktiviert: - `read`-Probe + `exec+read`-Probe (Tool-Stresstest) - - Image-Probe läuft, wenn das Modell Unterstützung für Bildeingaben bewirbt - - Ablauf (allgemein): - - Test generiert ein kleines PNG mit „CAT“ + zufälligem Code (`src/gateway/live-image-probe.ts`) + - Die Image-Probe läuft, wenn das Modell Unterstützung für Bildeingaben bewirbt + - Ablauf (auf hoher Ebene): + - Der Test erzeugt ein kleines PNG mit „CAT“ + zufälligem Code (`src/gateway/live-image-probe.ts`) - Sendet es über `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - Gateway parst Anhänge in `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - Der eingebettete Agent leitet eine multimodale Benutzernachricht an das Modell weiter - - Assertion: Antwort enthält `cat` + den Code (OCR-Toleranz: kleine Fehler sind erlaubt) + - Assertion: Die Antwort enthält `cat` + den Code (OCR-Toleranz: kleine Fehler sind erlaubt) -Tipp: Um zu sehen, was Sie auf Ihrer Maschine testen können (und die genauen IDs `provider/model`), führen Sie aus: +Tipp: Um zu sehen, was Sie auf Ihrer Maschine testen können (und die genauen `provider/model`-IDs), führen Sie Folgendes aus: ```bash openclaw models list @@ -383,23 +450,23 @@ openclaw models list --json ## Live: CLI-Backend-Smoke (Claude, Codex, Gemini oder andere lokale CLIs) - Test: `src/gateway/gateway-cli-backend.live.test.ts` -- Ziel: die Gateway- + Agent-Pipeline mit einem lokalen CLI-Backend validieren, ohne Ihre Standardkonfiguration zu berühren. -- Backend-spezifische Smoke-Standardwerte befinden sich in der Definition `cli-backend.ts` der besitzenden Erweiterung. -- Aktivierung: - - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Vitest direkt aufgerufen wird) +- Ziel: die Gateway-+Agent-Pipeline mit einem lokalen CLI-Backend validieren, ohne Ihre Standardkonfiguration anzufassen. +- Backend-spezifische Smoke-Standardwerte befinden sich in der Definition `cli-backend.ts` der jeweils zuständigen Erweiterung. +- Aktivieren: + - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Sie Vitest direkt aufrufen) - `OPENCLAW_LIVE_CLI_BACKEND=1` - Standardwerte: - Standard-Provider/-Modell: `claude-cli/claude-sonnet-4-6` - - Verhalten von Command/Args/Image kommt aus den Metadaten des besitzenden CLI-Backend-Plugin. -- Overrides (optional): + - Befehls-/Argument-/Image-Verhalten stammt aus den Metadaten des jeweils zuständigen CLI-Backend-Plugins. +- Überschreibungen (optional): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, um einen echten Bildanhang zu senden (Pfade werden in den Prompt injiziert). - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, um Bilddateipfade als CLI-Args statt per Prompt-Injektion zu übergeben. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (oder `"list"`), um zu steuern, wie Image-Args übergeben werden, wenn `IMAGE_ARG` gesetzt ist. - - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, um einen zweiten Turn zu senden und den Resume-Flow zu validieren. - - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, um die standardmäßige Kontinuitätsprobe innerhalb derselben Sitzung von Claude Sonnet -> Opus zu deaktivieren (auf `1` setzen, um sie zu erzwingen, wenn das ausgewählte Modell ein Wechselziel unterstützt). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, um Bilddateipfade als CLI-Argumente statt per Prompt-Injektion zu übergeben. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (oder `"list"`), um zu steuern, wie Bildargumente übergeben werden, wenn `IMAGE_ARG` gesetzt ist. + - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, um einen zweiten Turn zu senden und den Resume-Ablauf zu validieren. + - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, um die standardmäßige Kontinuitätsprobe Claude Sonnet -> Opus in derselben Sitzung zu deaktivieren (setzen Sie den Wert auf `1`, um sie zu erzwingen, wenn das ausgewählte Modell ein Switch-Ziel unterstützt). Beispiel: @@ -427,21 +494,21 @@ pnpm test:docker:live-cli-backend:gemini Hinweise: - Der Docker-Runner befindet sich unter `scripts/test-live-cli-backend-docker.sh`. -- Er führt den Live-CLI-Backend-Smoke im Repo-Docker-Image als nicht-root-Benutzer `node` aus. -- Er löst CLI-Smoke-Metadaten aus der besitzenden Erweiterung auf und installiert dann das passende Linux-CLI-Paket (`@anthropic-ai/claude-code`, `@openai/codex` oder `@google/gemini-cli`) in ein gecachtes beschreibbares Prefix unter `OPENCLAW_DOCKER_CLI_TOOLS_DIR` auf (Standard: `~/.cache/openclaw/docker-cli-tools`). -- `pnpm test:docker:live-cli-backend:claude-subscription` erfordert portable Claude Code Subscription-OAuth über entweder `~/.claude/.credentials.json` mit `claudeAiOauth.subscriptionType` oder `CLAUDE_CODE_OAUTH_TOKEN` aus `claude setup-token`. Es weist zuerst direktes `claude -p` in Docker nach und führt dann zwei Gateway-CLI-Backend-Turns aus, ohne Anthropic-API-Key-Umgebungsvariablen beizubehalten. Diese Subscription-Lane deaktiviert standardmäßig die Claude-MCP-/Tool- und Image-Probes, da Claude derzeit die Nutzung von Drittanbieter-Apps über zusätzliche Nutzungsabrechnung statt über normale Limits von Subscription-Plänen abrechnet. -- Der Live-CLI-Backend-Smoke übt jetzt denselben End-to-End-Ablauf für Claude, Codex und Gemini aus: Text-Turn, Bildklassifizierungs-Turn, dann MCP-`cron`-Tool-Call, verifiziert über die Gateway-CLI. -- Claudes standardmäßiger Smoke patcht die Sitzung außerdem von Sonnet auf Opus und verifiziert, dass die fortgesetzte Sitzung sich weiterhin an eine frühere Notiz erinnert. +- Er führt den Live-CLI-Backend-Smoke innerhalb des Repo-Docker-Images als Nicht-Root-Benutzer `node` aus. +- Er löst CLI-Smoke-Metadaten aus der jeweils zuständigen Erweiterung auf und installiert dann das passende Linux-CLI-Paket (`@anthropic-ai/claude-code`, `@openai/codex` oder `@google/gemini-cli`) in ein zwischengespeichertes beschreibbares Präfix unter `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (Standard: `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` erfordert portable Claude Code Subscription-OAuth entweder über `~/.claude/.credentials.json` mit `claudeAiOauth.subscriptionType` oder `CLAUDE_CODE_OAUTH_TOKEN` aus `claude setup-token`. Es beweist zuerst direktes `claude -p` in Docker und führt dann zwei Gateway-CLI-Backend-Turns aus, ohne Anthropic-API-Key-Umgebungsvariablen zu erhalten. Diese Subscription-Lane deaktiviert standardmäßig die Claude-MCP-/Tool- und Image-Probes, da Claude die Nutzung durch Drittanbieter-Apps derzeit über Extra-Usage-Abrechnung statt über normale Abo-Limits leitet. +- Der Live-CLI-Backend-Smoke testet jetzt denselben echten End-to-End-Ablauf für Claude, Codex und Gemini: Text-Turn, Image-Klassifizierungs-Turn, dann ein MCP-Tool-Aufruf `cron`, der über die Gateway-CLI verifiziert wird. +- Claudes Standard-Smoke patcht außerdem die Sitzung von Sonnet auf Opus und verifiziert, dass sich die fortgesetzte Sitzung weiterhin an eine frühere Notiz erinnert. ## Live: ACP-Bind-Smoke (`/acp spawn ... --bind here`) - Test: `src/gateway/gateway-acp-bind.live.test.ts` -- Ziel: den echten ACP-Konversations-Bind-Flow mit einem Live-ACP-Agenten validieren: +- Ziel: den echten ACP-Konversations-Bind-Ablauf mit einem Live-ACP-Agenten validieren: - `/acp spawn --bind here` senden - - eine synthetische Message-Channel-Konversation an Ort und Stelle binden - - ein normales Follow-up in derselben Konversation senden + - eine synthetische Message-Channel-Konversation direkt daran binden + - einen normalen Follow-up in derselben Konversation senden - verifizieren, dass das Follow-up im gebundenen ACP-Sitzungstranskript landet -- Aktivierung: +- Aktivieren: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` - Standardwerte: @@ -449,15 +516,15 @@ Hinweise: - ACP-Agent für direktes `pnpm test:live ...`: `claude` - Synthetischer Kanal: Slack-DM-artiger Konversationskontext - ACP-Backend: `acpx` -- Overrides: +- Überschreibungen: - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex` - `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` - Hinweise: - - Diese Lane verwendet die Gateway-Oberfläche `chat.send` mit admin-only synthetischen Feldern der Originating-Route, damit Tests Message-Channel-Kontext anhängen können, ohne vorzugeben, extern zuzustellen. - - Wenn `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nicht gesetzt ist, verwendet der Test die integrierte Agent-Registry des eingebetteten `acpx`-Plugin für den ausgewählten ACP-Harness-Agenten. + - Diese Lane verwendet die Gateway-Oberfläche `chat.send` mit rein administrativen synthetischen Feldern für die Origin-Route, damit Tests Message-Channel-Kontext anhängen können, ohne so zu tun, als würde extern zugestellt. + - Wenn `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nicht gesetzt ist, verwendet der Test die integrierte Agent-Registry des eingebetteten `acpx`-Plugins für den ausgewählten ACP-Harness-Agenten. Beispiel: @@ -486,28 +553,25 @@ Docker-Hinweise: - Der Docker-Runner befindet sich unter `scripts/test-live-acp-bind-docker.sh`. - Standardmäßig führt er den ACP-Bind-Smoke nacheinander gegen alle unterstützten Live-CLI-Agenten aus: `claude`, `codex`, dann `gemini`. - Verwenden Sie `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` oder `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, um die Matrix einzugrenzen. -- Er sourct `~/.profile`, stellt das passende CLI-Auth-Material im Container bereit, installiert `acpx` in ein beschreibbares npm-Prefix und installiert dann das angeforderte Live-CLI (`@anthropic-ai/claude-code`, `@openai/codex` oder `@google/gemini-cli`), falls es fehlt. -- Innerhalb von Docker setzt der Runner `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, damit `acpx` Provider-Umgebungsvariablen aus dem gesourcten Profil für das untergeordnete Harness-CLI verfügbar hält. +- Er sourct `~/.profile`, stellt das passende CLI-Auth-Material in den Container bereit, installiert `acpx` in ein beschreibbares npm-Präfix und installiert dann die angeforderte Live-CLI (`@anthropic-ai/claude-code`, `@openai/codex` oder `@google/gemini-cli`), falls sie fehlt. +- Innerhalb von Docker setzt der Runner `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, damit `acpx` die Provider-Umgebungsvariablen aus dem gesourcten Profil für die untergeordnete Harness-CLI verfügbar hält. ## Live: Codex-App-Server-Harness-Smoke -- Ziel: das Plugin-eigene Codex-Harness über die normale Gateway- - `agent`-Methode validieren: +- Ziel: die Plugin-eigene Codex-Harness über die normale Gateway-Methode + `agent` validieren: - das gebündelte `codex`-Plugin laden - `OPENCLAW_AGENT_RUNTIME=codex` auswählen - einen ersten Gateway-Agent-Turn an `codex/gpt-5.4` senden - - einen zweiten Turn an dieselbe OpenClaw-Sitzung senden und verifizieren, dass der App-Server-Thread - fortgesetzt werden kann - - `/codex status` und `/codex models` über denselben Gateway-Command- - Pfad ausführen + - einen zweiten Turn an dieselbe OpenClaw-Sitzung senden und verifizieren, dass der App-Server-Thread fortgesetzt werden kann + - `/codex status` und `/codex models` über denselben Gateway-Befehlspfad ausführen - Test: `src/gateway/gateway-codex-harness.live.test.ts` -- Aktivierung: `OPENCLAW_LIVE_CODEX_HARNESS=1` +- Aktivieren: `OPENCLAW_LIVE_CODEX_HARNESS=1` - Standardmodell: `codex/gpt-5.4` - Optionale Image-Probe: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` - Optionale MCP-/Tool-Probe: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` -- Der Smoke setzt `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, sodass ein kaputtes Codex- - Harness nicht bestehen kann, indem es stillschweigend auf PI zurückfällt. -- Auth: `OPENAI_API_KEY` aus Shell/Profil sowie optional kopierte +- Der Smoke setzt `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, damit eine defekte Codex-Harness nicht bestehen kann, indem stillschweigend auf PI zurückgefallen wird. +- Auth: `OPENAI_API_KEY` aus der Shell/dem Profil sowie optional kopierte Dateien `~/.codex/auth.json` und `~/.codex/config.toml` Lokales Rezept: @@ -531,19 +595,15 @@ pnpm test:docker:live-codex-harness Docker-Hinweise: - Der Docker-Runner befindet sich unter `scripts/test-live-codex-harness-docker.sh`. -- Er sourct das eingebundene `~/.profile`, übergibt `OPENAI_API_KEY`, kopiert Codex-CLI- - Auth-Dateien, falls vorhanden, installiert `@openai/codex` in ein beschreibbares eingebundenes npm- - Prefix, stellt den Quellbaum bereit und führt dann nur den Live-Test für das Codex-Harness aus. +- Er sourct das eingehängte `~/.profile`, übergibt `OPENAI_API_KEY`, kopiert vorhandene Codex-CLI-Auth-Dateien, installiert `@openai/codex` in ein beschreibbares eingehängtes npm-Präfix, stellt den Quellbaum bereit und führt dann nur den Live-Test der Codex-Harness aus. - Docker aktiviert standardmäßig die Image- und MCP-/Tool-Probes. Setzen Sie `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` oder `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0`, wenn Sie einen enger eingegrenzten Debug-Lauf benötigen. -- Docker exportiert außerdem `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, passend zur Live- - Testkonfiguration, damit `openai-codex/*`- oder PI-Fallback einen Codex-Harness- - Regressionsfehler nicht verbergen kann. +- Docker exportiert außerdem `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, passend zur Live-Test-Konfiguration, sodass ein Fallback auf `openai-codex/*` oder PI keine Regression der Codex-Harness verbergen kann. ### Empfohlene Live-Rezepte -Enge, explizite Allowlists sind am schnellsten und am wenigsten anfällig: +Schmale, explizite Allowlists sind am schnellsten und am wenigsten flaky: - Einzelnes Modell, direkt (ohne Gateway): - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts` @@ -551,7 +611,7 @@ Enge, explizite Allowlists sind am schnellsten und am wenigsten anfällig: - Einzelnes Modell, Gateway-Smoke: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Tool-Calling über mehrere Provider hinweg: +- Tool-Calling über mehrere Provider: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Google-Fokus (Gemini-API-Schlüssel + Antigravity): @@ -561,21 +621,21 @@ Enge, explizite Allowlists sind am schnellsten und am wenigsten anfällig: Hinweise: - `google/...` verwendet die Gemini-API (API-Schlüssel). -- `google-antigravity/...` verwendet die Antigravity-OAuth-Bridge (Cloud-Code-Assist-artiger Agent-Endpunkt). -- `google-gemini-cli/...` verwendet die lokale Gemini-CLI auf Ihrer Maschine (separate Auth + Tooling-Eigenheiten). +- `google-antigravity/...` verwendet die Antigravity-OAuth-Bridge (Cloud-Code-Assist-artiger Agent-Endpoint). +- `google-gemini-cli/...` verwendet die lokale Gemini-CLI auf Ihrer Maschine (separate Authentifizierung + Tooling-Besonderheiten). - Gemini-API vs. Gemini-CLI: - - API: OpenClaw ruft Googles gehostete Gemini-API über HTTP auf (API-Schlüssel / Profil-Auth); das ist es, was die meisten Benutzer mit „Gemini“ meinen. - - CLI: OpenClaw ruft eine lokale `gemini`-Binärdatei auf; sie hat ihre eigene Authentifizierung und kann sich anders verhalten (Streaming/Tool-Unterstützung/Versionsabweichung). + - API: OpenClaw ruft Googles gehostete Gemini-API über HTTP auf (API-Schlüssel / Profile-Authentifizierung); das ist das, was die meisten Benutzer mit „Gemini“ meinen. + - CLI: OpenClaw führt eine lokale Binärdatei `gemini` per Shell aus; sie hat ihre eigene Authentifizierung und kann sich anders verhalten (Streaming-/Tool-Support/Versionsunterschiede). ## Live: Modellmatrix (was wir abdecken) -Es gibt keine feste „CI-Modellliste“ (Live ist opt-in), aber dies sind die **empfohlenen** Modelle, die regelmäßig auf einer Entwicklermaschine mit Schlüsseln abgedeckt werden sollten. +Es gibt keine feste „CI-Modellliste“ (Live ist Opt-in), aber dies sind die **empfohlenen** Modelle, die regelmäßig auf einer Entwickler-Maschine mit Schlüsseln abgedeckt werden sollten. ### Modernes Smoke-Set (Tool-Calling + Bild) -Das ist der Lauf für die „üblichen Modelle“, von dem wir erwarten, dass er weiterhin funktioniert: +Das ist der Lauf für die „gängigen Modelle“, den wir funktionsfähig halten wollen: -- OpenAI (nicht Codex): `openai/gpt-5.4` (optional: `openai/gpt-5.4-mini`) +- OpenAI (nicht-Codex): `openai/gpt-5.4` (optional: `openai/gpt-5.4-mini`) - OpenAI Codex: `openai-codex/gpt-5.4` - Anthropic: `anthropic/claude-opus-4-6` (oder `anthropic/claude-sonnet-4-6`) - Google (Gemini-API): `google/gemini-3.1-pro-preview` und `google/gemini-3-flash-preview` (ältere Gemini-2.x-Modelle vermeiden) @@ -586,7 +646,7 @@ Das ist der Lauf für die „üblichen Modelle“, von dem wir erwarten, dass er Gateway-Smoke mit Tools + Bild ausführen: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Basislinie: Tool-Calling (Read + optional Exec) +### Baseline: Tool-Calling (Read + optional Exec) Wählen Sie mindestens eines pro Provider-Familie: @@ -605,67 +665,67 @@ Optionale zusätzliche Abdeckung (nice to have): ### Vision: Bild senden (Anhang → multimodale Nachricht) -Nehmen Sie mindestens ein bildfähiges Modell in `OPENCLAW_LIVE_GATEWAY_MODELS` auf (Claude/Gemini/OpenAI-Varianten mit Vision-Unterstützung usw.), um die Image-Probe auszuüben. +Nehmen Sie mindestens ein bildfähiges Modell in `OPENCLAW_LIVE_GATEWAY_MODELS` auf (Claude/Gemini/OpenAI-Varianten mit Vision-Unterstützung usw.), um die Image-Probe auszuführen. ### Aggregatoren / alternative Gateways -Wenn Sie Schlüssel dafür aktiviert haben, unterstützen wir auch Tests über: +Wenn Sie die entsprechenden Schlüssel aktiviert haben, unterstützen wir auch Tests über: -- OpenRouter: `openrouter/...` (hunderte Modelle; verwenden Sie `openclaw models scan`, um Kandidaten mit Tool-+Bild-Unterstützung zu finden) -- OpenCode: `opencode/...` für Zen und `opencode-go/...` für Go (Auth über `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) +- OpenRouter: `openrouter/...` (hunderte Modelle; verwenden Sie `openclaw models scan`, um geeignete Kandidaten mit Tool- und Bildunterstützung zu finden) +- OpenCode: `opencode/...` für Zen und `opencode-go/...` für Go (Authentifizierung über `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) -Weitere Provider, die Sie in die Live-Matrix aufnehmen können (wenn Sie Credentials/Konfiguration haben): +Weitere Provider, die Sie in die Live-Matrix aufnehmen können (wenn Sie Anmeldedaten/Konfiguration haben): - Integriert: `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot` -- Über `models.providers` (benutzerdefinierte Endpunkte): `minimax` (Cloud/API) sowie jeder OpenAI-/Anthropic-kompatible Proxy (LM Studio, vLLM, LiteLLM usw.) +- Über `models.providers` (benutzerdefinierte Endpoints): `minimax` (Cloud/API) sowie beliebige OpenAI-/Anthropic-kompatible Proxys (LM Studio, vLLM, LiteLLM usw.) -Tipp: Versuchen Sie nicht, „alle Modelle“ in der Dokumentation fest zu verdrahten. Die maßgebliche Liste ist das, was `discoverModels(...)` auf Ihrer Maschine zurückgibt + die verfügbaren Schlüssel. +Tipp: Versuchen Sie nicht, in der Dokumentation „alle Modelle“ fest zu kodieren. Die maßgebliche Liste ist das, was `discoverModels(...)` auf Ihrer Maschine zurückgibt + die verfügbaren Schlüssel. -## Credentials (niemals committen) +## Anmeldedaten (niemals committen) -Live-Tests erkennen Credentials auf dieselbe Weise wie die CLI. Praktische Auswirkungen: +Live-Tests erkennen Anmeldedaten auf dieselbe Weise wie die CLI. Praktische Auswirkungen: - Wenn die CLI funktioniert, sollten Live-Tests dieselben Schlüssel finden. -- Wenn ein Live-Test „no creds“ meldet, debuggen Sie genauso, wie Sie `openclaw models list` / Modellauswahl debuggen würden. +- Wenn ein Live-Test „keine Anmeldedaten“ meldet, debuggen Sie ihn genauso, wie Sie `openclaw models list` / die Modellauswahl debuggen würden. -- Auth-Profile pro Agent: `~/.openclaw/agents//agent/auth-profiles.json` (das ist es, was in den Live-Tests mit „profile keys“ gemeint ist) +- Auth-Profile pro Agent: `~/.openclaw/agents//agent/auth-profiles.json` (das ist es, was in den Live-Tests mit „Profilschlüssel“ gemeint ist) - Konfiguration: `~/.openclaw/openclaw.json` (oder `OPENCLAW_CONFIG_PATH`) -- Legacy-State-Verzeichnis: `~/.openclaw/credentials/` (wird in das bereitgestellte Live-Test-Home kopiert, wenn vorhanden, ist aber nicht der Hauptspeicher für Profilschlüssel) -- Lokale Live-Läufe kopieren standardmäßig die aktive Konfiguration, `auth-profiles.json`-Dateien pro Agent, das Legacy-Verzeichnis `credentials/` und unterstützte externe CLI-Auth-Verzeichnisse in ein temporäres Test-Home; bereitgestellte Live-Homes überspringen `workspace/` und `sandboxes/`, und Pfad-Overrides für `agents.*.workspace` / `agentDir` werden entfernt, damit Probes nicht Ihren echten Host-Workspace verwenden. +- Legacy-State-Verzeichnis: `~/.openclaw/credentials/` (wird in das bereitgestellte Live-Test-Home kopiert, wenn vorhanden, ist aber nicht der primäre Speicher für Profilschlüssel) +- Lokale Live-Läufe kopieren standardmäßig die aktive Konfiguration, `auth-profiles.json`-Dateien pro Agent, das Legacy-Verzeichnis `credentials/` und unterstützte externe CLI-Auth-Verzeichnisse in ein temporäres Test-Home; bereitgestellte Live-Homes überspringen `workspace/` und `sandboxes/`, und Pfad-Overrides für `agents.*.workspace` / `agentDir` werden entfernt, damit Probes Ihren echten Host-Workspace nicht berühren. -Wenn Sie sich auf Env-Schlüssel verlassen möchten (z. B. in Ihrem `~/.profile` exportiert), führen Sie lokale Tests nach `source ~/.profile` aus oder verwenden Sie die Docker-Runner unten (sie können `~/.profile` in den Container einbinden). +Wenn Sie sich auf Env-Schlüssel verlassen möchten (z. B. in Ihrem `~/.profile` exportiert), führen Sie lokale Tests nach `source ~/.profile` aus oder verwenden Sie die Docker-Runner unten (sie können `~/.profile` in den Container einhängen). -## Deepgram live (Audiotranskription) +## Live: Deepgram (Audiotranskription) - Test: `src/media-understanding/providers/deepgram/audio.live.test.ts` -- Aktivierung: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` +- Aktivieren: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` -## BytePlus Coding-Plan live +## Live: BytePlus Coding-Plan - Test: `src/agents/byteplus.live.test.ts` -- Aktivierung: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` -- Optionaler Modell-Override: `BYTEPLUS_CODING_MODEL=ark-code-latest` +- Aktivieren: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` +- Optionales Modell-Override: `BYTEPLUS_CODING_MODEL=ark-code-latest` -## ComfyUI-Workflow-Medien live +## Live: ComfyUI-Workflow-Medien - Test: `extensions/comfy/comfy.live.test.ts` -- Aktivierung: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` +- Aktivieren: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` - Umfang: - - Übt die gebündelten Bild-, Video- und `music_generate`-Pfade von comfy aus - - Überspringt jede Capability, sofern `models.providers.comfy.` nicht konfiguriert ist + - Testet die gebündelten Pfade von comfy für Bild, Video und `music_generate` + - Überspringt jede Fähigkeit, sofern `models.providers.comfy.` nicht konfiguriert ist - Nützlich nach Änderungen an comfy-Workflow-Übermittlung, Polling, Downloads oder Plugin-Registrierung -## Bildgenerierung live +## Live: Bildgenerierung - Test: `src/image-generation/runtime.live.test.ts` - Befehl: `pnpm test:live src/image-generation/runtime.live.test.ts` - Harness: `pnpm test:live:media image` - Umfang: - - Zählt jedes registrierte Plugin für Bildgenerierungs-Provider auf - - Lädt vor dem Prüfen fehlende Provider-Umgebungsvariablen aus Ihrer Login-Shell (`~/.profile`) - - Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Credentials nicht verdecken - - Überspringt Provider ohne nutzbare Auth/Profil/Modell - - Führt die Standardvarianten der Bildgenerierung über die gemeinsame Laufzeit-Capability aus: + - Zählt jedes registrierte Provider-Plugin für Bildgenerierung auf + - Lädt fehlende Provider-Umgebungsvariablen vor dem Testen aus Ihrer Login-Shell (`~/.profile`) + - Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht maskieren + - Überspringt Provider ohne nutzbare Authentifizierung/Profil/Modell + - Führt die standardmäßigen Varianten der Bildgenerierung über die gemeinsame Laufzeitfähigkeit aus: - `google:flash-generate` - `google:pro-generate` - `google:pro-edit` @@ -678,23 +738,23 @@ Wenn Sie sich auf Env-Schlüssel verlassen möchten (z. B. in Ihrem `~/.profile` - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"` - Optionales Auth-Verhalten: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Profile-Store-Auth zu erzwingen und rein umgebungsbasierte Overrides zu ignorieren + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Authentifizierung aus dem Profilspeicher zu erzwingen und reine Env-Overrides zu ignorieren -## Musikgenerierung live +## Live: Musikgenerierung - Test: `extensions/music-generation-providers.live.test.ts` -- Aktivierung: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` +- Aktivieren: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harness: `pnpm test:live:media music` - Umfang: - - Übt den gemeinsamen gebündelten Pfad für Musikgenerierungs-Provider aus + - Testet den gemeinsam genutzten gebündelten Provider-Pfad für Musikgenerierung - Deckt derzeit Google und MiniMax ab - - Lädt vor dem Prüfen Provider-Umgebungsvariablen aus Ihrer Login-Shell (`~/.profile`) - - Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Credentials nicht verdecken - - Überspringt Provider ohne nutzbare Auth/Profil/Modell + - Lädt Provider-Umgebungsvariablen vor dem Testen aus Ihrer Login-Shell (`~/.profile`) + - Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht maskieren + - Überspringt Provider ohne nutzbare Authentifizierung/Profil/Modell - Führt beide deklarierten Laufzeitmodi aus, wenn verfügbar: - `generate` mit reiner Prompt-Eingabe - `edit`, wenn der Provider `capabilities.edit.enabled` deklariert - - Aktuelle Abdeckung in der gemeinsamen Lane: + - Aktuelle Abdeckung der gemeinsamen Lane: - `google`: `generate`, `edit` - `minimax`: `generate` - `comfy`: separate Comfy-Live-Datei, nicht dieser gemeinsame Sweep @@ -702,47 +762,47 @@ Wenn Sie sich auf Env-Schlüssel verlassen möchten (z. B. in Ihrem `~/.profile` - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"` - Optionales Auth-Verhalten: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Profile-Store-Auth zu erzwingen und rein umgebungsbasierte Overrides zu ignorieren + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Authentifizierung aus dem Profilspeicher zu erzwingen und reine Env-Overrides zu ignorieren -## Videogenerierung live +## Live: Videogenerierung - Test: `extensions/video-generation-providers.live.test.ts` -- Aktivierung: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` +- Aktivieren: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harness: `pnpm test:live:media video` - Umfang: - - Übt den gemeinsamen gebündelten Pfad für Videogenerierungs-Provider aus - - Lädt vor dem Prüfen Provider-Umgebungsvariablen aus Ihrer Login-Shell (`~/.profile`) - - Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Credentials nicht verdecken - - Überspringt Provider ohne nutzbare Auth/Profil/Modell + - Testet den gemeinsam genutzten gebündelten Provider-Pfad für Videogenerierung + - Lädt Provider-Umgebungsvariablen vor dem Testen aus Ihrer Login-Shell (`~/.profile`) + - Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht maskieren + - Überspringt Provider ohne nutzbare Authentifizierung/Profil/Modell - Führt beide deklarierten Laufzeitmodi aus, wenn verfügbar: - `generate` mit reiner Prompt-Eingabe - - `imageToVideo`, wenn der Provider `capabilities.imageToVideo.enabled` deklariert und der ausgewählte Provider/das ausgewählte Modell in dem gemeinsamen Sweep buffer-gestützte lokale Bildeingaben akzeptiert - - `videoToVideo`, wenn der Provider `capabilities.videoToVideo.enabled` deklariert und der ausgewählte Provider/das ausgewählte Modell in dem gemeinsamen Sweep buffer-gestützte lokale Videoeingaben akzeptiert - - Aktuelle im gemeinsamen Sweep deklarierte, aber übersprungene `imageToVideo`-Provider: + - `imageToVideo`, wenn der Provider `capabilities.imageToVideo.enabled` deklariert und der ausgewählte Provider/das Modell buffer-gestützte lokale Bildeingabe im gemeinsamen Sweep akzeptiert + - `videoToVideo`, wenn der Provider `capabilities.videoToVideo.enabled` deklariert und der ausgewählte Provider/das Modell buffer-gestützte lokale Videoeingabe im gemeinsamen Sweep akzeptiert + - Aktuell deklarierte, aber im gemeinsamen Sweep übersprungene `imageToVideo`-Provider: - `vydra`, weil das gebündelte `veo3` nur Text unterstützt und das gebündelte `kling` eine Remote-Bild-URL erfordert - Provider-spezifische Vydra-Abdeckung: - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - - diese Datei führt `veo3` für Text-zu-Video sowie eine `kling`-Lane aus, die standardmäßig ein Fixture mit Remote-Bild-URL verwendet + - diese Datei führt `veo3` Text-zu-Video sowie standardmäßig eine `kling`-Lane aus, die eine Fixture mit Remote-Bild-URL verwendet - Aktuelle `videoToVideo`-Live-Abdeckung: - `runway` nur, wenn das ausgewählte Modell `runway/gen4_aleph` ist - - Aktuelle im gemeinsamen Sweep deklarierte, aber übersprungene `videoToVideo`-Provider: - - `alibaba`, `qwen`, `xai`, weil diese Pfade derzeit Referenz-URLs vom Typ `http(s)` / MP4 erfordern - - `google`, weil die aktuelle gemeinsame Gemini-/Veo-Lane lokale buffer-gestützte Eingaben verwendet und dieser Pfad im gemeinsamen Sweep nicht akzeptiert wird - - `openai`, weil der aktuellen gemeinsamen Lane Garantien für organisationsspezifischen Zugriff auf Video-Inpainting/Remix fehlen + - Aktuell deklarierte, aber im gemeinsamen Sweep übersprungene `videoToVideo`-Provider: + - `alibaba`, `qwen`, `xai`, da diese Pfade derzeit Remote-Referenz-URLs `http(s)` / MP4 erfordern + - `google`, da die aktuelle gemeinsame Gemini-/Veo-Lane lokale buffer-gestützte Eingabe verwendet und dieser Pfad im gemeinsamen Sweep nicht akzeptiert wird + - `openai`, da der aktuellen gemeinsamen Lane Garantien für organisationsspezifischen Zugriff auf Video-Inpaint/Remix fehlen - Optionale Eingrenzung: - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` - Optionales Auth-Verhalten: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Profile-Store-Auth zu erzwingen und rein umgebungsbasierte Overrides zu ignorieren + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Authentifizierung aus dem Profilspeicher zu erzwingen und reine Env-Overrides zu ignorieren -## Media-Live-Harness +## Live-Media-Harness - Befehl: `pnpm test:live:media` - Zweck: - - Führt die gemeinsamen Live-Suiten für Bild, Musik und Video über einen repo-nativen Einstiegspunkt aus + - Führt die gemeinsamen Live-Suites für Bild, Musik und Video über einen repo-nativen Entry-Point aus - Lädt fehlende Provider-Umgebungsvariablen automatisch aus `~/.profile` - - Grenzt standardmäßig jede Suite automatisch auf Provider ein, die derzeit nutzbare Auth besitzen - - Verwendet erneut `scripts/test-live.mjs`, sodass Heartbeat- und Quiet-Mode-Verhalten konsistent bleiben + - Grenzt jede Suite standardmäßig automatisch auf Provider ein, die derzeit nutzbare Authentifizierung haben + - Verwendet `scripts/test-live.mjs` erneut, sodass Heartbeat- und Quiet-Mode-Verhalten konsistent bleiben - Beispiele: - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` @@ -753,7 +813,7 @@ Wenn Sie sich auf Env-Schlüssel verlassen möchten (z. B. in Ihrem `~/.profile` Diese Docker-Runner teilen sich in zwei Gruppen: -- Live-Modell-Runner: `test:docker:live-models` und `test:docker:live-gateway` führen nur ihre jeweils passende Live-Datei mit Profilschlüsseln innerhalb des Repo-Docker-Images aus (`src/agents/models.profiles.live.test.ts` und `src/gateway/gateway-models.profiles.live.test.ts`), wobei Ihr lokales Konfigurationsverzeichnis und Ihr Workspace eingebunden werden (und `~/.profile` gesourct wird, falls eingebunden). Die passenden lokalen Einstiegspunkte sind `test:live:models-profiles` und `test:live:gateway-profiles`. +- Live-Modell-Runner: `test:docker:live-models` und `test:docker:live-gateway` führen nur ihre jeweils passende Live-Datei mit Profilschlüsseln innerhalb des Repo-Docker-Images aus (`src/agents/models.profiles.live.test.ts` und `src/gateway/gateway-models.profiles.live.test.ts`), wobei Ihr lokales Konfigurationsverzeichnis und Ihr Workspace eingehängt werden (und `~/.profile` gesourct wird, wenn es eingehängt ist). Die entsprechenden lokalen Entry-Points sind `test:live:models-profiles` und `test:live:gateway-profiles`. - Docker-Live-Runner verwenden standardmäßig eine kleinere Smoke-Obergrenze, damit ein vollständiger Docker-Sweep praktikabel bleibt: `test:docker:live-models` verwendet standardmäßig `OPENCLAW_LIVE_MAX_MODELS=12`, und `test:docker:live-gateway` verwendet standardmäßig `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, @@ -761,10 +821,10 @@ Diese Docker-Runner teilen sich in zwei Gruppen: `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` und `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Überschreiben Sie diese Env-Variablen, wenn Sie ausdrücklich den größeren vollständigen Scan möchten. -- `test:docker:all` baut das Live-Docker-Image einmal über `test:docker:live-build` und verwendet es dann für die beiden Docker-Live-Lanes erneut. +- `test:docker:all` baut das Live-Docker-Image einmal über `test:docker:live-build` und verwendet es dann für die beiden Live-Docker-Lanes wieder. - Container-Smoke-Runner: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` und `test:docker:plugins` starten einen oder mehrere echte Container und verifizieren Integrationspfade auf höherer Ebene. -Die Docker-Runner für Live-Modelle binden außerdem nur die benötigten CLI-Auth-Homes ein (oder alle unterstützten, wenn der Lauf nicht eingegrenzt ist) und kopieren sie dann vor dem Lauf in das Container-Home, damit externes CLI-OAuth Tokens aktualisieren kann, ohne den Auth-Store des Hosts zu verändern: +Die Docker-Runner für Live-Modelle binden außerdem nur die benötigten CLI-Auth-Homes ein (oder alle unterstützten, wenn der Lauf nicht eingegrenzt ist) und kopieren sie dann vor dem Lauf in das Container-Home, sodass externe CLI-OAuth Tokens aktualisieren kann, ohne den Auth-Speicher des Hosts zu verändern: - Direkte Modelle: `pnpm test:docker:live-models` (Skript: `scripts/test-live-models-docker.sh`) - ACP-Bind-Smoke: `pnpm test:docker:live-acp-bind` (Skript: `scripts/test-live-acp-bind-docker.sh`) @@ -774,103 +834,103 @@ Die Docker-Runner für Live-Modelle binden außerdem nur die benötigten CLI-Aut - Open-WebUI-Live-Smoke: `pnpm test:docker:openwebui` (Skript: `scripts/e2e/openwebui-docker.sh`) - Onboarding-Assistent (TTY, vollständiges Scaffolding): `pnpm test:docker:onboard` (Skript: `scripts/e2e/onboard-docker.sh`) - Gateway-Networking (zwei Container, WS-Auth + Health): `pnpm test:docker:gateway-network` (Skript: `scripts/e2e/gateway-network-docker.sh`) -- MCP-Kanal-Bridge (seeded Gateway + stdio-Bridge + roher Claude-Benachrichtigungsframe-Smoke): `pnpm test:docker:mcp-channels` (Skript: `scripts/e2e/mcp-channels-docker.sh`) -- Plugins (Install-Smoke + `/plugin`-Alias + Neustartsemantik für Claude-Bundle): `pnpm test:docker:plugins` (Skript: `scripts/e2e/plugins-docker.sh`) +- MCP-Kanal-Bridge (vorinitialisiertes Gateway + stdio-Bridge + roher Claude-Benachrichtigungsframe-Smoke): `pnpm test:docker:mcp-channels` (Skript: `scripts/e2e/mcp-channels-docker.sh`) +- Plugins (Installations-Smoke + `/plugin`-Alias + Neustartsemantik des Claude-Bundles): `pnpm test:docker:plugins` (Skript: `scripts/e2e/plugins-docker.sh`) -Die Docker-Runner für Live-Modelle binden den aktuellen Checkout außerdem schreibgeschützt ein und -stellen ihn innerhalb des Containers in ein temporäres Arbeitsverzeichnis bereit. Dadurch bleibt das Runtime- -Image schlank, während Vitest weiterhin gegen Ihren exakten lokalen Quellcode/Ihre Konfiguration ausgeführt wird. -Der Bereitstellungsschritt überspringt große lokale Caches und Build-Ausgaben von Apps wie -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` und app-lokale `.build`- oder -Gradle-Ausgabeverzeichnisse, damit Docker-Live-Läufe nicht Minuten mit dem Kopieren +Die Docker-Runner für Live-Modelle binden den aktuellen Checkout außerdem schreibgeschützt ein +und stellen ihn in einem temporären Arbeitsverzeichnis innerhalb des Containers bereit. Dadurch bleibt das Runtime-Image schlank, +während Vitest dennoch gegen Ihren exakt lokalen Quellcode/Ihre lokale Konfiguration ausgeführt wird. +Der Bereitstellungsschritt überspringt große nur lokal vorhandene Caches und App-Build-Ausgaben wie +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` sowie app-lokale `.build`- oder +Gradle-Ausgabeverzeichnisse, sodass Docker-Live-Läufe nicht Minuten mit dem Kopieren maschinenspezifischer Artefakte verbringen. -Sie setzen außerdem `OPENCLAW_SKIP_CHANNELS=1`, damit Gateway-Live-Probes im Container -keine echten Telegram-/Discord-/usw.-Kanal-Worker starten. -`test:docker:live-models` führt weiterhin `pnpm test:live` aus, also geben Sie -auch `OPENCLAW_LIVE_GATEWAY_*` weiter, wenn Sie die Gateway- -Live-Abdeckung in dieser Docker-Lane eingrenzen oder ausschließen müssen. -`test:docker:openwebui` ist ein Compatibility-Smoke auf höherer Ebene: Er startet einen -OpenClaw-Gateway-Container mit aktivierten OpenAI-kompatiblen HTTP-Endpunkten, +Sie setzen außerdem `OPENCLAW_SKIP_CHANNELS=1`, damit Gateway-Live-Probes keine +echten Kanal-Worker für Telegram/Discord/etc. innerhalb des Containers starten. +`test:docker:live-models` führt weiterhin `pnpm test:live` aus, geben Sie daher +auch `OPENCLAW_LIVE_GATEWAY_*` weiter, wenn Sie Gateway-Live-Abdeckung in dieser Docker-Lane +eingrenzen oder ausschließen möchten. +`test:docker:openwebui` ist ein Smoke-Test zur Kompatibilität auf höherer Ebene: Er startet einen +OpenClaw-Gateway-Container mit aktivierten OpenAI-kompatiblen HTTP-Endpoints, startet einen angehefteten Open-WebUI-Container gegen dieses Gateway, meldet sich über Open WebUI an, verifiziert, dass `/api/models` `openclaw/default` bereitstellt, und sendet dann eine echte Chat-Anfrage über den Proxy `/api/chat/completions` von Open WebUI. -Der erste Lauf kann spürbar langsamer sein, weil Docker möglicherweise das -Open-WebUI-Image ziehen muss und Open WebUI möglicherweise erst seinen eigenen Kaltstart abschließen muss. -Diese Lane erwartet einen nutzbaren Live-Modellschlüssel, und `OPENCLAW_PROFILE_FILE` +Der erste Lauf kann merklich langsamer sein, weil Docker möglicherweise zuerst das +Open-WebUI-Image ziehen muss und Open WebUI möglicherweise sein eigenes Cold-Start-Setup abschließen muss. +Diese Lane erwartet einen nutzbaren Live-Modell-Schlüssel, und `OPENCLAW_PROFILE_FILE` (`~/.profile` standardmäßig) ist der primäre Weg, ihn in Docker-Läufen bereitzustellen. -Erfolgreiche Läufe geben ein kleines JSON-Payload wie `{ "ok": true, "model": +Erfolgreiche Läufe geben eine kleine JSON-Payload wie `{ "ok": true, "model": "openclaw/default", ... }` aus. `test:docker:mcp-channels` ist bewusst deterministisch und benötigt kein -echtes Telegram-, Discord- oder iMessage-Konto. Es startet einen seeded Gateway- -Container, startet einen zweiten Container, der `openclaw mcp serve` aufruft, und -verifiziert dann Routing für Konversationserkennung, Lesen von Transkripten, Anhangsmetadaten, -Verhalten der Live-Ereigniswarteschlange, Routing ausgehender Sends sowie Claude-artige Kanal- + +echtes Telegram-, Discord- oder iMessage-Konto. Es startet einen vorinitialisierten Gateway- +Container, startet einen zweiten Container, der `openclaw mcp serve` ausführt, und +verifiziert dann geroutete Konversationserkennung, Transkript-Lesevorgänge, Anhangsmetadaten, +Verhalten der Live-Ereigniswarteschlange, Routing ausgehender Send-Vorgänge sowie Claude-artige Kanal- + Berechtigungsbenachrichtigungen über die echte stdio-MCP-Bridge. Die Benachrichtigungsprüfung -untersucht die rohen stdio-MCP-Frames direkt, sodass der Smoke validiert, was die -Bridge tatsächlich ausgibt, und nicht nur das, was ein bestimmtes Client-SDK zufällig sichtbar macht. +untersucht die rohen stdio-MCP-Frames direkt, sodass der Smoke das validiert, was die +Bridge tatsächlich ausgibt, nicht nur das, was ein bestimmtes Client-SDK zufällig bereitstellt. -Manueller ACP-Plain-Language-Thread-Smoke (nicht CI): +Manueller Plain-Language-Thread-Smoke für ACP (nicht CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Behalten Sie dieses Skript für Regressions-/Debug-Workflows. Es könnte für die Validierung des ACP-Thread-Routings erneut benötigt werden, also nicht löschen. +- Behalten Sie dieses Skript für Regressionen/Debugging-Workflows. Es könnte erneut für die Validierung des ACP-Thread-Routings benötigt werden, also löschen Sie es nicht. Nützliche Env-Variablen: -- `OPENCLAW_CONFIG_DIR=...` (Standard: `~/.openclaw`) eingebunden nach `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (Standard: `~/.openclaw/workspace`) eingebunden nach `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (Standard: `~/.profile`) eingebunden nach `/home/node/.profile` und vor dem Ausführen der Tests gesourct -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (Standard: `~/.cache/openclaw/docker-cli-tools`) eingebunden nach `/home/node/.npm-global` für gecachte CLI-Installationen innerhalb von Docker -- Externe CLI-Auth-Verzeichnisse/-Dateien unter `$HOME` werden schreibgeschützt unter `/host-auth...` eingebunden und dann vor dem Start der Tests nach `/home/node/...` kopiert +- `OPENCLAW_CONFIG_DIR=...` (Standard: `~/.openclaw`) wird nach `/home/node/.openclaw` eingehängt +- `OPENCLAW_WORKSPACE_DIR=...` (Standard: `~/.openclaw/workspace`) wird nach `/home/node/.openclaw/workspace` eingehängt +- `OPENCLAW_PROFILE_FILE=...` (Standard: `~/.profile`) wird nach `/home/node/.profile` eingehängt und vor dem Ausführen der Tests gesourct +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (Standard: `~/.cache/openclaw/docker-cli-tools`) wird nach `/home/node/.npm-global` eingehängt für zwischengespeicherte CLI-Installationen innerhalb von Docker +- Externe CLI-Auth-Verzeichnisse/-Dateien unter `$HOME` werden schreibgeschützt unter `/host-auth...` eingehängt und dann vor dem Teststart nach `/home/node/...` kopiert - Standardverzeichnisse: `.minimax` - Standarddateien: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Eingegrenzte Provider-Läufe binden nur die benötigten Verzeichnisse/Dateien ein, die aus `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` abgeleitet werden - - Manuell überschreiben mit `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` oder einer Komma-Liste wie `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Eingegrenzte Provider-Läufe hängen nur die benötigten Verzeichnisse/Dateien ein, die aus `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` abgeleitet werden + - Manuelles Überschreiben mit `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` oder einer Komma-Liste wie `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, um den Lauf einzugrenzen - `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, um Provider im Container zu filtern -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, um ein vorhandenes Image `openclaw:local-live` für Wiederholungsläufe zu verwenden, die keinen Neuaufbau benötigen -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um sicherzustellen, dass Credentials aus dem Profile Store kommen (nicht aus Env) -- `OPENCLAW_OPENWEBUI_MODEL=...`, um das vom Gateway für den Open-WebUI-Smoke bereitgestellte Modell auszuwählen -- `OPENCLAW_OPENWEBUI_PROMPT=...`, um den für den Open-WebUI-Smoke verwendeten Prompt für die Nonce-Prüfung zu überschreiben -- `OPENWEBUI_IMAGE=...`, um den angehefteten Tag des Open-WebUI-Images zu überschreiben +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, um ein vorhandenes Image `openclaw:local-live` für erneute Läufe zu verwenden, die keinen Neubau benötigen +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um sicherzustellen, dass Anmeldedaten aus dem Profilspeicher stammen (nicht aus Env) +- `OPENCLAW_OPENWEBUI_MODEL=...`, um das Modell auszuwählen, das vom Gateway für den Open-WebUI-Smoke bereitgestellt wird +- `OPENCLAW_OPENWEBUI_PROMPT=...`, um den für den Open-WebUI-Smoke verwendeten Nonce-Check-Prompt zu überschreiben +- `OPENWEBUI_IMAGE=...`, um den angehefteten Open-WebUI-Image-Tag zu überschreiben -## Doku-Sanity +## Dokumentations-Plausibilitätsprüfung -Führen Sie nach Doku-Änderungen Doku-Prüfungen aus: `pnpm check:docs`. -Führen Sie die vollständige Mintlify-Anchor-Validierung aus, wenn Sie zusätzlich In-Page-Überschriftenprüfungen benötigen: `pnpm docs:check-links:anchors`. +Führen Sie nach Änderungen an der Dokumentation die Doku-Prüfungen aus: `pnpm check:docs`. +Führen Sie die vollständige Mintlify-Anchor-Validierung aus, wenn Sie zusätzlich In-Page-Heading-Prüfungen benötigen: `pnpm docs:check-links:anchors`. ## Offline-Regression (CI-sicher) Dies sind Regressionen der „echten Pipeline“ ohne echte Provider: -- Gateway-Tool-Calling (Mock OpenAI, echtes Gateway + echte Agent-Schleife): `src/gateway/gateway.test.ts` (Fall: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Gateway-Assistent (WS `wizard.start`/`wizard.next`, schreibt Konfiguration + Auth erzwungen): `src/gateway/gateway.test.ts` (Fall: "runs wizard over ws and writes auth token config") +- Gateway-Tool-Calling (gemocktes OpenAI, echtes Gateway + Agent-Loop): `src/gateway/gateway.test.ts` (Fall: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Gateway-Assistent (WS `wizard.start`/`wizard.next`, schreibt Konfiguration + erzwungene Authentifizierung): `src/gateway/gateway.test.ts` (Fall: "runs wizard over ws and writes auth token config") -## Agent-Zuverlässigkeitsevals (Skills) +## Evaluierungen der Agent-Zuverlässigkeit (Skills) -Wir haben bereits einige CI-sichere Tests, die sich wie „Agent-Zuverlässigkeitsevals“ verhalten: +Wir haben bereits einige CI-sichere Tests, die sich wie „Evaluierungen der Agent-Zuverlässigkeit“ verhalten: -- Mock-Tool-Calling über das echte Gateway + die echte Agent-Schleife (`src/gateway/gateway.test.ts`). -- End-to-End-Assistentenabläufe, die Sitzungsverdrahtung und Konfigurationseffekte validieren (`src/gateway/gateway.test.ts`). +- Gemocktes Tool-Calling durch die echte Gateway-+Agent-Loop (`src/gateway/gateway.test.ts`). +- End-to-End-Abläufe des Assistenten, die Sitzungsverdrahtung und Konfigurationseffekte validieren (`src/gateway/gateway.test.ts`). Was für Skills noch fehlt (siehe [Skills](/de/tools/skills)): -- **Entscheidungsverhalten:** Wenn Skills im Prompt aufgelistet sind, wählt der Agent dann den richtigen Skill (oder vermeidet irrelevante)? -- **Compliance:** Liest der Agent vor der Verwendung `SKILL.md` und befolgt erforderliche Schritte/Args? -- **Workflow-Verträge:** Multi-Turn-Szenarien, die Tool-Reihenfolge, Übernahme des Sitzungsverlaufs und Sandbox-Grenzen prüfen. +- **Entscheidungsfindung:** Wählt der Agent, wenn Skills im Prompt aufgeführt sind, den richtigen Skill aus (oder vermeidet irrelevante)? +- **Compliance:** Liest der Agent vor der Verwendung `SKILL.md` und befolgt die erforderlichen Schritte/Argumente? +- **Workflow-Verträge:** Mehrzügige Szenarien, die Tool-Reihenfolge, Übernahme des Sitzungsverlaufs und Sandbox-Grenzen prüfen. -Zukünftige Evals sollten zunächst deterministisch bleiben: +Zukünftige Evaluierungen sollten zuerst deterministisch bleiben: -- Ein Szenario-Runner mit Mock-Providern, um Tool-Aufrufe + Reihenfolge, Skill-Datei-Lesevorgänge und Sitzungsverdrahtung zu prüfen. -- Eine kleine Suite skill-fokussierter Szenarien (verwenden vs. vermeiden, Gating, Prompt Injection). -- Optionale Live-Evals (opt-in, env-gesteuert) erst, nachdem die CI-sichere Suite vorhanden ist. +- Ein Szenario-Runner mit gemockten Providern, der Tool-Aufrufe + Reihenfolge, Skill-Dateilesevorgänge und Sitzungsverdrahtung prüft. +- Eine kleine Suite skillfokussierter Szenarien (verwenden vs. vermeiden, Gating, Prompt-Injection). +- Optionale Live-Evaluierungen (Opt-in, env-gesteuert) erst, nachdem die CI-sichere Suite vorhanden ist. ## Vertragstests (Plugin- und Kanalform) -Vertragstests verifizieren, dass jedes registrierte Plugin und jeder Kanal seinem +Vertragstests prüfen, dass jedes registrierte Plugin und jeder Kanal seinem Schnittstellenvertrag entspricht. Sie iterieren über alle erkannten Plugins und führen eine Suite von -Form- und Verhaltens-Assertions aus. Die standardmäßige Unit-Lane `pnpm test` -überspringt diese gemeinsamen Nahtstellen- und Smoke-Dateien absichtlich; führen Sie die Vertragsbefehle explizit aus, -wenn Sie gemeinsame Kanal- oder Provider-Oberflächen ändern. +Assertions zu Form und Verhalten aus. Die standardmäßige Unit-Lane `pnpm test` +überspringt diese gemeinsamen Seam- und Smoke-Dateien absichtlich; führen Sie die Vertragsbefehle explizit +aus, wenn Sie gemeinsame Kanal- oder Provider-Oberflächen ändern. ### Befehle @@ -882,13 +942,13 @@ wenn Sie gemeinsame Kanal- oder Provider-Oberflächen ändern. Befinden sich in `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Grundlegende Plugin-Form (ID, Name, Capabilities) +- **plugin** - Grundlegende Plugin-Form (ID, Name, Fähigkeiten) - **setup** - Vertrag des Setup-Assistenten -- **session-binding** - Verhalten der Sitzungsbindung -- **outbound-payload** - Struktur der Nachrichten-Payload +- **session-binding** - Verhalten beim Session-Binding +- **outbound-payload** - Struktur der Message-Payload - **inbound** - Verarbeitung eingehender Nachrichten - **actions** - Handler für Kanalaktionen -- **threading** - Verarbeitung von Thread-IDs +- **threading** - Umgang mit Thread-IDs - **directory** - API für Verzeichnis/Roster - **group-policy** - Durchsetzung von Gruppenrichtlinien @@ -896,39 +956,39 @@ Befinden sich in `src/channels/plugins/contracts/*.contract.test.ts`: Befinden sich in `src/plugins/contracts/*.contract.test.ts`. -- **status** - Status-Probes für Kanäle +- **status** - Kanal-Status-Probes - **registry** - Form der Plugin-Registry ### Provider-Verträge Befinden sich in `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Vertrag des Auth-Flows +- **auth** - Vertrag des Auth-Ablaufs - **auth-choice** - Auth-Auswahl/Selektion - **catalog** - API des Modellkatalogs -- **discovery** - Plugin-Discovery +- **discovery** - Plugin-Erkennung - **loader** - Plugin-Laden - **runtime** - Provider-Laufzeit -- **shape** - Plugin-Form/Schnittstelle +- **shape** - Plugin-Form/-Schnittstelle - **wizard** - Setup-Assistent ### Wann ausführen - Nach Änderungen an `plugin-sdk`-Exports oder Subpaths -- Nach dem Hinzufügen oder Ändern eines Kanal- oder Provider-Plugin -- Nach Refactorings an Plugin-Registrierung oder Discovery +- Nach dem Hinzufügen oder Ändern eines Kanal- oder Provider-Plugins +- Nach Refactorings an Plugin-Registrierung oder -Erkennung -Vertragstests laufen in CI und benötigen keine echten API-Schlüssel. +Vertragstests laufen in CI und erfordern keine echten API-Schlüssel. -## Regressionen hinzufügen (Leitfaden) +## Regressionen hinzufügen (Anleitung) Wenn Sie ein in Live entdecktes Provider-/Modellproblem beheben: -- Fügen Sie nach Möglichkeit eine CI-sichere Regression hinzu (Mock/Stub-Provider oder erfassen Sie die exakte Transformation der Request-Form) -- Wenn es von Natur aus nur live testbar ist (Rate Limits, Auth-Richtlinien), halten Sie den Live-Test eng eingegrenzt und über Env-Variablen opt-in +- Fügen Sie nach Möglichkeit eine CI-sichere Regression hinzu (Provider mocken/stubben oder die exakte Transformation der Request-Form erfassen) +- Wenn das Problem inhärent nur live auftritt (Rate Limits, Auth-Richtlinien), halten Sie den Live-Test eng gefasst und per Env-Variablen opt-in - Zielen Sie bevorzugt auf die kleinste Ebene, die den Fehler erkennt: - - Fehler bei Provider-Request-Konvertierung/-Replay → direkter Modelltst + - Fehler bei Provider-Request-Konvertierung/-Replay → Test für direkte Modelle - Fehler in Gateway-Sitzung/Verlauf/Tool-Pipeline → Gateway-Live-Smoke oder CI-sicherer Gateway-Mock-Test -- Guardrail für SecretRef-Traversal: - - `src/secrets/exec-secret-ref-id-parity.test.ts` leitet aus Registry-Metadaten (`listSecretTargetRegistryEntries()`) ein Beispielziel pro SecretRef-Klasse ab und prüft dann, dass Exec-IDs von Traversal-Segmenten abgelehnt werden. - - Wenn Sie in `src/secrets/target-registry-data.ts` eine neue Ziel-Familie für `includeInPlan`-SecretRef hinzufügen, aktualisieren Sie `classifyTargetClass` in diesem Test. Der Test schlägt absichtlich bei nicht klassifizierten Ziel-IDs fehl, damit neue Klassen nicht stillschweigend übersprungen werden können. +- SecretRef-Traversal-Geländer: + - `src/secrets/exec-secret-ref-id-parity.test.ts` leitet aus Registry-Metadaten (`listSecretTargetRegistryEntries()`) ein gesampeltes Ziel pro SecretRef-Klasse ab und prüft dann, dass Exec-IDs mit Traversal-Segmenten zurückgewiesen werden. + - Wenn Sie in `src/secrets/target-registry-data.ts` eine neue SecretRef-Zielfamilie `includeInPlan` hinzufügen, aktualisieren Sie `classifyTargetClass` in diesem Test. Der Test schlägt absichtlich bei nicht klassifizierten Ziel-IDs fehl, damit neue Klassen nicht stillschweigend übersprungen werden.