Verschiedene Agents sollten nicht am selben Baum arbeiten

Ein zentrales Problem paralleler Agents

s09-s11 ermoeglicht es dir, mehrere Teammates gleichzeitig zu starten - doch da lauert eine Falle: Sie arbeiten alle im selben Arbeitsverzeichnis. Alice aendert auth.py, Bob tut es gleichzeitig - Git-Konflikte, durcheinander gebrachte Dateien, gegenseitig verseuchte Tests.

Die Loesung in s12 ist git worktree: Im gleichen Repository kann man per git worktree add verschiedene Branches in verschiedenen Verzeichnissen auschecken. Jeder Agent erhaelt seinen eigenen Worktree und arbeitet in seinem eigenen Verzeichnis, ohne den anderen zu beeinflussen.

my-repo/                           # Hauptarbeitsbereich (Lead nutzt ihn)
.worktrees/
  alice-auth/                      # Isoliertes Verzeichnis fuer alice
    (branch: wt/alice-auth)
  bob-api/                         # Isoliertes Verzeichnis fuer bob
    (branch: wt/bob-api)
  index.json                       # Worktree-Register
  events.jsonl                     # Lifecycle-Ereignislog

Zwei-Ebenen-Aufgabenteilung

s12 teilt das System explizit in zwei Ebenen auf:

• Kontrollebene (control plane): JSON-Dateien in .tasks/. Ein Task ist die abstrakte Einheit fuer "was zu tun ist" - mit Abhaengigkeiten, Owner und Status.
• Ausfuehrungsebene (execution plane): Verzeichnisse in .worktrees/. Ein Worktree ist der physische Container fuer "wo es getan wird" - ein Verzeichnis plus ein Branch.

Beide Ebenen sind bidirektional ueber task.worktree und worktree.task_id verknuepft.

Diese Entkopplung erlaubt dir: Den Task-Mechanismus wiederzuverwenden, aber die Ausfuehrungsumgebung zu tauschen (z.B. Docker-Container statt git worktree). Oder die Ausfuehrungsebene beizubehalten, aber den Task-Mechanismus zu ersetzen (z.B. Datenbank statt JSON-Dateien).

Lifecycle-Demo

Hier wird der gesamte Ablauf durchgespielt: Task erstellen → Worktree erstellen → Befehle ausfuehren → keep oder remove. Jeder Schritt wird im Ereignislog erfasst (events.jsonl) - in Produktion dient das der Observability.

keep vs remove

Wenn ein Worktree seine Aufgabe erfuellt hat, gibt es zwei moegliche Endstaende:

• remove: git worktree remove --force - das Verzeichnis wird geloescht. Der Branch wird in der Regel ebenfalls bereinigt. Bedeutet: Dieser Versuch wird verworfen.
• keep: Nur in .worktrees/index.json wird status: kept gesetzt, das physische Verzeichnis bleibt erhalten. Bedeutet: Dieses Ergebnis wird behalten, warten auf Merge.

Uebliches Muster: Subagent fuehrt ein experimentelles Refactoring durch → Ergebnis ist gut → keep → Mensch reviewt → in Hauptbranch mergen → manuell remove. Schlechtes Ergebnis? Direkt remove und wegwerfen.