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 で同じ文法/同じコードチャンクでテストできるか、あるいは 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 テスト用コードチャンク生成器です.

${versionInstruction}

要件:
- プロジェクト全体ではなく、関数単位または小さなコードブロック単位で作成する。
- テスト項目と直接関連するコードのみ作成する。
- コード内にバージョン判定に必要な API/構文が現れるようにする。
- 回答は必ず JSON オブジェクトを一つだけ出力する。
- Markdown のコードフェンスを使用しない。

JSON 形式:
{
  "godot_version": "${targetVersion}",
  "syntax_scope": "${syntaxScope}",
  "source_code": "GDScript コードチャンク",
  "notes": "コードで確認すべき重要ポイント"
}

テスト項目:
${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 コードフェンスを使用しない。
- ${slotCase.generationRule}
- docs_chunks は説明根拠マッチングで、api_mapping と label_prototypes はマイグレーションソース根拠マッチングです。
- 既に Godot 4 ターゲット形態で適用されたコードや共通文法コードは 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がマイグレーションでない単一バージョンスロットである場合、現在の検証対象コード内にsource/before/requiredパターンが直接存在するときのみ「はい」とする。  
- 現在のSOURCE_CODEがJSONLのtarget/after/recommended形態と同等またはそれ以上の新しい形態であれば、すでに適用されたコードなので「いいえ」とする。  
- 検証対象バージョンがGodot 4またはcommonで、SOURCE_CODEがすでにtarget/after形態であれば、JSONLが正しいマイグレーション知識であっても現在のコードには「いいえ」とする。  
- 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 || '(コード生成後自動入力)'}`}