Estructura de aplicación del 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

Eres un clasificador de ítems de prueba de código de Godot.

A continuación, determina si el TEST_ITEM puede probarse con la misma sintaxis/código chunk tanto en Godot 3 como en Godot 4, o si es necesario crear código separado para Godot 3 y Godot 4.

Criterios de decisión:
- Si es un elemento que se puede describir de forma natural en ambos Godot 3/4 usando la misma sintaxis de GDScript y las mismas llamadas a la API, se clasifica como **"common"**.
- Si el nombre de la clase, el nombre de la función, la firma, el nombre del nodo, la forma de llamada u otros aspectos cambian de manera significativa entre versiones, se clasifica como **"separate"**.
- En caso de duda, se elige **"separate"**. Es preferible crear más pruebas seguras.

La respuesta debe ser un único objeto JSON con el siguiente formato:

{
  "syntax_scope": "common o separate",
  "label": "etiqueta corta en coreano",
  "reason": "una o dos frases explicando la decisión",
  "godot3_focus": "puntos a observar al generar código para Godot 3",
  "godot4_focus": "puntos a observar al generar código para Godot 4"
}

TEST_ITEM:
${itemTitle}

Eres un generador de fragmentos de código para pruebas de Godot.

${versionInstruction}

Requisitos:
- Escribe en unidades de función o bloques de código pequeños, no en todo el proyecto.
- Escribe solo el código directamente relacionado con el ítem de prueba.
- El código debe mostrar la API/sintaxis necesaria para determinar la versión.
- La respuesta debe contener únicamente un objeto JSON.
- No uses fences de código Markdown.

Formato JSON:
{
  "godot_version": "${targetVersion}",
  "syntax_scope": "${syntaxScope}",
  "source_code": "GDScript código chunk",
  "notes": "Puntos clave que deben verificarse en el código"
}

TEST_ITEM:
${itemTitle}

Eres un generador de JSONL para pruebas de Godot RAG.

Objetivo:
${slotCase.goal}

Tabla objetivo:
${table.label}

Propósito de la tabla:
${table.purpose}

Lista de campos:
${table.schema.map((field) => `- ${field}`).join('\n')}

Campos importantes para la determinación de coincidencia directa:
${table.directFields.map((field) => `- ${field}`).join('\n')}

Reglas de generación:
- La respuesta debe contener únicamente un objeto JSON.
- No utilices bloques de código Markdown.
- ${slotCase.generationRule}
- docs_chunks es una coincidencia de evidencia descriptiva, y api_mapping y label_prototypes son coincidencias de evidencia de origen de migración.
- El código ya aplicado en forma de objetivo Godot 4 o la sintaxis común no constituye una evidencia de "necesidad de conversión" en api_mapping/label_prototypes.
- negative_patterns y reject_when_seen_in_code son condiciones de rechazo. Las cadenas en estos campos deben interpretarse como evidencia de "no" y no como evidencia de "sí".
- No te limites a palabras clave amplias; haz que la relevancia se distinga según las cadenas reales o llamadas a API.
- No añadas campos arbitrariamente que no correspondan al propósito de la tabla.
- Los valores de source_url, source_file y *_id deben generarse de forma natural para pruebas.

TEST_ITEM:
${itemTitle}

CODE_VERSION:
${versionLabel}

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode}

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

- En **docs_chunks**, “sí” solo se permite cuando el JSONL describe directamente la acción central del **SOURCE_CODE**.  
- La acción central no es solo el nombre simple de la API, sino que incluye lo que el código calcula, a qué objetivo se aplica y, finalmente, qué estado/resultado produce.  
- Incluso si aparece la misma API o el mismo método, si el JSONL describe un propósito, un objetivo o un resultado diferentes, solo constituye una pista de búsqueda y no una evidencia directa, por lo que la respuesta es “no”.  
- Si el JSONL solo ofrece una descripción general de la API sin detallar los recursos específicos, ramificaciones, bucles o cambios de estado del **SOURCE_CODE**, no es una evidencia directa y la respuesta es “no”.  
- Si el **SOURCE_CODE** muestra una ejecución repetida, una ejecución única, una transición de estado o un reemplazo de recursos y el flujo descrito en el JSONL difiere, la respuesta es “no”.  
- Las funcionalidades que aparecen juntas en el mismo archivo o flujo de juego pueden ser pistas de búsqueda mutuas; sin embargo, solo cuando el objetivo final, el objetivo y el resultado del **SOURCE_CODE** coinciden con los descritos por el JSONL la respuesta es “sí”.  
- Incluso si en **api_symbols** o en los encabezados aparecen nombres de llamadas del **SOURCE_CODE**, si el contenido o los bloques de código describen un flujo de trabajo diferente, no constituye una evidencia directa.  
- Pistas periféricas que se repiten en varios códigos, como funciones de ciclo de vida, tipos comunes o nombres de propiedades genéricas, no son evidencia directa por sí solas.  
- Si los bloques de código del JSONL explican un ejemplo distinto al del **SOURCE_CODE**, aunque algunas APIs coincidan, la respuesta es “no”.  
- No se infiere que APIs de significado similar o casos de uso parecidos sean equivalentes según tu conocimiento; el JSONL debe mostrar explícitamente el propósito, objetivo y resultado del **SOURCE_CODE** actual.  
- Cuando **JSONL_GENERATED_FROM_CODE_VERSION** y **VERIFY_TARGET_CODE_VERSION** difieren, primero verifica si el JSONL describe el comportamiento del código de la versión objetivo de verificación.  
- Aunque las versiones difieran, si se describen explícitamente APIs/comportamientos comunes, podría ser “sí”; sin embargo, si los bloques de código o **api_symbols** del JSONL no coinciden con la sintaxis o llamadas reales del **SOURCE_CODE** actual, incluso si parecen la misma funcionalidad, la respuesta es “no”.

- Las preguntas de api_mapping y label_prototypes no son “¿JSONL y el código están de alguna manera relacionados?” sino “¿Debo cambiar el SOURCE_CODE actual basándome en este JSONL?”.
- Primero determina a cuál de las siguientes categorías pertenece el SOURCE_CODE actual según el JSONL: código antes del cambio, código ya cambiado, código irrelevante o código que no necesita transformación.
- “Sí” solo se permite cuando el SOURCE_CODE actual es código antes del cambio y la transformación que indica el JSONL debe aplicarse ahora.
- El JSONL de integración 3→4 se basa en comparar el código de Godot 3 antes del cambio con el código de Godot 4 después del cambio. En la verificación, separa si el SOURCE_CODE actual corresponde al código antes o después del cambio.
- Si el SOURCE_CODE actual ya está en la forma objetivo de Godot 4, aunque el JSONL parezca relacionado con la explicación de la migración, se considera “ya aplicado”, por lo que la respuesta es “No”.
- La evaluación de “necesita transformación” en label_prototypes es “Sí” solo cuando el SOURCE_CODE actual contiene realmente el patrón de uso, la composición de argumentos y el patrón de llamada anteriores al cambio.
- Un JSONL de transformación irrelevante es “No” incluso si el objetivo de verificación es código de Godot 3, siempre que la transformación no deba aplicarse al SOURCE_CODE actual.
- Los contenidos bajo source/before/required se interpretan como evidencia del código antes del cambio; los bajo target/after/recommended como la forma después del cambio; y los bajo negative/reject como condiciones bajo las cuales no debe aplicarse la transformación al código actual.
- Incluso si el nombre de la función coincide, debe quedar presente en el SOURCE_CODE actual el patrón anterior al cambio que describe el JSONL (por ejemplo, argumentos de llamada, manejo de valores de retorno, nodo heredado, estructura de código circundante) para que la respuesta sea “Sí”.
- source_api y target_api pueden compartir el mismo nombre o contener términos de match_terms tanto para source como para target. En ese caso, solo coincidir el nombre de la función o un término amplio de match_terms no basta para responder “Sí”.
- Funciones que aparecen en el mismo archivo o flujo de juego pueden ser candidatos de búsqueda mutua. Sin embargo, si el patrón anterior al cambio no está presente directamente en el SOURCE_CODE actual, la respuesta es “No”.
- Si JSONL_GENERATED_FROM_CODE_VERSION y VERIFY_TARGET_CODE_VERSION difieren, primero determina si el SOURCE_CODE actual corresponde al código antes del cambio o ya al código después del cambio descrito en el JSONL.
- Cuando JSONL_GENERATED_FROM_CODE_VERSION es una ranura de versión única que no corresponde a una migración, la respuesta es “Sí” solo si el código bajo verificación contiene directamente un patrón source/before/required.
- Si el SOURCE_CODE actual coincide o es más reciente que la forma target/after/recommended del JSONL, se considera código ya aplicado y la respuesta es “No”.
- Si la versión bajo verificación es Godot 4 o common y el SOURCE_CODE ya está en forma target/after, aunque el JSONL sea conocimiento de migración correcto, la respuesta sigue siendo “No”.
- Cuando change_type es signature_stable, no_change, common u otro que indique que no se necesita transformación, la respuesta es “No”.
- Incluso si un JSONL de migración se adjunta a código de Godot 4 o a código de sintaxis común, si no se requiere una transformación adicional, la respuesta es “No”.

- Antes del juicio, capture la operación principal de SOURCE_CODE en una frase, capture también la razón principal que describe JSONL en una frase y compárelas.  
- Considere como evidencia directa solo cuando el objeto objetivo, el propósito de la llamada, el flujo de entrada/parámetros y el resultado final estén en la misma dirección.  
- Incluso si parece un candidato de búsqueda similar, si no explica el SOURCE_CODE actual ni sirve como base para aplicarlo al SOURCE_CODE actual, es "No".

Eres un evaluador de coincidencia de evidencia JSONL.

${question}

Tabla:
${table.label}

Propósito de la tabla:
${table.purpose}

Criterios de evaluación:
- ${firstRule}
- Campos JSONL a revisar: ${table.directFields.join(', ')}
- ${tableRules.join('\n- ')}
- ${decisionRules.join('\n- ')}
- Simplemente coincidir palabras amplias como Godot, Godot3, Godot4, migration, 2D, physics no implica relevancia.
- El contenido mencionado negativamente en el JSONL, como "does not describe", "not related", "unrelated", "does not apply", no se reconoce como evidencia relevante.
- Si el JSONL trata sobre otra API, otro nodo o otro sistema, la respuesta es "no".
- No uses el conocimiento de Godot que poseas; utiliza únicamente la evidencia textual presente en el JSONL.
- La respuesta debe ser únicamente "sí" o "no".

VERSIÓN_DEL_CÓDIGO_GENERADO_DESDE_JSONL:
${sourceVersionKey}

VERSIÓN_DEL_CÓDIGO_OBJETIVO_DE_VERIFICACIÓN:
${targetVersionKey}

CÓDIGO_FUENTE:
${sourceCode}

JSONL:
${jsonlText}

Eres un generador de JSONL para pruebas de Godot RAG.

Objetivo: ${slotCase.goal}
Tabla objetivo: ${table.label}
Uso de la tabla: ${table.purpose}
Campos de coincidencia directa: ${table.directFields.join(', ')}

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

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode || '(Código generado automáticamente después de crear el código de Godot 3)'}

GODOT4_TARGET_CODE:
${targetCode || '(Código generado automáticamente después de crear el código de Godot 4)'}` : `SOURCE_CODE:
${sourceCode || '(Código generado automáticamente después de crear el código)'}`}