Le document du 27 initialement rédigé contenait beaucoup de descriptions d’objets et de structures, ce qui rendait difficile le suivi du flux réel des entrées
J’ai ensuite réorienté le document en fonction des retours du PR
J’ai modifié la forme pour indiquer précisément, dans les entrées développées avec # <chemin relatif>, quel fichier et quelle ligne sont transmis au parseur AST
En me basant sur des plages de lignes réelles, comme E020‑E034 dans player.gd, j’ai structuré le flux où une partie du texte passe à la recherche Retriever puis au jugement LLM
Les chemins de fichiers servent uniquement au suivi ; la recherche Retriever ne reçoit que le chunkText du code/texte concerné, critère que j’ai réaffirmé
docs_chunks, api_mapping et label_prototypes sont recherchés de la même manière, sans traitement spécial, et les candidats de recherche sont ensuite vérifiés par le LLM
Le travail d’aujourd’hui visait à fixer, avant toute implémentation, la description du flux afin d’éviter que l’IA ne modifie les plages ou ne se perde dans des explications abstraites : il s’agissait de documenter comment l’entrée et la sortie se relient à chaque point
Pour valider le flux décrit, j’ai implémenté l’outil web Source Flow Debugger
Il s’exécute localement à http://127.0.0.1:8010/ et permet de visualiser directement l’entrée du projet Godot
L’entrée du projet, développée avec # <chemin relatif>, est re‑segmentée par fichier : les fichiers .gd deviennent des chunks de type AST, tandis que .godot et .tscn sont découpés en chunks directs
En testant avec un petit projet Godot, j’ai observé la décomposition en 5 fichiers, 14 chunks, AST 9, Direct 5
Les fichiers de documentation comme README.md sont exclus du mode d’analyse source, et leur exclusion ainsi que la raison apparaissent à l’écran
Ajout d’une interface de débogage par chunk
Sous chaque chunk, j’ai placé les boutons Recherche docs_chunks, Recherche api_mapping, Recherche label_prototypes, Validate JSONL
Au lieu d’une case à cocher globale, chaque recherche s’effectue directement sous le chunk concerné
L’entrée du Retriever n’affiche que { "chunkText": "..." }, en excluant le chemin du fichier, le numéro de ligne et le prompt
La validation Qwen est réservée à l’étape prompt + chunkText + retrieved JSONL
En testant réellement le débogueur web, j’ai corrigé les problèmes suivants
Suppression du chargement automatique d’un exemple de code Godot au démarrage de la page
Vidage de la valeur de l’input d’upload au moment du clic afin que l’événement change se déclenche de nouveau même après un re‑upload du même fichier/dossier
Ajout de l’en‑tête cache-control: no-store aux réponses de fichiers statiques pour éviter que d’anciens scripts JS restent en cache
Protection de l’appel client.end() afin que le nettoyage s’exécute en toute sécurité même si la création/connexion du client PostgreSQL échoue
J’ai consigné le résultat de l’implémentation dans un document séparé avec captures d’écran
À ce stade, la décomposition par chunk est considérée comme suffisamment réussie ; l’étape suivante sera de déterminer comment exécuter réellement la recherche en base de données
Il faut vérifier, à partir du seul chunkText, quels candidats JSONL sont renvoyés par docs_chunks, api_mapping et label_prototypes
Il faut aussi définir, lors de la validation Qwen, comment juger la pertinence du JSONL par rapport au chunk actuel et décider de le conserver ou de le rejeter
Avant d’ajouter la recherche DB, j’ai expérimenté avec GPT pour créer des JSONL pertinents ou non pertinents liés à un chunk Godot de démonstration, afin de tester les prompts de correspondance
Au départ, la question « Ce JSONL contient‑il le code source correspondant ? Répondez uniquement oui ou non » produisait « oui » tant pour les JSONL pertinents que pour les non pertinents
J’ai ensuite limité la réponse à « oui » uniquement si l’un des champs source_api, source_pattern, match_terms, required_when_seen_in_code ou before_code correspondait exactement à la chaîne SOURCE_CODE ou à l’appel d’API réel
En évitant les jugements basés sur la similarité sémantique large ou les connaissances pré‑existantes de LLM sur Godot, et en ne regardant que les preuves textuelles présentes dans le JSONL, les JSONL pertinents donnent « oui », les non pertinents « non »
Cette expérience a montré que l’étape de validation Qwen après la recherche DB doit d’abord vérifier : « Le JSONL trouvé contient‑il une preuve textuelle qui correspond directement au chunk actuel ? », plutôt que de se baser sur une similarité de sens « plausible »
Demain, je prévois de créer plusieurs ensembles de démonstration de chunks Godot avec leurs JSONL pertinents et non pertinents, afin de tester de façon répétée quels arguments Qwen utilise pour produire « oui » ou « non ».
