Objectif du document

Qwen Validation Debugger est un outil qui teste le flux complet avec des données synthétiques avant que le Retriever opérationnel et le validateur ne soient terminés.

Pour un même sujet de test, créez du code Godot 3 et du code Godot 4, puis générez un JSONL correspondant au code et un JSONL qui ne correspond pas. Ensuite, injectez le même JSONL dans chaque version du code et vérifiez que le jugement final apparaît correctement comme Oui ou Non.

Le schéma de réponse et les types de jugement existants n’ont pas été modifiés.

Portée de la grammaire : common, separate
Table JSONL : docs_chunks, api_mapping, label_prototypes
Slots : positive, negative
Décision finale : Oui, Non

Les champs de valeur de jugement tierce, score, raison supplémentaire n'ont pas été créés.

Flux complet

TEST_ITEM
  -> classification commune / séparée
  -> sauvegarde du résultat de classification
  -> génération du code de version cible
  -> vérification réelle du parseur du moteur Godot
  -> vérification du code Oui/Non de Qwen
  -> génération de JSONL uniquement avec le code qui a réussi
  -> validation du schéma JSON existant
  -> vérification directe des preuves entre le code actuel
  -> validation croisée entre JSONL et le code

separate l'élément crée d'abord le code Godot 3. Le code Godot 4 prend ce code Godot 3 comme REFERENCE_GODOT3_CODE et génère un code correspondant qui maintient les mêmes fonctionnalités et le même flux d'exécution.

Séparation de la classification et de l'entrée de génération de code

La réponse de classification conserve les cinq champs existants.

{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "분류 근거",
  "godot3_focus": "Godot 3 코드 생성 포인트",
  "godot4_focus": "Godot 4 코드 생성 포인트"
}

reason, godot3_focus, godot4_focus sont conservés pour l'affichage à l'écran et l'historique, mais ne sont pas transmis au prompt de génération de code. Même si l'étape de classification explique une syntaxe de version incorrecte, cela empêche que la phrase devienne une base factuelle pour la génération suivante.

La génération de code n'utilise que les entrées suivantes :

Élément de test
common ou separate
Version cible de génération
Code Godot 3 déjà validé lorsqu’on génère separate pour Godot 4
En cas de nouvelle tentative, le code rejeté immédiatement précédent et le diagnostic réel de l'inspection

Contrat de code composite

Le code généré doit être un fichier GDScript complet que le moteur peut analyser, et non une simple chaîne ressemblant à un fragment de code.

La première instruction doit être une déclaration extends.
Utiliser la classe qui possède réellement l'API de test.
Les fonctions ordinaires ne doivent pas être imbriquées dans d’autres fonctions.
Utiliser l’API d’exécution réelle de l’élément de test.
Ne pas simuler le comportement cible avec pass, des commentaires ou des appels locaux.
Ne pas mélanger dans les commentaires ou le code des syntaxes réservées à la version opposée.
Le code Godot 4 doit conserver les fonctionnalités, les entrées, la cible et le résultat du code Godot 3 qui a déjà passé les tests.

Pour les éléments dont la syntaxe diffère clairement selon la version, comme RPC, le contrat de syntaxe officiel est fourni dans le prompt. Il ne s’agit pas d’une logique de substitution post‑génération des mots. Le texte source généré n’est pas modifié arbitrairement, il est directement injecté dans le parseur du moteur.

Inspection réelle du moteur Godot

Le fait que Qwen réévalue son propre code ne suffisait pas à empêcher le passage d’une syntaxe incorrecte. Lors d’un test réel, du code Godot 3 contenant le @rpc de Godot 4 a reçu une réponse « oui » de l’inspecteur Qwen.

Actuellement, le moteur réel est exécuté immédiatement après la génération du code.

Godot 3: --no-window --check-only --script  
Godot 4: --headless --check-only --script  
common: Vérification à la fois de Godot 3 et de Godot 4

Le fichier exécutable peut être spécifié avec GODOT3_BIN ou GODOT4_BIN. L'installation locale par défaut doit être placée dans le répertoire de données utilisateur en dehors du dépôt. Le code à analyser est créé uniquement en tant que fichier temporaire et est supprimé après l'analyse. Les journaux de diagnostic suppriment les chemins temporaires et le chemin du répertoire personnel de l'utilisateur.

La génération et la vérification du code sont effectuées au maximum trois fois. En cas d'échec, on change la graine pour éviter de répéter la même réponse, et on inclut le code précédent ainsi que le diagnostic réel du moteur dans l'invite de génération suivante.

Maintien du schéma JSONL

Les champs de niveau supérieur sont identiques aux trois définitions de tables existantes.

docs_chunks

chunk_id, doc_version, source_url, source_file, source_sha256,
doc_type, symbol, section_path, heading, content, code_blocks,
language_tags, godot_version_tags, api_symbols, token_count, metadata

api_mapping

mapping_id, source_api, target_api, change_type, godot_from,
godot_to, confidence, evidence_chunk_ids, match_terms, notes,
negative_patterns

label_prototypes

prototype_id, label, task_type, input_pattern, expected_finding,
recommended_action, evidence_mapping_ids, evidence_chunk_ids,
severity, validator_rules

validator_rules utilise également uniquement les quatre champs existants.

{
  "required_when_seen_in_code": [],
  "before_code": "",
  "after_code": "",
  "reject_when_seen_in_code": []
}

Après avoir reçu la réponse, vérifiez les champs obligatoires, le type, les énumérations et la présence de champs supplémentaires avec le schéma JSON d’origine. Si le modèle écrit confidence comme un nombre ou section_path comme une chaîne, refusez et régénérez jusqu’à trois fois.

Génération positive et negative

Le JSONL positif utilise les preuves directes du code synthétique actuel.

docs_chunks : décrit directement le but du code, la cible, le flux d’entrée et le résultat.
api_mapping : le source_api de Godot 3 et le target_api de Godot 4 doivent chacun être présents dans le code réel.
label_prototypes : les preuves « before » doivent se trouver dans le code Godot 3, les preuves « after » dans le code Godot 4.
Les negative_patterns et reject_when_seen_in_code du positif sont des tableaux vides.

Pour la génération du JSONL négatif, ne fournissez pas le code actuel ni l’élément actuel. Sélectionnez dynamiquement l’élément d’échantillon suivant comme NEGATIVE_TEST_ITEM et créez le JSONL uniquement avec cet autre élément. Après génération, le serveur compare directement avec le code actuel ; si les preuves source/before se chevauchent, il refuse.

Ce processus ne remplace pas un nom d’API ou une phrase par une correspondance un‑à‑un. Il utilise uniquement la sélection de l’ordre des échantillons et la comparaison de chaînes du résultat réel.

Ordre de validation

La validation se déroule dans l’ordre suivant.

Si le résultat est fixé par la structure de slot de version, jugez « non » sans appeler le modèle.
Si aucune preuve directe de la modification de migration n’est présente dans le code actuel, jugez « non ».
Ce n’est que si les deux conditions précédentes ne sont pas satisfaites que Qwen compare le sens et le mode d’utilisation.

La porte déterministe ne crée pas de nouvel état. La valeur de retour reste « oui » ou « non », comme auparavant.

JSONL	Cible de validation	Réponse attendue
`docs_chunks` positif même version	Code de référence	oui
`docs_chunks` positif version différente	Code croisé	non
`docs_chunks` négatif	N’importe quel code	non
Migration `3 -> 4` positif	Code Godot 3	oui
Migration `3 -> 4` positif	Code Godot 4	non
Migration `3 -> 4` négatif	N’importe quel code	non

Fiabilité des requêtes API

Désactivez la sortie de réflexion.
La classification, le code et le JSONL doivent demander une réponse JSON Schema ne contenant que les champs existants.
Le jugement final n’accepte que « oui » ou « non » en grammaire.
Changez la graine pour régénérer le code et le JSONL.
En cas de HTTP 429, 502, 503, 504, fermeture de connexion ou dépassement du délai, réessayez jusqu’à trois fois.

La clé API n’est incluse dans la requête qu’à partir de la valeur saisie actuellement dans la mémoire du navigateur. Elle n’est pas enregistrée dans le dépôt, la documentation, les journaux ou les commits.

Résultats du test du 15 juillet 2026

27 tests unitaires de contrat ont été réussis.

Lors de l’inspection du moteur Godot réel, les points suivants ont été constatés :

Le code remote func de Godot 3 a passé le parseur de Godot 3.
Ajouter @rpc à du code Godot 3 a été rejeté avec « Unexpected '@' ».
Le code @rpc de Godot 4 a passé le parseur de Godot 4.

Les résultats de l’examen Qwen sur RunPod sont les suivants :

E2E complet initial : 5/12 réussis. Des codes de synthèse Godot 3 incorrects et des jugements de pertinence large ont été détectés.
Après inspection du moteur et application du contrat de génération, E2E complet : 10/12 réussis.
Après ajout d’éléments négatifs dynamiques et de la porte de comparaison de chaînes directe, migration négative : 4/4 réussis.
Les 2 cas restants concernaient un modèle qui a ignoré le contrat de slot interdisant de réappliquer la migration positive à Godot 4. Cette condition a été déplacée vers une porte de version déterministe et les tests unitaires sont passés.
Un nouveau test complet a été lancé, mais le service RunPod a renvoyé HTTP 502 pour /v1/models et les requêtes de génération, interrompant le processus. Ce n’était pas un refus de code ou de JSONL, mais une absence de réponse du service distant.

Lorsque le service distant répondra à nouveau, les 12 scénarios E2E devront être réexécutés depuis le début.