Qwen Godot code JSONL test de correspondance des preuves – Checklist

Date de rédaction : 28 juin 2026

Objectif

Générer 50 fragments de code Godot 3 avec Qwen, puis vérifier, de la même manière que le test de correspondance des preuves JSONL réalisé hier, que le jugement « oui »/« non » est correctement attribué.

Ce test ne vise pas à évaluer les connaissances du modèle sur Godot. Il s’agit de déterminer, lorsqu’on fournit à la fois le SOURCE_CODE et le JSONL, si le JSONL contient réellement une preuve sous forme de chaîne/API/pattern correspondant directement au fragment de code.

En d’autres termes, les JSONL pertinents doivent être classés comme « oui », tandis que les JSONL non pertinents doivent être rejetés comme « non ».

Méthode de test

Pour chaque fragment de code, on associe au moins deux types de JSONL. Toutefois, comme certaines syntaxes sont communes à Godot 3 et Godot 4, on ne traite pas toutes les fonctionnalités comme étant exclusivement propres à Godot 3.

Chaque test est considéré comme le groupe d’entrées suivant.

JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunk

La demande de validation réelle consiste à vérifier, lorsqu’on envoie JSONL + prompt + chunk ensemble, si Qwen ne renvoie que oui ou non.

Dans le cas d’une syntaxe commune, on teste en se basant sur un même morceau de code. Le JSONL correct contient une description ou un motif du code/fonction concerné, tandis que le JSONL incorrect contient une description d’une fonction ou d’un système complètement différent. Les cas où la réponse attendue est oui et ceux où elle est non ne diffèrent pas parce que le code est différent, mais selon qu’il y a ou non une preuve directe dans le JSONL.

Boucle de génération répétée

L’objectif global est de tester les 50 fonctionnalités au complet. Cependant, aujourd’hui nous ne vérifierons manuellement que les 5 premières, puis nous réduirons le reste en analysant d’abord les schémas de réponses oui/non à partir des résultats accumulés.

Objectif du jour : 5  
Objectif total : 50/50

Après avoir rempli les 5, on n’augmente pas de façon excessive le nombre de nouveaux éléments, on examine d’abord la syntaxe commune, les différences de version et les tendances des faux positifs et des faux négatifs par tableau.

Les tests créent les données en répétant le flux ci‑dessous.

1. Donnez une fonctionnalité Godot à tester à Qwen.  
2. Indiquez d'abord si la fonctionnalité utilise une syntaxe commune à Godot 3/4, une syntaxe spécifique à Godot 3 ou une syntaxe spécifique à Godot 4.  
3. Si c'est une syntaxe commune, créez un seul bloc de code identique.  
4. Si c'est une syntaxe commune, créez un JSONL correct pour ce code/fonction et un JSONL incorrect pour une fonction totalement différente.  
5. Si ce n'est pas une syntaxe commune, créez séparément un JSONL dédié à Godot 4 et un JSONL dédié à Godot 3 pour les tester.  
6. Tous les JSONL doivent être créés en fonction des colonnes de la table cible.  
7. Insérez le JSONL + le bloc SOURCE_CODE dans l'invite de validation et vérifiez « oui »/« non ».  
8. Enregistrez si la réponse attendue correspond à la réponse réelle.

Le cœur du problème n’est pas la qualité de génération du code, mais de vérifier si le jugement de correspondance JSONL est fiable. Ainsi, le JSONL correct doit renvoyer « oui », et le JSONL incorrect doit renvoyer « non ».

Consignes générales de syntaxe

Les syntaxes qui restent identiques entre Godot 3 et Godot 4 ne doivent pas être traitées comme un test de classification de version. Par exemple, il peut exister du code utilisé des deux côtés comme _ready(), _process(delta), l’affectation de variables de base, print().

Dans ces cas, on procède comme suit.

Par conséquent, le tableau de suivi doit toujours indiquer si la syntaxe est commune. Cela permet, lors de la relecture des résultats, de distinguer si une syntaxe commune a été jugée à tort comme preuve de migration, ou si une syntaxe version‑spécifique a été traitée comme commune.

Mémo de redéfinition des critères

En testant les points 4 et 5, il est apparu difficile de rendre un jugement définitif. Selon que le JSONL a été créé à partir de Godot 3 ou de Godot 4, la réponse du même bloc de code variait, et cette différence est elle‑même devenue un objet d’analyse de pattern.

On ne décide donc plus de « bon / mauvais », mais on consigne d’abord la réponse brute comme suit.

L’ordre des réponses est généralement : docs_chunks lié, docs_chunks non lié, api_mapping lié, api_mapping non lié, label_prototypes lié, label_prototypes non lié.

Le point 4 était auparavant consigné comme les autres items, mais comme le test Godot 3 a produit un flux du type non, non, oui, non, oui, non, il a été exclu du jugement définitif. Ce document sert désormais d’observation : il ne s’agit plus de « combien sont corrects », mais de « dans quelles conditions quelles réponses fluctuent ».

Exemple de requête de génération

Voici un exemple de requête pour tester la première fonction, l’initialisation _ready() et la configuration de la taille du viewport.

Le format JSONL et l’usage de chaque JSONL sont détaillés dans un document séparé.

• Schéma et usage des JSONL de test Qwen

Fournis un morceau (chunk) pour Godot 3 et un pour Godot 4 correspondant à l'initialisation de la fonction `_ready()` et à la configuration de la taille du viewport.

Indique d'abord si cette fonctionnalité est une syntaxe commune à Godot 3 et Godot 4.

Si c'est une syntaxe commune, indique qu'il est possible de tester avec le même code.

Ensuite, fournis un JSONL correct conforme au format `docs_chunks` ainsi qu'un JSONL incorrect.

Cet exemple est basé sur docs_chunks. api_mapping et label_prototypes sont également créés de la même manière, en produisant des JSONL corrects et incorrects adaptés à chaque format et usage JSONL, et en vérifiant oui/non avec le même prompt de validation.

Les entrées de validation sont comme ci‑dessous.

JSONL:
<une ligne JSONL de réponse correcte ou incorrecte>

PROMPT:
<direct-evidence validator prompt>

SOURCE_CODE:
<segment de code Godot 3, segment de code Godot 4, ou segment de code syntaxe commune>

Le prompt est envoyé comme ci‑dessous, avec l’impression de juger les preuves d’explication directe ou les bases de transformation entre SOURCE_CODE et JSONL.

Vous êtes un juge de correspondance de preuves JSONL.

Déterminez si le JSONL ci-dessous contient une preuve directe d'explication ou de transformation pour le SOURCE_CODE ci-dessous.

**Critères de jugement :**
- Un des schémas JSONL doit correspondre exactement à une chaîne réelle ou à un appel d'API dans le SOURCE_CODE pour que la réponse soit « oui ».
- Le simple fait que des mots généraux comme Godot, Godot3, Godot4, migration, 2D, physics soient identiques ne constitue pas une pertinence.
- Si le JSONL porte sur une autre API, un autre nœud ou un autre système, la réponse est « non ».
- N'utilisez pas vos connaissances sur Godot, utilisez uniquement les preuves textuelles présentes dans le JSONL.
- La réponse doit être uniquement « oui » ou « non ».

Matrice de jugement

Liste de contrôle d’observation

Après les 50 échantillons de test par tableau, vérifier les points suivants.

Modèle d’enregistrement des tests

Copiez le tableau ci‑dessous et remplissez les résultats des tests.

Enregistrements par tableau

docs_chunks

Vérifier si les preuves descriptives de la documentation officielle correspondent directement aux morceaux de code.

| 9 | Vitesse de déplacement et logique de rotation de l'ennemi | Différence de version | La documentation sur la vitesse de déplacement et la rotation correspond aux attentes pour chaque code | Les documents non pertinents sont également rejetés comme prévu | 24/24 passé. L'objectif et le comportement final du déplacement/rotation sont relativement clairs, donc les candidats de documentation sont stablement séparés | | 10 | Le joueur disparaît lorsqu'il sort de l'écran | Syntaxe commune | La sortie de l'écran, global_position, get_viewport_rect().size, l'explication de hide() sont résumées comme « oui » | Les autres explications de code sont résumées comme « non » | Syntaxe commune 6/6 passé. Les justifications de la documentation et les candidats de migration sont bien séparés | | 11 | Détection de collision (Area2D ou PhysicsBody) | Différence de version | Comparaison des candidats de documentation expliquant l'événement de collision, la cible détectée, le rappel de collision/la relation du corps physique avec le chunk de code | Distinction avec les candidats expliquant la logique post‑collision comme le calcul des dégâts ou la gestion de la santé | Dans sample-11, vérifier que les justifications de « détection » de collision ne se mélangent pas avec celles du traitement post‑collision | | 12 | Calcul et application des dégâts lors d'une collision | Syntaxe commune | Comparaison des justifications de documentation qui calculent les dégâts et les appliquent à la santé de la cible avec le chunk de code | Distinction avec les candidats expliquant simplement la détection de collision, la mise à jour du score ou le game over | Vérifier dans sample-12 que le cœur de la justification de la documentation porte sur la formule/appli des dégâts plutôt que sur la collision elle‑même | | 13 | Logique de réduction de la santé du joueur | Syntaxe commune | Comparaison des justifications de documentation qui décrivent la diminution de la variable de santé du joueur, le traitement du coup, la gestion de la valeur minimale avec le chunk de code | Distinction avec les candidats décrivant la réduction de santé de l'ennemi ou l'augmentation du score | sample-13 doit distinguer si la chaîne health se réfère au joueur ou à l'ennemi pour juger la justification | | 14 | Gestion du game over lorsque la santé du joueur atteint 0 | Syntaxe commune | Comparaison des justifications de documentation qui décrivent health <= 0, le passage à l'état de game over, le changement/arrêt de scène avec le chunk de code | Distinction avec les candidats décrivant simplement la réduction de santé ou la suppression d'un ennemi | sample-14 vérifie que, après l'atteinte de 0, l'état résultant correspond à la justification de la documentation | | 15 | Logique de réduction de la santé de l'ennemi | Syntaxe commune | Comparaison des justifications de documentation qui décrivent la diminution de la variable de santé de l'ennemi et le traitement du coup avec le chunk de code | Distinction avec les candidats décrivant la réduction de santé du joueur ou le game over | sample-15 doit déterminer si l'objet cible est enemy ou player, ce qui est crucial pour la justification | | 16 | Suppression de l'ennemi lorsque sa santé atteint 0 et ajout de points | Syntaxe commune | Comparaison des justifications de documentation qui décrivent la suppression (queue_free()/désactivation) de l'ennemi et l'augmentation du score avec le chunk de code | Distinction avec les candidats décrivant simplement la réduction de santé ou l'affichage du score | sample-16 vérifie que la suppression et l'ajout de points sont présentés comme une action finale combinée | | 17 | Mise à jour de la variable de score | Syntaxe commune | Comparaison des justifications de documentation qui décrivent l'augmentation/diminution du score et la mise à jour de la valeur cumulée avec le chunk de code | Distinction avec les candidats qui ne font que mettre à jour l'affichage du label UI | sample-17 sépare la mise à jour de la donnée du score de la mise à jour de l'affichage à l'écran | | 18 | Fonction de mise à jour du texte du score (Label) | Syntaxe commune | Comparaison des justifications de documentation qui utilisent Label.text/formatage de chaîne pour refléter le score à l'écran avec le chunk de code | Distinction avec les candidats qui ne mettent à jour que la variable de score | sample-18 vérifie que la justification porte directement sur la réflexion du texte UI plutôt que sur la valeur du score elle‑même | | 19 | Lecture de la musique de fond (BGM) et réglage du volume | Syntaxe commune | Comparaison des justifications de documentation qui décrivent le nœud de lecture du BGM, le bus de volume, la boucle/régulation du volume avec le chunk de code | Distinction avec les candidats qui ne traitent que la lecture ponctuelle d'effets sonores | sample-19 sépare la validation du BGM en lecture continue et des appels courts de SFX |

| 20 | Fonction de lecture d'effets sonores (SFX) | Syntaxe commune | Création/appel du lecteur d'effets sonores, comparaison du raisonnement de lecture ponctuelle avec le bloc de code | Distinction avec les candidats de boucle/ajustement du volume de la musique de fond | sample-20 ne comporte pas de référence BGM uniquement avec des mots communs liés à l'audio |

| 21 | Implémentation de l'effet de vibration d'écran (Screen Shake) | Différence de version | Comparaison du chunk de code avec les explications sur le décalage de la caméra, l'intensité/durée du tremblement, Tween ou offset aléatoire | Distinction avec les candidats de déplacement d'ennemi, suivi de la caméra, animation UI | sample-21 vérifie si, même avec le mot « caméra », l'explication décrit directement le résultat de la vibration d'écran | | 22 | Création d'un système de particules et correspondance de position | Différence de version | Comparaison du chunk de code avec les explications sur la création du nœud particule, la synchronisation de position, le démarrage de l'émission | Distinction avec les candidats de création de nœud générique, de projectile, d'animation | sample-22 vérifie si la cible créée est une particule et si le flux de correspondance de position et d'émission est présent | | 23 | Fonction de changement de scène (Scene Change) | Différence de version | Comparaison du chunk de code avec les explications sur la demande de changement de scène, l'appel à SceneTree, le chemin de la scène cible | Distinction avec les candidats qui affichent un menu, mettent en pause ou chargent des ressources sans changer réellement de scène | sample-23 sépare les appels qui changent réellement l'écran/scene de ceux qui ne font qu'afficher un chargement ou une UI | | 24 | Chargement et affichage de la scène du menu principal | Différence de version | Comparaison du chunk de code avec les explications sur le chargement de la scène du menu principal et son affichage à l'écran | Distinction avec les candidats de simple transition de scène, pause ou préchargement de ressources | sample-24 sépare le flux qui affiche réellement la scène du menu de toute autre explication de gestion de scène | | 25 | Basculement de la fonction pause du jeu | Syntaxe commune | Comparaison du chunk de code avec les explications sur le basculement de l'état pause, get_tree().paused, la mise en pause/reprise selon l'entrée | Distinction avec les candidats d'ouverture de menu, de changement de scène, de game over | sample-25 vérifie si l'état de pause lui‑même est modifié ou s'il s'agit simplement d'une indication UI | | 26 | Vérification de l'état d'entrée clavier (Input.is_key_pressed) | Différence de version | Comparaison du chunk de code avec les explications sur Input.is_key_pressed, les constantes/clés | Distinction avec les candidats d'entrée via action map, entrée souris, logique de déplacement | sample-26 sépare la simple interrogation de l'état du clavier de la logique complète de déplacement | | 27 | Obtention des coordonnées de la position de la souris (curseur) | Syntaxe commune | Comparaison du chunk de code avec les explications sur la récupération de la position de la souris dans le viewport/global | Distinction avec les candidats de tir au clic, entrée tactile, affichage du curseur | sample-27 confirme qu'il s'agit du code qui lit les coordonnées, pas d'un événement de clic | | 28 | Fonction de génération de nombre aléatoire | Différence de version | Comparaison du chunk de code avec les explications sur l'initialisation du RNG, la génération de nombres, la spécification de la plage | Distinction avec les candidats de distribution de positions aléatoires, minuteur de spawn d'ennemi | sample-28 sépare la fonction de génération de nombre du gameplay qui utilise ce nombre | | 29 | Spawn d'ennemi à intervalles réguliers | Différence de version | Comparaison du chunk de code avec les explications basées sur Timer/timeout/temps cumulé pour créer périodiquement des ennemis | Distinction avec les candidats de calcul de position aléatoire ou IA de déplacement d'ennemi | sample-29 vérifie que l'intervalle de temps et l'appel de spawn sont directement justifiés | | 30 | Distribution aléatoire de la position des ennemis spawnés | Syntaxe commune | Comparaison du chunk de code avec les explications sur la plage de coordonnées aléatoires, la zone de spawn, la distribution de position | Distinction avec les candidats de minuteur de spawn à intervalles fixes | sample-30 confirme que l'explication porte sur où placer les ennemis, pas sur le moment du spawn | | 31 | Transition d'état d'animation du joueur (Idle, Run, Jump) | Différence de version | Comparaison du chunk de code avec les explications sur le changement du nom d'animation selon l'entrée/vitesse/état | Distinction avec les candidats de contrôle de vitesse ou de durée d'animation | sample-31 sépare la transition d'état de la régulation du temps de lecture | | 32 | Contrôle du temps de lecture d'une animation | Syntaxe commune | Comparaison du chunk de code avec les explications sur le contrôle de la vitesse d'animation, seek, advance, position de lecture | Distinction avec les candidats de transition d'état Idle/Run/Jump | sample-32 vérifie que l'accent est mis sur la modification du temps/vitesse de lecture, pas sur le choix de l'animation | | 33 | Ajustement de la taille de la zone de collision | Différence de version | Comparaison du chunk de code avec les explications sur les propriétés de taille de CollisionShape2D/Shape2D, les séries size/extents de RectangleShape2D | Distinction avec les candidats de détection de collision, traitement de dégâts, signal Area2D | sample-33 confirme que le code ajuste la forme/taille de la zone de collision, pas qu'il détecte une collision | | 34 | Application de la gravité physique (Gravity) | Différence de version | Comparaison du chunk de code avec les explications sur l'accumulation de la gravité et du delta dans la vélocité et son application via la fonction de déplacement | Distinction avec les candidats de force de saut, détection d'atterrissage, réglage de gravité d'Area | sample-34 sépare le flux d'accumulation de gravité de la logique de saut/atterrissage pour la validation | | 35 | Application de la force de saut (Jump) et détection d'atterrissage | Différence de version | Comparaison du chunk de code avec les explications sur is_on_floor(), la vélocité de saut, les conditions d'entrée, l'état d'atterrissage | Distinction avec les candidats qui n'appliquent que la gravité ou qui ne font que changer l'état d'animation | sample-35 vérifie que l'entrée de saut et la vérification du sol sont décrites dans le même flux de déplacement | | 36 | Gestion du glissement (Slide) lors d'une collision avec un mur | | | | | | 37 | Inversion de la direction du joueur (Facing Left/Right) | | | | | | 38 | Diminution du compteur de munitions (Ammo) | | | | | | 39 | Transition à l'état de rechargement (Reload) lorsque le chargeur est vide | | | | | | 40 | Liaison de l'événement de clic d'un bouton UI | | | | | | 41 | Basculement d'ouverture/fermeture du menu Paramètres (Settings) | | | | | | 42 | Mise à jour du texte lors du changement de langue (Language) | | | | | | 43 | Sérialisation JSON des données de sauvegarde (Save Game) | | | | | | 44 | Désérialisation JSON des données de chargement (Load Game) | | | | | | 45 | Gestion des erreurs de lecture/écriture de fichiers | | | | | | 46 | Vérification de l'état de connexion réseau | | | | | | 47 | Synchronisation via appel de fonction distante (RPC) | | | | | | 48 | Chargement dynamique des ressources de scène | | | | | | 49 | Libération de la mémoire et déchargement des ressources | | | | | | 50 | Impression de logs de débogage (print ou print_debug) | | | | |

api_mapping

Vérifier si les preuves concernant la façon dont les noms, classes, fonctions et symboles passent de Godot 3 à Godot 4 correspondent directement aux morceaux de code.

| 10 | Faire disparaître le joueur lorsqu'il sort de l'écran | Syntaxe commune | Comme il s'agit d'un code commun, aucune conversion du JSONL lié à api_mapping n'est nécessaire | Même les candidats de conversion non pertinents suivent le flux non | 6/6 passé. Il est confirmé que la table de migration n'est pas nécessaire dans la syntaxe commune | | 11 | Détection de collision (Area2D ou PhysicsBody) | Différence de version | Vérifier si les changements d'API de détection de collision Area2D/PhysicsBody ou de connexion de signaux sont nécessaires dans le code actuel | Distingué des mappings d'application de dégâts ou de gestion de la santé | sample-11 est un critère de mapping séparant l'API de détection elle-même de la logique de traitement ultérieure | | 12 | Calcul et application des dégâts lors d'une collision | Syntaxe commune | Vérifier si les changements d'API par version dans la méthode d'application des dégâts existent réellement dans le code | Distingué des mappings qui ne décrivent que le signal de détection de collision | sample-12 sépare les changements nécessitant un mapping de la simple description de la logique de jeu | | 13 | Logique de diminution de la santé du joueur | Syntaxe commune | Vérifier si le code de diminution de la santé du joueur nécessite réellement des changements d'API par version | Distingué des candidats de mapping pour la santé des ennemis, le score, la fin de jeu | sample-13 est majoritairement de la logique de jeu, observer si des justifications de migration sont excessives | | 14 | Gestion du game over lorsque la santé du joueur atteint 0 | Syntaxe commune | Vérifier si les changements de transition de scène, pause, API d'arbre dans la gestion du game over sont directement présents dans le code | Distingué des simples candidats de mapping de diminution de santé | sample-14 vérifie si l'API de transition d'état résultante constitue une justification de mapping | | 15 | Logique de diminution de la santé des ennemis | Syntaxe commune | Vérifier si la logique de diminution de la santé des ennemis nécessite réellement des changements d'API Godot 3→4 | Distingué des mappings de traitement de la santé du joueur ou du score | sample-15 est un cas où, si l'objet cible diffère, le candidat au mapping doit être rejeté (non) | | 16 | Suppression de l'ennemi et ajout de score lorsque sa santé atteint 0 | Syntaxe commune | Vérifier si les différences d'API de suppression, de mise à jour du score et de manipulation de l'arbre de scène sont présentes dans le code | Distingué des simples mappings de dégâts ou de mise à jour de Label | sample-16 examine séparément quelle partie de la suppression ou de l'ajout de score constitue une justification de mapping | | 17 | Mise à jour de la variable de score | Syntaxe commune | Vérifier si la mise à jour de la variable de score nécessite réellement une justification de changement d'API | Distingué des mappings de mise à jour du texte UI ou de sauvegarde/chargement | sample-17 vérifie qu'une simple opération sur une variable n'est pas surévaluée comme justification de migration | | 18 | Fonction de mise à jour du texte du score (Label) | Syntaxe commune | Vérifier si les changements d'accès au texte du Label ou de référence de nœud sont nécessaires dans le code actuel | Distingué des mappings de calcul de la valeur du score | sample-18 vérifie si les expressions de type Label.text sont communes ou varient selon les versions | | 19 | Lecture et réglage du volume de la musique de fond (BGM) | Syntaxe commune | Vérifier si les changements liés à AudioServer, AudioStreamPlayer, volume du bus sont directement nécessaires dans le code | Distingué du mapping de lecture ponctuelle des SFX | sample-19 s'assure que le mapping n'est pas appliqué uniquement sur des termes généraux liés à l'audio | | 20 | Fonction de lecture des effets sonores (SFX) | Syntaxe commune | Vérifier si les changements d'API de lecture des effets sonores ou de création de nœuds sont directement présents dans le code | Distingué du mapping de boucle/volume du BGM | sample-20 sépare les justifications de conversion même si SFX et BGM appartiennent à la même catégorie audio |

| 21 | Implémentation de l'effet de secousse d'écran (Screen Shake) | Différences de version | Vérifier s'il y a des changements d'API selon la version dans l'implémentation de Tween, Camera2D, offset/random shake | Distinction entre le suivi de la caméra et le mapping de déplacement général | sample-21 vérifie si le candidat lié à la caméra constitue une justification de la transformation de secousse d'écran |

| 22 | Création du système de particules et correspondance de position | Différence de version | Vérifier si les changements liés à Particles2D/GPUParticles2D, emitting, position/global_position sont directement présents dans le code | Distinction avec la génération de projectiles ou la création de nœuds généraux | sample-22 examine la séparation entre les évolutions d’API spécifiques aux systèmes de particules et la logique de création générale | | 23 | Fonction de changement de scène (Scene Change) | Différence de version | Vérifier si les changements des séries change_scene, change_scene_to_file, change_scene_to_packed sont directement présents dans le code actuel | Distinction avec le simple load()/preload() ou l’affichage du menu principal | sample-23 vérifie que les appels de changement de scène de Godot 3 et leurs remplacements dans Godot 4 sont correctement appliqués selon la version du code | | 24 | Chargement et affichage de la scène du menu principal | Différence de version | Vérifier si les changements liés au chargement de scène, à l’instanciation et à l’affichage du menu sont nécessaires dans le code actuel | Distinction avec le changement de scène général ou le préchargement de ressources | sample-24 s’assure que les raisons de modification de l’API de scène ne se confondent pas avec le but d’affichage du menu principal | | 25 | Fonction de bascule de pause du jeu | Syntaxe commune | Vérifier si les changements de pause mode/process mode, de pause d’arbre sont réellement nécessaires dans le code actuel | Distinction avec la UI du menu ou la pause de game over | sample-25 contrôle que le code de bascule de pause commun n’est pas surchargé de mappings de migration inutiles | | 26 | Vérification de l’état des touches du clavier (Input.is_key_pressed) | Différence de version | Vérifier si les changements de constantes de touches, scancode/keycode, et de Input.is_key_pressed correspondent directement au code | Distinction avec le traitement des actions de déplacement ou les entrées de souris | sample-26 sépare les évolutions de l’API de vérification d’état des touches et la logique de gameplay qui utilise ces entrées | | 27 | Obtention des coordonnées de la position de la souris (curseur) | Syntaxe commune | Vérifier si l’API de lecture de la position de la souris nécessite des justifications de changement selon les versions | Distinction avec la création de projectiles au clic ou les entrées tactiles | sample-27 s’assure qu’aucune justification de conversion superflue n’est ajoutée au code de lecture des coordonnées | | 28 | Fonction de génération de nombres aléatoires | Différence de version | Vérifier si les changements de randomize, RandomNumberGenerator, fonction range sont directement présents dans le code | Distinction avec la génération d’emplacements aléatoires ou le timer de spawn | sample-28 sépare les modifications de l’API de nombres aléatoires de l’objectif d’utilisation des nombres aléatoires | | 29 | Spawn d’ennemis à intervalles réguliers | Différence de version | Vérifier si les changements liés au signal Timer, à la connexion timeout, aux variantes yield/await sont directement présents dans le code actuel | Distinction avec la distribution aléatoire des positions d’ennemis ou le déplacement IA des ennemis | sample-29 examine la structure d’exécution périodique ainsi que la logique de création des cibles | | 30 | Distribution aléatoire des positions des ennemis spawnés | Syntaxe commune | Vérifier si les changements réels de l’API pour le calcul de la plage aléatoire, la taille du viewport, la zone de spawn sont nécessaires | Distinction avec le mapping du spawn basé sur le timer | sample-30 s’assure que le code ne contenant que le calcul de position n’est pas enrichi de mappings de fréquence de spawn inutiles | | 31 | Transition d’état d’animation du joueur (Idle, Run, Jump) | Différence de version | Vérifier si les changements liés à AnimatedSprite/AnimatedSprite2D, AnimationPlayer et aux transitions d’état correspondent directement au code | Distinction avec le mapping de vitesse de lecture/seek/contrôle du temps | sample-31 sépare les changements de noms de nœuds d’animation des modèles de transition d’état | | 32 | Contrôle du temps de lecture d’une animation | Syntaxe commune | Vérifier si les changements de vitesse de lecture, de seek, de position actuelle sont réellement nécessaires dans le code actuel | Distinction avec le mapping de sélection d’état Idle/Run/Jump | sample-32 différencie l’API de réglage du temps de lecture de l’API de transition d’état | | 33 | Ajustement de la taille de la zone de collision | Différence de version | Vérifier si les changements de CollisionShape2D, RectangleShape2D, taille/extents du shape sont directement nécessaires dans le code actuel | Distinction avec le signal de collision, le layer physique, le mapping de dégâts | sample-33 examine si les modifications de l’API de redimensionnement du shape correspondent réellement au code, séparées de l’API de détection de collision | | 34 | Application de la gravité physique (Gravity) | Différence de version | Vérifier si les changements liés à CharacterBody2D/KinematicBody2D, velocity, move_and_slide sont directement nécessaires dans le code actuel | Distinction avec l’impulsion de saut, la vérification du sol, le mapping de gravité d’Area2D | sample-34 confirme que la gravité est accumulée dans le cadre physique et appliquée au déplacement selon le mapping attendu | | 35 | Application de la force de saut et détection d’atterrissage | Différence de version | Vérifier si les changements de is_on_floor(), vitesse de saut, action Input, move_and_slide correspondent directement au code | Distinction avec le déplacement uniquement sous gravité, l’état d’animation, le mapping de collision murale | sample-35 vérifie que les conditions de démarrage du saut et la détection d’atterrissage sont correctement mappées ensemble | | 36 | Gestion du glissement (Slide) lors d’une collision avec un mur | | | | | | 37 | Inversion de la direction du joueur (Facing Left/Right) | | | | | | 38 | Diminution du compteur de munitions (Ammo) | | | | | | 39 | Transition vers l’état de rechargement (Reload) lorsque le chargeur est vide | | | | | | 40 | Connexion des événements de clic sur les boutons UI | | | | | | 41 | Bascule d’ouverture/fermeture du menu Paramètres (Settings) | | | | | | 42 | Mise à jour du texte lors du changement de langue (Language) | | | | | | 43 | Sérialisation JSON des données de sauvegarde (Save Game) | | | | | | 44 | Désérialisation JSON des données de chargement (Load Game) | | | | | | 45 | Gestion des erreurs de lecture/écriture de fichiers | | | | | | 46 | Vérification de l’état de connexion réseau | | | | | | 47 | Synchronisation via appel de fonction distante (RPC) | | | | | | 48 | Chargement dynamique des ressources de scène | | | | | | 49 | Libération de la mémoire et déchargement des ressources | | | | | | 50 | Impression de logs de débogage (print ou print_debug) | | | | |

label_prototypes

Vérifiez que l'exemple, qui ne consiste pas simplement à renommer mais implique un changement complet de la façon d'utiliser la fonction, de la composition des arguments et du modèle d'appel, correspond directement au fragment de code.

| 10 | Faire disparaître le joueur lorsqu'il sort de l'écran | Syntaxe commune | Comme il s'agit de code commun, la conversion du JSONL lié à label_prototypes ne semble pas nécessaire | Même les candidats de conversion non pertinents sont un flux non | 6/6 passé. Dans la syntaxe commune, il est confirmé que le prototype n'est pas forcément attaché | | 11 | Détection de collision (Area2D ou PhysicsBody) | Différence de version | Vérifier si la façon d'utiliser le signal/callback de détection de collision correspond au modèle avant modification du code actuel | Différencier du prototype d'application de dégâts après collision | sample-11 examine séparément le modèle d'événement de détection et le modèle de traitement du gameplay suivant | | 12 | Calcul et application des dégâts lors d'une collision | Syntaxe commune | Vérifier si le modèle d'appel appliquant les dégâts suite à une collision est présent directement dans le code actuel | Différencier du prototype de simple détection de collision ou de gestion de santé à 0 | sample-12 vérifie si la composition des arguments, l'objet cible et l'ordre d'application des dégâts sont basés sur le prototype | | 13 | Logique de réduction de la santé du joueur | Syntaxe commune | Vérifier si le modèle de frappe/réduction de santé du joueur est présent directement dans le code actuel | Différencier du prototype de réduction de santé des ennemis | sample-13 vérifie la différence de cible joueur/ennemi même dans la même catégorie de santé | | 14 | Gestion du game over lorsque la santé du joueur atteint 0 | Syntaxe commune | Vérifier si le modèle d'appel du game over après santé 0 est présent directement dans le code actuel | Différencier du prototype de simple réduction de santé ou de suppression d'ennemi | sample-14 vérifie si le prototype décrit la transition d'état/gestion de scène après la condition | | 15 | Logique de réduction de la santé des ennemis | Syntaxe commune | Vérifier si le modèle de réduction des dégâts/santé des ennemis est présent directement dans le code actuel | Différencier du prototype de dégâts du joueur | sample-15 examine si des faux positifs apparaissent lorsque les noms d'objet cible et de variable d'état se chevauchent largement | | 16 | Suppression de l'ennemi et ajout de score lorsque sa santé atteint 0 | Syntaxe commune | Vérifier si le modèle d'appel combinant suppression d'ennemi et augmentation du score est présent directement dans le code actuel | Différencier du prototype de simple mise à jour du score ou de simple suppression | sample-16 vérifie si le prototype regroupant plusieurs actions correspond à l'ordre réel du CODE SOURCE | | 17 | Mise à jour de la variable de score | Syntaxe commune | Vérifier si le modèle de mise à jour de la variable score est présent directement dans le code actuel | Différencier du prototype de réflexion du texte du label | sample-17 sépare la mise à jour des données internes et l'affichage UI | | 18 | Fonction de mise à jour du texte du score (Label) | Syntaxe commune | Vérifier si le modèle de mise à jour du texte du label est présent directement dans le code actuel | Différencier du prototype qui ne change que la variable score | sample-18 vérifie s'il s'agit d'un prototype concernant l'affichage à l'écran plutôt que le changement de valeur | | 19 | Lecture et réglage du volume de la musique de fond (BGM) | Syntaxe commune | Vérifier si le modèle de lecture/réglage du volume du BGM est présent directement dans le code actuel | Différencier du prototype de lecture ponctuelle d'SFX | sample-19 se concentre sur l'objectif de lecture continue/réglage du volume plutôt que sur les termes audio généraux | | 20 | Fonction de lecture des effets sonores (SFX) | Syntaxe commune | Vérifier si le modèle d'appel/lecture du SFX est présent directement dans le code actuel | Différencier du prototype de boucle BGM ou de volume de bus | sample-20 sépare la lecture d'effets courts et le flux de gestion de la musique de fond | | 21 | Implémentation de l'effet de secousse d'écran (Screen Shake) | Différence de version | Vérifier si le modèle d'application de l'intensité/du temps/du décalage de secousse d'écran est présent directement dans le code actuel | Différencier du prototype de suivi de caméra ou de Tween général | sample-21 vérifie que l'effet final est une secousse même s'il y a Camera2D/Tween |

| 22 | Création du système de particules et correspondance de position | Différence de version | Vérifier si la création de particules, la correspondance de position et le motif de démarrage de l'émission sont directement présents dans le code actuel | Distinction entre la création de projectiles ou de nœuds généraux et le prototype | sample-22 vérifie si le prototype décrit la synchronisation de position et le démarrage de l'émission |

| 23 | Fonction de changement de scène (Scene Change) | Différence de version | Vérifier si le modèle d’appel qui reçoit le chemin de la scène et passe à SceneTree est présent directement dans le code actuel | Différencier du simple chargement de ressources, ouverture de menu, prototype de pause | sample-23 doit vérifier si le prototype décrit l’entrée du chemin de changement de scène, la cible d’appel et le résultat du changement | | 24 | Chargement et affichage du menu principal | Différence de version | Vérifier si le modèle d’appel qui charge et affiche la scène du menu est présent directement dans le code actuel | Différencier du simple chargement de ressources, changement de scène, prototype du menu pause | sample-24 doit vérifier si le prototype décrit le résultat « afficher le menu principal » | | 25 | Basculement de la fonction pause du jeu | Syntaxe commune | Vérifier si le modèle qui inverse l’état de pause et regroupe le traitement UI/entrée associé est présent directement dans le code actuel | Différencier de l’ouverture du menu des paramètres ou du prototype de game over | sample-25 doit vérifier s’il faut considérer le changement du drapeau pause et l’affichage à la même étape | | 26 | Vérification de l’état d’entrée clavier (Input.is_key_pressed) | Différence de version | Vérifier si le modèle qui interroge directement l’état des touches est présent dans le code actuel | Différencier du prototype de force d’action, vecteur de déplacement, entrée souris | sample-26 consigne la séparation entre la requête d’entrée et l’action exécutée avec cette entrée | | 27 | Obtention des coordonnées de la position de la souris (curseur) | Syntaxe commune | Vérifier si le modèle qui lit les coordonnées du curseur pour les stocker ou les utiliser dans des calculs de position est présent directement dans le code actuel | Différencier du prototype d’événement de clic souris ou de création de projectile | sample-27 doit déterminer si la simple lecture de la position de la souris est le cœur du prototype | | 28 | Fonction de génération de nombre aléatoire | Différence de version | Vérifier si le modèle d’appel de génération de nombres aléatoires / spécification de plage est présent directement dans le code actuel | Différencier du prototype de distribution de position de spawn, table de loot, timer de spawn | sample-28 sépare l’appel à l’API random et les lieux où le résultat aléatoire est utilisé | | 29 | Spawn d’ennemis à intervalles réguliers | Différence de version | Vérifier si le modèle qui appelle la fonction de spawn à chaque intervalle de temps est présent directement dans le code actuel | Différencier du prototype de calcul de position aléatoire ou d’IA de suivi d’ennemi | sample-29 doit vérifier la condition temporelle, le timer et l’ordre d’appel du spawn | | 30 | Distribution aléatoire des positions des ennemis spawnés | Syntaxe commune | Vérifier si le modèle qui place les ennemis générés dans une zone aléatoire est présent directement dans le code actuel | Différencier du prototype de boucle de spawn qui crée des ennemis à intervalles fixes | sample-30 sépare la distribution / calcul des coordonnées du cycle de génération | | 31 | Transition d’état d’animation du joueur (Idle, Run, Jump) | Différence de version | Vérifier si le modèle qui change le nom de l’animation selon la valeur d’état ou la vitesse est présent directement dans le code actuel | Différencier du prototype de vitesse de lecture, de seek, de contrôle de cadre/temps | sample-31 doit déterminer si le passage à tel état est l’élément central | | 32 | Contrôle du temps de lecture d’une animation | Syntaxe commune | Vérifier si le modèle qui contrôle la vitesse de lecture, le seek, la position actuelle de lecture est présent directement dans le code actuel | Différencier du prototype de transition d’état Idle/Run/Jump | sample-32 doit vérifier que le contrôle du temps de lecture, et non le choix de l’animation, est l’élément central | | 33 | Ajustement de la taille de la zone de collision | Différence de version | Vérifier si le modèle qui lit ou modifie la valeur de taille du shape de collision est présent directement dans le code actuel | Différencier du prototype de traitement d’événement de collision ou d’application de dégâts | sample-33 sépare le changement de taille du shape de la gestion du résultat de la collision | | 34 | Application de la gravité physique (Gravity) | Différence de version | Vérifier si le modèle qui accumule la gravité dans la vélocité basée sur delta et la reflète dans l’appel de déplacement est présent directement dans le code actuel | Différencier du prototype d’entrée de saut, de vérification d’atterrissage, de spawn/timer | sample-34 doit déterminer si l’accumulation de gravité dans la boucle de déplacement physique est l’élément central | | 35 | Application de la force de saut et détection d’atterrissage | Différence de version | Vérifier si le modèle qui applique la force de saut lorsqu’on est au sol et vérifie ensuite l’atterrissage est présent directement dans le code actuel | Différencier du prototype de déplacement avec uniquement accumulation de gravité ou de transition d’état d’animation | sample-35 doit vérifier que la condition de saut, le changement de vitesse verticale et le jugement du sol sont liés dans le même flux | | 36 | Gestion du glissement (Slide) lors d’une collision avec un mur | | | | | | 37 | Inversion de la direction du joueur (Facing Left/Right) | | | | | | 38 | Diminution du compteur de munitions (Ammo) | | | | | | 39 | Transition vers l’état de rechargement (Reload) lorsque le chargeur est vide | | | | | | 40 | Liaison d’événement de clic sur les boutons UI | | | | | | 41 | Basculement d’ouverture/fermeture du menu Paramètres (Settings) | | | | | | 42 | Mise à jour du texte lors du changement de langue (Language) | | | | | | 43 | Sérialisation JSON des données de sauvegarde (Save Game) | | | | | | 44 | Désérialisation JSON des données de chargement (Load Game) | | | | | | 45 | Gestion des erreurs de lecture/écriture de fichiers | | | | | | 46 | Vérification de l’état de connexion réseau | | | | | | 47 | Synchronisation via appel de fonction distante (RPC) | | | | | | 48 | Chargement dynamique des ressources de scène | | | | | | 49 | Libération de la mémoire et déchargement des ressources | | | | | | 50 | Impression de logs de débogage (print ou print_debug) | | | | |

Ajout du 6 juillet 2026

Les numéros 6 à 10 avaient déjà été observés en détail le 3 juillet 2026, où le flux d’amélioration avait été intégré. Ainsi, dans ce document, nous ne laissons pas les sections 6‑10 vides ; nous avons reporté les observations existantes dans les tableaux docs_chunks, api_mapping et label_prototypes en les adaptant chacune.

Le 6 juillet 2026, à partir de http://localhost:8520/#item=sample-22, nous avons ajouté les enregistrements 11 à 22. Cette plage décrit, pour chaque entrée, quel candidat de preuve correspond à quel JSONL, et quels candidats doivent être relégués à d’autres codes, transformations ou motifs.

Ajout du 8 juillet 2026

Le 8 juillet 2026, à partir de http://localhost:8520/#item=sample-32, nous avons poursuivi avec les enregistrements 23 à 32. Cette plage est considérée davantage comme un tableau d’observations : comment docs_chunks, api_mapping et label_prototypes doivent expliquer ou rejeter le même fragment de code sous différents points de vue, plutôt que comme un tableau de décisions définitives.

Ajout du 13 juillet 2026

Le 13 juillet 2026, à partir de http://localhost:8520/#item=sample-35, nous avons enregistré les entrées 33 à 35. Cette section porte sur des zones où la taille des collisions, la gravité, le saut/atterrissage, etc., interagissent ; il faut donc examiner non seulement la simple superposition de chaînes, mais aussi le but du code et son emplacement d’application.

Observation inverse du point 5

Le point 5 était inclus dans la quantité cible du jour, mais lorsqu’on l’a inspecté à rebours en JSONL selon Godot 4, le résultat ne s’est pas limité à des paires « oui/non » propres. Nous ne tranchons donc pas encore la décision et le considérerons comme sujet d’analyse de motifs à l’étape suivante.

L’ordre des réponses est : docs_chunks #1, docs_chunks #2, api_mapping #1, api_mapping #2, label_prototypes #1, label_prototypes #2.

Ce résultat doit être vu non pas comme une simple erreur du modèle, mais comme un signal indiquant que les champs match_terms, required_when_seen_in_code et content du JSONL sont peut‑être trop larges. En particulier, des chaînes communes comme move_and_slide() ou Input.is_action_pressed constituent des preuves directes, mais peuvent être trop générales pour justifier des limites de vitesse maximale ou des différences de version.

Enregistrements de cas de non‑correspondance

Faux positif

Cas où la réponse correcte était « non », mais le modèle a indiqué « oui ».

Faux négatif

Cas où la réponse correcte était « oui », mais le modèle a indiqué « non ».

Violation du format de réponse

Cas où la réponse n’est ni « oui » ni « non », mais un texte explicatif, du JSON, une réponse vide ou plusieurs phrases.

Résumé des observations

En menant les tests, nous remplissons les chiffres et les réponses brutes ci‑dessous. Nous ne tranchons pas encore les décisions ; nous observons simplement où les réponses fluctuent.