<span id="scenario-guide-test-results" />

# Testergebnisse der Szenario-Anleitungen

Am 2026-09-07 haben wir diese Anleitungen in einem separaten Testprojekt mit Lizard CLI 0.3.92 geprüft. Anwendungsprüfungen sind vom Build-Status getrennt. Die Tests verwendeten die Befehle aus den Anleitungen, mit einem eigenen Projektnamen und dem Dokumentations-Test-Branch für das GitHub-Beispiel.

| Anleitung | Ergebnis | Prüfungen |
|---|---|---|
| [Remote MCP](https://lizard.build/de/docs/guides/deploy-mcp-server) | Lokal und in der Cloud bestanden | Health 200; fehlendes und ungültiges Token 401; authentifiziertes GET 405; abgelehnter Origin 403; initialize, tools/list und tools/call; Ergebnis `5` über öffentliches HTTPS |
| [Coding-Agent: Upload](https://lizard.build/de/docs/guides/deploy-from-coding-agent) | Bestanden | `lizard up`, Health 200, datenbankgestützte Antwort 200, unbekannte Route 404; eine aktualisierte Postgres-Zeile blieb nach einem Service-Neustart erhalten |
| [Coding-Agent: GitHub](https://lizard.build/de/docs/guides/deploy-from-coding-agent) | Bestanden | Repository mit `--no-deploy` verknüpft; Branch, Stammverzeichnis und Umgebung vor `redeploy` konfiguriert; die öffentliche App las dieselbe vorhandene Postgres-Zeile |
| [Redis worker](https://lizard.build/de/docs/deploy/workers) | Bestanden | Port 0; enqueue und Ergebnis; Ergebnis nach Neustart beibehalten; neuer Job nach Neustart; ein nicht abgeschlossener Verarbeitungseintrag wurde beim Start wiederhergestellt |
| [Telegram bot](https://lizard.build/de/docs/guides/telegram-bot) | Nur lokale Tests | Sieben gemockte Tests decken Updates, fehlgeschlagene Sends, Token-Prüfungen und Webhook-Ablehnung ab. Ein echter Token-, Chat- und Cloud-Echo-Test ist weiterhin erforderlich |

<span id="versions" />

## Versionen

Der MCP-Container lief mit Node.js 22.23.2 und MCP TypeScript SDK 1.30.0. Das coding-agent-Beispiel verwendet `pg` 8.16.3 und war mit Managed Postgres verbunden, auf dem PostgreSQL 18.4 lief. Der Worker-Container lief mit Python 3.13.15 und redis-py 6.4.0. Lockfiles für Abhängigkeiten oder exakte Requirements liegen bei den Beispielen.

<span id="scope" />

## Umfang

Die MCP-Prüfung deckt den zustandslosen HTTP-Transport des Beispiels und ein festes Bearer-Token ab. Sie stellt keine OAuth-Kompatibilität, Browser-Unterstützung, Streaming über lange Zeiträume oder Lastkapazität fest. Das Token läuft nach einer Stunde ab.

Die GitHub-Prüfung verwendete den Dokumentations-Branch und das Verzeichnis `_examples/agent-app`. Sie testete ein explizites Redeploy; nicht getestet wurden jede Berechtigungskonfiguration für private Repositories oder jedes Webhook-Ereignis.

Die Redis-Wiederherstellungsprüfung legte vor dem Neustart eines einzelnen Consumers einen nicht abgeschlossenen Verarbeitungseintrag an. Nicht getestet wurden Redis-Ausfall, mehrere Worker oder genau-einmalige externe Effekte. Die Datenbankprüfung belegt Persistenz über einen Anwendungsneustart hinweg, nicht Backup oder Disaster Recovery.

Die Laufzeit-Log-Tails waren für die Test-Services anfangs leer. Ein Live-Log-Stream des Workers lieferte später einen neu verarbeiteten Job. Verwende die HTTP-, MCP-Client- und Job-Ergebnis-Prüfungen als Abschlusskriterien; ein leerer Log-Tail allein belegt weder Erfolg noch Misserfolg.

Das Telegram-Beispiel ist nicht als cloud-verifiziert markiert. Sein Preflight liest `getMe` und `getWebhookInfo`, ohne den Webhook des Bots zu ändern. Verwende einen separaten Test-Bot, bevor du seine Polling-Schleife aktivierst.

Siehe [Framework-Testergebnisse](https://lizard.build/de/docs/framework-guides/validation) für den separaten Framework-Batch mit 16 Rezepten und [known issues](https://lizard.build/de/docs/platform/known-issues) für CLI-Archiv- und Exit-Code-Einschränkungen bei fehlgeschlagenen Builds.