Cuando una Task termina de ejecutarse, interesa saber qué ocurrió realmente: qué cambió, si funcionó y, si algo salió mal, cómo continuar.
Lectura de resultados y Archive
Apertura del resultado de una Task terminada
Un clic en cualquier tarjeta de Task — en ejecución, terminada o archivada — abre su vista de resultado. Se muestra lo siguiente:
- Un resumen de lo que se hizo y por qué
- La lista completa de los archivos modificados
- Los resultados de los pasos de la Pipeline (pass/fail por paso)
- Las capturas de pantalla realizadas durante la ejecución, si se habilitó el paso opcional Snapshot
- Metadatos: tiempos, qué proveedor/modelo de IA la gestionó y un enlace al commit de Git
Interpretación de los veredictos
Dos tipos de comprobaciones automáticas producen un veredicto. El veredicto de pruebas unitarias es simplemente pass o fail, basado en el conjunto de pruebas existente del proyecto. El veredicto de extremo a extremo (E2E) tiene algunos resultados posibles más, ya que las pruebas E2E ejercitan la aplicación real en ejecución:
| Veredicto | Qué significa |
|---|---|
PASS | Todos los escenarios de extremo a extremo pasaron |
FEATURE_BUG | La prueba E2E encontró un bug real en la funcionalidad implementada |
ENHANCEMENT_REQUEST | Las pruebas revelaron que la funcionalidad funciona pero le falta algo que valdría la pena añadir más adelante |
DATA_ISSUE | El fallo se debió a los datos de prueba o al estado del entorno, no al código en sí |
ENVIRONMENT_ERROR | El propio entorno de pruebas tuvo un problema (p. ej. un servicio no estaba en ejecución); no refleja la calidad del código |
UNKNOWN | El resultado no pudo clasificarse automáticamente y requiere que una persona lo revise |
Gestión de una Task fallida
Un estado failed significa que la Pipeline encontró algo que no pudo resolver por sí sola dentro de su presupuesto de reintentos. Al abrir la Task se ve qué paso falló y el motivo registrado, además del diagnóstico del Watchdog si intentó antes una recuperación automática. A partir de ahí, normalmente se puede reanudar la Task desde el paso fallido (o desde uno anterior, si la corrección debe comenzar más atrás) en lugar de empezar de cero: AITM conserva todo lo que ya tuvo éxito.
Gestión de un conflicto
Un estado conflict significa que la fusión automática de Git de AITM encontró un conflicto genuino — dos cambios que tocan las mismas líneas de forma incompatible — que el intento de resolución asistido por IA no pudo resolver con seguridad por sí solo. Cuando esto ocurre, AITM muestra exactamente qué archivos entraron en conflicto para poder resolverlo; nunca adivina ni elige un lado en silencio cuando ambos cambios parecen intencionados.
El Archive
Cuando una Task termina y su cambio se ha fusionado en dev, se archiva en el Archive: un registro con capacidad de búsqueda de cada Task completada, de la más reciente a la más antigua, con su título, proyecto, fecha de finalización y estado final. Es el rastro de auditoría permanente.
En el Archive es posible buscar y filtrar Tasks (por proyecto, fecha o estado) y abrir el registro completo de cualquiera de ellas: el prompt original, los pasos de la Pipeline, el veredicto de la revisión, los resultados de las pruebas y un resumen en lenguaje sencillo de lo que cambió, redactado por el paso Docs. Una Task archivada no queda bloqueada: Restore la devuelve a la cola. Para una variación de un trabajo antiguo, suele ser más limpio crear una Task nueva que reutilice el prompt archivado como punto de partida.
Consejos
- Si una Task falla, conviene reanudarla desde el paso fallido en lugar de empezar de nuevo: todo lo que ya tuvo éxito se conserva.
- Si la IA se atasca a mitad de una Task, el Watchdog la reanuda automáticamente hasta un número limitado de intentos antes de marcarla como
failed. - Como cada Task deja un registro completo en el Archive, este sirve también como documentación de por qué el proyecto es como es.