Qwen Godot Code JSONL Beweis‑Abgleich Test‑Checkliste
Erstellungsdatum: 28. Juni 2026
Zweck
Erstelle mit Qwen 50 Code‑Chunks für Godot 3 und prüfe, ob die Ja/Nein‑Entscheidung wie beim gestrigen JSONL‑Beweis‑Abgleich‑Test korrekt getroffen wird.
Dieser Test soll nicht prüfen, ob das Modell Godot‑Wissen besitzt. Es geht darum, zu beurteilen, ob im JSONL ein tatsächlicher Beweis‑String/API/Pattern vorhanden ist, das exakt zum jeweiligen Code‑Chunk passt, wenn SOURCE_CODE und JSONL zusammengeführt werden.
Mit anderen Worten: Relevante JSONL‑Einträge müssen mit Ja beantwortet werden, nicht‑relevante mit Nein verworfen werden.
Testverfahren
Für jeden Code‑Chunk werden mindestens zwei Arten von JSONL angehängt. Da es in Godot 3 und Godot 4 identische Syntax geben kann, werden nicht alle Funktionen ausschließlich als Godot 3‑Spezifikationen behandelt.
| JSONL‑Typ | Erwartete Antwort | Bedeutung |
|---|---|---|
| Korrektes JSONL | Ja |
Mindestens einer der Einträge source_api, source_pattern, match_terms, required_when_seen_in_code oder before_code stimmt exakt mit dem Code‑Chunk überein |
| Inkorrektes JSONL | Nein |
Das JSONL enthält Belege, die nur andere APIs, andere Nodes, andere Systeme oder nur sehr allgemeine Begriffe teilen |
Jeder Test wird als folgende Eingabe‑Gruppe betrachtet.
JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunkDie eigentliche Validierungsanfrage besteht darin, zu prüfen, ob Qwen nur ja oder nein zurückgibt, wenn JSONL + Prompt + Chunk zusammen übergeben werden.
Bei gemeinsamen Syntaxen wird ein einzelner Code‑Chunk als Basis für den Test verwendet. In diesem Fall ist das korrekte JSONL eine JSONL‑Datei, die eine Beschreibung oder ein Muster für den jeweiligen Code/die jeweilige Funktion enthält, während das falsche JSONL eine Beschreibung einer völlig anderen Funktion oder eines anderen Systems enthält. Fälle, bei denen die erwartete Antwort ja ist, und Fälle, bei denen sie nein ist, unterscheiden sich nicht durch unterschiedliche Codes, sondern dadurch, ob im JSONL direkte Belege vorhanden sind oder nicht.
Wiederholungs‑Erzeugungs‑Schleife
Das Gesamtziel ist ein Test aller 50 Funktionen. Heute werden jedoch nur die ersten 5 manuell überprüft, und anschließend wird das Ergebnis aus den kumulierten Daten verwendet, um zunächst das Antwortmuster ja/nein zu analysieren.
Heutiges Ziel: 5 Stück
Gesamtziel: 50/50Nachdem fünf ausgefüllt wurden, erhöht man die Anzahl neuer Einträge nicht gewaltsam, sondern betrachtet zunächst die gemeinsamen Syntaxen/Versionsunterschiede sowie das Auftreten von False Positives und False Negatives je Tabelle.
Der Test erzeugt Daten, indem er den untenstehenden Ablauf wiederholt.
1. Gib Qwen eine Godot‑Funktion zum Testen.
2. Zeige zuerst an, ob die Funktion gemeinsame Syntax von Godot 3/4, spezifische Syntax von Godot 3 oder spezifische Syntax von Godot 4 ist.
3. Wenn es gemeinsame Syntax ist, erstelle einen einzigen Code‑Chunk.
4. Wenn es gemeinsame Syntax ist, erstelle ein korrektes JSONL für den betreffenden Code/Funktion und ein falsches JSONL für eine völlig andere Funktion.
5. Wenn es keine gemeinsame Syntax ist, erstelle separate JSONL für Godot 4 und Godot 3 und teste sie.
6. Alle JSONL werden gemäß den Zieltabellenspalten erstellt.
7. Füge das JSONL + SOURCE_CODE‑Chunk in die Validierungsaufforderung ein und prüfe „Ja“/„Nein“.
8. Protokolliere, ob die erwartete Antwort mit der tatsächlichen Antwort übereinstimmt.Der Kernpunkt ist nicht die Qualität der Codegenerierung, sondern ob die JSONL‑Beweiszuordnung zuverlässig funktioniert. Deshalb muss das korrekte JSONL mit „ja“ beantwortet werden, das falsche JSONL mit „nein“.
Gemeinsame Syntax – Hinweis
Syntax, die in Godot 3 und Godot 4 unverändert bleibt, darf nicht als Versions‑Testfall betrachtet werden. Zum Beispiel können _ready(), _process(delta), Standard‑Variablenzuweisungen und print() in beiden Versionen vorkommen.
In solchen Fällen wird wie folgt verfahren:
| Code‑Charakteristik | Test‑Methode | Erwartung |
|---|---|---|
| Godot 3/4 gemeinsame Syntax | Ein einziger Code‑Chunk testet das zugehörige Funktions‑JSONL und ein völlig anderes Funktions‑JSONL | Nur anhand der direkten JSONL‑Begründung muss zwischen „ja“ und „nein“ unterschieden werden |
| Godot 3‑spezifische Syntax | Der Godot 3‑Chunk wird verwendet, um das Godot 3‑exklusive JSONL mit dem Godot 4‑exklusiven JSONL zu vergleichen | Wenn die tatsächliche Godot 3‑Zeichenkette/Pattern im JSONL vorkommt, „ja“ |
| Godot 4‑spezifische Syntax | Der Godot 4‑Chunk wird verwendet, um das Godot 4‑exklusive JSONL mit dem Godot 3‑exklusive JSONL zu vergleichen | Wenn die tatsächliche Godot 4‑Zeichenkette/Pattern im JSONL vorkommt, „ja“ |
| Versionsunabhängige Funktionsbeschreibung | Der Code muss in den JSONL‑content/code_blocks direkt begründet sein, egal welche Version |
Nur bei breiter semantischer Ähnlichkeit „nein“ |
Daher muss in der Aufzeichnungstabelle vermerkt werden, ob es sich um gemeinsame Syntax handelt. So kann später unterschieden werden, ob ein gemeinsamer Syntax‑Eintrag fälschlicherweise als Migrations‑Begründung verwendet wurde oder ob versionsspezifische Syntax fälschlicherweise als gemeinsam behandelt wurde.
Neudefinition der Kriterien – Notizen
Beim Testen von Punkt 4 und 5 zeigte sich, dass eine endgültige Bewertung schwierig ist. Insbesondere hängt die Antwort für denselben Code‑Chunk davon ab, ob das JSONL nach Godot 3‑ oder Godot 4‑Standards erstellt wurde – diese Differenz wurde selbst zum Analyse‑Objekt.
Daher wird vorerst nicht zwischen „gut“ und „schlecht“ unterschieden, sondern die Rohantworten wie folgt festgehalten:
| Kategorie | JSONL‑Erstellungs‑Basis | Prüfcodes | Erwarteter aktueller Verlauf |
|---|---|---|---|
| Gemeinsame Syntax | Godot 3‑Basis | Gemeinsamer Code oder gleichwertiger Godot 3/4‑Code | ja, nein, ja, nein, ja, nein |
| Gemeinsame Syntax | Godot 4‑Basis | Gemeinsamer Code oder gleichwertiger Godot 3/4‑Code | ja, nein, ja, nein, ja, nein |
| Versionsunterschied | Godot 3‑Basis | Godot 3‑Code | ja, nein, ja, nein, ja, nein |
| Versionsunterschied | Godot 3‑Basis | Godot 4‑Code | Meist nein. Nur wenn api_mapping oder prototype explizit eine Godot 3 → 4‑Umwandlung begründen, können einzelne ja‑Antworten auftreten – diese werden separat betrachtet |
| Versionsunterschied | Godot 4‑Basis | Godot 3‑Code | Meist nein. Nur wenn das JSONL gleichzeitig Quell‑ und Ziel‑Zeichenketten enthält, können einzelne ja‑Antworten auftreten – diese werden separat betrachtet |
| Versionsunterschied | Godot 4‑Basis | Godot 4‑Code | ja, nein, ja, nein, ja, nein |
Die Reihenfolge der Antworten wird grundsätzlich nach docs_chunks‑bezogen, docs_chunks‑unbezogen, api_mapping‑bezogen, api_mapping‑unbezogen, label_prototypes‑bezogen, label_prototypes‑unbezogen bewertet.
Punkt 4 wurde zuvor wie die anderen Einträge dokumentiert, aber weil bei Godot 3‑Tests ein Muster von nein, nein, ja, nein, ja, nein auftrat, wird er aus der endgültigen Bewertung ausgeschlossen. Dieses Dokument dient künftig als Beobachtungs‑Protokoll, das eher fragt: „Unter welchen Kriterien schwanken welche Antworten?“ statt „Wie viele waren korrekt?“.
Beispiel für eine Erstellungs‑Anfrage
Unten steht ein Beispiel für die Anfrage, wenn die erste Funktion _ready() – Initialisierung und Viewport‑Größeneinstellung – getestet wird.
Die JSONL‑Formate und die jeweiligen Verwendungszwecke sind in einem separaten Dokument beschrieben.
Bitte gib einen Godot3-Chunk und einen Godot4-Chunk, die die Initialisierung der _ready()-Funktion und die Einstellung der Viewport-Größe enthalten.
Zeige zuerst an, ob diese Funktion in Godot3 und Godot4 gemeinsame Syntax ist.
Falls es gemeinsame Syntax ist, gib an, dass derselbe Code für Tests verwendet werden kann.
Und stelle ein korrektes JSONL im docs_chunks-Format sowie ein falsches JSONL bereit.Dieses Beispiel bezieht sich auf docs_chunks. Für api_mapping und label_prototypes erstellt man auf dieselbe Weise korrekte JSONL‑ und fehlerhafte JSONL‑Dateien, die dem jeweiligen JSONL‑Format und Verwendungszweck entsprechen, und prüft mit demselben Validierungs‑Prompt „Ja“/„Nein“.
Die Validierungseingabe sieht dann wie folgt aus.
JSONL:
<Antwort oder falsche JSONL Zeile>
PROMPT:
<Direkter Beweis‑Validator‑Prompt>
SOURCE_CODE:
<Godot‑3‑Code‑Chunk, Godot‑4‑Code‑Chunk oder gemeinsamer‑Syntax‑Code‑Chunk>Der Prompt wird, wie unten gezeigt, gesendet, um das direkte Erklärungskriterium oder die Transformationsgrundlage zwischen SOURCE_CODE und JSONL zu beurteilen.
Du bist ein JSONL‑Beweis‑Matching‑Entscheider.
Beurteile, ob das untenstehende JSONL direkte Erklärungs‑ oder Transformationsbegründung für den untenstehenden **SOURCE_CODE** enthält.
**Beurteilungskriterien:**
- Es ist nur „Ja“, wenn einer der JSONL‑Schemas exakt mit einem tatsächlichen String oder API‑Aufruf im **SOURCE_CODE** übereinstimmt.
- Wenn nur allgemeine Begriffe wie *Godot*, *Godot3*, *Godot4*, *migration*, *2D*, *physics* übereinstimmen, ist das nicht relevant.
- Wenn das JSONL Inhalte zu anderen APIs, anderen Nodes oder anderen Systemen enthält, ist es „Nein“.
- Verwende dein Wissen über Godot nicht, sondern nutze ausschließlich die im JSONL angegebenen String‑Begründungen.
- Die Antwort muss ausschließlich „Ja“ oder „Nein“ enthalten.Bewertungs-Matrix
| Erwartete Antwort | Tatsächliche Antwort | Vorläufige Interpretation | Zu protokollierender Inhalt |
|---|---|---|---|
Ja |
Ja |
Entspricht den Erwartungen | Korrektes JSONL wird direkt als Beweis anerkannt |
Nein |
Nein |
Entspricht den Erwartungen | Fehlerhaftes JSONL wird verworfen |
Ja |
Nein |
Überprüfung erforderlich | Es gibt einen direkten Beweis, aber er wurde übersehen. Kandidat für falsche Negative |
Nein |
Ja |
Überprüfung erforderlich | Es gibt keinen direkten Beweis, aber es wurde anerkannt. Kandidat für falsche Positive |
Ja oder Nein |
Andere Antwort | Überprüfung erforderlich | Verstöße gegen das Antwortformat, z. B. Erklärung, JSON, leere Antwort, mehrdeutige Antwort |
Beobachtungs-Checkliste
Nach Abschluss von 50 Stichproben‑Tests pro Tabelle die folgenden Punkte prüfen.
| Check | Kriterium | Ergebnis |
|---|---|---|
| Antwortformat | Jede Antwort gibt nur Ja oder Nein aus |
|
| Relevante JSONL‑Antwort | Bei relevanten JSONL‑Tests erscheint die Ja‑Antwort stabil |
|
| Irrelevante JSONL‑Antwort | Bei irrelevanten JSONL‑Tests erscheint die Nein‑Antwort stabil |
|
| Aufzeichnung falscher Positive | Fälle, in denen Nein korrekt war, aber Ja ausgegeben wurde, werden separat protokolliert |
|
| Aufzeichnung falscher Negative | Fälle, in denen Ja korrekt war, aber Nein ausgegeben wurde, werden separat protokolliert |
|
| Breiter Wortfilter | Wörter wie Godot, migration, 2D, physics allein führen nicht zu Ja |
|
| Direkter String‑Beweis | Bei Ja‑Entscheidungen gibt es ein passendes JSONL‑Feld zu tatsächlichen Code‑Strings/API/Pattern |
|
| Gemeinsame Syntax‑Unterscheidung | Für Godot 3/4‑gemeinsame Syntax‑Beispiele wurden erwartete Ja/Nein‑JSONLs anhand desselben Code‑Chunks getestet |
|
| Unterschied pro Tabelle | Unterschiede zwischen docs_chunks, api_mapping, label_prototypes werden dokumentiert |
|
| Reproduzierbarkeit | Wiederholte Eingaben führen nicht zu stark schwankenden Entscheidungen | |
| Nächste Bewertung | Entscheiden, ob dieser Prompt und das Bewertungsverfahren an das nächste PoC weitergegeben werden können |
Testprotokoll‑Vorlage
Kopiere die folgende Tabelle und fülle die Testergebnisse ein.
| ID | Funktion | Gemeinsame Syntax? | Tabelle | JSONL‑Typ | Erwartete Antwort | Tatsächliche Antwort | Bewertung | Direkt übereinstimmendes Feld | Notizen |
|---|---|---|---|---|---|---|---|---|---|
| G03-001-A | _ready()‑Funktion initialisieren und Viewport‑Größe setzen |
Korrektes JSONL | Ja |
||||||
| G03-001-B | _ready()‑Funktion initialisieren und Viewport‑Größe setzen |
Fehlerhaftes JSONL | Nein |
Aufzeichnungen pro Tabelle
docs_chunks
Prüfe, ob die erklärende Dokumentationsbegründung direkt mit dem Code‑Chunk übereinstimmt.
| Nummer | Funktion | Gemeinsame Syntax | Zugehöriges JSONL Ergebnis | Unabhängiges JSONL Ergebnis | Hinweis |
|---|---|---|---|---|---|
| 1 | _ready() Funktionsinitialisierung und Viewport‑Größeneinstellung |
Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
Node._ready, get_viewport().get_visible_rect().size, DisplayServer.window_set_size sind in den docs_chunks‑Erklärungen mit Ja belegt; _process(delta)‑Erklärung im JSONL wird mit Nein bewertet |
| 2 | _process(delta) Frame‑weise Update‑Schleife |
Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
_process(delta), position.x +=, speed * delta sind in den docs_chunks‑Erklärungen mit Ja belegt; Vector2.lerp‑Erklärung im JSONL wird mit Nein bewertet |
| 3 | Spieler‑Bewegungseingabe verarbeiten (WASD oder Pfeiltasten) | Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
Input.is_action_pressed, Vector2.ZERO, direction.normalized(), velocity, move_and_slide() sind in den docs_chunks‑Erklärungen mit Ja belegt; TileMapLayer.set_cell()‑Erklärung im JSONL wird mit Nein bewertet |
| 4 | Anwendung von Spieler‑Bewegungsgeschwindigkeit und Beschleunigung | Versionsunterschied | Vorherige beidseitige Ja‑Einträge werden im endgültigen Urteil ausgeschlossen |
In Godot‑3‑Prüfung erschien auf der Docs‑Seite Nein/Nein, daher erneute Prüfung nötig |
Aufgrund roher Antworten Nein, Nein, Ja, Nein, Ja, Nein ist eine Neudefinition der Kriterien erforderlich |
| 5 | Begrenzung der maximalen Spieler‑Geschwindigkeit | Versionsunterschied | Erste Beobachtung nach Godot 3. Umgekehrte Rohantwort für Godot 4: Code‑Beispiel Ja/Ja, Godot 3‑Code Ja/Ja |
In der umgekehrten Godot 4‑Betrachtung wurden alle Docs‑Kandidaten mit Ja markiert |
CharacterBody2D, max_speed, velocity = input_vector * max_speed, move_and_slide(), Input.is_action_pressed überschneiden sich direkt als Zeichenketten. Es muss geprüft werden, ob der Funktionsumfang eingeschränkt werden muss; Musteranalyse erforderlich |
| 6 | Projektil bei Mausklick erzeugen und abschießen | Versionsunterschied | Godot 3/4‑Erklärungen passen jeweils zum Code und wurden in den 24/24‑Durchläufen vollständig akzeptiert |
Andere Code‑Erklärungen wurden wie erwartet verworfen | Unterschiedliche Behandlung von PackedScene.instance() und instantiate() sowie Maus‑Eingaben führt zu einer Trennung der Docs‑Kandidaten je nach Code‑Basis |
| 7 | Verwaltung von Projektilbewegung und Lebensdauer (time‑to‑live) | Versionsunterschied | Docs_chunks‑Erklärungen stimmen mit dem Projektil‑Bewegungs/TTL‑Code überein | Unrelevante Docs‑Erklärungen wurden wie erwartet verworfen | Von den 22/24 Fällen weicht nur die Zuordnung in api_mapping/label_prototypes ab, wo Godot‑3‑Begründungen fälschlicherweise auch bei Godot 4 mit Ja markiert wurden |
| 8 | KI‑Logik für das Verfolgen des Spielers durch den Feind (Enemy) | Versionsunterschied | Godot 4‑Docs‑Kandidat wird fälschlicherweise auch bei Godot 3‑Code mit Ja markiert – false positive beobachtet |
Andere Code‑Kandidaten zeigen ebenfalls Ja bei beiden Versionen, daher erneute Prüfung nötig |
Gesamt 21/24; Docs_chunks haben das gleiche Verfolgungs‑/Bewegungsthema oder ähnliche API‑Hinweise breit als Beleg herangezogen |
| 9 | Bewegungs‑ und Drehlogik des Feindes | Versionsunterschied | Bewegungs‑ und Drehungs‑Docs‑Begründungen passen jeweils zum Code | Unrelevante Docs‑Kandidaten wurden wie erwartet verworfen | 24/24 bestanden. Ziel und Endverhalten von Bewegung/Drehung sind klar, sodass die Docs‑Kandidaten stabil differenziert werden |
| 10 | Spieler verschwindet, wenn er den Bildschirm verlässt | Gemeinsame Syntax | Verlassen des Bildschirms, global_position, get_viewport_rect().size, hide()‑Erklärung wird mit Ja belegt |
Andere Code‑Erklärungen werden mit Nein belegt |
Gemeinsame Syntax 6/6 bestanden. Docs‑Begründungen und Migrations‑Kandidaten sind gut getrennt |
| 11 | Kollisionsdetektion (Area2D oder PhysicsBody) | Versionsunterschied | Kollisions‑Events, Zielobjekte, Callback‑/Physik‑Body‑Beziehungen werden mit Docs‑Kandidaten gegenüber Code‑Chunks abgeglichen | Unterscheidung von Kandidaten, die nach der Kollision Schaden oder Lebenspunkte behandeln | In sample-11 wird geprüft, dass die Begründung für das „Erkennen“ einer Kollision nicht mit der nachfolgenden „Verarbeitung“ vermischt wird |
| 12 | Schaden berechnen und anwenden bei Kollision | Gemeinsame Syntax | Schadensermittlung aus Kollisions‑Ergebnis und Anwendung auf Ziel‑Lebenspunkte wird mit Docs‑Begründungen abgeglichen | Kandidaten, die nur Kollisionserkennung, Punktestand‑Update oder Game‑Over beschreiben, werden getrennt | sample-12 prüft, ob die Schadensformel/Anwendung das Kernstück der Docs‑Begründung ist, nicht nur die Kollision selbst |
| 13 | Logik zum Reduzieren der Spieler‑Lebenspunkte | Gemeinsame Syntax | Reduktion der Spieler‑Health‑Variable, Treffer‑Verarbeitung, Untergrenzen‑Handling wird mit Docs‑Begründungen abgeglichen | Kandidaten, die Feind‑Health‑Reduktion oder Punktestand‑Erhöhung beschreiben, werden getrennt | sample-13 muss unterscheiden, ob das Wort health sich auf den Spieler oder den Feind bezieht |
| 14 | Game‑Over, wenn Spieler‑Health 0 erreicht | Gemeinsame Syntax | health <= 0, Wechsel in Game‑Over‑Zustand, Szenen‑Wechsel/Stop‑Ablauf wird mit Docs‑Begründungen abgeglichen |
Kandidaten, die nur Health‑Reduktion oder Feind‑Entfernung beschreiben, werden getrennt | sample-14 prüft, ob nach Erreichen von 0 der resultierende Zustand mit den Docs‑Begründungen übereinstimmt |
| 15 | Logik zum Reduzieren der Feind‑Lebenspunkte | Gemeinsame Syntax | Reduktion der Feind‑Health‑Variable und Treffer‑Verarbeitung wird mit Docs‑Begründungen abgeglichen | Kandidaten, die Spieler‑Health‑Reduktion oder Game‑Over beschreiben, werden getrennt | sample-15 muss klarstellen, ob das Objekt ein Enemy oder ein Player ist – entscheidend für die Begründungsbewertung |
| 16 | Entfernen des Feindes bei 0 Health und Punkte hinzufügen | Gemeinsame Syntax | Entfernen des Feindes (queue_free()/Deaktivierung) und Punkte‑Erhöhung werden mit Docs‑Begründungen abgeglichen |
Kandidaten, die nur Health‑Reduktion oder Punkte‑Anzeige behandeln, werden getrennt | sample-16 prüft, ob sowohl das Entfernen als auch das Hinzufügen von Punkten als ein zusammengehöriger End‑Ablauf beschrieben wird |
| 17 | Aktualisierung der Punkte‑Variable (Score) | Gemeinsame Syntax | Erhöhung/Reduktion der Score‑Variable, kumulative Aktualisierung wird mit Docs‑Begründungen abgeglichen | Kandidaten, die nur UI‑Label‑Update oder Rendering beschreiben, werden getrennt | sample-17 unterscheidet zwischen Daten‑Update und Anzeige‑Update |
| 18 | Funktion zum Aktualisieren des Score‑Textes (Label) | Gemeinsame Syntax | Label.text/String‑Formatierung zur Anzeige des Scores wird mit Docs‑Begründungen abgeglichen |
Kandidaten, die nur die Score‑Variable ändern, werden getrennt | sample-18 prüft, ob die UI‑Text‑Reflexion das eigentliche Begründungs‑Kriterium ist |
| 19 | Hintergrundmusik (BGM) abspielen und Lautstärke steuern | Gemeinsame Syntax | BGM‑Node, Bus‑Lautstärke, Loop‑/Volume‑Einstellungen werden mit Docs‑Begründungen abgeglichen | Kandidaten, die nur einmalige Sound‑Effekte beschreiben, werden getrennt | sample-19 unterscheidet zwischen dauerhaftem BGM und kurzen SFX‑Aufrufen |
| 20 | Funktion zum Abspielen von Sound‑Effekten (SFX) | Gemeinsame Syntax | Erstellung/Auslösung eines Audio‑Players für einmalige Wiedergabe wird mit Docs‑Begründungen abgeglichen | Kandidaten, die BGM‑Loop‑/Volume‑Steuerung beschreiben, werden getrennt | sample-20 stellt sicher, dass allgemeine Audio‑Begriffe nicht fälschlicherweise BGM‑Begründungen zugeordnet werden |
| 21 | Bildschirmvibration (Screen Shake) Effekt implementieren | Versionsunterschied | Kamera-Offset, Vibrationsstärke/-dauer, Tween oder zufälliger Offset – Erklärung anhand von Code‑Chunks im Vergleich | Gegnerbewegung, Kameraverfolgung, UI‑Animationskandidaten unterscheiden | sample-21 prüft, ob trotz des gleichen Wortes „Kamera“ die Bildschirmvibration direkt erklärt wird |
| 22 | Partikelsystem erzeugen und Position abgleichen | Versionsunterschied | Partikel‑Node erzeugen, Position synchronisieren, Emission starten – Erklärung anhand von Code‑Chunks im Vergleich | Normale Node‑Erzeugung, Projektil‑Erzeugung, Animationskandidaten unterscheiden | sample-22 prüft, ob das Ziel ein Particle ist und ob Positionsabgleich sowie Emissionsablauf enthalten sind |
| 23 | Szenenwechsel (Scene Change) Funktion | Versionsunterschied | Szenenwechsel‑Anfrage, SceneTree‑Aufruf, Ziel‑Szenen‑Pfad – Erklärung anhand von Code‑Chunks im Vergleich | Menü‑Anzeige, Pause, Ressourcen‑Laden – Kandidaten, die keinen eigentlichen Szenenwechsel darstellen, unterscheiden | sample-23 unterscheidet, ob tatsächlich ein Aufruf zum Wechseln von Bildschirm/Szene erfolgt oder nur ein einfacher Ladevorgang bzw. UI‑Anzeige erklärt wird |
| 24 | Hauptmenü‑Szene laden und anzeigen | Versionsunterschied | Hauptmenü‑Szene laden und auf dem Bildschirm darstellen – Erklärung anhand von Code‑Chunks im Vergleich | Einfacher Szenenwechsel, Pause, Ressourcen‑Preload‑Kandidaten unterscheiden | sample-24 prüft, ob der Ablauf tatsächlich das Menü‑Scene anzeigt oder nur andere Szenen‑Verarbeitungen beschreibt |
| 25 | Spiel‑Pause (Pause) Funktion umschalten | Gemeinsame Syntax | Pause‑Zustand umschalten, get_tree().paused, Erklärung anhand von Code‑Chunks im Vergleich, die Pause/Weiter bei Eingabe beschreiben | Menü öffnen, Szenenwechsel, Game‑Over‑Kandidaten unterscheiden | sample-25 prüft, ob der Pause‑Zustand selbst geändert wird oder nur eine UI‑Anzeige erfolgt |
| 26 | Tastatureingabe‑Status prüfen (Input.is_key_pressed) | Versionsunterschied | Input.is_key_pressed und Tastenkonstanten/Key‑Codes erklären – Code‑Chunk‑Vergleich | Action‑Map‑Eingaben, Maus‑Eingaben, Bewegungs‑Logik‑Kandidaten unterscheiden | sample-26 trennt die reine Abfrage des Tastatur‑Status von der gesamten Bewegungs‑Logik |
| 27 | Maus‑Position (Cursor) Koordinaten holen | Gemeinsame Syntax | Viewport‑/global‑Mouse‑Position abfragen – Erklärung anhand von Code‑Chunks im Vergleich | Maus‑Klick‑Schießen, Touch‑Eingaben, Cursor‑Anzeige‑Kandidaten unterscheiden | sample-27 prüft, ob es sich um Code handelt, der nur die Koordinaten liest und nicht um ein Klick‑Event |
| 28 | Zufallszahl‑Erzeugungsfunktion | Versionsunterschied | RNG‑Initialisierung, Zufallszahl erzeugen, Wertebereich festlegen – Code‑Chunk‑Vergleich | Zufällige Positionsverteilung, Gegner‑Spawn‑Timer‑Kandidaten unterscheiden | sample-28 trennt die reine Zahlen‑Erzeugungsfunktion von der Gameplay‑Logik, die die Zahl verwendet |
| 29 | Gegner in bestimmten Intervallen spawnen | Versionsunterschied | Timer/Timeout/aufgesummte Zeit nutzen, um Gegner periodisch zu erzeugen – Code‑Chunk‑Vergleich | Zufällige Positionsberechnung oder Gegner‑AI‑Bewegung unterscheiden | sample-29 prüft, ob das Zeitintervall und der Spawn‑Aufruf direkt belegt sind |
| 30 | Position der gespawnten Gegner zufällig verteilen | Gemeinsame Syntax | Zufälliger Koordinaten‑Bereich, Spawn‑Area, Positionsverteilung – Code‑Chunk‑Vergleich | Timer‑Kandidaten, die Gegner zu bestimmten Zeiten spawnen, unterscheiden | sample-30 erklärt, dass es nicht um den Zeitpunkt des Erstellens, sondern um die Platzierung geht |
| 31 | Spieler‑Animationszustände wechseln (Idle, Run, Jump) | Versionsunterschied | Eingabe/Geschwindigkeit/Zustand nutzen, um Animationsnamen zu ändern – Code‑Chunk‑Vergleich | Animations‑Abspielgeschwindigkeit oder Zeitsteuerung unterscheiden | sample-31 trennt Zustandswechsel von der Steuerung der Abspielzeit |
| 32 | Animations‑Abspielzeit steuern | Gemeinsame Syntax | animation speed, seek, advance, playback‑Position steuern – Code‑Chunk‑Vergleich | Idle/Run/Jump‑Zustandswechsel‑Kandidaten unterscheiden | sample-32 prüft, ob es um die Auswahl einer Animation geht oder um die Kontrolle von Zeit/Geschwindigkeit |
| 33 | Kollisionsbereich‑Größe anpassen | Versionsunterschied | CollisionShape2D/Shape2D‑Größe, RectangleShape2D‑size/extents – Code‑Chunk‑Vergleich | Kollisions‑Erkennung, Schaden‑Verarbeitung, Area2D‑Signal‑Kandidaten unterscheiden | sample-33 prüft, ob der Code die Form/Größe des Kollisionsbereichs ändert und nicht nur das Auftreten einer Kollision |
| 34 | Physikalische Schwerkraft (Gravity) anwenden | Versionsunterschied | velocity mit gravity und delta akkumulieren und über move‑Funktion anwenden – Code‑Chunk‑Vergleich | Sprungkraft, Bodenerkennung, Area‑Gravity‑Einstellungen unterscheiden | sample-34 trennt den Ablauf der Gravitäts‑Akkumulation von Sprung‑/Bodenerkennungs‑Logik |
| 35 | Sprung‑Kraft anwenden und Bodenkontakt erkennen | Versionsunterschied | is_on_floor(), Sprung‑Velocity, Eingabebedingungen, Bodenzustand – Code‑Chunk‑Vergleich | Nur Gravitation oder Animations‑Zustandswechsel‑Kandidaten unterscheiden | sample-35 prüft, ob Sprung‑Eingabe und Bodenerkennung im selben Bewegungs‑Ablauf erklärt werden |
| 36 | Bei Wandkollision rutschen (Slide) verarbeiten | | | | |
| 37 | Spieler‑Richtung umschalten (Facing Left/Right) | | | | |
| 38 | Munitions‑Zähler verringern | | | | |
| 39 | Bei leerem Magazin Nachladen (Reload) Zustand wechseln | | | | |
| 40 | UI‑Button‑Klick‑Ereignis verbinden | | | | |
| 41 | Einstellungen‑Menü öffnen/schließen umschalten | | | | |
| 42 | Text bei Sprach‑Änderung aktualisieren | | | | |
| 43 | Spielstand‑Daten (Save Game) JSON serialisieren | | | | |
| 44 | Spielstand‑Daten (Load Game) JSON deserialisieren | | | | |
| 45 | Datei‑Lese/Schreib‑Fehler behandeln | | | | |
| 46 | Netzwerk‑Verbindungs‑Status prüfen | | | | |
| 47 | Synchronisation über Remote‑Funktion (RPC) Aufruf | | | | |
| 48 | Szenen‑Ressourcen dynamisch laden | | | | |
| 49 | Speicher freigeben und Ressourcen entladen | | | | |
| 50 | Debug‑Log ausgeben (print oder print_debug) | | | | |
api_mapping
Überprüfen, ob die Begründung dafür, wie sich Namen, Klassen, Funktionen und Symbole von Godot 3 zu Godot 4 ändern, direkt mit dem Code‑Chunk übereinstimmt.
| Nummer | Funktion | Gemeinsame Syntax | Zugehöriges JSONL‑Ergebnis | Unabhängiges JSONL‑Ergebnis | Hinweis |
|---|---|---|---|---|---|
| 1 | _ready()‑Funktion initialisieren und Viewport‑Größe festlegen |
Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
Mapping mit DisplayServer.window_set_size, Vector2i ist Ja; Mapping mit AudioServer.get_bus_volume_db wird als Nein bewertet |
| 2 | _process(delta)‑Update‑Schleife pro Frame |
Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
Stabil‑Mapping mit position.x, delta, _process ist Ja; Mapping mit get_node("Sprite2D") wird als Nein bewertet |
| 3 | Eingabe für Spielerbewegung verarbeiten (WASD oder Pfeiltasten) | Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
Mapping mit CharacterBody2D.move_and_slide, velocity, Vector2 ist Ja; Mapping mit Node.connect/Signal‑Connect wird als Nein bewertet |
| 4 | Geschwindigkeit und Beschleunigung des Spielers anwenden | Versionsunterschied | Vorherige beidseitige Ja‑Einträge werden bei endgültiger Bewertung ausgeschlossen |
In Godot‑3‑Prüfung wird die Seite api_mapping zu Ja/Nein gespalten |
Mapping von move_and_slide, CharacterBody3D, move_toward, velocity.x, velocity.z, target_velocity muss je nach Code‑Version neu bewertet werden |
| 5 | Maximale Geschwindigkeit des Spielers begrenzen | Versionsunterschied | Erste Beobachtung nach Godot 3‑Standard. Rückwärts‑Rohantwort nach Godot 4: Godot 4‑Code Ja/Ja, Godot 3‑Code Nein/Nein |
Im Godot 4‑Code sind beide Mapping‑Kandidaten Ja, im Godot 3‑Code sind beide Nein |
Unterschiedliche Rückgabe von move_and_slide, velocity, limit_speed und Kollisions‑Normalen; Musteranalyse nötig, um erwartete Werte für Godot 4‑ vs. Godot 3‑Syntax zu trennen |
| 6 | Projektil bei Mausklick erzeugen und abschießen | Versionsunterschied | Unterschiedliche API‑Implementierungen für Projektil‑Erzeugung in Godot 3/4 und Eingabeverarbeitung werden wie erwartet gematcht | Unabhängige Mapping‑Kandidaten werden verworfen | Wie bei PackedScene.instance() vs. instantiate() wird Quelle/Ziel getrennt und in den 24/24‑Durchlauf aufgenommen |
| 7 | Bewegung und Lebensdauer (time‑to‑live) des Projektils verwalten | Versionsunterschied | In Godot 3 wird das Transformations‑Mapping als Ja erfasst |
Dasselbe Mapping wird in Godot 4 ebenfalls als Ja markiert – Inkonsistenz beobachtet |
Gesamt 22/24; wenn es sich bereits um Godot 4‑Code handelt, ist keine Transformation nötig, daher muss im Validierungs‑Prompt klarer geprüft werden, ob die Quelle‑Seite relevant ist |
| 8 | KI‑Logik des Gegners (Enemy) zur Verfolgung des Spielers | Versionsunterschied | Die Diskrepanz bei Eintrag 8 stammt nicht von api_mapping |
Unabhängige Mapping‑Kandidaten werden wie erwartet verworfen | Gesamte Inkonsistenz entsteht in docs_chunks; das Mapping dient als Hilfs‑Achse, um Versions‑Änderungen der Verfolgungs‑KI‑APIs zu prüfen |
| 9 | Bewegungs‑ und Rotationslogik des Gegners | Versionsunterschied | Rotations‑/Bewegungs‑Mapping stimmt mit dem Code‑Standard überein | Unabhängige Mapping‑Kandidaten werden ebenfalls verworfen | 24/24 bestanden. Unterschiede bei Geschwindigkeits‑ und Rotations‑APIs sind relativ gut getrennt |
| 10 | Verschwinden, wenn der Spieler den Bildschirm verlässt | Gemeinsame Syntax | Da es gemeinsamer Code ist, scheint keine Umwandlung von JSONL im Zusammenhang mit api_mapping nötig zu sein | Unrelevante Umwandlungskandidaten führen ebenfalls zu Nein | 6/6 bestanden. In der gemeinsamen Syntax wurde bestätigt, dass die Migrationstabelle nicht zwingend angehängt werden muss |
| 11 | Kollisionsdetektion (Area2D oder PhysicsBody) | Versionsunterschied | Überprüfen, ob Änderungen der Area2D/PhysicsBody-Kollisions-API oder Signalverbindungen im aktuellen Code ein erforderliches Mapping darstellen | Unterscheidung vom Mapping für Schadensanwendung oder Gesundheitsverwaltung | sample-11 ist ein Bewertungspunkt, der das Mapping trennt zwischen der Detektions-API selbst und der nachfolgenden Verarbeitungslogik |
| 12 | Schadensberechnung und -anwendung bei Kollision | Gemeinsame Syntax | Prüfen, ob versionsspezifische API-Änderungen im Schadensanwendungsmodus im tatsächlichen Code vorhanden sind | Unterscheidung vom Mapping, das nur das Kollisionssignal beschreibt | sample-12 unterscheidet, ob eine Änderung ein Mapping erfordert oder lediglich eine einfache Spiel-Logikbeschreibung ist |
| 13 | Logik zur Verringerung der Spieler‑Gesundheit | Gemeinsame Syntax | Überprüfen, ob für den Code zur Verringerung der Spieler‑Gesundheit versionsspezifische API-Änderungen tatsächlich erforderlich sind | Unterscheidung von Mapping‑Kandidaten für Gegner‑Gesundheit, Punkte und Game‑Over | sample-13 beobachtet, ob aufgrund des stark spiel‑logik‑bezogenen Charakters Migration‑Begründungen übermäßig angehängt werden |
| 14 | Game‑Over‑Verarbeitung, wenn die Spieler‑Gesundheit 0 erreicht | Gemeinsame Syntax | Prüfen, ob Szenenwechsel, Pause und Änderungen der Baum‑API im Game‑Over‑Code direkt vorhanden sind | Unterscheidung von einfachen Gesundheit‑Verringerungs‑Mapping‑Kandidaten | sample-14 prüft, ob die API für Zustandswechsel als Mapping‑Begründung gilt |
| 15 | Logik zur Verringerung der Gegner‑Gesundheit | Gemeinsame Syntax | Überprüfen, ob für die Gegner‑Gesundheits‑Verringerungs‑Logik tatsächlich Godot‑3→4‑API‑Änderungen erforderlich sind | Unterscheidung vom Mapping für Spieler‑Gesundheit oder Punkteverwaltung | sample-15 ist ein Punkt, bei dem, wenn das Zielobjekt unterschiedlich ist, das Mapping‑Kriterium zu Nein führen muss |
| 16 | Entfernen und Punkte hinzufügen, wenn der Gegner 0 Gesundheit hat | Gemeinsame Syntax | Prüfen, ob Unterschiede bei der Entfernen‑API, Score‑Aktualisierungs‑API und Szenenbaum‑Manipulation im aktuellen Code vorhanden sind | Unterscheidung von einfachem Damage‑Mapping oder Label‑Aktualisierungs‑Mapping | sample-16 analysiert getrennt, welcher Teil – Entfernen oder Punkte‑Hinzufügen – das Mapping‑Argument liefert |
| 17 | Aktualisierung der Punktzahl‑Variable (Score) | Gemeinsame Syntax | Überprüfen, ob für die Aktualisierung der Punktzahl‑Variable tatsächlich API‑Änderungen als Begründung nötig sind | Unterscheidung vom Mapping für UI‑Text‑Aktualisierung oder Speicher‑/Ladevorgänge | sample-17 prüft, ob einfache Variablenoperationen nicht überbewertet als Migrations‑Begründung gelten |
| 18 | Funktion zur Aktualisierung des Punktzahl‑Textes (Label) | Gemeinsame Syntax | Prüfen, ob Änderungen im Zugriff auf Label‑Text oder Node‑Referenzen im aktuellen Code erforderlich sind | Unterscheidung vom Mapping zur Berechnung des Punktwerts | sample-18 prüft, ob die Label.text‑Verwendung allgemein ist und ob versionsspezifische Änderungen vorliegen |
| 19 | Wiedergabe und Lautstärkeregelung von Hintergrundmusik (BGM) | Gemeinsame Syntax | Überprüfen, ob Änderungen an AudioServer, AudioStreamPlayer oder Bus‑Lautstärke im Code direkt nötig sind | Unterscheidung vom Mapping für einmalige SFX‑Wiedergabe | sample-19 stellt sicher, dass nur allgemeine Audio‑Begriffe nicht automatisch ein Mapping erzeugen |
| 20 | Funktion zur Wiedergabe von Soundeffekten (SFX) | Gemeinsame Syntax | Prüfen, ob Änderungen an der SFX‑Wiedergabe‑API oder Node‑Erstellung im Code direkt vorhanden sind | Unterscheidung vom Mapping für BGM‑Loop/Lautstärkeregelung | sample-20 trennt die Transformations‑Begründung, selbst wenn SFX und BGM zur selben Audio‑Klasse gehören |
| 21 | Bildschirmvibration (Screen Shake) Effekt Implementierung | Versionsunterschied | Überprüfen, ob es API-Änderungen pro Version bei der Implementierung von Tween, Camera2D, offset/random shake gibt | Unterscheidung zwischen Kameraverfolgung und allgemeinem Bewegungs‑Mapping | sample-21 verifiziert, ob die kamerabezogene Auswahl die Grundlage für die Bildschirmvibrationstransformation ist |
| 22 | Partikelsystem erstellen und Position abgleichen | Versionsunterschied | Particles2D/GPUParticles2D, emitting, position/global_position Änderungen prüfen, ob sie direkt im Code vorhanden sind | Unterscheidung zwischen Projektilerzeugung und allgemeiner Node-Erzeugungszuordnung | sample-22 betrachtet die Trennung von reinen Partikelsystem-API-Änderungen und allgemeiner Erstellungslogik |
| 23 | Szenenwechsel‑Funktion (Scene Change) | Versionsunterschied | Prüfen, ob die Änderungen von change_scene, change_scene_to_file, change_scene_to_packed im aktuellen Code direkt vorkommen | Unterscheidung von einfachem load()/preload() oder Hauptmenü‑Anzeige‑Mapping | sample-23 prüft, ob die Aufrufe zum Szenenwechsel in Godot 3 und die Ersatzaufrufe in Godot 4 korrekt zur jeweiligen Code‑Version passen |
| 24 | Hauptmenü‑Szene laden und anzeigen | Versionsunterschied | Prüfen, ob Änderungen bei Szene‑Laden, Instanziierung und Menü‑Anzeige im aktuellen Code nötig sind | Unterscheidung von allgemeinem Szenenwechsel oder Ressourcen‑preload‑Mapping | sample-24 stellt sicher, dass das Ziel der Hauptmenü‑Anzeige nicht mit Änderungen der Scene‑API vermischt wird |
| 25 | Spiel‑Pause‑Funktion umschalten | Gemeinsame Syntax | Prüfen, ob pause‑mode/process‑mode, tree‑pause Änderungen im aktuellen Code tatsächlich benötigt werden | Unterscheidung von Menü‑UI oder Game‑Over‑Mapping | sample-25 prüft, ob die allgemeine Pause‑Umschalt‑Logik nicht übermäßig mit Migrations‑Mapping versehen ist |
| 26 | Tastatureingabe‑Status prüfen (Input.is_key_pressed) | Versionsunterschied | Prüfen, ob Tastenkonstanten, Scancode/Keycode, Input.is_key_pressed Änderungen exakt zum Code passen | Unterscheidung von Action‑Map‑Bewegungs‑Handling oder Maus‑Eingabe‑Mapping | sample-26 trennt API‑Änderungen zur Tastenzustands‑Abfrage von Gameplay‑Logik, die Eingaben nutzt |
| 27 | Maus‑Position (Cursor) Koordinaten holen | Gemeinsame Syntax | Prüfen, ob die API zum Abfragen der Maus‑Position versionsabhängige Änderungen erfordert | Unterscheidung von Klick‑Projektile‑Erzeugung oder Touch‑Eingabe‑Mapping | sample-27 stellt sicher, dass für das Lesen von Koordinaten kein unnötiger Transformations‑Grund angehängt ist |
| 28 | Zufallszahl‑Erzeugungs‑Funktion | Versionsunterschied | Prüfen, ob randomize, RandomNumberGenerator, range‑Funktion Änderungen direkt im Code vorkommen | Unterscheidung von zufälligen Spawn‑Positionen oder Spawn‑Timer‑Mapping | sample-28 trennt Änderungen der Zufalls‑API von deren Verwendungszwecken |
| 29 | Gegner‑Spawn in regelmäßigen Intervallen | Versionsunterschied | Prüfen, ob Timer‑Signal, timeout‑Verbindung, yield/await Änderungen im aktuellen Code direkt vorkommen | Unterscheidung von zufälliger Gegner‑Verteilung oder Gegner‑KI‑Bewegungs‑Mapping | sample-29 prüft gleichzeitig die periodische Ausführungsstruktur und die Erzeugungs‑Logik |
| 30 | Zufällige Verteilung der gespawnten Gegnerpositionen | Gemeinsame Syntax | Prüfen, ob random‑range, Viewport‑Größe, Spawn‑Area‑Berechnung tatsächliche API‑Änderungen benötigen | Unterscheidung von Timer‑basiertem periodischem Spawn‑Mapping | sample-30 stellt sicher, dass bei reinem Positions‑Berechnungscode kein Spawn‑Intervall‑Mapping angehängt ist |
| 31 | Spieler‑Animations‑Zustandswechsel (Idle, Run, Jump) | Versionsunterschied | Prüfen, ob AnimatedSprite/AnimatedSprite2D, AnimationPlayer Zustandswechsel Änderungen exakt zum Code passen | Unterscheidung von playback‑speed/seek/time‑Control‑Mapping | sample-31 trennt Änderungen von Animations‑Node‑Namen und Zustands‑Wechsel‑Mustern |
| 32 | Steuerung der Animations‑Abspieldauer | Gemeinsame Syntax | Prüfen, ob playback‑speed, seek, current‑position Änderungen im aktuellen Code nötig sind | Unterscheidung von Idle/Run/Jump‑Zustands‑Auswahl‑Mapping | sample-32 trennt die API zur Steuerung der Abspieldauer von der Zustands‑Wechsel‑API |
| 33 | Größe des Kollisionsbereichs anpassen | Versionsunterschied | Prüfen, ob CollisionShape2D, RectangleShape2D, shape‑size/extents Änderungen direkt im Code nötig sind | Unterscheidung von collision‑signal, physics‑layer, damage‑Mapping | sample-33 prüft, ob die Änderungen an der Shape‑Größen‑API, nicht an der Kollisions‑Erkennungs‑API, zum Code passen |
| 34 | Physikalische Schwerkraft (Gravity) anwenden | Versionsunterschied | Prüfen, ob CharacterBody2D/KinematicBody2D, velocity, move_and_slide Änderungen direkt im Code nötig sind | Unterscheidung von Sprung‑Impuls, Bodenkontakt, Area2D‑Gravity‑Mapping | sample-34 prüft, ob die Schwerkraft‑Akkumulation im Physik‑Frame korrekt gemappt wird |
| 35 | Sprung‑Kraft anwenden und Landung erkennen | Versionsunterschied | Prüfen, ob is_on_floor(), Sprung‑velocity, Input‑Action, move_and_slide Änderungen exakt zum Code passen | Unterscheidung von rein gravitäts‑basiertem Move, Animations‑Zustand, Wand‑Kollisions‑Mapping | sample-35 prüft, ob Sprung‑Start‑Bedingungen und Landungs‑Erkennung zusammengehörige Mappings benötigen |
| 36 | Behandlung des Gleiten (Slide) bei Wand‑Kollision | | | | |
| 37 | Spieler‑Richtungswechsel (Facing Left/Right) | | | | |
| 38 | Munitions‑Zähler (Ammo) verringern | | | | |
| 39 | Zustandswechsel zu Nachladen (Reload), wenn Magazin leer ist | | | | |
| 40 | UI‑Button‑Klick‑Ereignis verbinden | | | | |
| 41 | Einstellungen‑Menü öffnen/schließen umschalten | | | | |
| 42 | Text‑Aktualisierung bei Sprach‑Änderung | | | | |
| 43 | Spielstand‑Daten (Save Game) JSON‑Serialisierung | | | | |
| 44 | Spielstand‑Daten (Load Game) JSON‑Deserialisierung | | | | |
| 45 | Fehlerbehandlung beim Datei‑Lesen/‑Schreiben | | | | |
| 46 | Netzwerk‑Verbindungs‑Status prüfen | | | | |
| 47 | Synchronisation über Remote‑Funktions‑Aufruf (RPC) | | | | |
| 48 | Dynamisches Laden von Szenen‑Ressourcen | | | | |
| 49 | Speicher‑Freigabe und Ressourcen‑Entladen | | | | |
| 50 | Debug‑Log‑Ausgabe (print oder print_debug) | | | | |
label_prototypes
Stellen Sie sicher, dass das Beispiel, bei dem nicht nur der Name geändert wird, sondern die Art der Funktionsverwendung, die Argumentstruktur und das Aufrufmuster vollständig geändert werden, direkt mit dem Code‑Chunk übereinstimmt.
| Nummer | Funktion | Gemeinsame Syntax | Zugehöriges JSONL‑Ergebnis | Unabhängiges JSONL‑Ergebnis | Hinweis |
|---|---|---|---|---|---|
| 1 | _ready()‑Funktion initialisieren und Viewport‑Größe festlegen |
Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
DisplayServer.window_set_size(Vector2i(1920, 1080))‑Prototyp ist Ja; AudioStreamPlayer3D‑Prototyp wird als Nein bewertet |
| 2 | _process(delta)‑Update‑Schleife pro Frame |
Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
func _process(delta) und position.x += move_speed * delta‑Prototyp ist Ja; _input(event)/event.is_action_pressed‑Prototyp wird als Nein bewertet |
| 3 | Eingabe für Spielerbewegung verarbeiten (WASD oder Pfeiltasten) | Gemeinsame Syntax | Zugehöriges JSONL Ja beobachtet |
Unabhängiges JSONL Nein beobachtet |
Input.is_action_pressed, velocity = direction * move_speed, move_and_slide()‑Prototyp ist Ja; @onready/Node‑Pfadzugriff‑Prototyp wird als Nein bewertet |
| 4 | Geschwindigkeit und Beschleunigung des Spielers anwenden | Versionsunterschied | Vorherige beidseitige Ja‑Einträge werden bei der endgültigen Bewertung ausgeschlossen |
In Godot‑3‑Prüfung wird bei den label_prototypes zwischen Ja/Nein unterschieden |
Die Achsen‑move_toward(velocity.x/velocity.z), move_and_slide(), CharacterBody3D‑Prototypen müssen erneut geprüft werden, ob sie versionsspezifisch oder allgemeine String‑Begründungen sind |
| 5 | Maximale Geschwindigkeit des Spielers begrenzen | Versionsunterschied | Erste Beobachtung nach Godot 3. Umgekehrte Rohantwort nach Godot 4: Godot 4‑Code Ja/Nein, Godot 3‑Code Ja/Nein |
Tween‑Prototyp wird in beiden Fällen als Nein verworfen |
CharacterBody2D, move_and_slide(), velocity kommen in beiden Codes vor, daher werden die zugehörigen Prototypen in beiden Fällen als Ja erfasst. Versionsspezifische und allgemeine String‑Begründungen müssen getrennt werden |
| 6 | Projektil bei Mausklick erzeugen und abschießen | Versionsunterschied | Das Erzeugungs‑/Abschuss‑Muster des Projektils stimmt mit dem Code‑Muster überein | Unabhängige Prototyp‑Kandidaten werden ebenfalls verworfen | In den 24/24‑bestanden Abläufen enthalten. Eingabeverarbeitung und Projektil‑Erzeugungsmuster sind klar getrennt |
| 7 | Bewegung und Lebensdauer (time‑to‑live) des Projektils verwalten | Versionsunterschied | Der Transformations‑Prototyp wird im Godot 3‑Code als Ja erfasst |
Derselbe Prototyp erscheint im Godot 4‑Code ebenfalls als Ja – Inkonsistenz beobachtet |
Gesamt 22/24; bereits transformierter Godot 4‑Code darf keinen „Transformations‑erforderlich“‑Prototyp erhalten |
| 8 | KI‑Logik für das Verfolgen des Spielers durch den Gegner (Enemy) | Versionsunterschied | Bei label_prototypes war die Diskrepanz bei Eintrag 8 nicht die direkte Ursache | Unabhängige Prototyp‑Kandidaten werden wie erwartet verworfen | Gesamte Diskrepanz entsteht in docs_chunks. Der Prototyp dient als Hilfsachse, um Änderungen im Einsatz der Verfolgungs‑KI zu prüfen |
| 9 | Bewegungs‑ und Rotationslogik des Gegners | Versionsunterschied | Das Bewegungs‑/Rotations‑Aufruf‑Muster stimmt mit dem Code‑Muster überein | Unabhängige Prototyp‑Kandidaten werden wie erwartet verworfen | 24/24 bestanden. Berechnung der Bewegungsgeschwindigkeit und Anwendung der Rotation sind relativ klar getrennt |
| 10 | Spieler verschwindet, wenn er den Bildschirm verlässt | Gemeinsame Syntax | Da es gemeinsamer Code ist, wird bei label_prototypes kein Transformations‑Bedarf gesehen | Unabhängige Transformations‑Kandidaten ergeben Nein |
6/6 bestanden. Bei gemeinsamer Syntax wird kein Prototyp angehängt |
| 11 | Kollisionsdetektion (Area2D oder PhysicsBody) | Versionsunterschied | Prüfen, ob die Verwendung von Kollisions‑Signal/Callback dem Muster vor der Code‑Änderung entspricht | Unterscheidet sich vom Prototyp für Schaden nach Kollision | sample-11 trennt das Erkennungs‑Ereignis‑Muster von nachfolgenden Gameplay‑Verarbeitungen |
| 12 | Schaden berechnen und anwenden bei Kollision | Gemeinsame Syntax | Prüfen, ob das Aufruf‑Muster zur Schadensanwendung nach einer Kollision im aktuellen Code direkt vorkommt | Unterscheidet sich vom einfachen Kollisions‑ oder 0‑HP‑Prototyp | sample-12 prüft, ob Parameter, Zielobjekt und Reihenfolge der Schadensanwendung als Prototyp‑Begründung gelten |
| 13 | Logik zum Reduzieren der Spieler‑HP | Gemeinsame Syntax | Prüfen, ob das Muster für Treffer/HP‑Reduktion des Spielers im aktuellen Code direkt vorkommt | Unterscheidet sich vom Gegner‑HP‑Prototyp | sample-13 verifiziert, ob trotz gleicher Health‑Kategorie Spieler‑ und Gegner‑Ziel unterschieden werden |
| 14 | Spiel‑Over, wenn Spieler‑HP 0 erreicht | Gemeinsame Syntax | Prüfen, ob das Aufruf‑Muster für Game‑Over nach HP 0 im aktuellen Code direkt vorkommt | Unterscheidet sich vom reinen HP‑Reduzieren‑ oder Gegner‑Entfernen‑Prototyp | sample-14 prüft, ob nach der Bedingung Zustandswechsel/Scene‑Handling vom Prototyp beschrieben wird |
| 15 | Logik zum Reduzieren der Gegner‑HP | Gemeinsame Syntax | Prüfen, ob das Muster für Schaden/HP‑Reduktion des Gegners im aktuellen Code direkt vorkommt | Unterscheidet sich vom Spieler‑Schaden‑Prototyp | sample-15 untersucht, ob bei breiter Überschneidung von Objekt‑ und Variablennamen False Positives entstehen |
| 16 | Gegner entfernen und Punkte hinzufügen, wenn HP 0 | Gemeinsame Syntax | Prüfen, ob das kombinierte Muster für Gegner‑Entfernung + Score‑Erhöhung im aktuellen Code direkt vorkommt | Unterscheidet sich vom reinen Score‑Update‑ oder reinen Entfernen‑Prototyp | sample-16 prüft, ob mehrere Aktionen im Prototyp in der gleichen Reihenfolge wie im SOURCE_CODE auftreten |
| 17 | Score‑Variable aktualisieren | Gemeinsame Syntax | Prüfen, ob das Muster zur Aktualisierung der Score‑Variable im aktuellen Code direkt vorkommt | Unterscheidet sich vom Label‑Text‑Update‑Prototyp | sample-17 trennt interne Daten‑Updates von UI‑Anzeige‑Updates |
| 18 | Funktion zum Aktualisieren des Score‑Labels | Gemeinsame Syntax | Prüfen, ob das Muster zur Aktualisierung des Label‑Texts im aktuellen Code direkt vorkommt | Unterscheidet sich vom reinen Score‑Variablen‑Prototyp | sample-18 prüft, ob es sich um ein Anzeige‑Prototyp (nicht nur Wert‑Änderung) handelt |
| 19 | Hintergrundmusik (BGM) abspielen und Lautstärke anpassen | Gemeinsame Syntax | Prüfen, ob das Muster zum Abspielen/Anpassen der Lautstärke von BGM im aktuellen Code direkt vorkommt | Unterscheidet sich vom einmaligen SFX‑Abspiel‑Prototyp | sample-19 fokussiert auf kontinuierliche Wiedergabe/Lautstärke‑Steuerung statt allgemeiner Audio‑Begriffe |
| 20 | Funktion zum Abspielen von Sound‑Effekten (SFX) | Gemeinsame Syntax | Prüfen, ob das Muster zum Aufrufen/Abspielen von SFX im aktuellen Code direkt vorkommt | Unterscheidet sich vom BGM‑Loop‑ oder Bus‑Volume‑Prototyp | sample-20 trennt kurze Effekt‑Wiedergabe von Hintergrundmusik‑Management |
| 21 | Implementierung des Bildschirm‑Shake‑Effekts | Versionsunterschied | Prüfen, ob das Muster für Intensität/Zeit/Offset des Shakes im aktuellen Code direkt vorkommt | Unterscheidet sich vom Kamera‑Follow‑ oder allgemeinen Tween‑Prototyp | sample-21 verifiziert, dass trotz vorhandener Camera2D/Tween der Endeffekt tatsächlich ein Shake ist |
| 22 | Partikelsystem erzeugen und positionieren | Versionsunterschied | Prüfen, ob das Muster für Partikel‑Erzeugung, Positions‑Abgleich und Start des Emittierens im aktuellen Code direkt vorkommt | Unterscheidet sich vom Projektil‑Erzeugungs‑ oder generischen Node‑Erstellungs‑Prototyp | sample-22 prüft, ob Position‑Synchronisation und Emissions‑Start vom Prototyp beschrieben werden |
| 23 | Szenenwechsel (Scene Change) Funktion | Versionsunterschied | Prüfen, ob das Aufrufmuster, das einen Szenenpfad entgegennimmt und zu einem SceneTree wechselt, direkt im aktuellen Code vorhanden ist | Unterscheiden von einfachem Ressourcenladen, Menü öffnen, Pause‑Prototype | sample-23 prüft, ob das Prototype den Eingabepfad, das Aufrufziel und das Ergebnis des Szenenwechsels beschreibt |
| 24 | Hauptmenü‑Szene laden und anzeigen | Versionsunterschied | Prüfen, ob das Aufrufmuster zum Laden und Anzeigen der Menü‑Szene direkt im aktuellen Code vorhanden ist | Unterscheiden von einfachem Ressourcenladen, Szenenwechsel, Pause‑Menu‑Prototype | sample-24 prüft, ob das Prototype das Ergebnis „Hauptmenü anzeigen“ bis zum Ende erklärt |
| 25 | Spiel‑Pause (Pause) Funktion umschalten | Gemeinsame Syntax | Prüfen, ob das Muster, das den Pause‑Zustand umkehrt und zugehörige UI/Eingabeverarbeitung bündelt, direkt im aktuellen Code vorhanden ist | Unterscheiden von Menü‑Öffnen‑Prototype oder Game‑Over‑Prototype | sample-25 prüft, ob die Änderung des Pause‑Flags und die Anzeige im selben Ablauf betrachtet werden müssen |
| 26 | Tastatureingabe‑Status prüfen (Input.is_key_pressed) | Versionsunterschied | Prüfen, ob das Muster, das den Tastatur‑Status direkt pollt, im aktuellen Code vorhanden ist | Unterscheiden von Action‑Strength, Bewegungsvektor, Maus‑Input‑Prototype | sample-26 zeichnet die Trennung von Eingabeabfrage und den darauf basierenden Aktionen auf |
| 27 | Mausposition (Cursor) Koordinaten holen | Gemeinsame Syntax | Prüfen, ob das Muster, das die Cursor‑Koordinaten liest und für Variablen oder Positionsberechnungen nutzt, direkt im aktuellen Code vorhanden ist | Unterscheiden von Maus‑Klick‑Ereignis‑ oder Projektil‑Erzeugungs‑Prototype | sample-27 prüft, ob das reine Abfragen der Mausposition der Kern ist |
| 28 | Zufallszahl‑Erzeugungsfunktion | Versionsunterschied | Prüfen, ob das Muster für Zufallszahl‑Erzeugung/ Bereichsangabe direkt im aktuellen Code vorhanden ist | Unterscheiden von Spawn‑Positions‑Verteilung, Drop‑Tabelle, Timer‑Spawn‑Prototype | sample-28 trennt den Aufruf der Random‑API von den Verwendungsstellen des Ergebnisses |
| 29 | Gegner‑Spawn in regelmäßigen Intervallen | Versionsunterschied | Prüfen, ob das Muster, das in festen Zeitabständen die Spawn‑Funktion aufruft, direkt im aktuellen Code vorhanden ist | Unterscheiden von zufälliger Positionsberechnung oder Gegner‑Verfolgungs‑AI‑Prototype | sample-29 prüft, ob Zeitbedingungen, Timer und Spawn‑Aufruf in der richtigen Reihenfolge stehen |
| 30 | Zufällige Verteilung der gespawnten Gegnerpositionen | Gemeinsame Syntax | Prüfen, ob das Muster, das erzeugte Gegner innerhalb eines zufälligen Bereichs platziert, direkt im aktuellen Code vorhanden ist | Unterscheiden von Spawn‑Loop‑Prototype, das in festen Intervallen erzeugt | sample-30 trennt Verteilungs‑/Koordinatenberechnung von der Erzeugungsrate |
| 31 | Spieler‑Animationszustandswechsel (Idle, Run, Jump) | Versionsunterschied | Prüfen, ob das Muster, das je nach Zustandswert oder Geschwindigkeit den Animationsnamen ändert, direkt im aktuellen Code vorhanden ist | Unterscheiden von Playback‑Speed, Seek, Frame/Time‑Control‑Prototype | sample-31 prüft, ob der eigentliche Wechsel des Zustands das Wesentliche ist |
| 32 | Steuerung der Animations‑Abspieldauer | Gemeinsame Syntax | Prüfen, ob das Muster, das Wiedergabegeschwindigkeit, Seek und aktuelle Position steuert, direkt im aktuellen Code vorhanden ist | Unterscheiden von Idle/Run/Jump‑Zustands‑Prototype | sample-32 prüft, ob die Kontrolle der Abspieldauer, nicht die Auswahl der Animation, im Fokus steht |
| 33 | Kollisionsbereich‑Größe anpassen | Versionsunterschied | Prüfen, ob das Muster, das die Größe eines Kollisions‑Shapes liest oder ändert, direkt im aktuellen Code vorhanden ist | Unterscheiden von Kollisions‑Ereignis‑Verarbeitung oder Schadens‑Anwendung‑Prototype | sample-33 trennt die Änderung der Shape‑Größe vom eigentlichen Kollisions‑Ergebnis |
| 34 | Physikalische Schwerkraft (Gravity) anwenden | Versionsunterschied | Prüfen, ob das Muster, das basierend auf Delta die Schwerkraft zur Geschwindigkeit addiert und über den Bewegungsaufruf umsetzt, direkt im aktuellen Code vorhanden ist | Unterscheiden von Sprung‑Eingabe, Bodenkontakt‑Prüfung, Spawn/Timer‑Prototype | sample-34 prüft, ob die Akkumulation der Schwerkraft innerhalb der Physik‑Bewegungsschleife das Kernstück ist |
| 35 | Sprung‑Kraft anwenden und Landung erkennen | Versionsunterschied | Prüfen, ob das Muster, das bei Bodenkontakt Sprungkraft hinzufügt und anschließend die Landung prüft, direkt im aktuellen Code vorhanden ist | Unterscheiden von reinem Schwerkraft‑Akkumulations‑Bewegungs‑Prototype oder Animations‑Zustands‑Prototype | sample-35 prüft, ob Sprungbedingungen, vertikale Geschwindigkeitsänderung und Bodenerkennung in einem Ablauf zusammengefasst sind |
| 36 | Wand‑Kollision‑Slide‑Behandlung | | | | |
| 37 | Spieler‑Richtungswechsel (Facing Left/Right) | | | | |
| 38 | Munitions‑Zähler verringern | | | | |
| 39 | Beim leeren Magazin Nachladen‑Zustand aktivieren | | | | |
| 40 | UI‑Button‑Klick‑Ereignis verbinden | | | | |
| 41 | Einstellungen‑Menü öffnen/schließen umschalten | | | | |
| 42 | Text‑Update bei Sprachwechsel | | | | |
| 43 | Spielstand‑JSON serialisieren | | | | |
| 44 | Spielstand‑JSON deserialisieren | | | | |
| 45 | Datei‑Lese/Schreib‑Fehlerbehandlung | | | | |
| 46 | Netzwerk‑Verbindungs‑Status prüfen | | | | |
| 47 | Synchronisation über Remote‑Funktion (RPC) Aufruf | | | | |
| 48 | Dynamisches Laden von Szenen‑Ressourcen | | | | |
| 49 | Speicherfreigabe und Ressourcen‑Entladen | | | | |
| 50 | Debug‑Log‑Ausgabe (print oder print_debug) | | | | |
2026‑07‑06 zusätzliche Aufzeichnungen
Die Einträge 6 bis 10 wurden bereits am 3. Juli 2026 mit dem verbesserten Ablauf detailliert beobachtet. Deshalb lassen wir in diesem Dokument die Nummern 6‑10 nicht leer, sondern haben die bisherigen Beobachtungen jeweils in die Tabellen docs_chunks, api_mapping und label_prototypes übernommen.
Am 6. Juli 2026 wurden anhand von http://localhost:8520/#item=sample-22 die Einträge 11 bis 22 ergänzt. In diesem Abschnitt wird für jeden Punkt angegeben, welche Kandidaten‑JSONL als Beleg dienen und welche Kandidaten in einen anderen Code, eine andere Transformation oder ein anderes Muster überführt werden müssen.
2026‑07‑08 zusätzliche Aufzeichnungen
Am 8. Juli 2026 wurden anhand von http://localhost:8520/#item=sample-32 die Einträge 23 bis 32 ergänzt. Dieser Abschnitt ist eher eine Beobachtungstabelle, in der festgehalten wird, wie docs_chunks, api_mapping und label_prototypes denselben Code‑Chunk aus unterschiedlichen Perspektiven erklären oder ablehnen sollten, als ein endgültiges Entscheidungsschema.
2026‑07‑13 zusätzliche Aufzeichnungen
Am 13. Juli 2026 wurden anhand von http://localhost:8520/#item=sample-35 die Einträge 33 bis 35 ergänzt. Dieser Abschnitt behandelt Bereiche, in denen Größe von Kollisionszonen, Schwerkraft, Sprung‑/Landeverhalten usw. physikalische Bewegungen und Kollisionsformen gegenseitig beeinflussen; hier muss man neben reinem String‑Overlap auch den Zweck und den Anwendungsort des Codes berücksichtigen.
Rückwärts‑Beobachtung von Eintrag 5
Eintrag 5 war zwar im heutigen Zielumfang enthalten, aber bei einer rückwärtsgerichteten Prüfung mit Godot 4‑JSONL ergab sich kein klares Ja/Nein‑Ergebnis. Deshalb wird die Feststellung vorerst nicht getroffen und im nächsten Schritt als Analyse‑Pattern behandelt.
Die Antwortreihenfolge lautet: docs_chunks #1, docs_chunks #2, api_mapping #1, api_mapping #2, label_prototypes #1, label_prototypes #2.
| Prüfcode | Antwortreihenfolge | Beobachtung |
|---|---|---|
| Godot 4‑Code | Ja, Ja, Ja, Ja, Ja, Nein |
Da viele Strings wie limit_speed, velocity, move_and_slide(), Input.is_action_pressed direkt im Code vorkommen, werden die Docs‑/API‑Kandidaten breit mit Ja bewertet |
| Godot 3‑Code | Ja, Ja, Nein, Nein, Ja, Nein |
Docs‑Kandidaten und das CharacterBody2D‑Prototype erhalten Ja, aber die api_mapping‑Kandidaten für Godot 4 erhalten Nein |
Dieses Ergebnis sollte nicht nur als Fehlfunktion des Modells gesehen werden, sondern als Hinweis darauf, dass die Felder match_terms, required_when_seen_in_code und content in den JSONL‑Dateien zu allgemein sein könnten. Insbesondere Strings, die sowohl in move_and_slide() als auch in Input.is_action_pressed vorkommen, dienen zwar als direkter Beleg, könnten aber für Begrenzungen der Maximalgeschwindigkeit oder Versionsunterschiede zu breit gefasst sein.
Fälle von Inkonsistenzen
False Positive
Fälle, bei denen Nein korrekt wäre, aber Ja ausgegeben wurde.
| ID | Funktion | Gemeinsame Syntax? | Tabelle | Falsche JSONL‑Zusammenfassung | Qwen‑Antwort | Grund für erneute Prüfung |
|---|---|---|---|---|---|---|
False Negative
Fälle, bei denen Ja korrekt wäre, aber Nein ausgegeben wurde.
| ID | Funktion | Gemeinsame Syntax? | Tabelle | Richtige JSONL‑Zusammenfassung | Qwen‑Antwort | Grund für erneute Prüfung |
|---|---|---|---|---|---|---|
Verstöße gegen das Antwortformat
Fälle, bei denen statt Ja oder Nein eine Erklärung, JSON, leere Antwort oder mehrere Sätze geliefert wurden.
| ID | Funktion | Gemeinsame Syntax? | Tabelle | Erwartete Antwort | Tatsächliche Antwort | Hinweis |
|---|---|---|---|---|---|---|
Beobachtungs‑Zusammenfassung
Während der Tests werden die untenstehenden Zahlen und Rohantworten ausgefüllt. Hier wird noch keine endgültige Entscheidung getroffen, sondern lediglich beobachtet, bei welchen Kriterien die Antworten schwanken.
| Punkt | docs_chunks | api_mapping | label_prototypes | Gesamt |
|---|---|---|---|---|
| Beobachtungen heute | Ergänzungen 23‑32 | Ergänzungen 23‑32 | Ergänzungen 23‑32 | Ergänzungen 23‑32 (Stand 08.07.2026) |
| Gesamte Beobachtungen | 32/50 Testeinträge | 32/50 Testeinträge | 32/50 Testeinträge | 32/50 Testeinträge |
| Anzahl getesteter Code‑Chunks | 32/50 | 32/50 | 32/50 | 32/50 |
| Anzahl gemeinsamer Syntax‑Beispiele | kumulativ noch nicht ermittelt | kumulativ noch nicht ermittelt | kumulativ noch nicht ermittelt | Nach Label‑Eintrag 32 separate Auswertung nötig |
| Anzahl Versions‑Unterschied‑Beispiele | kumulativ noch nicht ermittelt | kumulativ noch nicht ermittelt | kumulativ noch nicht ermittelt | Nach Label‑Eintrag 32 separate Auswertung nötig |
| Erwartete Übereinstimmung (1. Runde) | 5 | 5 | 5 | 15 |
| Erwartete Abweichung (1. Runde) | 0 | 0 | 0 | 0 |
| Rohantwort Rückwärts‑Beobachtung (Eintrag 5) Godot 4 | Godot 4 Ja/Ja, Godot 3 Ja/Ja |
Godot 4 Ja/Ja, Godot 3 Nein/Nein |
Godot 4 Ja/Nein, Godot 3 Ja/Nein |
Muster‑Analyse erforderlich |
| Verstöße gegen das Antwortformat | 0 | 0 | 0 | 0 |
| Wiederholungsbedarf | 2 | 2 | 2 | Neu‑Definition für 4/5 nötig |
| Aktuelle Bewertung | Entscheidung ausgesetzt | Entscheidung ausgesetzt | Entscheidung ausgesetzt | Weiterführende Muster‑Analyse bis inkl. Ergänzungen 23‑32 nötig |