15. Git, tareas paralelas, subagentes y flujos de desarrollo avanzados

Objetivo del tema

Coordinar trabajo de desarrollo complejo mediante ramas y worktrees de Git, sesiones paralelas, Fork y subagentes, manteniendo aislados el historial de conversación, los archivos y las decisiones que no deben interferirse.

15.1 Tres formas distintas de ramificar el trabajo

No todas las «ramas» proporcionan el mismo aislamiento

Mecanismo	Qué separa	Qué no separa automáticamente
Nueva sesión	Conversación, instrucciones e historial.	Archivos del proyecto y directorio de trabajo compartido.
Fork de Bionic	Una alternativa de conversación desde una respuesta concreta.	Rama, working tree o procesos de Git.
Rama de Git	Historial de commits y línea de desarrollo.	Archivos simultáneos si se usa el mismo working tree.
Git worktree	Directorio de trabajo y rama en una carpeta independiente.	Servicios externos, puertos, bases de datos o cachés compartidos.
Subagente	Una subtarea y su contexto operativo.	Recursos y archivos, salvo que el flujo los aísle expresamente.

La documentación de Bionic define Fork como una nueva rama de sesión abierta junto a la original. No indica que cree una rama de Git. Por seguridad, trata ambos mecanismos como independientes.

15.2 Git como registro auditable

Git permite responder qué cambió, quién lo incorporó y desde qué estado. Antes de delegar:

Trabaja desde un commit conocido, registra cambios preexistentes y evita mezclar tareas independientes en el mismo commit. Bionic puede utilizar Git, pero la decisión de crear una rama, confirmar, fusionar o publicar debe formar parte explícita del encargo.

15.3 Ramas por objetivo

Una rama debe representar un resultado coherente y revisable. Usa nombres descriptivos como fix/normalizar-codigos o docs/guia-instalacion.

La prohibición de publicar o reescribir historial es especialmente importante cuando el agente sólo fue autorizado a implementar localmente.

15.4 Commits pequeños y verificables

Un commit útil:

• Resuelve un objetivo concreto.
• Incluye sus pruebas o documentación relacionada.
• No contiene secretos, cachés ni archivos temporales.
• Parte de pruebas conocidas y deja pruebas reproducibles.
• Tiene un mensaje que describe el cambio, no la herramienta usada.

Antes de autorizar un commit, revisa git diff --staged. La frase «crea un commit» no implica permiso para hacer push.

15.5 Sesiones paralelas de Bionic

Bionic permite abrir sesiones en pestañas y continuar tareas en segundo plano aunque cambies de pestaña o proyecto. Esto resulta útil para:

Un indicador aparece junto a una sesión cuando Bionic termina el trabajo en segundo plano. Revisa el resultado antes de iniciar una acción dependiente.

15.6 El peligro del directorio compartido

Las sesiones de un mismo proyecto comparten los archivos y, en un proyecto de código, pueden apuntar al mismo directorio local. Dos ediciones simultáneas pueden:

• Sobrescribir cambios o producir un diff combinado.
• Ejecutar formateadores sobre el trabajo de la otra sesión.
• Cambiar la rama activa para ambas tareas.
• Usar migraciones, puertos o datos de prueba incompatibles.
• Atribuir un fallo a la sesión equivocada.

15.7 Matriz para decidir si paralelizar

Riesgo según tipo de trabajo

Combinación	Riesgo	Medida
Dos investigaciones de sólo lectura	Bajo	Definir preguntas diferentes y un formato común de entrega.
Lectura y edición en el mismo directorio	Medio	Advertir al revisor que el estado puede cambiar mientras inspecciona.
Ediciones en archivos distintos del mismo directorio	Medio-alto	Preferir worktrees; scripts y formatters pueden tocar ambos conjuntos.
Ediciones en los mismos archivos	Alto	Serializar o usar worktrees y fusionar después.
Dos sesiones cambiando ramas	Alto	Nunca hacerlo en el mismo working tree.
Dos tareas con worktrees y recursos independientes	Controlado	Revisar cada rama y fusionar en orden.

15.8 Aislar con Git worktree

git worktree crea directorios separados vinculados al mismo repositorio. Desde una línea base limpia y conocida:

Cada carpeta tiene su propia rama y archivos. Abre cada una como directorio de trabajo separado en Bionic. Verifica antes que las rutas ../inventario-docs y ../inventario-estadisticas no existan y permanezcan dentro del directorio previsto.

15.9 Fork para explorar alternativas

Usa Fork sobre una respuesta elegible cuando quieras comparar dos caminos desde el mismo contexto:

1. Llega hasta un diagnóstico o plan compartido.
2. Crea el Fork desde esa respuesta.
3. En la rama original analiza la alternativa A.
4. En el Fork analiza la alternativa B.
5. Coloca ambas sesiones lado a lado y compara criterios.

Mantén ambas ramas en modo de sólo lectura hasta elegir. Si permites que editen el mismo directorio, los archivos dejarán de reflejar alternativas independientes. Bionic 1.1.1 corrigió además un problema donde mover una sesión bifurcada también movía su sesión padre.

15.10 Cuándo usar una sesión nueva y cuándo un Fork

Selección del mecanismo conversacional

Situación	Elección
Continuar corrigiendo el mismo cambio	Misma sesión.
Comparar dos soluciones desde el mismo diagnóstico	Fork.
Investigar una tarea independiente en el mismo proyecto	Nueva sesión.
Modificar una rama distinta en paralelo	Nuevo worktree y sesión asociada a esa carpeta.
Trabajar en otro repositorio	Otro proyecto o directorio claramente separado.

15.11 Qué es un subagente en Bionic

Un subagente es un proceso especializado que trabaja como parte de una tarea principal y devuelve sus hallazgos al agente coordinador. Bionic documenta agentes de exploración en la configuración y utiliza subagentes especializados, por ejemplo para visión y para revisar comandos de shell en Auto Review.

La disponibilidad y forma exacta de uso dependen de la versión, la configuración, el modelo y la tarea. El agente principal puede decidir delegar; el usuario debe evaluar el resultado consolidado, no asumir que varias opiniones garantizan corrección.

15.12 Buenas subtareas para delegar

• Localizar consumidores de una API en distintos paquetes.
• Inventariar pruebas, documentación o migraciones relacionadas.
• Investigar por separado rendimiento, seguridad y compatibilidad.
• Comparar alternativas sin editar archivos.
• Inspeccionar una imagen mediante un modelo con visión.
• Revisar un conjunto acotado de comandos o resultados.

Evita delegar a varios subagentes cambios solapados en los mismos archivos. La exploración de sólo lectura es el punto de partida más seguro.

15.13 Diseñar contratos de subtarea

Cada subtarea necesita objetivo, alcance, prohibiciones y formato de retorno:

El agente coordinador debe comprobar evidencia, reconciliar desacuerdos y decidir qué información pasa al plan.

15.14 Subagentes no equivalen a verificación independiente

Dos subagentes pueden compartir el mismo modelo, contexto parcial o supuesto equivocado. Para obtener verificación real:

• Define preguntas y fuentes diferentes.
• Exige referencias a archivos y líneas.
• Usa pruebas y comandos reproducibles.
• Revisa el diff con Git fuera del resumen del agente.
• Reserva la decisión final a una persona responsable.

15.15 Recursos, contexto y costo

El paralelismo puede multiplicar solicitudes, tokens, memoria, herramientas y procesos. Con modelos locales, varias tareas pueden competir por CPU, GPU y contexto; con modelos cloud, pueden aumentar consumo y créditos.

Limita cantidad de sesiones y subagentes, define criterios de detención y evita duplicar la misma búsqueda. Una tarea secuencial breve puede ser más barata y rápida que coordinar varias ramas.

15.16 Integrar resultados sin perder trazabilidad

Antes de fusionar ramas o implementar un informe de subagentes, crea una tabla de integración:

Registro de integración

Tarea	Base	Archivos	Pruebas	Estado
Documentación	Commit de origen	README y guías	Enlaces o lint	Pendiente / aprobada
Funcionalidad	Commit de origen	Código y tests	Suite enfocada	Pendiente / aprobada
Revisión	Diff exacto	Sólo lectura	Hallazgos	Resuelta / abierta

Registra el commit base porque dos ramas creadas en momentos distintos pueden comparar estados diferentes.

15.17 Fusionar en un orden consciente

Antes de cada merge:

1. Revisa el diff de la rama respecto de la base.
2. Ejecuta sus pruebas dentro del worktree correspondiente.
3. Confirma que el directorio receptor esté limpio.
4. Fusiona una rama.
5. Ejecuta pruebas integradas antes de fusionar la siguiente.

No pidas resolver conflictos automáticamente sin entender ambas intenciones. Un archivo sin marcadores puede seguir siendo semánticamente incorrecto.

15.18 Conflictos y fallos de integración

Conflictos visibles e invisibles

Tipo	Ejemplo	Respuesta
Textual	Dos ramas cambian las mismas líneas.	Comparar intenciones y resolver manualmente.
Semántico	Archivos distintos cambian contratos incompatibles.	Ejecutar integración, tipos y pruebas de consumidores.
Dependencias	Dos lockfiles o versiones incompatibles.	Regenerar con el gestor correcto y auditar el resultado.
Entorno	Dos tareas esperan el mismo puerto o base de datos.	Aislar recursos y repetir la prueba.
Producto	Las ramas implementan decisiones contradictorias.	Detener el merge y pedir una decisión humana.

15.19 Acciones externas y límites de autoridad

Crear cambios locales no autoriza automáticamente a:

• Hacer push o forzar una rama.
• Abrir, aprobar o fusionar un pull request.
• Publicar paquetes, releases o imágenes.
• Desplegar en un entorno.
• Modificar issues, tableros o servicios externos.

Estas operaciones afectan a otras personas o sistemas. Deben estar expresamente incluidas en el objetivo y revisarse antes de ejecutarse.

15.20 Práctica: dos cambios paralelos con worktrees

Utiliza inventario-demo de los temas 13 y 14. Asegúrate de que sus pruebas pasen y el repositorio esté limpio. Desde su carpeta raíz crea dos worktrees:

Tarea A: documentación

Abre ../inventario-docs como un proyecto o directorio separado y solicita:

Tarea B: estadísticas

Abre ../inventario-estadisticas en otro proyecto y solicita:

Revisión e integración

1. Comprueba en cada worktree su rama, estado, diff y pruebas.
2. Crea un commit pequeño en cada rama sólo después de revisar.
3. Regresa al directorio original y confirma que esté limpio.
4. Fusiona primero tarea/estadisticas y ejecuta npm test.
5. Fusiona luego tarea/docs, revisa el README y repite las pruebas.
6. Comprueba el historial y el diff acumulado antes de cualquier push.

15.21 Diagnóstico de problemas

Problemas frecuentes en flujos paralelos

Problema	Comprobación o solución
Dos sesiones mezclan cambios.	Detén ambas, revisa Git y reasigna cada tarea a un worktree separado.
Un Fork modifica la alternativa original.	Ambas conversaciones comparten directorio; vuelve a la base y utiliza worktrees.
Git dice que la rama ya está en uso.	Consulta git worktree list; una rama no puede estar activa en dos worktrees.
Las ramas pasan solas pero fallan juntas.	Busca conflicto semántico, dependencia, esquema o recurso compartido.
El subagente devuelve afirmaciones incompatibles.	Exige evidencia, marca la contradicción y decide en el agente principal.
El equipo se queda sin memoria o créditos.	Reduce concurrencia, usa tareas secuenciales o selecciona modelos apropiados.
Una tarea publicó cambios.	Detén nuevas acciones, registra el estado y coordina la recuperación; no reescribas historia compartida sin acuerdo.

15.22 Resumen

• Sesiones, Fork, ramas Git, worktrees y subagentes separan dimensiones diferentes.
• Un Fork de conversación no crea aislamiento del sistema de archivos.
• Las tareas de sólo lectura son las candidatas más seguras para paralelizar.
• Dos tareas escritoras necesitan worktrees o directorios independientes.
• Los subagentes funcionan mejor con contratos acotados y evidencia verificable.
• Cada rama debe revisarse y probarse antes y después de integrar.
• Los conflictos semánticos pueden existir aunque Git no muestre marcadores.
• Commit, push, merge y despliegue son autorizaciones diferentes.

En el próximo tema aprenderemos a utilizar, crear, instalar y compartir Skills con instrucciones reutilizables.

Fuentes oficiales consultadas: sesiones, trabajo en segundo plano y Fork, código, Git y revisión, proyectos y trabajo con repositorios, subagente revisor y estructura de Fork, flujos agénticos de varios pasos, agentes de exploración y cambios actuales de subagentes, Git y sesiones.