Con varios agentes trabajando a la vez sobre el mismo repo, todos commiteaban en la rama compartida y cada uno encontraba en la carpeta el trabajo a medio hacer de los demás. Los agentes se frenaban al ver cambios ajenos, y juntar todo en la rama principal le quedaba a Sebastián, Task por Task. Un día, además, una rama compartida quedó tomada por el worktree de una Task ya cerrada, y Sebastián tuvo que liberarla a mano para volver a usarla. Así que lo ordenamos en tres pasos, entre el 5 y el 7 de septiembre.
La Revisión. Una Task puede pedir el visto bueno de Sebastián antes de que su código entre a la rama base. Se pide, se ve y se aprueba desde la pantalla de la Task, y mientras tanto el código espera en su rama.
Los Repos. Un Repo pasó a ser una entidad propia: un clon de git con su rama central, que se asigna a los Proyectos. Cada Task sabe en qué rama de qué repos se trabaja, y el campo de la rama sugiere las que ya existen en el clon. Agencia lee git para mostrar y sugerir; las operaciones las hace el agente, que es quien tiene el contexto de su Task.
La rama por Task, como regla. Desde el 7 de septiembre, toda Task que toca código arranca su propia rama y un worktree dentro de su Carpeta de trabajo, y antes de cerrar integra la rama en la rama base y retira el worktree. El cierre lo controla: una Task termina con su rama ya mergeada. El brief del agente y el skill del canal cuentan la secuencia entera, así cada agente la sigue igual.