Avec le convertisseur Markdown → JSONL, la collecte de la documentation officielle a progressé de 1 550 à 1 422 fichiers JSONL
Continué l’exécution du Qwen Validation Debugger du test 46 au test 50, puis vérifié le code généré, les inspections du moteur Godot 3/4 et les résultats de validation JSONL
Les éléments du journal de débogage 50 ont finalisé le code commun et la validation JSONL ; le chargement dynamique des ressources de scène 48 a échoué parce que le modèle a créé un chemin de ressource fixe inexistant, rejeté par le moteur
En cas de nouvelle tentative, le diagnostic moteur précédent est transmis et le débogueur a été amélioré pour utiliser un seed stable différent à chaque ronde sans enregistrer manuellement la syntaxe ou les réponses par item
Chargé le JSONL actuel du collecteur 8501 dans outputs/godot-rag-sqlite/godot-rag.sqlite3 et comparé les 1 570 URL, domaines et SHA‑256 originaux avec les sources des enregistrements
Configuré dans SQLite les tables docs_chunks, api_mapping, label_prototypes, la provenance des originaux et l’index de recherche FTS5, tout en permettant de recréer un instantané avec le même builder avant la fin de la collecte complète
Après comparaison du dump SQLite et de la base vectorielle avec le JSONL destiné à Git, choisi SQLite comme format conservant la provenance des enregistrements originaux et pouvant être regénéré et partagé sans serveur dédié
Au départ, SQLite n’était ajouté à Git qu’en tant que livrable de référence, tandis que la stratégie F du Source Flow Debugger continuait à pointer vers PostgreSQL, créant une incohérence où le même JSONL devait être reflété séparément dans SQLite et PostgreSQL
Pour éliminer la double gestion, les données de référence et le dépôt d’exécution de la stratégie F ont été unifiés dans le SQLite commitée, et les paramètres de connexion et chemins de migration PostgreSQL ont été retirés
Les candidats BM25 sont lus depuis SQLite FTS5, puis calculés en Node avec Okapi BM25 ; les embeddings sont stockés dans le même SQLite sous record_embeddings avec le modèle, la dimension, le SHA‑256 du contenu de l’enregistrement et le vecteur Float32, afin que seuls les enregistrements modifiés soient ré‑indexés
Le Source Flow Debugger vérifie directement la révision, le nombre d’enregistrements et le nombre d’embeddings du SQLite commitée, et les vecteurs stockés sont recherchés en Node via la similarité cosinus
Le dump de la base vectorielle dépend du modèle d’embedding, de la dimension et de l’implémentation de l’index, il n’est donc pas conservé comme donnée de référence séparée ; lorsqu’il est nécessaire, il est regénéré comme index dérivé dans le même SQLite