Cómo AITM fusiona el trabajo terminado en dev, corrige hacia adelante los fallos de pruebas posteriores a la fusión en lugar de revertir, y verifica que una Task solo tocó lo que debía tocar.

Fusión, correcciones posteriores a la fusión y Scope Gate

Cómo funciona la fusión

Cada Task se ejecuta en su propia rama/Worktree de git. Cuando la Pipeline termina (implementación, revisión y pruebas en verde), la Task entra en la Merge queue de AITM — una cola serializada para que las Tasks concurrentes nunca se fusionen en dev al mismo tiempo y pisen los cambios de las demás.

• Disparador de fusión automática. Una Task con autoMergeDev activado se fusiona en dev automáticamente cuando su Pipeline termina — sin paso de aprobación manual, de modo que el trabajo terminado aterriza de forma continua en lugar de acumularse esperando a que alguien haga clic en fusionar.
• Pre-merge build gate. La rama de la Task se actualiza primero con el dev actual, y después se compila y se comprueban sus tipos tal como quedará tras la fusión. Si la comprobación está en rojo, un Agent de corrección dispone de un número limitado de intentos; los errores que ya existen en dev no se atribuyen a la Task. Si el gate sigue en rojo, la Task no se fusiona y termina en conflict con la salida de la compilación adjunta.
• Gestión de conflictos. Si la rama de una Task entra en conflicto con lo que ya ha aterrizado en dev, AITM reintenta la fusión con distintas estrategias y después entrega los archivos en conflicto a un resolvedor de conflictos de IA, que combina ambos cambios y vuelve a ejecutar el build gate. Una Task en espera en conflict se vuelve a comprobar automáticamente; si la causa ha desaparecido entretanto, se autorrepara y continúa hacia la fusión.
• Fusión controlada en dev. Las fusiones se realizan de una en una desde la cola, de modo que dev nunca queda en un estado de fusión a medias. La fusión no es un paso de la Pipeline: la Task muestra finished con un marcador Finalizing… y pasa a archived cuando la fusión aterriza. Mientras una Task permanece en conflict, las demás Tasks en cola de la misma pestaña esperan detrás de ella — por lo que conviene resolverla pronto.

Detección y corrección de errores posteriores a la fusión

Una vez que la rama de una Task se ha fusionado en dev, AITM vuelve a ejecutar las pruebas afectadas contra el nuevo estado de dev. Si ahora fallan, la respuesta predeterminada es no revertir la fusión.

Ejemplo: una Task añade un campo nuevo a un modelo compartido. Se fusiona sin problemas y sus propias pruebas pasan. Pero otra Task, ya en curso en otra rama, dependía de la forma antigua de ese modelo; tras aterrizar ambas, una prueba de integración compartida empieza a fallar. En lugar de revertir cualquiera de las dos fusiones (lo que también descartaría la mitad sana y no relacionada de cada cambio), AITM:

1. Aísla qué archivos/pruebas fallan realmente y el cambio de qué Task es responsable.
2. Corrige hacia adelante en una rama — se crea una Task correctiva que apunta solo al área que falla, partiendo del estado actual de dev (no del diff de ninguna de las Tasks originales).
3. Vuelve a probar la corrección de forma aislada antes de permitir que se acerque de nuevo a dev.
4. Fusiona la corrección a través de la misma cola que cualquier otra Task.

Esta filosofía de "corregir hacia adelante" evita el daño en cascada: revertir una fusión después de que otro trabajo ya se haya construido encima obligaría a una cadena de reversiones adicionales. Corregir la rotura real en su sitio, en su propia rama, mantiene el radio de impacto limitado al único problema encontrado.

Evaluación del Scope de la Task (Business Scope Gate)

Cada Task declara de antemano qué archivos planea tocar. Cuando la Task termina, el Business Scope Gate compara los archivos que realmente cambió con esa declaración.

• Fuera de Scope significa que un archivo modificado nunca se declaró y no tiene una conexión plausible con el objetivo declarado de la Task — por ejemplo, una Task sobre la página de pago que además edita un archivo de ajustes de administración no relacionado.
• Enmiendas de Scope. A veces tocar un archivo no declarado es legítimo — un tipo compartido tenía que cambiar, o una constante vive en un archivo vecino. En ese caso la Task registra una justificación breve y explícita del archivo adicional (una "scope amendment") en lugar de salirse de los límites en silencio. Una enmienda justificada se acepta; un archivo adicional sin explicación no.
• Violaciones bloqueantes frente a consultivas. No todos los archivos no declarados se tratan de la misma manera:
  • Bloqueante — el archivo modificado es realmente ajeno a la Task (área funcional distinta, sin dependencia compartida, sin justificación). Esto detiene la fusión hasta que se resuelva.
  • Consultiva — el archivo modificado reside en el mismo directorio/módulo que el Scope declarado y está plausiblemente relacionado (p. ej. un archivo hermano en la misma carpeta de funcionalidad). Se marca para revisión, pero por sí solo no bloquea la fusión.

Qué se convierte en bug y qué en una Task nueva

Cuando un paso de revisión encuentra algo más allá del diff inmediato, AITM decide entre dos resultados:

• Se convierte en bug cuando el hallazgo es una violación de Scope bloqueante, o un defecto genuino no relacionado con lo que la Task debía hacer — algo que ya está roto y necesita su propio ciclo de corrección, independiente del resultado de la Task actual.
• Se convierte en una Task nueva (de seguimiento) cuando el hallazgo es un refinamiento, una mejora deseable o una idea legítima pero fuera de Scope surgida mientras se trabajaba en otra cosa — entra en la cola por derecho propio en lugar de ampliar el Scope de la Task actual.

Esta separación mantiene el diff de cada Task centrado en lo que se le pidió, sin dejar de capturar todo lo que un revisor advierte por el camino — nada de lo observado durante la revisión se descarta en silencio, pero tampoco se cuela en un cambio no relacionado.

Cuando una Task falla y requiere intervención humana

No todos los fallos son recuperables automáticamente. El Watchdog y los mecanismos de autorreparación de AITM gestionan por sí solos los contratiempos de infraestructura y los fallos rutinarios de compilación/pruebas, pero algunos errores son terminales — necesitan una decisión humana, no otro reintento. Una Task termina en el estado terminal failed cuando:

• La configuración es incorrecta. Claves de API no válidas, ajustes incorrectos, JSON malformado — nada en el código puede arreglar un entorno roto.
• A la IA le faltan datos. El prompt de la Task está incompleto o es ambiguo, no se aportó el contexto necesario o los requisitos están insuficientemente especificados.
• Existe un bloqueo fundamental que solo una persona puede resolver. La arquitectura necesita aclaración, el Scope es discutido o un servicio de terceros está caído de forma que requiere un reconocimiento explícito antes de poder continuar.

Ejemplo: supóngase que una Task falla porque los requisitos entran en conflicto con la arquitectura existente. AITM no puede adivinar cuál es el diseño correcto — una persona tiene que aclararlo. En ese punto:

1. La Task se marca como failed.
2. La persona usuaria (y Claude) analizan la causa raíz en Chat o Brainstorm.
3. La persona decide: ¿volver a encolar con un Scope más claro? ¿Registrar primero una Task independiente de diseño de arquitectura? ¿Ajustar el enfoque?
4. Después se crea una nueva Task con el entendimiento refinado, o se vuelve a encolar con un prompt actualizado.

No todos los fallos son bugs — muchos son legítimamente irresolubles sin aportación humana. Fallido no significa trabajo desperdiciado — los diagnósticos y registros de una ejecución fallida siguen indicando exactamente dónde se torció algo. Y cuando una Task falla, es un punto de conversación entre la persona usuaria y AITM, no un callejón sin salida.

Modelo de ramas

Todo proyecto gestionado por AITM sigue el mismo modelo de versiones de dos ramas.

• dev es la rama predeterminada / de integración. Cada Task de la Pipeline se fusiona en dev — aquí es donde el trabajo terminado y probado aterriza de forma continua (véase la Merge queue más arriba).
• main es la rama estable de versiones. Solo se actualiza mediante una fusión dev → main en el momento de la versión, no por Tasks individuales.
• No existe una rama master. AITM nunca la crea ni la espera.
• Los proyectos importados pueden conservar su propia rama de integración. Si un proyecto que se incorpora ya usa otro nombre para su rama de integración, se establece mediante el ajuste Integration branch (defaultBranch) en los ajustes del proyecto, y se usa allí la comprobación Verify remote para confirmar que se resuelve contra el remoto git real.
• El Gitea incluido en la versión Docker crea repositorios de demostración con dev como rama predeterminada, en consonancia con este mismo modelo desde el primer momento.

Si el proyecto de una Task no tiene un remoto git utilizable, la Task se detiene con un mensaje accionable que remite a Project settings → Verify remote en lugar de mostrar un error de git sin procesar.