Qwen-Test-JSONL-Schema und Verwendungszweck

Erstellungsdatum: 28. Juni 2026

Zweck

Erstelle einen Godot‑Code‑Chunk mit Qwen und füge dem Code‑Chunk korrekte JSONL und falsche JSONL hinzu, um bei der Ja/Nein‑Validierung die zu beachtende JSONL‑Format und die Verwendung jedes JSONL zu dokumentieren.

Dieses Dokument ist kein Dokument, das Beispieldaten bereitstellt. Es ist ein Schemareferenzdokument, um beim Testen zu überprüfen, welche JSONL welche Rolle spielt und welche Felder für die direkte Evidenzbewertung verwendet werden.

Gemeinsame Kriterien

JSONL schreibt ein JSON‑Objekt pro Zeile.

{...}
{...}
{...}

Im Test wird kein Wrapper um den Tabellennamen gesetzt, sondern das Feld, das der Spalte der Zieltabelle entspricht, auf der obersten Ebene platziert.

Gut:
{"chunk_id":"...","content":"...","code_blocks":[...]}

Vermeiden:
{"table":"docs_chunks","payload":{"chunk_id":"..."}}

Felder, die in der DB automatisch erzeugt werden oder in den Such‑Index geschrieben werden, müssen im Test‑JSONL nicht manuell ausgefüllt werden.

DB‑Betriebsfeld	Test‑JSONL‑Basis
`id`	ausgeschlossen
`embedding`	ausgeschlossen oder null
`search_tsv`	ausgeschlossen
`created_at`	ausgeschlossen

Bei der direkten Beweisprüfung von Qwen ist wichtig, dass „welches Feld in JSONL exakt mit dem tatsächlichen String/API/Pattern des SOURCE_CODE übereinstimmt“.

docs_chunks

Verwendung

docs_chunks ist ein JSONL, das offizielle Dokumentationsbeschreibungen, Tutorials und den Text von Klassenreferenzen in Chunks speichert.

Es wird verwendet, um Code‑Erklärungsanfragen, die Überprüfung gemeinsamer API‑Nutzungen und die Bestätigung von Godot 3/4‑gemeinsamen Syntaxbeschreibungen zu unterstützen. Es dient eher als Grundlage, um zu prüfen, “ob dieser Code direkt mit einer offiziellen Dokumentationsbeschreibung verknüpft ist”, als für die Migrationsregeln selbst.

JSONL‑Format

{
  "chunk_id": "text, required",
  "doc_version": "text, required",
  "source_url": "text, required",
  "source_file": "text, required",
  "source_sha256": "text, required",
  "doc_type": "text, required",
  "symbol": "text or null",
  "section_path": "array, required",
  "heading": "text or null",
  "content": "text, required",
  "code_blocks": "array, required",
  "language_tags": "array<string>",
  "godot_version_tags": "array<string>",
  "api_symbols": "array<string>",
  "token_count": "integer or null",
  "metadata": "object"
}

Direktbeweis durch Feld

Feld	Direktbeweis‑Kriterium
`content`	Muss die API, Funktionsnamen, Knotennamen, Code‑Muster aus dem `SOURCE_CODE` beschreiben
`code_blocks`	Muss denselben Code‑String oder Aufruf‑Muster wie im `SOURCE_CODE` enthalten
`api_symbols`	Muss exakt mit den im `SOURCE_CODE` vorhandenen API/Symbolen übereinstimmen
`heading`	Sekundärer Beweis. Nur die Überschrift stimmt, aber kein Text‑/Code‑Beweis → schwach
`godot_version_tags`	Nur zur Versionsreferenz. Darauf allein darf keine `Ja`‑Entscheidung basieren

Rolle im Test

Fall	Erwartung
`SOURCE_CODE` verwendet `get_viewport_rect().size` und dieselbe Formulierung erscheint in `content` oder `code_blocks`	`Ja`
Nur ein breites Thema wird mit `SOURCE_CODE` geteilt, aber es gibt keinen tatsächlichen String/API	`Nein`
Gemeinsame Syntax von Godot 3/4 wird erklärt und der Code‑String stimmt exakt	`Ja`
Nur Versions‑Tags passen, aber es fehlt ein Code‑Beweis	`Nein`

api_mapping

Zweck

api_mapping ist eine JSONL‑Datei, die speichert, wie Namen, Klassennamen, Funktionsnamen und Symbolnamen von Godot 3 zu Godot 4 geändert wurden.

Sie wird für einfache Namensänderungen, Umbenennungen, Ersetzungen sowie die Bewertung von veralteten/entfernten APIs verwendet. Beispiele, bei denen sich die gesamte Funktionsweise ändert, gehören eher zu label_prototypes.

JSONL‑Format

{
  "mapping_id": "text, required",
  "source_api": "text, required",
  "target_api": "text or null",
  "change_type": "text, required",
  "godot_from": "text, required",
  "godot_to": "text, required",
  "confidence": "text, required",
  "evidence_chunk_ids": "array<string>",
  "match_terms": "array<string>",
  "notes": "text",
  "negative_patterns": "array<string>"
}

Direktbeweis durch Feldbetrachtung

Feld	Direktbeweis‑Kriterium
`source_api`	Muss tatsächlich im SOURCE_CODE vorkommen
`target_api`	Wird zur Verifizierung des umgewandelten Codes oder der Migrationsbeschreibung verwendet
`match_terms`	Muss exakt mit den tatsächlichen Zeichenketten/API im SOURCE_CODE übereinstimmen
`notes`	Zusatzinformationen. Wird eher zusammen mit source_api/match_terms betrachtet als ein eigenständiger Beweis
`negative_patterns`	Wenn der SOURCE_CODE diesem Muster entspricht, liefert es vielmehr einen „Nein“‑Beweis

Rolle im Test

Fall	Erwartung
Im SOURCE_CODE befindet sich `KinematicBody2D` und das JSONL‑`source_api` ist ebenfalls `KinematicBody2D`	`Ja`
Im SOURCE_CODE gibt es `yield(` und das JSONL‑`match_terms` enthält `yield(`	`Ja`
Das JSONL lautet `Camera -> Camera3D`, aber der SOURCE_CODE ist `KinematicBody2D`	`Nein`
Nur breite Begriffe wie Godot 3/4, Migration überschneiden sich	`Nein`

label_prototypes

Zweck

label_prototypes ist ein JSONL, das nicht nur einfache Namensänderungen, sondern komplette Änderungen in der Funktionsnutzung, Parameterstruktur und Aufrufmustern speichert.

Wenn api_mapping beantwortet, „Welcher Name wurde in welchen geändert?“, dann nähert sich label_prototypes der Frage, „Wie soll der Code strukturiert werden?“.

JSONL‑Format

{
  "prototype_id": "text, required",
  "label": "text, required",
  "task_type": "text, required",
  "input_pattern": "text, required",
  "expected_finding": "text, required",
  "recommended_action": "text, required",
  "evidence_mapping_ids": "array<string>",
  "evidence_chunk_ids": "array<string>",
  "severity": "text",
  "validator_rules": "object"
}

validator_rules kann die folgenden Unterfelder haben.

{
  "required_when_seen_in_code": "array<string>",
  "before_code": "text",
  "after_code": "text",
  "reject_when_seen_in_code": "array<string>"
}

Direktbegründung für Felder

Feld	Direktbegründungs‑Kriterium
`input_pattern`	Muss exakt dem Aufrufmuster im `SOURCE_CODE` entsprechen
`expected_finding`	Beschreibung, welches Problem/Muster gefunden werden soll
`recommended_action`	Richtung der Umwandlung oder Erklärung
`validator_rules.required_when_seen_in_code`	Muss tatsächlich im `SOURCE_CODE` vorkommen, um ein „Ja“‑Begründung zu sein
`validator_rules.before_code`	Wenn es exakt dasselbe vorherige Code‑Muster wie im `SOURCE_CODE` ist, liefert es eine starke „Ja“‑Begründung
`validator_rules.reject_when_seen_in_code`	Wenn das Muster im `SOURCE_CODE` vorkommt, ist das entsprechende Prototype ein „Nein“

Rolle im Test

Fall	Erwartung
Im `SOURCE_CODE` gibt es `yield(get_tree().create_timer(...), "timeout")` und `before_code` hat dasselbe Muster	`Ja`
Im `SOURCE_CODE` gibt es `move_and_slide(velocity)` und das Prototype erklärt die Änderung dieser Aufrufart	`Ja`
Der `SOURCE_CODE` ist ein `yield`, das Prototype beschreibt jedoch eine `Color8`‑Umwandlung	`Nein`
Nur das gleiche Label wird geteilt, aber das tatsächliche Muster fehlt	`Nein`

Grenzen der drei JSONL

JSONL	Kernfrage	Hauptsächlich zu prüfen
`docs_chunks`	Steht dieser Code in direktem Zusammenhang mit einer offiziellen Dokumentations‑/Tutorial‑Beschreibung?	`content`, `code_blocks`, `api_symbols`
`api_mapping`	Haben sich die im Code enthaltenen API/Symbole von Godot 3 zu 4 im Namen oder Ziel geändert?	`source_api`, `target_api`, `match_terms`
`label_prototypes`	Entspricht das Nutzungsmuster/Argument/Aufrufmuster des Codes einem vollständigen Änderungsbeispiel?	`input_pattern`, `validator_rules`, `before_code`

Gemeinsame Syntax‑Verarbeitung

Gleiche Syntax in Godot 3 und Godot 4 wird nicht als Versionsunterschied gewertet.

Situation	Zu verwendendes JSONL	Bewertungs‑Kriterium
Code, der allgemein verwendet wird, wie `_ready()`, `_process(delta)`, `print()`	Das zugehörige Code/Funktions‑JSONL 1 + ein völlig anderes Funktions‑JSONL 1	Wenn es ein direktes Beweis‑Muster im gleichen Code‑Chunk gibt, dann `Ja`; bei völlig anderem Funktions‑Chunk `Nein`
Migration‑JSONL, das nicht zu gemeinsamem Syntax‑Code passt	`api_mapping` oder `label_prototypes` – falsche Antwort	Wenn keine echte API/Pattern vorhanden ist, dann `Nein`
Godot 3‑spezifische API taucht auf	Godot 3‑exklusives JSONL + Godot 4‑exklusives JSONL	Das JSONL, das exakt zum Godot 3‑String/Pattern im `SOURCE_CODE` passt, ist `Ja`
Godot 4‑spezifische API taucht auf	Godot 4‑exklusives JSONL + Godot 3‑exklusives JSONL	Das JSONL, das exakt zum Godot 4‑String/Pattern im `SOURCE_CODE` passt, ist `Ja`