Diferentes agentes no deberían agarrar el mismo árbol.

Un problema difícil con los agentes paralelos

s09-s11 te permite iniciar varios compañeros de equipo al mismo tiempo, pero hay un problema: están todos en el mismo directorio de trabajo. Alice está cambiando auth.py y Bob también está cambiando auth.py al mismo tiempo: conflictos de git, confusión de archivos y contaminación mutua de pruebas.

La solución para s12 es git worktree: en el mismo almacén, puedes verificar diferentes sucursales en diferentes directorios a través de git worktree add. Cada agente tiene su propio árbol de trabajo y trabaja en su propio directorio, invisibles entre sí.

my-repo/ # Espacio de trabajo principal (para cliente potencial)
.árboles de trabajo/
  alice-auth/ # directorio de aislamiento de alice
    (rama: wt/alice-auth)
  bob-api/ # directorio de aislamiento de bob
    (rama: peso/bob-api)
  index.json # registro de árbol de trabajo
  events.jsonl # Registro de eventos del ciclo de vida

División del trabajo en dos planos.

s12 Divida explícitamente el sistema en dos planos:

• Plano de control: archivo JSON en .tasks/. La tarea es una unidad abstracta de "qué hacer", incluidas las dependencias, el propietario y el estado.
• Plano de ejecución: Directorio en .worktrees/. Worktree es el contenedor físico de "dónde hacerlo", un directorio + una rama.

Los dos están vinculados bidireccionalmente a través de task.worktree y worktree.task_id.

Este tipo de desacoplamiento le permite: Reutilizar el mecanismo de administración de tareas pero cambiar el entorno de ejecución (por ejemplo, no git worktree, sino el contenedor acoplable). O cambiar el mecanismo de la tarea pero reutilizar el árbol de trabajo (por ejemplo, no un archivo JSON sino una base de datos).

demostración del ciclo de vida

Revíselo completamente a continuación: crear tarea → crear árbol de trabajo → ejecutar comandos → conservar o eliminar. Cada paso tiene un registro de registro de eventos (events.jsonl), que se utiliza para la observabilidad en producción.

keep vs remove

Hay dos finales cuando worktree completa su misión:

• remove: git worktree remove --force, elimina el directorio. Generalmente también se limpian las ramas. Es equivalente a "ya no quiero esta exploración".
• mantener: solo marque estado: mantenido en .worktrees/index.json y se conserva el directorio físico. Es equivalente a "Voy a obtener este resultado, espera hasta que lo combine".

Modo común: el subagente ejecuta una refactorización experimental → se ejecuta con buenos resultados → mantener → revisión humana → se fusiona con la rama principal → se elimina manualmente. ¿Pobre efecto? Simplemente retírelo y deséchelo.