Structure d'application du prompt Qwen Validation Debugger

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

mapping_id
source_api
target_api
change_type
godot_from
godot_to
confidence
evidence_chunk_ids
match_terms
notes
negative_patterns

prototype_id
label
task_type
input_pattern
expected_finding
recommended_action
evidence_mapping_ids
evidence_chunk_ids
severity
validator_rules

Vous êtes un classificateur d'éléments de test de code Godot.

Déterminez si le TEST_ITEM ci‑dessous peut être testé avec la même syntaxe/même bloc de code à la fois dans Godot 3 et Godot 4, ou s'il faut créer séparément du code pour Godot 3 et pour Godot 4.

Critères de jugement :
- Si c’est un élément qui peut être expliqué naturellement dans les deux versions grâce à la même syntaxe GDScript et aux mêmes appels d’API, il est « common ».
- Si le nom de classe, le nom de fonction, la signature, le nom de nœud, le mode d’appel, etc., diffèrent de manière significative entre les versions, il est « separate ».
- En cas d’ambiguïté, choisissez « separate ». Il vaut mieux créer davantage de tests sûrs.
- La réponse doit être un seul objet JSON.

Format JSON :
{
  "syntax_scope": "common ou separate",
  "label": "court libellé en coréen",
  "reason": "une ou deux phrases expliquant pourquoi",
  "godot3_focus": "points à considérer lors de la génération du code Godot 3",
  "godot4_focus": "points à considérer lors de la génération du code Godot 4"
}

TEST_ITEM :
${itemTitle}

Vous êtes un générateur de fragments de code pour les tests Godot.

${versionInstruction}

Exigences :
- Écrire au niveau des fonctions ou de petits blocs de code, pas pour l'ensemble du projet.
- Écrire uniquement le code directement lié à l'élément de test.
- Le code doit exposer les API/syntaxe nécessaires pour déterminer la version.
- La réponse doit contenir un seul objet JSON.
- Ne pas utiliser de bloc de code Markdown.

Format JSON :
{
  "godot_version": "${targetVersion}",
  "syntax_scope": "${syntaxScope}",
  "source_code": "fragment de code GDScript",
  "notes": "Points clés à vérifier dans le code"
}

ÉLÉMENT_DE_TEST :
${itemTitle}

Tu es un générateur JSONL pour les tests RAG de Godot.

Objectif :
${slotCase.goal}

Table cible :
${table.label}

Utilisation de la table :
${table.purpose}

Liste des champs :
${table.schema.map((field) => `- ${field}`).join('\n')}

Champs importants pour le jugement de correspondance directe :
${table.directFields.map((field) => `- ${field}`).join('\n')}

Règles de génération :
- La réponse doit contenir exactement un seul objet JSON.
- N'utilise pas de bloc de code Markdown.
- ${slotCase.generationRule}
- `docs_chunks` correspond à la correspondance basée sur l'explication, et `api_mapping` ainsi que `label_prototypes` correspondent à la correspondance basée sur la source de migration.
- Le code déjà appliqué sous forme cible Godot 4 ou le code de syntaxe commune ne constitue pas une raison « transformation nécessaire » dans `api_mapping`/`label_prototypes`.
- `negative_patterns` et `reject_when_seen_in_code` sont des conditions de rejet. Les chaînes contenues dans ces champs doivent être interprétées comme des raisons « non », et non comme des raisons « oui ».
- Ne te limite pas aux mots‑clés généraux, mais base la pertinence/irrélevance sur les chaînes réelles ou les appels d'API.
- N'ajoute pas de champs qui sortent du cadre d'utilisation de la table.
- Les valeurs `source_url`, `source_file`, *_id doivent être rédigées de façon naturelle pour les tests.

ÉLÉMENT_DE_TEST :
${itemTitle}

VERSION_DU_CODE :
${versionLabel}

${isMigrationPair ? `CODE_SOURCE_GODOT3:
${sourceCode}

CODE_CIBLE_GODOT4:
${targetCode}` : `CODE_SOURCE:
${sourceCode}`}

- Dans docs_chunks, « oui » n’est autorisé que lorsque le JSONL décrit directement le comportement central du SOURCE_CODE.
- Le comportement central ne se limite pas à un simple nom d’API ; il inclut ce que le code calcule, sur quel objet il s’applique et quel état/résultat final il produit.
- Même si la même API ou la même méthode apparaît, si le JSONL décrit un objectif, un objet cible ou un résultat différents, il ne s’agit que d’un candidat de recherche et non d’une preuve directe, donc « non ».
- Si le JSONL ne fournit qu’une description générale de l’API sans expliquer les ressources spécifiques, les branches, les boucles ou les changements d’état du SOURCE_CODE, ce n’est pas une preuve directe, donc « non ».
- Si le SOURCE_CODE représente une exécution répétée, une exécution unique, une transition d’état ou un remplacement de ressource, et que le flux décrit par le JSONL diffère, c’est « non ».
- Les fonctionnalités apparaissant ensemble dans le même fichier ou le même flux de jeu peuvent être des candidats de recherche mutuels. Ce n’est « oui » que si le but final, la cible et le résultat du SOURCE_CODE correspondent à ceux décrits par le JSONL.
- Même si des noms d’appels du SOURCE_CODE figurent dans api_symbols ou les titres, si le contenu ou les blocs de code décrivent un flux de travail différent, ce n’est pas une preuve directe.
- Les indices contextuels récurrents dans plusieurs codes, comme les fonctions de cycle de vie, les types communs ou les noms d’attributs généraux, ne constituent pas une preuve directe.
- Si les blocs de code du JSONL illustrent un exemple différent de celui du SOURCE_CODE, même si certaines API sont les mêmes, c’est « non ».
- On ne doit pas inférer que des API au sens similaire ou des cas d’utilisation similaires sont équivalents selon nos connaissances. Le JSONL doit exposer directement le but, la cible et le résultat du SOURCE_CODE actuel.
- Si JSONL_GENERATED_FROM_CODE_VERSION et VERIFY_TARGET_CODE_VERSION diffèrent, il faut d’abord vérifier que le JSONL décrit le comportement du code de la version cible en cours de vérification.
- Même si les versions diffèrent, il peut être « oui » si les API/behaviors communs sont explicitement décrits ; toutefois, si les blocs de code ou api_symbols du JSONL ne correspondent pas à la syntaxe/API réelle du SOURCE_CODE actuel, c’est « non », même si cela ressemble à la même fonctionnalité.

- Les questions concernant **api_mapping** et **label_prototypes** ne portent pas sur « si le JSONL et le code sont même légèrement liés », mais sur « si, à partir de ce JSONL, il faut maintenant modifier le **SOURCE_CODE** actuel ».
- Commencez par déterminer, à partir du JSONL, si le **SOURCE_CODE** actuel correspond à du code **avant modification**, du code **déjà modifié**, du code **sans rapport**, ou à du code **ne nécessitant pas de conversion**.
- « Oui » n’est autorisé que lorsque le **SOURCE_CODE** actuel est du code **avant modification** et que la conversion décrite dans le JSONL doit être appliquée immédiatement.
- Le JSONL d’intégration 3→4 a été créé en comparant le code **avant** de Godot 3 et le code **après** de Godot 4. Lors de la validation, il faut distinguer si le **SOURCE_CODE** actuel correspond au code **avant** ou **après**.
- Si le **SOURCE_CODE** actuel est déjà sous forme cible de Godot 4, même si le JSONL semble lié à la description de migration, il est considéré comme « déjà appliqué », donc la réponse est « Non ».
- Le jugement « conversion nécessaire » de **label_prototypes** n’est « Oui » que lorsque le **SOURCE_CODE** actuel contient réellement le mode d’utilisation, la composition des arguments et le schéma d’appel **avant** la conversion.
- Un JSONL de conversion « sans rapport » donne « Non » même si le code cible de la validation est du code Godot 3, tant que la conversion ne s’applique pas au **SOURCE_CODE** actuel.
- Les sections **source/before/required** servent de preuve de code **avant** modification, les sections **target/after/recommended** décrivent la forme **après** modification, et les sections **negative/reject** indiquent les conditions dans lesquelles la conversion ne doit **pas** être appliquée au code actuel.
- Même si le nom de fonction est identique, il faut que le **pattern** « avant » décrit par le JSONL (arguments d’appel, traitement du retour, nœud hérité, structure du code environnant, etc.) soit présent explicitement dans le **SOURCE_CODE** pour que la réponse soit « Oui ».
- **source_api** et **target_api** peuvent partager le même nom ou contenir des termes communs dans **match_terms**. Ce n’est pas suffisant pour répondre « Oui » si seul le nom de fonction ou un terme large correspond.
- Les fonctionnalités qui apparaissent dans le même fichier ou le même flux de jeu peuvent être considérées comme candidates à la recherche mutuelle. Toutefois, si le **pattern** « avant » n’est pas présent dans le **SOURCE_CODE** actuel, la réponse reste « Non ».
- Si **JSONL_GENERATED_FROM_CODE_VERSION** et **VERIFY_TARGET_CODE_VERSION** diffèrent, il faut d’abord déterminer si le **SOURCE_CODE** actuel correspond au code **avant** ou **déjà après** du JSONL.
- Lorsque **JSONL_GENERATED_FROM_CODE_VERSION** représente une version unique (et non une migration), la réponse n’est « Oui » que si le code à valider contient explicitement le pattern **source/before/required**.
- Si le **SOURCE_CODE** actuel correspond déjà à la forme **target/after/recommended** du JSONL ou à une version plus récente, il s’agit d’un code déjà appliqué, donc la réponse est « Non ».
- Si la version à valider est Godot 4 ou « common » et que le **SOURCE_CODE** est déjà sous forme **target/after**, même si le JSONL représente une migration correcte, la réponse est « Non ».
- Lorsque **change_type** est *signature_stable*, *no_change*, *common* ou tout autre indicateur d’absence de conversion nécessaire, la réponse est « Non ».
- Même si un JSONL de migration est attaché à du code Godot 4 ou à du code à syntaxe commune, si aucune conversion supplémentaire n’est requise, la réponse est « Non ».

- Avant le jugement, résumez l'opération principale du CODE_SOURCE en une phrase, ainsi que le raisonnement principal décrit par le JSONL en une phrase, puis comparez les deux.
- Considérez comme preuve directe uniquement lorsque les objets cibles, le but de l'appel, le flux d'entrée/paramètres et le résultat final sont alignés dans la même direction.
- Même si cela ressemble à un candidat de recherche similaire, si cela n'explique pas le CODE_SOURCE actuel ou ne constitue pas une preuve applicable au CODE_SOURCE actuel, c'est « non ».

Vous êtes un juge de correspondance de preuves JSONL.

${question}

Tableau :
${table.label}

Utilisation du tableau :
${table.purpose}

Critères de jugement :
- ${firstRule}
- Champs JSONL à examiner : ${table.directFields.join(', ')}
- ${tableRules.join('\n- ')}
- ${decisionRules.join('\n- ')}
- Si les mots larges tels que Godot, Godot3, Godot4, migration, 2D, physics sont simplement identiques, ils ne sont pas pertinents.
- Les contenus mentionnés négativement dans le JSONL, comme "does not describe", "not related", "unrelated", "does not apply", ne sont pas reconnus comme preuves pertinentes.
- 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".

JSONL_GENERATED_FROM_CODE_VERSION:
${sourceVersionKey}

VERIFY_TARGET_CODE_VERSION:
${targetVersionKey}

SOURCE_CODE:
${sourceCode}

JSONL:
${jsonlText}

Vous êtes un générateur JSONL pour les tests Godot RAG.

Objectif: ${slotCase.goal}
Table cible: ${table.label}
Utilisation de la table: ${table.purpose}
Champs de correspondance directe: ${table.directFields.join(', ')}

TEST_ITEM: ${itemTitle}
CODE_VERSION: ${versionLabel}

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode || '(Entrée automatique après génération du code Godot 3)'}

GODOT4_TARGET_CODE:
${targetCode || '(Entrée automatique après génération du code Godot 4)'}` : `SOURCE_CODE:
${sourceCode || '(Entrée automatique après génération du code)'}`}