XAIO
Docs/Testing/Auto-Fix & Pre-Flight Validation

Auto-Fix & Pre-Flight Validation

Aktualisiert 3. Mai 2026Testing

Automatische Guardrails: Build Auto-Fixer, Pre-Flight Validierung vor dem Veröffentlichen, Fix-Errors-Button.

Neben aktiv geforderten Tests hat XAIO drei automatische Sicherheitsnetze, die im Hintergrund laufen — du musst nichts dafür tun.

Build Auto-Fixer

Wenn `npm run build` während des Veröffentlichens fehlschlägt, übernimmt ein kleineres KI-Modell automatisch den Fix-Versuch. Es bekommt:

  • Die Fehler-Stack-Trace
  • Den relevanten Code-Ausschnitt
  • Den Build-Kontext (TypeScript-Version, dependencies, etc.)

Es darf bis zu 2 Mal retryen. Falls auch der zweite Fix fehlschlägt, wird die Veröffentlichung abgebrochen und du bekommst einen Bericht im Chat — mit Diff was probiert wurde, damit du es nicht nochmal manuell anstoßen musst.

Konversation und Diff bleiben in der Publish-Historie sichtbar.

Backend Pre-Flight Validation

Vor jedem Publish eines Web-App-Projekts macht XAIO automatisch einen Smoke-Check gegen alle Backend-Routen:

1. Backend startet im Publish-Container

2. Pro Route ein einfacher GET/POST mit Default-Payload

3. Wenn eine Route 500 Internal Server Error wirft → Publish wird blockiert

4. Im Publish-Dialog erscheint die fehlschlagende Route + Stack-Trace

Das verhindert, dass du eine kaputte Backend-Version live nimmst.

Fix-Errors-Button

Im Workspace Backend-Tab und Preview-Tab gibt es einen Fix Errors-Button, der erscheint, sobald Errors auflaufen (rotes Badge mit Count).

Klick auf den Button:

1. Sammelt die letzten Errors (Logs, Tracebacks, Console-Errors)

2. Schickt sie als context-injected Message in den Chat

3. Der Agent priorisiert sie automatisch und schlägt Fixes vor

Du musst keine Log-Zeilen kopieren oder Stack-Traces tippen.

Wann der Agent von sich aus testet

Der Chat-Agent läuft Tests freiwillig, ohne expliziten Auftrag, in diesen Fällen:

  • Nach größeren Refactorings (mehrere Dateien geändert) → kurze Smoke-Tests
  • Nach Migration-Änderungen → Up + Down-Test, Daten-Roundtrip
  • Vor git push wenn Pre-Push-Hook konfiguriert ist
  • Nach Auto-Fix → erneuter Build-Test bevor das Resultat zurückgegeben wird

Manuelle Pre-Flight

Wenn du selbst eine Pre-Flight ausführen willst, ohne zu publishen:

> Lass die Pre-Flight Validation manuell laufen — ich will erst wissen ob alles passt, bevor ich publishe.

Der Agent macht den gleichen Smoke-Check, gibt dir aber nur den Bericht zurück ohne tatsächlich zu publishen.