Qwen Validation Debugger Prompt Application Structure

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

You are a Godot code test item classifier.

Determine whether the TEST_ITEM below can be tested with the same syntax/code chunk in both Godot 3 and Godot 4, or whether separate code for Godot 3 and Godot 4 must be created.

Judgment criteria:
- If it is an item that can be naturally explained in both Godot 3/4 with the same GDScript syntax and the same API calls, it is "common."
- If the API/syntax meaningfully changes by version, such as class names, function names, signatures, node names, or call styles, it is "separate."
- If ambiguous, treat it as "separate." It is better to create more safe tests.
- The answer must output **exactly one** JSON object.

JSON format:
{
  "syntax_scope": "common or separate",
  "label": "short Korean label",
  "reason": "one or two sentences explaining why",
  "godot3_focus": "points to consider when generating Godot 3 code",
  "godot4_focus": "points to consider when generating Godot 4 code"
}

TEST_ITEM:
${itemTitle}

You are a Godot test code chunk generator.

${versionInstruction}

Requirements:
- Write it as a function-level or small code block rather than the entire project.
- Include only the code directly related to the test item.
- The API/syntax needed for version detection must be visible in the code.
- The response must output exactly one JSON object.
- Do not use Markdown code fences.

JSON format:
{
  "godot_version": "${targetVersion}",
  "syntax_scope": "${syntaxScope}",
  "source_code": "GDScript code chunk",
  "notes": "Key points to verify in the code"
}

TEST_ITEM:
${itemTitle}

You are a Godot RAG test JSONL generator.

Goal:
${slotCase.goal}

Target table:
${table.label}

Table purpose:
${table.purpose}

Field list:
${table.schema.map((field) => `- ${field}`).join('\n')}

Fields important for direct matching judgment:
${table.directFields.map((field) => `- ${field}`).join('\n')}

Generation rules:
- The answer must output exactly one JSON object.
- Do not use a Markdown code fence.
- ${slotCase.generationRule}
- docs_chunks is explanation evidence matching, and api_mapping and label_prototypes are migration source evidence matching.
- Code already applied in Godot 4 target form or common syntax is not a "transformation needed" evidence for api_mapping/label_prototypes.
- negative_patterns and reject_when_seen_in_code are rejection conditions. Strings placed in these fields should be interpreted as "no" evidence, not "yes" evidence.
- Do not match only broad keywords; make relevance/irrelevance depend on actual strings/API calls.
- Do not arbitrarily add fields that deviate from the table purpose.
- source_url, source_file, *_id values should be written naturally for testing.

TEST_ITEM:
${itemTitle}

CODE_VERSION:
${versionLabel}

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode}

GODOT4_TARGET_CODE:
${targetCode}` : `SOURCE_CODE:
${sourceCode}`}

- In docs_chunks, "yes" is allowed only when the JSONL directly describes the core operation of SOURCE_CODE.  
- The core operation includes not just a simple API name but also what the code computes, what target it applies to, and ultimately what state/result it produces.  
- Even if the same API or method appears, if the JSONL describes a different purpose, different target object, or different result, it is only a search candidate and not a direct justification, so the answer is "no".  
- If the JSONL provides only a generic description of the same API and does not explain the specific resources, branches, loops, or state changes of the SOURCE_CODE, it is not a direct justification, so the answer is "no".  
- If the SOURCE_CODE involves repeated execution, single execution, state transition, or resource replacement, and the JSONL’s flow differs, the answer is "no".  
- Functions that appear together in the same file or game flow can be search candidates for each other. Even in this case, it is "yes" only when the final purpose, target, and result of the SOURCE_CODE match those described by the JSONL.  
- Even if api_symbols or headings contain part of a call name from the SOURCE_CODE, if the content/code_blocks describe a different workflow, it is not a direct justification.  
- Repeated contextual clues across multiple code files, such as lifecycle functions, common types, or generic property names, are not direct justifications on their own.  
- If the JSONL’s code_blocks describe example code that differs from the SOURCE_CODE, it is "no" even if some APIs are the same.  
- Do not infer that different APIs with similar meanings or similar use cases are equivalent based on your knowledge. The JSONL must directly reveal the current SOURCE_CODE’s purpose/target/result.  
- If JSONL_GENERATED_FROM_CODE_VERSION and VERIFY_TARGET_CODE_VERSION differ, first verify whether the JSONL explains the behavior of the code version currently under verification.  
- Even if the versions differ, it can be "yes" if common APIs/common operations are explicitly described; however, if the JSONL’s code_blocks/api_symbols differ from the actual syntax/API calls in the current SOURCE_CODE, it is "no" even if they appear to perform the same function.

- The question of api_mapping and label_prototypes is not “Is there any relation between JSONL and the code?” but rather “Based on this JSONL, should we now change the current SOURCE_CODE?”
- First, determine whether the current SOURCE_CODE, according to the JSONL, falls into pre‑change code, already changed code, irrelevant code, or code that does not need conversion.
- “Yes” is allowed only when the current SOURCE_CODE is pre‑change code and the conversion described by the JSONL should be applied now.
- The 3→4 integrated JSONL was created by looking at both the Godot 3 pre‑change code and the Godot 4 post‑change code. During verification, separate whether the current SOURCE_CODE is the pre‑change code or the post‑change code.
- If the current SOURCE_CODE is already in the Godot 4 target form, even if the JSONL appears related to migration instructions, it is considered “already applied,” so the answer is “No.”
- The “conversion needed” judgment in label_prototypes is “Yes” only when the current SOURCE_CODE actually contains the pre‑change usage, argument composition, and call pattern described.
- An irrelevant‑conversion JSONL is “No” even if the verification target is Godot 3 code, as long as the conversion does not apply to the current SOURCE_CODE.
- Content under source/before/required is read as evidence of pre‑change code; content under target/after/recommended is read as the post‑change form; content under negative/reject is read as conditions under which the conversion must not be applied to the current code.
- Even if the function name is the same, the pre‑change pattern described by the JSONL (such as call arguments, return‑value handling, inherited node, surrounding code structure) must be directly present in the SOURCE_CODE for the answer to be “Yes.”
- source_api and target_api may share the same name or contain source/target terms in match_terms. A match on a single function name or a broad match_terms alone does not constitute “Yes.”
- Features that appear together in the same file or game flow can be search candidates for each other. Still, if the pre‑change pattern to be applied is not directly present in the current SOURCE_CODE, the answer is “No.”
- If JSONL_GENERATED_FROM_CODE_VERSION and VERIFY_TARGET_CODE_VERSION differ, first distinguish whether the current SOURCE_CODE is the pre‑change code or already the post‑change code from the JSONL.
- If JSONL_GENERATED_FROM_CODE_VERSION is a single version slot that is not a migration, the answer is “Yes” only when the source/before/required pattern is directly present in the current verification target code.
- If the current SOURCE_CODE matches or is newer than the JSONL’s target/after/recommended form, it is already applied, so the answer is “No.”
- When the verification target version is Godot 4 or common and the SOURCE_CODE is already in the target/after form, the answer is “No” even if the JSONL contains correct migration knowledge.
- If change_type is signature_stable, no_change, common, etc., indicating that no conversion is needed, the answer is “No.”
- Even if a migration JSONL is attached to Godot 4 code or common‑syntax code, the answer is “No” when no additional conversion is required.

- Before judging, capture the core operation of SOURCE_CODE in one sentence, also capture the core rationale described by JSONL in one sentence, and compare the two.  
- Consider it direct evidence only when the target objects, call purpose, input/argument flow, and final result are aligned in the same direction.  
- Even if it looks like a similar search candidate, if it does not explain the current SOURCE_CODE or provide a basis for applying to the current SOURCE_CODE, it is “No.”

You are a JSONL evidence matching judge.

${question}

Table:
${table.label}

Table purpose:
${table.purpose}

Decision criteria:
- ${firstRule}
- JSONL fields to review: ${table.directFields.join(', ')}
- ${tableRules.join('\n- ')}
- ${decisionRules.join('\n- ')}
- If only broad words such as Godot, Godot3, Godot4, migration, 2D, physics are the same, it is not relevant.
- Content in JSONL that is mentioned negatively, such as "does not describe", "not related", "unrelated", "does not apply", is not recognized as relevant evidence.
- If the JSONL is about a different API, different node, or different system, it is "No".
- Do not use your own Godot knowledge; use only the string evidence written in the JSONL.
- The answer must output only "Yes" or "No".

JSONL_GENERATED_FROM_CODE_VERSION:
${sourceVersionKey}

VERIFY_TARGET_CODE_VERSION:
${targetVersionKey}

SOURCE_CODE:
${sourceCode}

JSONL:
${jsonlText}

You are a JSONL generator for Godot RAG testing.

Goal: ${slotCase.goal}
Target Table: ${table.label}
Table Purpose: ${table.purpose}
Direct Matching Fields: ${table.directFields.join(', ')}

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

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode || '(Automatically filled after generating Godot 3 code)'}

GODOT4_TARGET_CODE:
${targetCode || '(Automatically filled after generating Godot 4 code)'}` : `SOURCE_CODE:
${sourceCode || '(Automatically filled after code generation)'}`}