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 | 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 | 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 | Bestanden | Repository mit --no-deploy verknüpft; Branch, Stammverzeichnis und Umgebung vor redeploy konfiguriert; die öffentliche App las dieselbe vorhandene Postgres-Zeile |
| Redis worker | Bestanden | Port 0; enqueue und Ergebnis; Ergebnis nach Neustart beibehalten; neuer Job nach Neustart; ein nicht abgeschlossener Verarbeitungseintrag wurde beim Start wiederhergestellt |
| 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 |
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.
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 für den separaten Framework-Batch mit 16 Rezepten und known issues für CLI-Archiv- und Exit-Code-Einschränkungen bei fehlgeschlagenen Builds.