Chaque agent a son propre arbre de travail.

Le problème des agents parallèles

Les leçons s09–s11 vous permettent de lancer plusieurs teammates en parallèle, mais il y a un piège invisible : ils partagent tous le même répertoire de travail. Alice modifie auth.py, Bob fait de même en même temps — conflits git, fichiers corrompus, tests qui se polluent mutuellement.

La solution de s12 est git worktree : dans un même dépôt, git worktree add permet de checker out différentes branches dans différents répertoires. Chaque agent dispose de son propre worktree, travaille dans son propre répertoire, invisible aux autres.

my-repo/                           # répertoire principal (pour le lead)
.worktrees/
  alice-auth/                      # répertoire isolé d'alice
    (branch: wt/alice-auth)
  bob-api/                         # répertoire isolé de bob
    (branch: wt/bob-api)
  index.json                       # registre des worktrees
  events.jsonl                     # journal des événements du cycle de vie

Deux plans distincts

s12 découpe explicitement le système en deux plans :

• Plan de contrôle (control plane) : les fichiers JSON dans .tasks/. Une tâche est l'unité abstraite de « ce qu'il faut faire » — avec dépendances, owner, status.
• Plan d'exécution (execution plane) : les répertoires dans .worktrees/. Un worktree est le conteneur physique de « où le faire » — un répertoire + une branche.

Les deux sont liés bilatéralement via task.worktree et worktree.task_id.

Ce découplage permet de : réutiliser le mécanisme de gestion des tâches en changeant l'environnement d'exécution (par exemple des conteneurs Docker à la place de git worktrees). Ou d'inverser — changer le mécanisme de tâches (base de données plutôt que fichiers JSON) en conservant les worktrees.

Démonstration du cycle de vie

Voici le parcours complet : create task → create worktree → run commands → keep ou remove. Chaque étape est enregistrée dans un journal d'événements (events.jsonl) — en production, c'est lui qui assure l'observabilité.

keep vs remove

Quand un worktree a accompli sa mission, deux issues sont possibles :

• remove : git worktree remove --force, le répertoire est supprimé. La branche est généralement nettoyée aussi. Équivaut à « cette exploration ne sert à rien ».
• keep : on marque simplement status: kept dans .worktrees/index.json, le répertoire physique est conservé. Équivaut à « ce résultat est bon, en attente de fusion ».

Schéma courant : un subagent effectue un refactor expérimental → le résultat est satisfaisant → keep → revue humaine → fusion dans la branche principale → suppression manuelle. Résultat décevant ? remove directement.