Ein Prompt wird zu einer geprüften, getesteten, dokumentierten und gemergten Änderung — während man etwas anderes erledigt. Die Pipeline hat 12 Schritte und kümmert sich um alle.

Die Pipeline

Was man bekommt

• Jeder Task arbeitet auf einem eigenen, isolierten Branch, sodass parallele Tasks nie kollidieren und der Hauptcode sicher bleibt.
• Ein KI-Review und automatische Korrekturen erfolgen, bevor das Ergebnis überhaupt zu sehen ist.
• Unit- und End-to-End-Tests werden automatisch ausgeführt.
• Das Ergebnis wird gegen die angegebenen Akzeptanzkriterien geprüft.
• Dokumentation und Behavioral Contracts werden automatisch aktuell gehalten.
• Merges werden eingereiht, und der Build muss bestehen, bevor eine Änderung landet.
• Schlägt etwas fehl, erholt sich AITM selbstständig, und es kann ab jedem Schritt fortgesetzt werden.
• Jeder Task hinterlässt eine lesbare Ergebniszusammenfassung und einen Verlauf.

Die 12 Schritte

1. Branch — der Task bekommt einen eigenen sicheren Arbeitsbereich, der nicht mit anderen Tasks kollidieren kann. Ergebnis: der Hauptcode bleibt unangetastet, bis die Arbeit fertig ist.
2. Architect — die KI liest den Prompt und den relevanten Code und plant die Lösung. Ergebnis: ein durchdachter Plan, welche Teile des Projekts sich ändern.
3. Code — aus dem Plan werden tatsächliche Dateiänderungen. Ergebnis: die fertige Implementierung.
4. Compliance-check — vergleicht bei komplexen Tasks den Diff unabhängig mit den Anforderungen. Einfachere Tasks werden übersprungen, Befunde gehen an Review. Ergebnis: frühe Warnung vor übersehenen Anforderungen.
5. Review — die KI prüft die Arbeit wie ein Kollege und gibt ein Urteil ab. Ergebnis: ein zweites Augenpaar, ohne auf einen Menschen zu warten.
6. Fix — behebt alles, was Review beanstandet hat; kann einige Male mit Review im Wechsel laufen. Ergebnis: ein bereinigtes Ergebnis.
7. Test — führt die automatisierten Unit-Tests des Projekts aus. Ergebnis: Sicherheit, dass die Änderung bestehendes Verhalten nicht gebrochen hat.
8. E2E — führt Tests aus, die die App wie ein echter Benutzer bedienen. Läuft nur, wenn das Projekt End-to-End-Tests hat, parallel zu Test. Ergebnis: die gesamte Benutzerreise ist verifiziert.
9. Verify — vergleicht das Ergebnis mit den Akzeptanzkriterien des Tasks; jedes endet als bestanden, fehlgeschlagen oder nicht verifizierbar. Ergebnis: eine klare Antwort, ob der Task tut, was verlangt wurde.
10. Snapshot — optionaler Schritt, der Screenshots der UI aufnimmt. Ergebnis: eine visuelle Dokumentation der Änderung.
11. Docs — aktualisiert Dokumentation und Behavioral Contracts entsprechend der Änderung. Läuft immer. Ergebnis: Dokumentation, die nicht veraltet.
12. Chain-audit — arbeitet nur am letzten Task einer Kette abhängiger Tasks und prüft die Kriterien aller früheren Tasks erneut. Ergebnis: Gewissheit, dass die ganze Kette zusammenhält.

Das Mergen ist kein Pipeline-Schritt — nach dem letzten Schritt tritt der Task in die Merge-Queue ein, die ihn in den dev-Branch mergt. Bis dahin zeigt ein fertiger Task die Markierung Finalizing…. Details siehe Merging, Post-Merge Fixes & Scope Gate.

Wo man eingreift

• Das Task-Ergebnis wird geprüft — siehe Ergebnisse lesen & Archiv.
• Der Prompt wird angepasst, wenn das Ergebnis nicht der Absicht entspricht.
• Es wird ab einem Schritt fortgesetzt oder der Task neu eingereiht, wenn eine Pipeline gestoppt wurde.

Wenn ein Schritt fehlschlägt

Ein hängender Schritt wird automatisch wiederholt; die Anzahl der Wiederholungen wird unter Settings → Pipeline festgelegt. Ist der Build nach der Synchronisation mit dev rot, wird ein Reparaturversuch unternommen, und bei Merge-Konflikten wird zuerst eine KI-gestützte Auflösung versucht. Reicht das nicht, bleibt der Task markiert und der Grund wird angezeigt. Die Karte eines fehlgeschlagenen oder konfliktbehafteten Tasks bietet dann eine Schaltfläche mit einem Wiederherstellungsvorschlag.