Aprender AI-DLC creando un juego, parte 6: un bugfix

Esta es la parte 6 de una serie sobre aprender AI-DLC creando un juego, World Rift Conflict, en Godot con un backend en AWS. La parte 3 creó las pruebas de extremo a extremo automáticas. Después, una revisión de código de ese trabajo encontró tres errores pequeños. Este artículo los sigue por el alcance bugfix de AI-DLC y mira qué costaron seis etapas y qué aportaron.

Partes publicadas:

• Parte 1: configuración
• Parte 2: prueba de concepto
• Parte 3: tests E2E automáticos
• Parte 4: lo que vio la revisión
• Parte 5: dentro de una etapa
• Parte 6: un bugfix (este artículo)

En resumen

1. Incluso un bugfix pasa por seis etapas: Reverse Engineering, Requirements Analysis, Code Generation, Build and Test, Deployment Pipeline y Deployment Execution.
2. El análisis encontró dos huecos que la revisión de código no había visto, uno de ellos una forma de subir un secreto al repositorio.
3. Una revisión de los requisitos detectó una prueba de aceptación que habría pasado también con el código roto.
4. Editar un documento después de su revisión bloquea la aprobación hasta que se revisa el cambio.
5. Llevó unas horas. Para tres errores menores es mucho, pero salió con pruebas que demuestran cada arreglo.

Los tres errores

El kit E2E ejecuta el registro y el inicio de sesión del juego en Linux y en tres navegadores contra un backend de pruebas aparte. La revisión encontró:

1. Un valor de seguridad caducado. Una protección impide ejecutar pruebas contra producción comparando los IDs de los grupos de usuarios. Leía el ID de producción una vez y guardaba esa copia para siempre.
2. Un archivo de configuración cambiado. Para crear una exportación de prueba, el kit cambia el amplify_outputs.json del juego por el del backend de pruebas y luego lo devuelve. Si la exportación se interrumpía, el archivo de prueba se quedaba. Si se interrumpía dos veces, la copia del archivo real se sobrescribía.
3. Un buzón impaciente. La prueba lee el código de confirmación de un correo real. Un correo sin código la hacía fallar al momento en lugar de esperar hasta dos minutos.

Reverse Engineering: el análisis vio más

Pedí un nuevo análisis completo del código en lugar de mirar solo tres funciones. El análisis ubicó cada error por archivo y línea, y encontró dos cosas que la revisión no había visto:

• La copia de seguridad del error 2 no estaba en .gitignore, y la comprobación de secretos solo conocía el nombre exacto amplify_outputs.json. Un git add -A después de una interrupción podía haberla subido.
• Sin un ID de la app de Amplify configurado, la protección terminaba en silencio y seguía usando la copia que tuviera.

Requirements Analysis: cuatro preguntas, dos revisiones

La etapa hizo cuatro preguntas, con cada opción explicada: cuándo refrescar (en cada ejecución), qué hacer si el refresco falla (parar, nunca usar la copia vieja), hasta dónde llega el arreglo del archivo (hasta el final, incluida la comprobación de secretos), y si sacar mi dominio de pruebas del código (no).

La primera revisión señaló un requisito que yo había escrito sin preguntar: parar cuando falta el ID de la app. Tenía razón. No me lo habían preguntado, así que lo confirmé en la aprobación con Request Changes, junto con cuatro arreglos pequeños.

Después, la aprobación no volvía a abrirse:

Requirements Analysis can't go ahead as things stand: which way would you like to go on?

La revisión registrada era del texto anterior. Aprobar un documento cambiado con una revisión vieja es justo lo que la protección impide. Empezar la etapa de nuevo era una salida. Otra más barata era pedir una revisión de la versión corregida, que AI-DLC registra como pedida por la persona.

Esa segunda revisión encontró el mejor error del día. La prueba de aceptación de "un refresco fallido detiene la ejecución" usaba un perfil de AWS desconocido. Pero un perfil desconocido ya falla en la comprobación de credenciales, antes de que corra el código arreglado, así que la prueba también pasaría con el código roto. El plan la cambió por un ID de app bien formado que no existe: las credenciales pasan y solo falla el refresco.

Code Generation y Build and Test

El plan me llegó para aprobarlo antes de escribir código, y un agente desarrollador lo construyó: 18 pruebas unitarias nuevas, con toda la batería en verde. El revisor de arquitectura dijo READY con cinco hallazgos menores, que acepté como pendientes.

Build and Test ejecutó las pruebas de aceptación contra AWS después de mi visto bueno:

Prueba	Resultado
Ejecución completa en Linux, Chromium, Firefox y WebKit	pasa; el refresco añade 6–7 s
ID de app falso, en la ejecución y en la limpieza	las dos paran con código 2 y borran la copia vieja
ID de app vacío	para con código 2 y nombra el ajuste
Una exportación real interrumpida con Ctrl-C	la siguiente ejecución repara el archivo y pasa

La exportación interrumpida necesitó cuatro intentos. El primero mandó la señal tarde, y al proceso equivocado. Los dos siguientes chocaron con un token de AWS SSO caducado. La CLI aws seguía respondiendo con credenciales en caché, pero el SDK de JavaScript que usa el kit no. Después de aws sso login, el cuarto esperó al archivo marcador que escribe la exportación e interrumpió al instante.

Desplegar un arreglo de herramientas de prueba

No había cambiado nada de lo que ejecutan los jugadores, así que las prácticas del equipo ya respondían las preguntas de despliegue, y AI-DLC las rellenó citando la fuente en lugar de preguntar. Hice el push, Amplify reconstruyó el mismo juego y pasó la comprobación rápida de producción.

¿Valió la pena?

Seis etapas y tres revisiones para tres errores menores es mucho. Lo que aportó:

• Dos huecos que la revisión original no vio, uno de ellos un camino para subir un secreto.
• Una prueba de aceptación que no habría demostrado nada, detectada antes de escribirla.
• Una prueba de regresión para cada error, y un registro de por qué se tomó cada decisión.

Lo que cambiaría: para un error tan pequeño, la etapa Deployment Pipeline casi solo repitió las prácticas del equipo. La próxima vez el alcance puede componerse sin ella.

Qué viene después

Las herramientas están listas. Lo siguiente es el juego en sí: las etapas de Ideation de World Rift Conflict.