Sobald ein Task fertig gelaufen ist, soll bekannt sein, was tatsächlich passiert ist — was sich geändert hat, ob es funktioniert hat und, falls etwas schiefging, wie es weitergeht.
Ergebnisse lesen & Archiv
Das Ergebnis eines abgeschlossenen Tasks öffnen
Ein Klick auf eine beliebige Task-Karte — laufend, abgeschlossen oder archiviert — öffnet die Ergebnisansicht. Zu sehen sind:
- Eine Zusammenfassung dessen, was getan wurde und warum
- Die vollständige Liste der geänderten Dateien
- Die Ergebnisse der Pipeline-Schritte (bestanden/fehlgeschlagen pro Schritt)
- Alle während des Laufs aufgenommenen Screenshots, wenn der optionale Schritt Snapshot aktiviert war
- Metadaten: Zeitangaben, welcher KI-Provider bzw. welches Modell den Task bearbeitet hat, und ein Link zum Git-Commit
Urteile verstehen
Zwei Arten automatisierter Prüfungen erzeugen ein Urteil. Das Unit-Test-Urteil ist ein einfaches Bestanden oder Fehlgeschlagen auf Grundlage der vorhandenen Test-Suite des Projekts. Das End-to-End-(E2E-)Urteil hat einige mehr mögliche Ausgänge, da E2E-Tests die echte laufende App ausführen:
| Urteil | Bedeutung |
|---|---|
PASS | Alle End-to-End-Szenarien wurden bestanden |
FEATURE_BUG | Der E2E-Test hat einen echten Bug im implementierten Feature gefunden |
ENHANCEMENT_REQUEST | Die Tests haben gezeigt, dass das Feature funktioniert, aber etwas fehlt, das später ergänzt werden sollte |
DATA_ISSUE | Der Fehlschlag wurde durch Testdaten oder den Zustand der Umgebung verursacht, nicht durch den Code selbst |
ENVIRONMENT_ERROR | Die Testumgebung selbst hatte ein Problem (z. B. lief ein Dienst nicht) — kein Rückschluss auf den Code |
UNKNOWN | Das Ergebnis konnte nicht automatisch klassifiziert werden und braucht einen menschlichen Blick |
Einen fehlgeschlagenen Task behandeln
Der Status failed bedeutet, dass die Pipeline auf etwas gestoßen ist, das sie innerhalb ihres Wiederholungsbudgets nicht selbst lösen konnte. Der Task wird geöffnet, um zu sehen, welcher Schritt fehlgeschlagen ist, mit dem erfassten Grund sowie der Diagnose des Watchdog, falls dieser zuvor eine automatische Wiederherstellung versucht hat. Von dort lässt sich der Task in der Regel ab dem fehlgeschlagenen Schritt (oder einem früheren, wenn die Korrektur weiter vorn ansetzen muss) fortsetzen, statt von vorn zu beginnen — AITM bewahrt alles, was bereits erfolgreich war.
Einen Konflikt behandeln
Der Status conflict bedeutet, dass der automatische Git-Merge von AITM auf einen echten Konflikt gestoßen ist — zwei Änderungen, die dieselben Zeilen auf unvereinbare Weise betreffen —, den der KI-gestützte Lösungsversuch nicht sicher allein beilegen konnte. In diesem Fall zeigt AITM genau, welche Dateien in Konflikt geraten sind, damit er gelöst werden kann; es wird nie geraten und stillschweigend eine Seite gewählt, wenn beide Änderungen beabsichtigt wirken.
Das Archiv
Sobald ein Task abgeschlossen und seine Änderung nach dev gemergt ist, wird er im Archiv abgelegt — einer durchsuchbaren Aufzeichnung jedes abgeschlossenen Tasks, die neuesten zuerst, mit Titel, Projekt, Abschlussdatum und Endstatus. Es ist der dauerhafte Prüfpfad.
Im Archiv lassen sich Tasks durchsuchen und filtern (nach Projekt, Datum oder Status) und der vollständige Datensatz jedes Tasks öffnen: der ursprüngliche Prompt, die Pipeline-Schritte, das Review-Urteil, die Testergebnisse und eine allgemeinverständliche Zusammenfassung der Änderungen, geschrieben vom Schritt Docs. Ein archivierter Task ist nicht weggesperrt — Restore stellt ihn wieder in die Warteschlange. Für eine Variation früherer Arbeit ist meist ein neuer Task sauberer, der den archivierten Prompt als Ausgangspunkt verwendet.
Gut zu wissen
- Schlägt ein Task fehl, wird er ab dem fehlgeschlagenen Schritt fortgesetzt, statt von vorn zu beginnen — alles bereits Erfolgreiche bleibt erhalten.
- Bleibt die KI mitten im Task hängen, setzt der Watchdog ihn automatisch fort, bis zu einer begrenzten Zahl von Versuchen, bevor er ihn als
failedmarkiert. - Da jeder Task im Archiv einen vollständigen Datensatz hinterlässt, dient es zugleich als Dokumentation dafür, warum das Projekt so aussieht, wie es aussieht.