Enregistrement de la mise en œuvre du débogueur de flux source

Date de rédaction : 27 juin 2026

Objectif

Ce document est le compte‑rendu de la mise en œuvre et de la vérification du flux décrit dans docs/roadmaps/2026-06-27-source-to-ast-input-flow.md à l'aide du débogueur web réel.

Le point clé vérifié aujourd'hui est le suivant.

Entrée du projet Godot  
  -> Déplier les fichiers selon le chemin relatif  
  -> Identifier le type de fichier  
  -> Décomposer les .gd en fragments de code de type AST  
  -> Décomposer les ressources texte comme .godot, .tscn en chunks directs  
  -> Afficher uniquement le chunkText de chaque chunk comme entrée du Retriever  
  -> Fournir un bouton de recherche docs_chunks / api_mapping / label_prototypes sous le chunk  
  -> Connecter le JSONL recherché à une structure pouvant être joint à la requête de validation Qwen

Cette implémentation n’est pas un Retriever complet, mais un débogueur web permettant de suivre visuellement le flux entre le Retriever et l’entrée AST. Autrement dit, avant d’évaluer la qualité de recherche dans la base de données, il sert à vérifier quels fichiers sont découpés en quels fragments et quel texte est transmis comme entrée de recherche au Retriever.

Flux web implémenté

Le débogueur web a été exécuté à l’adresse http://127.0.0.1:8010/.

Les zones visibles à l’écran sont les suivantes :

• Zone de saisie du point de terminaison de la base de données
• Zone de saisie de validation Qwen
• Zone de saisie du prompt source
• Zone de saisie de la source développée
• Indicateurs de résumé des fichiers/segments
• Résultats d’inclusion/exclusion par fichier
• Texte original par segment, entrée du Retriever, bouton de recherche dans la base de données, aperçu de la requête Qwen

L’écran observé aujourd’hui est le suivant.

Vérification de l’entrée du projet Godot

Le test a été réalisé sous la forme d’un petit projet Godot.

Les fichiers d’entrée étaient les suivants.

minidodge/project.godot
minidodge/scripts/player.gd
minidodge/scripts/enemy.gd
minidodge/scenes/player.tscn
minidodge/README.md

Après le téléchargement, l'entrée interne se déploie sous la forme suivante.

# minidodge/project.godot
config_version=5

[application]
config/name="Mini Dodge Upload Test"
run/main_scene="res://scenes/player.tscn"

# minidodge/scripts/player.gd
extends Area2D

signal hit

@export var speed = 400
...

# <Chemin relatif> l’en-tête est destiné au suivi. Il n’est pas inclus dans le Retriever.

Résultats de l’analyse

Le résumé présenté par le débogueur web lors de ce test est le suivant.

Le jugement par fichier était le suivant.

Traitement des fichiers .gd

Les fichiers .gd sont traités par la logique du parseur AST.

Par exemple, player.gd a été divisé comme suit.

extends Area2D
signal hit
@export var speed = 400
var screen_size
func _ready():
func _process(delta):
func start(pos):

Le chunk réel inclut le corps de la fonction.

Par exemple, la fonction _process reste un seul chunk.

func _process(delta):
	var velocity = Vector2.ZERO
	if Input.is_action_pressed(&"move_right"):
		velocity.x += 1
	if Input.is_action_pressed(&"move_left"):
		velocity.x -= 1

	if velocity.length() > 0:
		velocity = velocity.normalized() * speed
		$AnimatedSprite2D.play()
	else:
		$AnimatedSprite2D.stop()

	position += velocity * delta
	position = position.clamp(Vector2.ZERO, screen_size)

Dans enemy.gd, nous avons constaté que le code pouvant être un indice pour Godot 3 est également séparé en chunks.

extends KinematicBody2D

func _physics_process(delta):
	velocity = move_and_slide(velocity)

traitement de chunk direct

project.godot n’est pas envoyé à l’AST Parser mais est découpé par sections de configuration.

Par exemple, le contenu suivant est un chunk direct.

[application]
config/name="Mini Dodge Upload Test"
run/main_scene="res://scenes/player.tscn"

Le fichier player.tscn n'est pas envoyé à l'AST Parser, mais est divisé par blocs de ressources.

Par exemple, le contenu suivant est un chunk direct.

[node name="Player" type="Area2D"]
script = ExtResource("1")

Ainsi, la raison de cette division est que les fichiers .tscn et .godot sont nécessaires pour déterminer un projet Godot, mais ils ne sont pas destinés à être analysés au niveau des fonctions AST comme les fonctions .gd.

Vérification de l'entrée du Retriever

À la date d'aujourd'hui, l'entrée du Retriever ne contient qu'un seul chunkText.

Par exemple, l'entrée du Retriever pour le chunk extends KinematicBody2D est la suivante.

{
  "chunkText": "extends KinematicBody2D"
}

Bouton de recherche DB par chunk

Au départ, il était possible de placer la sélection de table comme une option globale, mais en réalité, chaque chunk peut nécessiter une table différente pour la recherche.

Ainsi, le bouton a été placé sous chaque chunk.

Recherche docs_chunks  
Recherche api_mapping  
Recherche label_prototypes  
Valider JSONL

Le flux a été établi comme suit.

Texte de chunk actuel  
  -> Cliquez sur le bouton du tableau sous le chunk  
  -> Effectuer une recherche dans le tableau concerné  
  -> Afficher les candidats JSONL  
  -> Vérifier Qwen avec prompt + chunkText + JSONL récupéré

Ici, le prompt n’est pas une entrée Retriever. Le prompt n’est utilisé que lors de l’étape de validation de Qwen.

Ce qui a été vérifié aujourd’hui

Ce qui a été vérifié aujourd’hui se résume en quatre points principaux.

1. Le problème où du code d’exemple était inséré automatiquement sur un écran vide a été résolu. Auparavant, à l’ouverture de la page, l’exemple Mini Dodge était chargé automatiquement, donnant l’impression que le contenu précédent persistait même après le téléchargement d’un dossier vide. Désormais, juste après le rechargement, l’entrée source est vide.

2. Lors du re‑téléchargement du même fichier ou dossier, le navigateur déclenche à nouveau l’événement change en vidant la valeur de l’input de téléchargement au moment du clic.

3. Pour éviter que le cache JavaScript statique ne subsiste pendant le développement, la réponse du serveur local inclut désormais cache-control: no-store.

4. Lors de l’ajout d’un projet Godot, les fichiers .gd sont traités comme des AST chunk, tandis que les fichiers .godot et .tscn sont traités comme des direct chunk, comme confirmé dans l’interface web.

Ce qui reste à faire

Le découpage en chunks semble fonctionnel à un certain degré.

Le travail principal à poursuivre demain porte sur la façon d’effectuer la recherche dans la base de données.

Il faut notamment vérifier les points suivants :

• Lorsque l’on recherche dans docs_chunks uniquement avec chunkText, quel JSONL est renvoyé ?
• Lorsque l’on recherche dans api_mapping uniquement avec chunkText, les correspondances entre Godot 3 et Godot 4 sont correctement identifiées ?
• Lorsque l’on recherche dans label_prototypes uniquement avec chunkText, les exemples d’utilisation des fonctions / les schémas d’appels sont bien capturés ?
• En l’absence de résultats ou en cas de résultats erronés, comment les éliminer lors de l’étape de validation Qwen ?
• Sous quelle forme afficher les JSONL récupérés à l’écran pour faciliter la prise de décision ?

Le débogueur web créé aujourd’hui sert d’outil d’observation pour vérifier l’étape suivante. Maintenant que la façon dont les fichiers sont découpés commence à être visible, il faudra suivre comment chaque chunk récupère ses références dans la base de données.