Verschiedene Agenten sollten nicht denselben Baum ergreifen.

Ein schwieriges Problem mit Parallelagenten

s09-s11 ermöglicht es Ihnen, mehrere Teamkollegen gleichzeitig zu starten, aber es gibt eine Gefahr: Sie befinden sich alle im selben Arbeitsverzeichnis. Alice ändert auth.py und Bob ändert gleichzeitig auch auth.py – Git-Konflikte, Dateiverwirrung und gegenseitige Kontamination von Tests.

Die Lösung für s12 ist git worktree: Im selben Warehouse können Sie über git worktree add verschiedene Zweige in verschiedenen Verzeichnissen auschecken. Jeder Agent erhält seinen eigenen Arbeitsbaum und arbeitet in seinem eigenen Verzeichnis, unsichtbar für die anderen.

my-repo/ # Hauptarbeitsbereich (für Lead)
.worktrees/
  alice-auth/ # Alices Isolationsverzeichnis
    (Zweig: wt/alice-auth)
  bob-api/ # bobs Isolationsverzeichnis
    (Zweig: wt/bob-api)
  index.json # Worktree-Registrierung
  events.jsonl # Lebenszyklus-Ereignisprotokoll

Arbeitsteilung in zwei Ebenen

s12 Teilen Sie das System explizit in zwei Ebenen auf:

• Steuerungsebene: JSON-Datei in .tasks/. Eine Aufgabe ist eine abstrakte Einheit dessen, „was zu tun ist“, einschließlich Abhängigkeiten, Eigentümer und Status.
• Ausführungsebene: Verzeichnis in .worktrees/. Worktree ist der physische Container „wo es zu tun ist“, ein Verzeichnis + ein Zweig.

Die beiden sind bidirektional über task.worktree und worktree.task_id verbunden.

Diese Art der Entkopplung ermöglicht Ihnen: Den Aufgabenverwaltungsmechanismus wiederzuverwenden, aber die Ausführungsumgebung zu ändern (z. B. nicht Git Worktree, sondern Docker-Container). Oder ändern Sie den Aufgabenmechanismus, verwenden Sie aber den Arbeitsbaum wieder (z. B. keine JSON-Datei, sondern eine Datenbank).

Demonstration des Lebenszyklus

Gehen Sie es unten vollständig durch: Aufgabe erstellen → Arbeitsbaum erstellen → Befehle ausführen → behalten oder entfernen. Jeder Schritt verfügt über einen Ereignisprotokoll-Eintrag (events.jsonl), der zur Beobachtbarkeit in der Produktion verwendet wird.

keep vs remove

Es gibt zwei Enden, wenn Worktree seine Mission erfüllt:

• remove: git worktree remove --force, lösche das Verzeichnis. Auch Filialen werden grundsätzlich aufgeräumt. Es ist gleichbedeutend mit „Ich möchte diese Erkundung nicht mehr.“
• keep: Markieren Sie nur status: beibehalten in .worktrees/index.json, und das physische Verzeichnis bleibt erhalten. Es ist äquivalent zu „Ich werde dieses Ergebnis erhalten, warte, bis ich es zusammenführe.“

Gemeinsamer Modus: Subagent führt einen experimentellen Refactor aus → wird mit guten Ergebnissen ausgeführt → behalten → menschliche Überprüfung → wird mit dem Hauptzweig zusammengeführt → manuell entfernt. Schlechte Wirkung? Einfach entfernen und wegwerfen.