Der Prompt ist kein Ziel der AST‑Syntaxanalyse, sondern wird getrennt nach Analyse‑Intention und Retriever/LLM‑Bewertungsrichtung behandelt
Der AST‑Parser erhält Quellcode, Dateipfad, Dateityp und Original‑Hash als Quell‑Metadaten
Der Retriever soll nicht nach Dateipfaden, sondern nach aus Code‑Ausschnitten extrahierten APIs, Symbolen, Identifiern und Prompt‑Intentionen suchen und die Vektor‑DB abfragen
Das heute erstellte Dokument muss morgen erneut überprüft werden. Insbesondere muss geprüft werden, ob die Grenzen zwischen AST‑Chunks, Direct‑Chunks, Retriever‑Query und Trace‑Metadaten im Dokument konsistent bleiben
In der Godot‑Quellcode‑Analyse‑Pipeline wurden die Rollen von docs_chunks, api_mapping und label_prototypes erneut zusammengefasst
docs_chunks wird im Datenfluss zur Erstellung von Code‑Erklärungen verwendet. Auf Basis von AST‑/Code‑Fragments und Prompt werden offizielle Dokumentations‑Chunks durchsucht, irrelevante Belege verworfen und anschließend ein Erklär‑JSONL erzeugt.
api_mapping ist das Ziel, in dem gespeichert wird, wie Funktions‑, Klassen‑ und Symbolnamen von Godot 3 zu Godot 4 geändert wurden.
label_prototypes ist das Ziel, das Umwandlungsmuster speichert, wenn nicht nur der Name, sondern die gesamte Funktionsweise, Parameterstruktur und Aufrufmuster einer Funktion geändert wurden.
Das Projekt auf GitHub bzw. das lokale Dateisystem wird auf AST‑/Code‑Fragment‑Ebene analysiert, danach wird der benötigte Retriever aufgerufen und Qwen 3.6 on‑demand gestartet – die Struktur wurde dokumentiert
Offizielle Dokumentations‑Markdowns werden je nach Inhaltstyp in docs_chunks (Erklärungstext), api_mapping (Namens‑/Symbol‑Änderungen) oder label_prototypes (Änderungen in Nutzung/Aufrufmuster) eingeteilt und als JSONL gespeichert.
Die Retriever‑Suchergebnisse, LLM‑Validierungsergebnisse und Validator‑Durchläufe werden als JSONL/Score‑DB‑Fluss gespeichert.
Spalten, Aggregationsmethoden und Klassifikations‑Labels der Score‑DB sind noch nicht festgelegt; derzeit dient sie nur als Zwischenspeicher für Ergebnisse vor der Dateisystem‑Klassifizierung.
Auf Basis des klassifizierten Dateisystems soll später Quellcode für SFT und DPO entworfen werden.
Während der Dokumentation der LLM‑Klassifizierung stellte sich heraus, dass das LLM nur die ersten 3000 Zeichen des gesamten Markdown‑Texts übermittelte, obwohl die Anforderung die komplette Übermittlung vorsah – dies wurde korrigiert.
Dieser Vorgang bestätigte erneut, dass Dokumentation nicht nur eine einfache Aufzeichnung, sondern ein Prozess zur Verifizierung des tatsächlichen Code‑Verhaltens ist.
Beim Markdown → JSONL‑Konvertieren stoppte der RunPod‑Server unerwartet; nach Neustart der Streamlit‑App wurde beobachtet, dass der vorherige Fortschritt nicht zurückgesetzt, sondern fortgesetzt wurde.
Nach dem Neustart der App wurden noch nicht verarbeitete Dateien auf pending zurückgesetzt; ein erneuter Start nutzte die bestehenden Klassifizierungsergebnisse und setzte die Verarbeitung ab derselben Datei fort.
Für langwierige Konvertierungsaufgaben ist ein Frühwarn‑Alarm nötig, der über das bevorstehende Herunterfahren bzw. Nicht‑Erreichen einer Antwort des RunPod‑Servers informiert.
Der Prozess des Markdown → JSONL‑Konverters und der Vorbereitung zum Einspielen in die lokale DB wurde im Rückblick festgehalten
Statt das offizielle Markdown direkt in die DB zu laden, wird es zuerst in ein JSONL‑Zwischenergebnis konvertiert, um Vorschau und Validierung zu ermöglichen.
Die Konvertierung teilt die Ergebnisse in docs_chunks, api_mapping und label_prototypes auf und strukturiert sie so, dass sie leicht in die lokale PostgreSQL importiert werden können.
Der Grund, warum das Repository zunächst öffentlich und dann wieder privat gestellt wurde, sowie die Überlegungen zur Veröffentlichung, wurden im Rückblick zusammengefasst
Aufgrund von Unsicherheit über das eigene Können war eine öffentliche Veröffentlichung belastend, aber das Teilen von Aufzeichnungen kann anderen als Sprungbrett dienen und das eigene Wachstum beschleunigen.
Es wurde auch ein Plan dokumentiert, einen lokalen LLM‑Endpoint in einer Oracle‑Cloud‑Umgebung mit 24 GB VRAM zu betreiben, um GitHub‑Workflows/PR‑Reviews zu automatisieren.
Wegen Verlust des Oracle‑Cloud‑Accounts und des umständlichen RunPod‑Setups wird die LLM‑basierte PR‑Review‑Automatisierung vorerst verschoben.
Die verbleibende Aufgabe für heute ist, etwa 1 500 offizielle Markdown‑Dateien in JSONL zu konvertieren und in die lokale DB zu laden
Das Konvertieren einer Datei dauert länger als erwartet, sodass noch unklar ist, ob alle 1 500 heute fertig werden.
Nach aktuellem Log‑Stand wurden in etwa 1 Stunde 9 Minuten done 39 Dateien + deferred 4 Dateien, also insgesamt 43 Dateien verarbeitet.
Die durchschnittliche Geschwindigkeit liegt bei ca. 1,6 Minuten pro Datei; für die gesamten 1 570 Dateien wird rechnerisch etwa 42 Stunden benötigt.
Für morgen und übermorgen ist wenig Zeit zu erwarten; daher wird der weitere Validierungsplan festgehalten
Bereits erzeugte JSONL‑Dateien werden in die lokale PostgreSQL importiert und geprüft, ob sie durchsuchbar sind.