Das am 27. zuerst erstellte Dokument enthielt viele Objekt‑ und Strukturbeschreibungen, sodass das eigentliche Eingabeverhalten schwer nachzuvollziehen war
Anschließend wurde die Dokumentationsrichtung anhand von PR‑Feedback neu ausgerichtet
Die Form wurde geändert, sodass in den ausgeklappten Eingaben # <relative Pfad> konkret angegeben wird, welche Zeile welcher Datei in den AST‑Parser gelangt
Wie bei player.gd E020‑E034 wird anhand tatsächlicher Zeilenbereiche beschrieben, wie ein Teil des Textes in die Retriever‑Suche und die LLM‑Entscheidung übergeht
Dateipfade dienen nur der Nachverfolgung; für die Retriever‑Suche wird ausschließlich das chunkText des Code‑/Textabschnitts verwendet – diese Regel wurde erneut fixiert
docs_chunks, api_mapping, label_prototypes werden ohne Sonderbehandlung auf dieselbe Weise durchsucht, wobei die LLM die gefundenen Kandidaten erneut verifiziert
Die heutige Arbeit hatte das Ziel, vor der eigentlichen Implementierung festzulegen, wie Eingaben und Ausgaben an welchen Stellen verbunden werden, um zu verhindern, dass die KI willkürlich Bereiche ändert oder nur abstrakte Strukturbeschreibungen liefert
Um den dokumentierten Flow zu prüfen, wurde das Web‑Tool Source Flow Debugger implementiert
Lokal unter http://127.0.0.1:8010/ gestartet, um die Godot‑Projekteingaben direkt zu inspizieren
Die mit # <relative Pfad> ausgeklappten Projekteingaben werden dateiweise wieder aufgeteilt; .gd wird zu AST‑Chunks, .godot und .tscn zu Direct‑Chunks
Ein kleines Godot‑Projekt wurde getestet und in 5 files, 14 chunks, AST 9, Direct 5 zerlegt
Dokumente wie README.md werden im source‑analysis‑Modus ausgeschlossen und der Ausschluss sowie dessen Grund bleiben sichtbar
UI zum Debuggen pro Chunk hinzugefügt
Unter jedem Chunk wurden Buttons für docs_chunks Suche, api_mapping Suche, label_prototypes Suche und Validate JSONL platziert
Statt einer globalen Tabellen‑Checkbox erfolgt die Suche jeweils direkt unter dem jeweiligen Chunk
Der Retriever‑Input zeigt nur { "chunkText": "…" } an, ohne Dateipfad, Zeilennummer oder Prompt
Die Qwen‑Validierung wird ausschließlich im Schritt prompt + chunkText + retrieved JSONL verwendet
Probleme, die beim praktischen Einsatz des Web‑Debuggers auftraten, wurden behoben
Das automatische Laden von Beispiel‑Godot‑Code beim Seiten‑Load wurde entfernt
Auch nach erneutem Hochladen derselben Datei/Ordners wird das Browser‑change‑Event erneut ausgelöst, indem der Upload‑Input‑Wert beim Klick geleert wird
Um veraltetes JS während der Entwicklung zu vermeiden, wurde cache-control: no-store zu den statischen Dateiresponsen hinzugefügt
Beim PostgreSQL‑Suchpfad wird ein möglicher Fehler beim Erzeugen/Verbinden des Clients durch ein geschütztes client.end() abgefangen, sodass das Aufräumen sicher abläuft
Das Ergebnis der Implementierung wurde mit Screenshots in einem separaten Dokument festgehalten
Nach aktuellem Stand ist die Chunk‑weise Zerlegung weitgehend erfolgreich; das nächste Kernziel ist, wie die DB‑Suche tatsächlich durchgeführt wird
Es muss geprüft werden, welche JSONL‑Kandidaten aus docs_chunks, api_mapping, label_prototypes allein anhand von chunkText zurückkommen
Außerdem muss entschieden werden, wie die Qwen‑Validierung beurteilt, ob das gefundene JSONL zum aktuellen Chunk passt und ob es verworfen wird
Vor der DB‑Integration wurden Demo‑Godot‑Chunks und zugehörige/irrelevante JSONL mit GPT erzeugt, um Prompt‑Matching‑Experimente durchzuführen
Zunächst fragte man: „Enthält dieses JSONL Code‑Inhalte? Bitte nur Ja/Nein antworten.“ – sowohl relevante als auch irrelevante JSONL wurden mit „Ja“ beantwortet
Danach wurde die Regel eingeführt, dass einer der Felder source_api, source_pattern, match_terms, required_when_seen_in_code oder before_code exakt mit dem tatsächlichen SOURCE_CODE‑String/API‑Aufruf übereinstimmen muss, um „Ja“ zu erhalten
Statt breiter Wortähnlichkeiten oder Vorwissen der LLM über Godot zu nutzen, soll ausschließlich der im JSONL angegebene String als Beleg herangezogen werden: relevante JSONL → „Ja“, irrelevante → „Nein“
Dieses Experiment zeigte, dass die Qwen‑Validierung nach der DB‑Suche nicht auf einer vagen semantischen Ähnlichkeit, sondern darauf basieren muss, ob das gefundene JSONL einen direkten String‑Beleg für den aktuellen Chunk enthält
Morgen sollen mehrere Demo‑Sets von Godot‑Chunks mit zugehörigen/irrelevanten JSONL erstellt werden, um wiederholt zu testen, welche Belege Qwen zu „Ja“ bzw. „Nein“ führen
