idea_world_labDEV JOURNAL
Donnerstag, 25. Juni 2026

Godot-Quellcode-Analyse‑Bewertungsarchitektur

Erstellungsdatum: 25. Juni 2026

Zweck

Mit dem offiziellen Godot‑Dokumentations‑RAG werden GitHub‑Quellcodes projektweise klassifiziert und anschließend der Ablauf zur Erstellung von SFT/DPO‑Daten strukturiert.

Der Kern dieses Überblicks besteht darin, docs_chunks, api_mapping und label_prototypes alle als Ziel für die Klassifizierung von offiziellen Dokumentations‑Markdown → JSONL zu behandeln. Je nach Dokumenttyp werden Erklärung‑Chunks zu docs_chunks, Änderungen von Funktions‑/Klassen‑/Symbolnamen zu api_mapping und Änderungen in der Funktionsnutzung/Parameter‑Zusammensetzung/Aufrufmustern zu label_prototypes gesendet.

Aktuelle Schlussfolgerung

In der anfänglichen Phase der Dokumentationssammlung sind die folgenden drei Kern‑Tabellen vorzubereiten.

Tabelle Rolle
docs_chunks Ziel für das Speichern von Erklärungs‑Texten, Tutorials und Class‑Reference‑Chunks aus der offiziellen Dokumentation
api_mapping Ziel für die Speicherung, wie Funktions‑, Klassen‑ und Symbolnamen von Godot 3 zu Godot 4 geändert wurden
label_prototypes Ziel für die Speicherung, wie man vorgehen muss, wenn sich die Funktionsnutzung, Parameter‑Zusammensetzung oder Aufrufmuster komplett ändern
Punkt Zusammenfassung
Vorherige Verwirrung Zunächst dachte man, die drei Tabellen würden unterschiedliche Arbeitsabläufe repräsentieren.
Neue Grenze Alle drei Tabellen dienen als Speicherziele, wenn offizielle Dokumentations‑Markdown in JSONL klassifiziert wird.
Aktuelle Priorität Wie ursprünglich geplant die drei Tabellen beibehalten und je nach Dokumenttyp in ein oder mehrere JSONL‑Dateien klassifizieren und speichern.

Endgültige Analyseeinheit

Eingabe ist ein GitHub‑Projekt oder ein lokales Projekt‑Verzeichnis.

Der Analysator durchforstet das Dateisystem und zerlegt Godot‑bezogene Dateien in AST‑ oder Code‑Snippet‑Einheiten.

Erste Ziel‑Dateien:

Datei Zweck
.gd Analyse von GDScript‑AST/Zeilen/Funktions‑Einheiten
.tscn, .tres Extraktion von Hinweisen zu Klassen, Skripten und Node‑Typen aus Szenen/Resourcen
project.godot Extraktion von Projekt‑Hinweisen wie Version, Features, Renderer, Autoload usw.
README/Dokumentation Unterstützung bei Projektbeschreibung und Godot‑Versions‑Hinweisen

On‑Demand‑LLM‑Aufruf‑Ablauf

Das LLM wird nicht dauerhaft laufen gelassen, sondern bei Bedarf on‑demand für jedes benötigte AST‑/Code‑Snippet aufgerufen.

Jedes AST‑Snippet wird zusammen mit den folgenden Begründungen an das LLM übermittelt.

AST/code chunk
+ Erforderliche offizielle Dokumentations-JSONL-Suchergebnisse
+ Ausgabe-JSONL-Schema
+ Projekt-/Datei-Identifikationsinformationen

LLM‑Antwort‑Schema und score‑DB‑Speicherspalten sind noch nicht festgelegt. In diesem Dokument wird nur festgehalten, welche Tabelle in welchem Ablauf gesucht wird und wie das Ergebnis zur Dateisystem‑Klassifizierung verwendet wird.

Code‑Erklärung‑Erzeugungs‑Datenfluss

Code‑Erklärung‑Erzeugungs‑Datenfluss

Bei der Code‑Erklärung ist docs_chunks die zentrale Referenz.

Ablauf:

  1. Der Benutzer gibt „Was bedeutet das?“ und Quellcode ein.
  2. Der AST‑Parser zerlegt den Code in Stücke.
  3. Der Retriever sucht in docs_chunks nach relevanten offiziellen Dokumenten.
  4. Qwen 3.6 prüft, ob Prompt, Quellcode‑Stück und gefundene Referenz zusammenpassen.
  5. Nicht relevante Suchergebnisse werden verworfen.
  6. Relevante Referenzen und Code‑Stücke werden erneut an Qwen 3.6 übergeben, um ein Erklärungs‑JSONL zu erzeugen.
  7. Der Validator prüft die Antwort.
  8. Das validierte Ergebnis wird in der score‑DB gespeichert.
  9. Auf Basis der score‑DB‑Ergebnisse wird das Dateisystem klassifiziert.

Godot 3 → Godot 4 Funktionsnamen‑Umwandlungs‑Ablauf

Godot 3‑zu‑Godot 4 Funktionsnamen‑Umwandlungs‑Ablauf

Bei der Migration ist api_mapping die zentrale Referenz.

Ablauf:

  1. Der Benutzer gibt „Muss das umgewandelt werden?“ und Quellcode ein.
  2. Der AST‑Parser extrahiert mögliche Godot‑API‑Symbole.
  3. Der Retriever sucht in api_mapping nach Quell‑API, Ziel‑API und Änderungstyp.
  4. Qwen 3.6 prüft, ob das Suchergebnis tatsächlich mit dem Code‑Stück zusammenhängt.
  5. Nicht relevante Mappings werden verworfen.
  6. Nur relevante Mappings werden verwendet, um ein Godot 3 → 4 Migrations‑JSONL zu erzeugen.
  7. Der Validator prüft die Umwandlungs‑Antwort.
  8. Das validierte Ergebnis wird in der score‑DB gespeichert.
  9. Auf Basis der score‑DB‑Ergebnisse wird das Dateisystem klassifiziert.

Godot 3 → Godot 4 Nutzungsmuster‑Umwandlungs‑Ablauf

Godot 3‑zu‑Godot 4 Nutzungsmuster‑Umwandlungs‑Ablauf

Bei der Nutzungsmuster‑Umwandlung ist label_prototypes die zentrale Referenz.

Ablauf:

  1. Der Benutzer gibt „Muss das umgewandelt werden?“ und Quellcode ein.
  2. Der AST‑Parser extrahiert Funktionsaufrufe, Parameter‑Zusammensetzungen und mögliche Aufrufmuster.
  3. Der Retriever sucht in label_prototypes nach Referenzen für Nutzung/Parameter/Aufrufmuster‑Umwandlungen.
  4. Qwen 3.6 prüft, ob das Suchergebnis tatsächlich mit dem Code‑Stück zusammenhängt.
  5. Nicht relevante Prototypen werden verworfen.
  6. Nur relevante Prototypen werden verwendet, um ein Godot 3 → 4 Nutzungsmuster‑Umwandlungs‑JSONL zu erzeugen.
  7. Der Validator prüft die Umwandlungs‑Antwort.
  8. Das validierte Ergebnis wird in der score‑DB gespeichert.
  9. Auf Basis der score‑DB‑Ergebnisse wird das Dateisystem klassifiziert.

Score‑DB

Retriever‑Suchergebnisse pro AST‑Stück, LLM‑Validierungsergebnisse und Validator‑Bestätigungen werden letztlich in der score‑DB gespeichert.

Die score‑DB ist kein Trainings‑Datensatz, sondern ein Speicher für die Entscheidungs‑Ergebnisse zur Dateisystem‑Klassifizierung. Sie protokolliert die Ergebnisse von Retriever, LLM und Validator, die im Quellcode‑Analyse‑Prozess entstanden sind.

  • docs_chunks‑Suchergebnis: Ergebnis der Prüfung, ob die offizielle Dokumentations‑Referenz bei einer Code‑Erklärungs‑Anfrage tatsächlich zum Code passt.
  • api_mapping‑Suchergebnis: Ergebnis der Prüfung, ob die Funktions‑/Symbol‑Umwandlungs‑Referenz von Godot 3 → 4 tatsächlich zum Code passt.
  • label_prototypes‑Suchergebnis: Ergebnis der Prüfung, ob die Referenz für Funktions‑Nutzungs‑weise, Parameter‑Zusammensetzung und Aufruf‑Muster‑Umwandlung tatsächlich zum Code passt.

Spalten, Aggregations‑Methoden und Klassifizierungs‑Labels der score‑DB sind noch nicht definiert. Dieses Dokument legt nur fest, dass die score‑DB als „Speicher für Vor‑Klassifizierungs‑Entscheidungen“ dient.

Endgültige Dateisystem‑Klassifizierung:

project source
  -> AST/code chunks
  -> official docs JSONL retrieval
  -> on-demand LLM verification
  -> score DB
  -> classified filesystem

SFT und DPO Erstellung

Die detaillierte Ausgestaltung von SFT und DPO ist noch nicht festgelegt. Was bereits feststeht, ist, dass die Score‑DB selbst keine Lern‑Datenquelle ist. Zunächst wird das Dateisystem klassifiziert, und anschließend soll die klassifizierte Dateisystem‑Basis als Quelle für die Planung von SFT und DPO dienen.

Git Upload Sicherheitsrichtlinien

In dieser Dokumentation werden die Web‑UI, lokale Transformations‑Skripte, AST‑Analyse‑Skripte, API‑Schlüssel, JSONL‑Ausgaben und Test‑Quellcode nicht hochgeladen.

Erlaubt zum Hochladen:

  • Architekturdokumentation
  • Flussdiagramm‑Bilder
  • Rückblick‑/Roadmap‑Texte, die öffentlich gemacht werden dürfen

Verboten zum Hochladen:

  • Streamlit‑Web‑App‑Code
  • Markdown → JSONL‑Konvertierungs‑Experiment‑Skript
  • Retriever/AST‑Analyse‑Experiment‑Skript
  • API‑Schlüssel, Endpunkt, .env
  • Gesamtes gesammeltes Markdown‑Original‑ZIP
  • AST/Code‑Chunk‑Analyse‑Ergebnisse
  • Zwischen‑JSONL‑Ausgaben
  • Für Tests geklonte externe Godot‑Projekt‑Quellcodes