Wie AITM fertige Arbeit nach dev mergt, Testfehlschläge nach dem Merge durch Vorwärtskorrektur statt Revert behebt und prüft, dass ein Task nur das berührt hat, was er berühren sollte.

Merging, Post-Merge Fixes & Scope Gate

Wie das Mergen funktioniert

Jeder Task läuft in einem eigenen Git-Branch/Worktree. Sobald die Pipeline abgeschlossen ist (Implementierung, Review und Tests sind alle grün), tritt der Task in die Merge-Queue von AITM ein — eine serialisierte Warteschlange, damit gleichzeitige Tasks nie zur selben Zeit nach dev mergen und sich gegenseitig die Änderungen überschreiben.

  • Automatischer Merge-Auslöser. Ein Task mit aktiviertem autoMergeDev wird nach Abschluss seiner Pipeline automatisch nach dev gemergt — ohne manuelle Freigabe, sodass fertige Arbeit laufend landet, statt sich anzusammeln und darauf zu warten, dass jemand auf Merge klickt.
  • Build-Gate vor dem Merge. Der Branch des Tasks wird zunächst auf den aktuellen Stand von dev gebracht und dann so gebaut und typgeprüft, wie er nach dem Merge aussehen wird. Ist die Prüfung rot, erhält ein Fix-Agent eine begrenzte Zahl von Versuchen; Fehler, die bereits auf dev bestehen, werden dem Task nicht angelastet. Bleibt das Gate rot, wird der Task nicht gemergt und endet in conflict, wobei die Build-Ausgabe angehängt wird.
  • Konfliktbehandlung. Steht der Branch eines Tasks im Konflikt mit dem, was bereits in dev gelandet ist, wiederholt AITM den Merge mit unterschiedlichen Strategien und übergibt die in Konflikt stehenden Dateien dann an einen KI-Konfliktlöser, der beide Änderungen zusammenführt und das Build-Gate erneut ausführt. Ein in conflict wartender Task wird automatisch erneut geprüft; ist die Ursache inzwischen verschwunden, heilt er sich selbst und fährt mit dem Merge fort.
  • Kontrollierter Merge nach dev. Merges erfolgen nacheinander aus der Queue, sodass dev nie in einem halb gemergten Zustand ist. Das Mergen ist kein Pipeline-Schritt: Der Task zeigt finished mit einer Markierung Finalizing… und wird archived, sobald der Merge gelandet ist. Solange ein Task in conflict bleibt, warten andere Tasks in der Queue desselben Tabs hinter ihm — es lohnt sich daher, ihn zeitnah zu lösen.
Ein fertiger Task wird finalisiert und gemergt
Ein fertiger Task wird finalisiert und in dev gemergt.

Fehlererkennung und -behebung nach dem Merge

Sobald der Branch eines Tasks nach dev gemergt ist, führt AITM die betroffenen Tests erneut gegen den neuen Stand von dev aus. Schlagen sie nun fehl, besteht die Standardreaktion nicht darin, den Merge zurückzunehmen.

Beispiel: Ein Task fügt einem gemeinsamen Modell ein neues Feld hinzu. Er mergt sauber, und seine eigenen Tests bestehen. Ein anderer Task, der bereits auf einem anderen Branch in Arbeit ist, hing jedoch von der alten Form dieses Modells ab — nachdem beide gelandet sind, beginnt ein gemeinsamer Integrationstest zu scheitern. Statt einen der beiden Merges zurückzunehmen (womit auch die unabhängige, funktionierende Hälfte jeder Änderung verloren ginge), geht AITM so vor:

  1. Isolieren, welche Dateien/Tests tatsächlich fehlschlagen und welche Änderung welches Tasks dafür verantwortlich ist.
  2. Vorwärtskorrektur auf einem Branch — es wird ein Korrektur-Task erzeugt, der nur den fehlschlagenden Bereich anvisiert und vom aktuellen Stand von dev ausgeht (nicht vom Diff eines der ursprünglichen Tasks).
  3. Erneutes Testen der Korrektur in Isolation, bevor sie wieder in die Nähe von dev darf.
  4. Mergen der Korrektur über dieselbe Queue wie jeden anderen Task.

Diese Philosophie der "Vorwärtskorrektur" vermeidet Kaskadenschäden: Einen Merge zurückzunehmen, nachdem andere Arbeit bereits darauf aufgebaut hat, würde eine Kette weiterer Reverts erzwingen. Die eigentliche Störung an Ort und Stelle auf einem eigenen Branch zu beheben, hält den Wirkungsradius auf das eine gefundene Problem begrenzt.

Bewertung des Task-Scopes (Business Scope Gate)

Jeder Task deklariert vorab, welche Dateien er berühren will. Wenn der Task abgeschlossen ist, vergleicht das Business Scope Gate die Dateien, die er tatsächlich geändert hat, mit dieser Deklaration.

  • Außerhalb des Scopes bedeutet, dass eine geänderte Datei nie deklariert wurde und keinen plausiblen Bezug zum erklärten Ziel des Tasks hat — zum Beispiel, wenn ein Task zur Checkout-Seite auch eine nicht zugehörige Admin-Einstellungsdatei bearbeitet.
  • Scope-Ergänzungen. Manchmal ist das Berühren einer nicht deklarierten Datei legitim — ein gemeinsamer Typ musste geändert werden, oder eine Konstante liegt in einer Nachbardatei. In diesem Fall hält der Task eine kurze, ausdrückliche Begründung für die zusätzliche Datei fest (eine "Scope-Ergänzung"), statt stillschweigend die Grenzen zu verlassen. Eine begründete Ergänzung wird akzeptiert; eine unbegründete zusätzliche Datei nicht.
  • Blockierende vs. beratende Verstöße. Nicht jede nicht deklarierte Datei wird gleich behandelt:
    • Blockierend — die geänderte Datei ist dem Task wirklich fremd (anderer Funktionsbereich, keine gemeinsame Abhängigkeit, keine Begründung). Das stoppt den Merge, bis es gelöst ist.
    • Beratend — die geänderte Datei liegt im selben Verzeichnis/Modul wie der deklarierte Scope und steht plausibel damit in Zusammenhang (z. B. eine Nachbardatei im selben Funktionsordner). Sie wird zur Prüfung markiert, blockiert den Merge aber nicht von sich aus.

Was zu einem Bug und was zu einem neuen Task wird

Findet ein Review-Schritt etwas, das über den unmittelbaren Diff hinausgeht, entscheidet AITM zwischen zwei Ergebnissen:

  • Wird zu einem Bug, wenn der Befund ein blockierender Scope-Verstoß oder ein echter Defekt ist, der nichts mit dem zu tun hat, was der Task leisten sollte — etwas, das bereits kaputt ist und einen eigenen Korrekturzyklus braucht, unabhängig vom Ausgang des aktuellen Tasks.
  • Wird zu einem neuen (Folge-)Task, wenn der Befund eine Verfeinerung, eine wünschenswerte Verbesserung oder eine berechtigte, aber außerhalb des Scopes liegende Idee ist, die bei der Arbeit an etwas anderem aufkam — sie kommt zu eigenen Bedingungen in die Queue, statt den Scope des aktuellen Tasks zu erweitern.

Diese Trennung hält den Diff jedes Tasks auf das fokussiert, was von ihm verlangt wurde, und erfasst dennoch alles, was einem Reviewer nebenbei auffällt — nichts, was beim Review beobachtet wurde, geht stillschweigend verloren, wird aber auch nicht in eine unzusammenhängende Änderung eingeschmuggelt.

Wenn ein Task fehlschlägt und menschliches Eingreifen nötig ist

Nicht jeder Fehlschlag ist automatisch behebbar. Der Watchdog und die Self-Heal-Mechanismen von AITM bewältigen Infrastrukturstörungen und gewöhnliche Compile-/Testfehler selbstständig, aber manche Fehler sind terminal — sie brauchen eine menschliche Entscheidung, keinen weiteren Wiederholungsversuch. Ein Task endet im terminalen Zustand failed, wenn:

  • Die Konfiguration falsch ist. Ungültige API-Schlüssel, falsche Einstellungen, fehlerhaftes JSON — nichts im Code kann eine defekte Umgebung reparieren.
  • Der KI Daten fehlen. Der Task-Prompt ist unvollständig oder mehrdeutig, erforderlicher Kontext wurde nicht geliefert, oder die Anforderungen sind unzureichend spezifiziert.
  • Es ein grundlegendes Hindernis gibt, das nur ein Benutzer lösen kann. Die Architektur braucht Klärung, der Scope ist umstritten, oder ein Drittanbieterdienst ist auf eine Weise ausgefallen, die eine ausdrückliche Kenntnisnahme erfordert, bevor die Arbeit weitergehen kann.

Beispiel: Ein Task schlägt fehl, weil die Anforderungen der bestehenden Architektur widersprechen. AITM kann nicht erraten, welcher Entwurf korrekt ist — ein Mensch muss das klären. An diesem Punkt:

  1. Wird der Task als failed markiert.
  2. Die Grundursache wird (gemeinsam mit Claude) im Chat oder in Brainstorm besprochen.
  3. Es wird entschieden: erneut einreihen mit klarerem Scope? Zuerst einen separaten Architektur-Entwurfs-Task anlegen? Den Ansatz anpassen?
  4. Anschließend wird ein neuer Task mit dem verfeinerten Verständnis angelegt oder mit einem aktualisierten Prompt neu eingereiht.

Nicht alle Fehlschläge sind Bugs — viele sind ohne menschliche Eingabe schlicht nicht lösbar. Fehlgeschlagen heißt nicht vergeudete Arbeit — die Diagnosedaten und Logs eines fehlgeschlagenen Laufs zeigen weiterhin genau, wo etwas schiefgegangen ist. Und wenn ein Task fehlschlägt, ist das ein Gesprächspunkt zwischen Mensch und AITM, keine Sackgasse.

Branch-Modell

Jedes von AITM verwaltete Projekt folgt demselben Release-Modell mit zwei Branches.

  • dev ist der Standard-/Integrations-Branch. Jeder Pipeline-Task mergt nach dev — dort landet fertige, getestete Arbeit laufend (siehe die Merge-Queue oben).
  • main ist der stabile Release-Branch. Er wird nur durch einen Merge dev → main zum Release-Zeitpunkt aktualisiert, nicht durch einzelne Tasks.
  • Es gibt keinen master-Branch. AITM legt nie einen an und erwartet auch keinen.
  • Importierte Projekte können ihren eigenen Integrations-Branch behalten. Verwendet ein Projekt, das aufgenommen wird, bereits einen anderen Namen für seinen Integrations-Branch, wird dieser über die Einstellung Integration branch (defaultBranch) in den Project settings festgelegt, und mit der Prüfung Verify remote dort wird bestätigt, dass er sich gegen das tatsächliche Git-Remote auflösen lässt.
  • Das mitgelieferte Gitea im Docker-Release legt Demo-Repositories mit dev als Standard-Branch an und entspricht damit von Haus aus demselben Modell.

Hat das Projekt eines Tasks kein nutzbares Git-Remote, stoppt der Task mit einer umsetzbaren Meldung, die auf Project settings → Verify remote verweist, statt einen rohen Git-Fehler anzuzeigen.