Mit dem Markdown → JSONL‑Konverter wurden 1 422 von 1 550 offiziellen Dokumenten in JSONL konvertiert.
Die Schritte 46‑50 des Qwen Validation Debugger wurden fortgesetzt und erzeugter Code, Godot 3/4‑Engine‑Prüfungen sowie JSONL‑Validierungsergebnisse wurden überprüft.
Das Debug‑Log für Schritt 50 enthält den Abschluss des gemeinsamen Codes und der JSONL‑Validierung; bei Schritt 48 scheitert das dynamische Laden von Szenen‑Ressourcen, weil ein fester Pfad ohne vorhandenes Modell erzeugt wird und die Engine‑Prüfung ihn ablehnt.
Beim erneuten Versuch wird die vorherige Engine‑Diagnose übergeben, und der Debugger verwendet für jede Generierungsrunde einen stabilen Seed, ohne dass Syntax oder Antworten manuell registriert werden.
Der aktuelle JSONL‑Datensatz des Collectors 8501 wird nach outputs/godot-rag-sqlite/godot-rag.sqlite3 geladen und die 1 570 Original‑URLs, Domains und SHA‑256‑Hashes aus pages.zip werden abgeglichen.
In SQLite werden docs_chunks, api_mapping, label_prototypes, die Provenienz der Originaldokumente und ein FTS5‑Such‑Index eingerichtet, sodass vor Abschluss der Gesamtsammlung Snapshots mit demselben Builder erstellt werden können.
Der gesammelte JSONL‑Datensatz wird in ein Git‑kompatibles Format überführt; SQLite‑ und Vektor‑DB‑Dumps werden verglichen, wobei die Original‑Records und Provenienz unverändert bleiben und ein re‑erzeugbarer, teil‑serverloser SQLite‑Dump gewählt wird.
Anfangs wurde SQLite nur als Artefakt für Git‑Uploads hinzugefügt, während die F‑Strategie des Source‑Flow‑Debuggers weiterhin PostgreSQL nutzte; das führte zu Inkonsistenzen, weil dieselben JSONL‑Daten separat in SQLite und PostgreSQL gespiegelt werden mussten.
Zur Vermeidung doppelter Verwaltung wird die F‑Strategie‑Basisdatenbank auf die commit‑basierte SQLite reduziert und PostgreSQL‑Verbindungs‑ und Migrations‑Konfigurationen entfernt.
BM25‑Kandidaten werden aus SQLite‑FTS5 gelesen, in Node mit Okapi‑BM25 berechnet; Embeddings werden zusammen mit Modell, Dimension, Record‑SHA‑256 und Float32‑Vektor in record_embeddings derselben SQLite gespeichert, sodass nur geänderte Records neu indiziert werden.
Der Source‑Flow‑Debugger prüft nun direkt die Revision, Record‑Anzahl und Embedding‑Anzahl der commit‑basierten SQLite, und die gespeicherten Vektoren werden in Node mittels Cosine‑Similarity durchsucht.
Vektor‑DB‑Dumps werden nicht als eigenständige Referenzdaten behandelt, da sie vom Embedding‑Modell, den Dimensionen und der Index‑Implementierung abhängen; bei Bedarf werden sie als abgeleitete Indizes im selben SQLite neu erzeugt.