Le document du 27 initial était chargé 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 selon les retours du PR
J’ai modifié la forme pour indiquer, dans les entrées développées avec # <chemin relatif>, précisément quel fichier et quelle ligne sont transmis au parseur AST
Comme pour player.gd de E020 à E034, j’ai structuré le flux en fonction des plages de lignes réelles, montrant comment 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 façon, sans traitement spécial, et les candidats sont ensuite vérifiés par le LLM
Le travail d’aujourd’hui visait à fixer, avant toute implémentation, la documentation du point où l’entrée et la sortie se rejoignent, afin d’éviter que l’IA ne modifie les plages ou ne dérive vers des explications abstraites
Pour valider le flux documenté, 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 les entrées 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 type documentation comme le README.md sont exclus du mode d’analyse source, et leur exclusion ainsi que la raison correspondante restent affichées à l’écran
Ajout d’une interface de débogage par chunk
Sous chaque chunk, j’ai placé les boutons docs_chunks recherche, api_mapping recherche, label_prototypes recherche et Validate JSONL
Au lieu d’une case à cocher globale, chaque recherche s’effectue directement sous le chunk concerné
L’entrée du Retriever montre uniquement { "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 utilisant le débogueur web, j’ai corrigé les problèmes rencontrés
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 clic pour que l’événement change se déclenche à 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 afin d’éviter la persistance d’anciens scripts JS pendant le développement
Protection de l’appel client.end() pour 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 jugée suffisamment aboutie ; l’étape suivante sera de déterminer comment exécuter réellement les recherches 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 également 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 utilisé GPT pour créer des JSONL pertinents ou non pertinents associés à des chunks Godot de démonstration, afin d’expérimenter les prompts de correspondance
Au départ, le prompt « Ce JSONL contient‑il le contenu du code source ? Répondez uniquement oui ou non » renvoyait « 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 considérant 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 correspondant directement au chunk actuel ? », plutôt que de se baser sur une similarité de sens « plausible »
Demain, je créerai plusieurs jeux de démonstration de chunks Godot avec leurs JSONL pertinents ou non, afin de tester de façon répétée quels critères Qwen utilise pour produire « oui » ou « non »
