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

너는 Godot 코드 테스트 항목 분류기다.

아래 TEST_ITEM이 Godot 3과 Godot 4에서 같은 문법/같은 코드 chunk로 테스트해도 되는지, 아니면 Godot 3용 코드와 Godot 4용 코드를 따로 만들어야 하는지 판정하라.

판정 기준:
- 같은 GDScript 문법과 같은 API 호출로 Godot 3/4 모두에서 자연스럽게 설명 가능한 항목이면 "common"이다.
- 클래스명, 함수명, 시그니처, 노드명, 호출 방식처럼 버전별로 의미 있게 달라지는 API/문법이면 "separate"다.
- 애매하면 "separate"로 둔다. 테스트를 안전하게 더 많이 만드는 쪽이 낫다.
- 답변은 반드시 JSON 객체 하나만 출력한다.

JSON 형식:
{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "왜 그렇게 봤는지 한두 문장",
  "godot3_focus": "Godot 3 코드 생성 시 볼 포인트",
  "godot4_focus": "Godot 4 코드 생성 시 볼 포인트"
}

TEST_ITEM:
${itemTitle}

너는 Godot 테스트용 코드 chunk 생성기다.

${versionInstruction}

요구사항:
- 전체 프로젝트가 아니라 함수 단위 또는 작은 코드 블록 단위로 작성한다.
- 테스트 항목과 직접 관련 있는 코드만 작성한다.
- 코드 안에 버전 판단에 필요한 API/문법이 드러나야 한다.
- 답변은 반드시 JSON 객체 하나만 출력한다.
- Markdown code fence를 쓰지 않는다.

JSON 형식:
{
  "godot_version": "${targetVersion}",
  "syntax_scope": "${syntaxScope}",
  "source_code": "GDScript 코드 chunk",
  "notes": "코드에서 확인해야 할 핵심 포인트"
}

TEST_ITEM:
${itemTitle}

너는 Godot RAG 테스트용 JSONL 생성기다.

목표:
${slotCase.goal}

대상 테이블:
${table.label}

테이블 용도:
${table.purpose}

필드 목록:
${table.schema.map((field) => `- ${field}`).join('\n')}

직접 매칭 판단에 중요한 필드:
${table.directFields.map((field) => `- ${field}`).join('\n')}

생성 규칙:
- 답변은 반드시 JSON 객체 하나만 출력한다.
- Markdown code fence를 쓰지 않는다.
- ${slotCase.generationRule}
- docs_chunks는 설명 근거 매칭이고, api_mapping과 label_prototypes는 마이그레이션 source 근거 매칭이다.
- 이미 Godot 4 target 형태로 적용된 코드나 공통문법 코드는 api_mapping/label_prototypes의 "변환 필요" 근거가 아니다.
- negative_patterns와 reject_when_seen_in_code는 거절 조건이다. 이 필드에 들어간 문자열은 "예" 근거가 아니라 "아니오" 근거로 해석되어야 한다.
- 넓은 주제어만 맞추지 말고, 실제 문자열/API 호출 기준으로 관련/무관이 갈리게 만든다.
- 테이블 용도에서 벗어난 필드를 임의로 늘리지 않는다.
- source_url, source_file, *_id 값은 테스트용으로 자연스럽게 작성한다.

TEST_ITEM:
${itemTitle}

CODE_VERSION:
${versionLabel}

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode}

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

- docs_chunks에서 "예"는 JSONL이 SOURCE_CODE의 핵심 동작을 직접 설명할 때만 허용한다.
- 핵심 동작은 단순 API 이름이 아니라 코드가 무엇을 계산하고, 어떤 대상에 적용하며, 최종적으로 어떤 상태/결과를 만드는지까지 포함한다.
- 같은 API나 같은 메서드가 등장해도 JSONL이 다른 목적, 다른 대상 객체, 다른 결과를 설명하면 검색 후보일 뿐 직접 근거가 아니므로 "아니오"다.
- JSONL이 같은 API의 일반 설명만 제공하고 SOURCE_CODE의 구체적인 리소스, 분기, 반복, 상태 변화까지 설명하지 않으면 직접 설명 근거가 아니므로 "아니오"다.
- SOURCE_CODE가 반복 실행, 단발 실행, 상태 전환, 리소스 교체 중 어떤 흐름인지 보고 JSONL의 흐름이 다르면 "아니오"다.
- 같은 파일이나 같은 게임 흐름에서 함께 등장하는 기능끼리는 서로 검색 후보가 될 수 있다. 이 경우에도 SOURCE_CODE의 최종 목적, 대상, 결과와 JSONL이 설명하는 최종 목적, 대상, 결과가 같을 때만 "예"다.
- api_symbols나 heading에 SOURCE_CODE의 일부 호출명이 있어도, content/code_blocks가 다른 작업 흐름을 설명하면 직접 설명 근거가 아니다.
- 라이프사이클 함수, 공통 타입, 일반 속성명처럼 여러 코드에서 반복되는 주변 단서만 맞는 것은 직접 근거가 아니다.
- JSONL의 code_blocks가 SOURCE_CODE와 다른 예제 코드를 설명하고 있다면, 일부 API가 같아도 "아니오"다.
- 비슷한 의미의 다른 API나 비슷한 사용 사례를 네 지식으로 동등하다고 추론하지 않는다. JSONL에 현재 SOURCE_CODE의 목적/대상/결과가 직접 드러나야 한다.
- JSONL_GENERATED_FROM_CODE_VERSION과 VERIFY_TARGET_CODE_VERSION이 다르면, JSONL이 현재 검증 대상 버전의 코드 동작까지 설명하는지 먼저 확인한다.
- 버전이 달라도 공통 API/공통 동작을 명시적으로 설명하면 "예"일 수 있지만, JSONL의 code_blocks/api_symbols가 현재 SOURCE_CODE의 실제 문법/API 호출과 다르면 같은 기능처럼 보여도 "아니오"다.

- api_mapping과 label_prototypes의 질문은 "JSONL과 코드가 조금이라도 관련 있나"가 아니라 "이 JSONL을 근거로 현재 SOURCE_CODE를 지금 바꿔야 하나"이다.
- 먼저 현재 SOURCE_CODE를 JSONL 기준으로 변경 전 코드, 이미 변경 후 코드, 무관한 코드, 변환 불필요 코드 중 어디에 해당하는지 판정하라.
- "예"는 현재 SOURCE_CODE가 변경 전 코드이고, JSONL이 말하는 변환을 지금 적용해야 할 때만 허용한다.
- 3->4 통합 JSONL은 Godot 3 변경 전 코드와 Godot 4 변경 후 코드를 함께 보고 만든 근거다. 검증 때는 현재 SOURCE_CODE가 그중 변경 전 코드인지 변경 후 코드인지 분리해서 판단하라.
- 현재 SOURCE_CODE가 이미 Godot 4 target 형태라면, JSONL이 마이그레이션 설명과 관련 있어 보여도 "이미 적용됨"이므로 "아니오"다.
- label_prototypes의 "변환 필요" 판단은 현재 SOURCE_CODE가 변경 전 사용 방식, 인자 구성, 호출 패턴을 실제로 담고 있을 때만 "예"다.
- 무관 변환 JSONL은 검증 대상이 Godot 3 코드여도 현재 SOURCE_CODE에 적용할 변환이 아니면 "아니오"다.
- source/before/required 계열 내용은 변경 전 코드 근거로, target/after/recommended 계열 내용은 변경 후 형태로, negative/reject 계열 내용은 현재 코드에 그 변환을 적용하면 안 되는 조건으로 읽는다.
- 함수명이 같아도 호출 인자, 반환값 처리, 상속 노드, 주변 코드 구조처럼 JSONL이 말하는 변경 전 패턴이 SOURCE_CODE에 직접 남아 있어야만 "예"다.
- source_api와 target_api가 같은 이름을 공유하거나 match_terms에 source/target 용어가 함께 들어갈 수 있다. 이때 단일 함수명이나 넓은 match_terms만 일치하면 "예"가 아니다.
- 같은 파일이나 같은 게임 흐름에서 함께 등장하는 기능끼리는 서로 검색 후보가 될 수 있다. 그래도 현재 SOURCE_CODE에 적용할 변경 전 패턴이 직접 남아 있지 않으면 "아니오"다.
- JSONL_GENERATED_FROM_CODE_VERSION과 VERIFY_TARGET_CODE_VERSION이 다르면, 현재 SOURCE_CODE가 JSONL의 변경 전 코드인지 이미 변경 후 코드인지 먼저 구분하라.
- JSONL_GENERATED_FROM_CODE_VERSION이 migration이 아닌 단일 버전 슬롯이면, 현재 검증 대상 코드 안에 source/before/required 패턴이 직접 있을 때만 "예"다.
- 현재 SOURCE_CODE가 JSONL의 target/after/recommended 형태와 같거나 더 최신 형태이면, 이미 적용된 코드이므로 "아니오"다.
- 검증 대상 버전이 Godot 4 또는 common인데 SOURCE_CODE가 이미 target/after 형태이면, JSONL이 올바른 migration 지식이어도 현재 코드에는 "아니오"다.
- change_type이 signature_stable, no_change, common처럼 변환이 필요 없음을 뜻하면 "아니오"다.
- Godot 4 코드 또는 공통문법 코드에 마이그레이션 JSONL이 붙어도, 추가 변환이 필요하지 않으면 "아니오"다.

- 판정 전에 SOURCE_CODE의 핵심 동작을 한 문장으로 잡고, JSONL이 설명하는 핵심 근거도 한 문장으로 잡아 둘을 비교한다.
- 둘의 대상 객체, 호출 목적, 입력/인자 흐름, 최종 결과가 같은 방향일 때만 직접 근거로 본다.
- 비슷한 검색 후보처럼 보여도 현재 SOURCE_CODE를 설명하거나 현재 SOURCE_CODE에 적용할 근거가 아니면 "아니오"다.

너는 JSONL 근거 매칭 판정기다.

${question}

테이블:
${table.label}

테이블 용도:
${table.purpose}

판정 기준:
- ${firstRule}
- 검토할 JSONL 필드: ${table.directFields.join(', ')}
- ${tableRules.join('\n- ')}
- ${decisionRules.join('\n- ')}
- 단순히 Godot, Godot3, Godot4, migration, 2D, physics 같은 넓은 단어가 같으면 관련 없음이다.
- JSONL에 "does not describe", "not related", "unrelated", "does not apply"처럼 부정적으로 언급된 내용은 관련 근거로 인정하지 않는다.
- JSONL이 다른 API, 다른 노드, 다른 시스템에 대한 내용이면 "아니오"다.
- 네가 알고 있는 Godot 지식은 사용하지 말고, JSONL에 적힌 문자열 근거만 사용하라.
- 답변은 반드시 "예" 또는 "아니오" 하나만 출력하라.

JSONL_GENERATED_FROM_CODE_VERSION:
${sourceVersionKey}

VERIFY_TARGET_CODE_VERSION:
${targetVersionKey}

SOURCE_CODE:
${sourceCode}

JSONL:
${jsonlText}

너는 Godot RAG 테스트용 JSONL 생성기다.

목표: ${slotCase.goal}
대상 테이블: ${table.label}
테이블 용도: ${table.purpose}
직접 매칭 필드: ${table.directFields.join(', ')}

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

${isMigrationPair ? `GODOT3_SOURCE_CODE:
${sourceCode || '(Godot 3 코드 생성 후 자동 기입)'}

GODOT4_TARGET_CODE:
${targetCode || '(Godot 4 코드 생성 후 자동 기입)'}` : `SOURCE_CODE:
${sourceCode || '(코드 생성 후 자동 기입)'}`}