idea_world_labDEV JOURNAL
Dienstag, 28. Juli 2026

2026-07-28 Source Flow Debugger Tatsächlicher Quellcode‑Suchbericht

Ziel

In den bisherigen Aufzeichnungen wurde nur vermerkt, dass das eigentliche Godot‑Projekt in 134 Chunks aufgeteilt und durchsucht wurde und dass die zugehörige Dokumentation in den oberen Ergebnissen enthalten war. Diese Formulierung lässt jedoch offen, was jeder Chunk zurückgegeben hat, ob das zurückgegebene JSONL tatsächlich in SQLite existiert und ob vorhandene, direktere Dokumente in SQLite durch die Rangfolge übergangen wurden.

Dieser Bericht behandelt die folgenden drei Fragen getrennt:

  1. Welche JSONL‑Kandidaten hat der Source Flow Debugger pro Chunk zurückgegeben?
  2. Stimmen die zurückgegebenen Kandidaten exakt mit den verifizierten Original‑JSONL‑Einträgen in der commit‑basierten SQLite‑Datenbank überein?
  3. Befanden sich die direkt nachgewiesenen Einträge in SQLite oben in den Ergebnissen, oder ist eine Rangverbesserung nötig?

Der Qwen‑Endpunkt war nicht verfügbar, daher wurden in diesem Durchlauf nur die Suche und der Abgleich mit SQLite durchgeführt. Die Klassifizierung der Godot‑Versionen durch Qwen sowie die Genehmigungs‑/Ablehnungs‑Ergebnisse der Kandidaten wurden nicht protokolliert, und das bloße Auftauchen eines Suchkandidaten wird nicht als erfolgreicher End‑to‑End‑Test gewertet.

Eingabedaten

  • Repository:
    godotengine/godot-demo-projects
  • Lizenz: MIT
  • Commit: cae8dc567a56d3e7936f171bcb85f0ccb9634ad0
  • Projekt: 2d/hexagonal_map
  • Eingabedateien: project.godot, map.tscn, tileset.tres,
    tileset_edit.tscn, troll.gd, troll.tscn
  • Anzahl Eingabedateien: 6
  • Erzeugte Chunks: 134
  • AST‑Chunks: 3
  • Direkte Chunks: 131

Die für die Ausführung genutzte SQLite‑Datei ist
outputs/godot-rag-sqlite/godot-rag.sqlite3. Zum Zeitpunkt der Ausführung enthielt sie
docs_chunks 2 265 Einträge, api_mapping 1 133 Einträge, label_prototypes 2 Einträge und 3 399 Embeddings.

Ausführungsstatus

Schritt Status Bedeutung dieses Laufs
SQLite FTS5 + Okapi BM25 aktiv Alle 134 Chunks wurden durchsucht
embedding inaktiv Kein API‑Key für Query‑Embedding gesetzt
reranker inaktiv Kein Provider‑API‑Key gesetzt
Qwen validator inaktiv Qwen‑Endpunkt ist ausgefallen

Daher stellt die nachfolgende Rangliste nicht das Endergebnis des gesamten F‑Strategie‑Workflows dar, sondern das Ergebnis der lexical/BM25‑Phase.

Gesamtergebnis des Abgleichs

Kennzahl Ergebnis
Chunks 134
Pro Chunk zurückgegebene BM25‑Kandidaten 80
Mit SQLite abgeglichene Rückgaben 10 720
Nach Duplikatenbereinigung 844
Kandidaten, die in SQLite nicht gefunden wurden 0
Kandidaten, deren provenance nicht verified ist 0
Kandidaten, bei denen raw_json von SQLite abweicht 0
Rückgaben aus docs_chunks 10 713
Rückgaben aus api_mapping 7
Rückgaben aus label_prototypes 0

Die Konsistenz der Rückgabedaten war korrekt. Alle 10 720 IDs, die der Source Flow Debugger in seiner Tabelle anzeigte, konnten in SQLite nachgeschlagen werden, ihr provenance war verified und das zurückgegebene raw_json entsprach exakt dem gespeicherten Eintrag.

Dennoch bedeutet das nicht, dass die Suchqualität durchweg optimal war. Da alle 134 Chunks die Obergrenze von 80 Kandidaten füllten, konnten die lexical‑Kandidaten nicht weiter eingegrenzt werden. Außerdem führte der Schutz von Dateianker‑Begriffen dazu, dass in neun Chunks ein Dokument mit niedrigerem BM25‑Score auf Platz 1 aufstieg.

Beispielhafte Chunk‑Ergebnisse

Gut gefundene Fälle

Chunk Eingabe‑Zusammenfassung Rückgabe‑Ergebnis SQLite‑Abgleich
1 Beschreibung des Dateiformats project.godot Manually editing project.godot (Platz 1) gleiche ID und Originaltext
13 TileMapLayer, tile_map_data, TileSet TileMapLayer (Platz 1), Methode (Platz 2), TileData (Platz 3) alle verifizierten docs_chunks
42 TileSetAtlasSource, Textur‑Region TileSetAtlasSource (Platz 1), TileSetSource (Platz 2) direkter Klassen‑Nachweis
125 _physics_process, Input.get_axis, move_and_slide Physics process (Platz 1), 2D‑Bewegungs‑Dokumente (Platz 5‑7), CharacterBody2D (Platz 8) Bewegungs‑ und Physik‑Dokumente vorhanden
130 CharacterBody2D‑Node CharacterBody2D‑Klasse (Platz 1) direkter Klassen‑Nachweis

Der erste Platz von Chunk 1 wurde nicht allein durch den BM25‑Score erreicht, sondern blieb dank des lexical‑Anchor‑Schutzes für project.godot erhalten. In diesem Fall stimmt die Dateiformats‑Beschreibung exakt, sodass der Schutz gerechtfertigt war.

Fälle, bei denen eine Rangverbesserung erforderlich ist

Chunk 123: extends CharacterBody2D

  • Tatsächlicher Rang 1: Collision exceptions
  • Dokumentation der Klasse CharacterBody2D: Rang 17
  • Zuordnung KinematicBody2D -> CharacterBody2D: Rang 6

In SQLite gab es zwar die korrekte Dokumentation der Klasse CharacterBody2D, sie wurde jedoch hinter den breiteren Dokumenten zu Kollision / Bewegung platziert. Es handelt sich nicht um fehlende Daten, sondern um ein Rangproblem. Bei kurzen Deklarations‑Chunks muss ein exakt übereinstimmender Klassenname und Struktur‑Feld stärker gewichtet werden als allgemeine Kontext‑Token.

Chunk 124: tan(deg_to_rad(30))

  • Tatsächlicher Rang 1: Setting up the spring arm and camera
  • Evaluating expressions: Rang 2 und 3

Obwohl das Dokument mit Rang 1 ein Beispiel für deg_to_rad enthält und somit nicht völlig irrelevant ist, wurde es von einem 3D‑Tutorial übertroffen, das die reine Funktionsaufruf‑Erklärung behandelt. Eine Neuordnung, die reine API‑Beschreibungen von einfachen Anwendungsbeispielen trennt, ist nötig.

Strukturkandidaten, die einer erneuten Qwen‑Validierung bedürfen

Chunk 13: PackedByteArray in map.tscn enthalten

Die Zuordnung PackedByteArray -> byte[] landete auf Rang 48. Das gespeicherte JSONL erklärt die Migration von C#‑Collections, die Eingabe ist jedoch eine GDScript‑Szenen‑Ressource. Die Tokens stimmen überein, aber Sprache und Anwendungskontext unterscheiden sich, sodass sie in der Suchphase nicht endgültig akzeptiert werden dürfen.

Chunk 130: Node, die bereits CharacterBody2D verwendet

Die Zuordnung KinematicBody2D -> CharacterBody2D erreichte Rang 3. Diese Zuordnung ist für die Versionsbestimmung relevant, aber im aktuellen Chunk fehlt die alte API KinematicBody2D. Sie ist kein Kandidat für eine Migrationswarnung; Qwen muss JSONL und Original‑Chunk gemeinsam betrachten und als „Godot 4“‑Begründung oder als nicht anzuwenden klassifizieren.

Der originale SQLite‑JSONL‑Text beider Fälle wurde unverändert im reviewCases‑Abschnitt des maschinellen Lesberichts erhalten.

Warum label_prototypes 0 Einträge hat

Die Prototypen in SQLite bestehen nur aus den beiden Einträgen:

  • enum PlaneSemanticLabel
  • class OpenXRSpatialComponentPlaneSemanticLabelList

Im Chunk hexagonal_map gab es keine dieser Eingabemuster. Daher ist das Fehlen von label_prototypes in diesem Durchlauf kein Versäumnis, sondern das Ergebnis eines aktivierten strukturellen Filter‑Mechanismus.

Aktuelle Schlussfolgerung

  • Die Konsistenz zwischen Rückgabekandidaten und dem SQLite‑Originaltext wurde bestätigt.
  • Typische Projekteinstellungen, TileSet, TileMapLayer und Bewegungs‑Funktions‑Suchen wurden direkt in hochrangige Dokumente aufgenommen.
  • Nicht alle Chunks füllten das Kandidaten‑Maximum von 80 Einträgen, sodass die Reduktion nicht ausreichte.
  • Bei kurzen Klassen‑Deklarationen und einzelnen Funktionsaufrufen wurden direktere Dokumente nach hinten verdrängt.
  • Struktur‑Mappings können allein aufgrund passender Tokens in die Kandidaten gelangen; Qwen kann im abgeschalteten Zustand keine endgültige Entscheidung treffen.

Kriterien für den nächsten Durchlauf

Sobald der Qwen‑Endpunkt wieder verfügbar ist, werden dieselben 134 Chunks mit demselben Commit erneut verarbeitet und folgende Punkte ergänzt:

  1. Klassifizierung jedes Struktur‑Kandidaten in Godot 3, Godot 4, Keine Relevanz, Begründungs‑Mangel
  2. Ablehnung von Kandidaten wie PackedByteArray -> byte[], bei denen der Sprach‑Kontext nicht passt
  3. Ablehnung von Migrations‑Kandidaten in Chunks, die bereits die Ziel‑API verwenden
  4. Ablehnung von nicht‑relevanten Negative‑Control‑JSONL‑Einträgen
  5. Beobachtung der Rangverschiebungen von Direkt‑Dokumenten vor und nach Anwendung von Embedding und Reranker

2026‑08‑01 F‑Strategie und erneute Qwen‑Validierung

Der gleiche externe Repository‑Commit und die sechs Original‑Dateien von 2d/hexagonal_map wurden erneut in das Source‑Flow‑Debugger‑GUI geladen. Nach aktuellem Chunk‑Standard entstanden 146 Chunks. In einem vollständigen Such‑Audit, bei dem BM25, Embedding, Union und Reranker sequenziell ausgeführt wurden, wurden alle 146 Chunks verarbeitet; es gab keine fehlenden Rückgabe‑Datensätze, nicht verifizierten Provenance oder von der Original‑JSONL abweichende Einträge in SQLite.

Tatsächliche Datei Chunk Prüfungsumfang
project.godot 20 Gesamte Hybrid‑Suche, komplette Qwen‑Validierung, erneute Prüfung einzelner fehlerhafter Chunks
map.tscn 6 Gesamte Hybrid‑Suche und Qwen‑Validierung
tileset.tres 54 Gesamtes Such‑Audit, Prüfung von Atlas‑Source und finaler Resource‑Vertretung
tileset_edit.tscn 54 Gesamtes Such‑Audit, Prüfung von Root‑Node und Sprite‑Node‑Vertretung
troll.gd 3 Gesamte Hybrid‑Suche und Qwen‑Validierung
troll.tscn 9 Gesamte Hybrid‑Suche und Qwen‑Validierung

Ergebnisse der getrennten Suche und Validierung

  • Die Deklaration und Nodes von CharacterBody2D lieferten die Klassendokumentation sowie die Zuordnung KinematicBody2D -> CharacterBody2D. Qwen akzeptierte nur die Zuordnung, die Ziel‑API und Chunk exakt entsprechen, und klassifizierte sie als Godot 4.
  • PackedScene, Node2D, Sprite2D, TileSetAtlasSource usw. lieferten korrekte Klassendokumente, jedoch ohne Nachweis einer Versions‑Exklusivität, sodass sie als Begründungs‑Mangel markiert blieben.
  • Die Einstellung run/main_scene stimmte exakt mit dem Dokument Setting the main scene und dem SQLite‑Original überein. Da die natürliche Sprachbeschreibung die Einstellung nicht wörtlich wiederholte, wurde sie im ersten Durchlauf abgelehnt; nach Ergänzung der Regel, dass strukturierte Schlüssel‑Wert‑Paare als Beleg gelten, wurde sie akzeptiert.
  • doc_version bzw. godot_version_tags sind lediglich Metadaten der Dokumentensammlung und beweisen nicht automatisch eine Versions‑Exklusivität. Die Regel wurde angepasst, sodass nur ein direkter Unterschied in der JSONL‑Beschreibung einer Hauptversions‑Differenz zur Festlegung führt.

Datenlücken, die durch den vollständigen SQLite‑Abgleich aufgedeckt wurden

Folgende Ausdrücke wurden im GUI‑Top‑Kandidaten‑Set nicht gefunden, obwohl sie in den SQLite‑Tabellen docs_chunks, api_mapping und label_prototypes als raw_json existieren. Alle entsprechenden Datensätze hatten einen Wert von 0.

  • scene resource header
  • script external resource declaration
  • project format version setting
  • untyped declaration warning setting
  • window stretch aspect setting
  • default clear color setting

Diese Fälle zeigen, dass korrekte JSONL‑Einträge in SQLite vorhanden sind, aber die aktuelle Sammlung keine direkten Belege liefert; daher gibt der Validator Keine Relevanz zurück, ohne willkürlich zu Godot 3 oder Godot 4 zu wechseln.

Die Regel‑Anpassungen wurden in den Commits d504f50 und 2222634 implementiert und bestanden alle 33 Source‑Flow‑Debugger‑Tests. Es wurden keine festen Listen von Code‑Syntax, API‑Namen oder Einstellungsschlüsseln in die Regeln aufgenommen.

Ergebnisse