Conversion de la documentation officielle en JSONL avec le Markdown → JSONL Converter : 1 422 fichiers sur 1 550 ont été traités.
Exécution continue du Qwen Validation Debugger du test 46 au test 50, vérification du code généré, de la compatibilité Godot 3/4 et des résultats de validation JSONL.
Le journal de débogage du test 50 montre que la validation du code commun et du JSONL est terminée ; le chargement dynamique des ressources de scène 48 échoue parce que le modèle crée un chemin de ressource fixe inexistant, rejeté par le moteur.
Lors des nouvelles tentatives, le diagnostic du moteur précédent est transmis et le débogueur a été amélioré pour choisir un seed stable différent à chaque ronde, sans enregistrer manuellement la syntaxe ou les réponses.
Le JSONL actuel du collecteur 8501 est chargé dans outputs/godot-rag-sqlite/godot-rag.sqlite3, puis comparé aux 1 570 URL d’origine, domaines et SHA‑256 contenus dans pages.zip.
Création dans SQLite des tables docs_chunks, api_mapping, label_prototypes, ainsi que du provenance des documents et d’un index de recherche FTS5, permettant de générer un instantané avec le même builder avant la fin de la collecte.
Après comparaison du dump SQLite et du vecteur‑DB, le format de dépôt Git conserve les enregistrements d’origine et le provenance, et un SQLite autonome est choisi pour la re‑génération et le partage sans serveur supplémentaire.
Initialement, SQLite n’était ajouté au dépôt que comme artefact de production, tandis que la stratégie F du Source Flow Debugger continuait d’utiliser PostgreSQL, créant un problème de cohérence entre les deux bases.
Pour éliminer la double gestion, la donnée de référence et le dépôt d’exécution de la stratégie F ont été unifiés dans un seul SQLite, et les paramètres de connexion et les chemins de migration PostgreSQL ont été supprimés.
Les candidats BM25 sont maintenant lus depuis FTS5 SQLite, puis calculés avec Okapi BM25 côté Node ; les embeddings sont stockés dans record_embeddings du même SQLite avec le modèle, la dimension, le SHA‑256 du contenu et le vecteur Float32, afin de ne ré‑indexer que les enregistrements modifiés.
Le Source Flow Debugger consulte directement la révision, le nombre d’enregistrements et le nombre d’embeddings du SQLite commité, et les vecteurs stockés sont recherchés via cosine similarity côté Node.
Le dump du vecteur‑DB 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 ; il peut être regénéré à la demande à partir du même SQLite comme index dérivé.