Un prompt se convierte en un cambio revisado, probado, documentado y fusionado — mientras se hace otra cosa. El Pipeline tiene 12 pasos y se ocupa de todos ellos.

El Pipeline

Qué se obtiene

• Cada Task trabaja en su propia rama aislada, de modo que los Tasks paralelos nunca colisionan y el código principal permanece a salvo.
• Una revisión por IA y correcciones automáticas tienen lugar antes de que se vea el resultado.
• Las pruebas unitarias y end-to-end se ejecutan automáticamente.
• El resultado se comprueba frente a los criterios de aceptación indicados.
• La documentación y los Behavioral Contracts se mantienen actualizados automáticamente.
• Las fusiones se encolan y la compilación debe pasar antes de que un cambio se integre.
• Cuando algo falla, AITM se recupera por sí solo y se puede reanudar desde cualquier paso.
• Cada Task deja un resumen de resultado legible y un historial.

Los 12 pasos

1. Branch — el Task obtiene su propio espacio de trabajo seguro que no puede colisionar con otros Tasks. Se obtiene: el código principal intacto hasta que el trabajo esté listo.
2. Architect — la IA lee el prompt y el código relevante y planifica la solución. Se obtiene: un plan meditado de qué partes del proyecto cambian.
3. Code — el plan se convierte en cambios reales de archivos. Se obtiene: la implementación terminada.
4. Compliance-check — compara de forma independiente el diff con los requisitos en Tasks complejos. Omite los Tasks más simples y pasa los hallazgos a Review. Se obtiene: aviso temprano de requisitos omitidos.
5. Review — la IA comprueba el trabajo como lo haría un colega y emite un veredicto. Se obtiene: un segundo par de ojos sin esperar a una persona.
6. Fix — atiende todo lo que Review señaló; puede iterar con Review unas cuantas veces. Se obtiene: un resultado depurado.
7. Test — ejecuta las pruebas unitarias automatizadas del proyecto. Se obtiene: confianza en que el cambio no rompió el comportamiento existente.
8. E2E — ejecuta pruebas que manejan la aplicación como un usuario real. Se ejecuta solo cuando el proyecto tiene pruebas end-to-end, en paralelo con Test. Se obtiene: el recorrido completo del usuario verificado.
9. Verify — compara el resultado con los criterios de aceptación del Task; cada uno termina como passed, failed o unverifiable. Se obtiene: una respuesta clara sobre si el Task hace lo solicitado.
10. Snapshot — paso opcional que captura pantallas de la interfaz. Se obtiene: un registro visual del cambio.
11. Docs — actualiza la documentación y los Behavioral Contracts para reflejar lo que cambió. Se ejecuta siempre. Se obtiene: documentación que no se queda obsoleta.
12. Chain-audit — solo actúa sobre el último Task de una cadena de Tasks dependientes, volviendo a comprobar los criterios de cada Task anterior. Se obtiene: la garantía de que toda la cadena es coherente.

La fusión no es un paso del Pipeline — tras el último paso, el Task entra en la Merge queue, que lo fusiona en la rama dev. Hasta entonces, un Task terminado muestra un marcador Finalizing…. Más detalles en Merging, Post-Merge Fixes & Scope Gate.

Dónde se interviene

• Se revisa el resultado del Task — véase Reading Results & Archive.
• Se edita el prompt si el resultado no coincide con la intención.
• Se reanuda desde un paso o se vuelve a encolar el Task cuando un Pipeline se ha detenido.

Cuando un paso falla

Un paso bloqueado se reintenta automáticamente; el número de reintentos se establece en Settings → Pipeline. Si la compilación está en rojo tras sincronizar con dev, se intenta una reparación, y los conflictos de fusión se intentan resolver primero con resolución asistida por IA. Si eso no basta, el Task queda señalado y se ve el motivo. La tarjeta de un Task fallido o en conflicto ofrece entonces un botón con una sugerencia de recuperación.