Différents agents ne doivent pas s’emparer du même arbre.

Un problème difficile avec les agents parallèles

s09-s11 vous permet de démarrer plusieurs coéquipiers en même temps, mais il y a un piège : Ils sont tous dans le même répertoire de travail. Alice change auth.py, et Bob change également auth.py en même temps - conflits git, confusion de fichiers et contamination mutuelle des tests.

La solution pour s12 est git worktree : dans le même entrepôt, vous pouvez extraire différentes branches dans différents répertoires via git worktree add. Chaque agent dispose de son propre arbre de travail et travaille dans son propre répertoire, invisible les uns aux autres.

my-repo/ # Espace de travail principal (pour le prospect)
.worktrees/
  alice-auth/ #répertoire d'isolation d'Alice
    (branche : wt/alice-auth)
  bob-api/ #répertoire d'isolation de bob
    (branche : wt/bob-api)
  index.json # registre worktree
  events.jsonl # Journal des événements du cycle de vie

Division du travail sur deux plans

s12 Diviser explicitement le système en deux plans :

• Plan de contrôle : fichier JSON dans .tasks/. La tâche est une unité abstraite de « que faire », comprenant les dépendances, le propriétaire et le statut.
• Plan d'exécution : Répertoire dans .worktrees/. Worktree est le conteneur physique de "où le faire", un répertoire + une branche.

Les deux sont liés de manière bidirectionnelle via task.worktree et worktree.task_id.

Ce type de découplage permet de : Réutiliser le mécanisme de gestion des tâches mais changer l'environnement d'exécution (par exemple, pas git worktree, mais docker conteneur). Ou changer le mécanisme des tâches mais réutiliser l'arbre de travail (par exemple, pas un fichier JSON mais une base de données).

démonstration du cycle de vie

Parcourez-le entièrement ci-dessous : créer une tâche → créer un arbre de travail → exécuter des commandes → conserver ou supprimer. Chaque étape possède un enregistrement de journal des événements (events.jsonl), qui est utilisé à des fins d'observabilité en production.

keep vs remove

Il y a deux fins lorsque worktree termine sa mission :

• remove : git worktree remove --force, supprimez le répertoire. Les branches sont également généralement nettoyées. Cela équivaut à "Je ne veux plus de cette exploration".
• keep : marquez uniquement statut : conservé dans .worktrees/index.json, et le répertoire physique est conservé. Cela équivaut à "Je vais obtenir ce résultat, attendez de le fusionner".

Mode commun : le sous-agent exécute un refactor expérimental → s'exécute avec de bons résultats → conserver → examen humain → fusionne dans la branche principale → supprime manuellement. Mauvais effet ? Il suffit de le retirer et de le jeter.