Das am 27. Tag zuerst erstellte Dokument enthielt viele Objekt‑ und Strukturbeschreibungen, sodass das eigentliche Eingabeverfahren schwer nachzuvollziehen war
Anschließend wurde die Dokumentenrichtung anhand von PR‑Feedback neu ausgerichtet
Die Form wurde geändert, sodass in den mit # <relativer Pfad> aufgeklappten Eingaben konkret angegeben wird, welche Datei und welche Zeile in den AST‑Parser gelangt
Wie bei player.gd von E020‑E034 wird anhand tatsächlicher Zeilenbereiche beschrieben, welcher Teil des Textes über die Retriever‑Suche und die LLM‑Bewertung weiterverarbeitet wird
Dateipfade dienen nur der Nachverfolgung; für die Retriever‑Suche wird ausschließlich das chunkText des Code‑/Text‑Ausschnitts verwendet – diese Regel wurde erneut fixiert
docs_chunks, api_mapping und label_prototypes werden ohne Sonderbehandlung auf dieselbe Weise durchsucht, wobei die LLM die Suchergebnisse erneut verifiziert
Die heutige Arbeit hatte das Ziel, vor der eigentlichen Implementierung festzulegen, wie Eingaben und Ausgaben an welchen Stellen miteinander verknüpft werden, damit die KI nicht willkürlich Bereiche ändert oder 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/ ausführen, um die Godot‑Projekteingaben direkt zu inspizieren
Die mit # <relativer Pfad> aufgeklappten Projekteingaben werden dateiweise wieder aufgeteilt; .gd wird zu AST‑Chunks, .godot und .tscn zu Direct‑Chunks
Ein kleines Godot‑Projekt liefert 5 Dateien, 14 Chunks, AST 9, Direct 5
Dokumentdateien wie README.md werden im source‑analysis‑Modus ausgeschlossen und der Ausschluss samt Grund wird angezeigt
UI für Chunk‑Debugging hinzugefügt
Unter jedem Chunk wurden die Buttons 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
Beim erneuten Hochladen derselben Datei/Ordners wird das change‑Event des Browsers 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 Datei‑Responses 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 und label_prototypes allein anhand von chunkText zurückkommen
In der Qwen‑Validierungsphase muss entschieden werden, ob das gefundene JSONL zum aktuellen Chunk passt und ggf. verworfen wird
Vor der DB‑Suche wurden mit GPT Demo‑Godot‑Chunks und zugehörige bzw. nicht zugehörige JSONL erzeugt, um Prompt‑Matching‑Experimente durchzuführen
Zunächst fragte man: „Enthält dieses JSONL Code, ja/nein?“ – sowohl relevante als auch irrelevante JSONL wurden mit „ja“ beantwortet
Danach wurde eingeschränkt, 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
Durch die Beschränkung auf reine String‑Übereinstimmung im JSONL (keine weite Wortähnlichkeit oder Vorwissen des LLM) wurden relevante JSONL mit „ja“ und irrelevante mit „nein“ klassifiziert
Dieses Experiment zeigte, dass die Qwen‑Validierung nach der DB‑Suche nicht auf „plausible semantische Ähnlichkeit“, sondern darauf prüfen muss, ob das gefundene JSONL einen direkten String‑Bezug zum aktuellen Chunk enthält
Morgen sollen mehrere Demo‑Sets von Godot‑Chunks mit zugehörigen bzw. nicht zugehörigen JSONL erstellt werden, um wiederholt zu testen, welche Begründungen Qwen für „ja“ bzw. „nein“ liefert
