Source Flow Debugger Implementation Record

Date: June 27, 2026

Purpose

This document records the implementation and verification of the flow described in docs/roadmaps/2026-06-27-source-to-ast-input-flow.md using an actual web debugger.

The key points verified today are as follows.

Godot project input
  -> Expand files based on relative paths
  -> Determine file type
  -> .gd is split into AST-like code fragments
  -> Text resources such as .godot, .tscn are split into direct chunks
  -> Display only the chunkText of each chunk as Retriever input
  -> Provide a search button under the chunk for docs_chunks / api_mapping / label_prototypes
  -> Connect the retrieved JSONL to a structure that can be attached to a Qwen verification request

This implementation is not a completed Retriever, but a web debugger for visually tracking the relationship between the Retriever and AST input. In other words, before judging DB search quality, it is used to first verify which files are split into which pieces and what text goes into the Retriever search input.

Implemented Web Flow

The web debugger was run at http://127.0.0.1:8010/.

The areas visible on the screen are as follows.

• DB endpoint input area
• Qwen validation input area
• Source Prompt input area
• Expanded Source input area
• File/chunk summary metrics
• Inclusion/exclusion results per file
• Original text per chunk, Retriever Input, DB search button, Qwen request preview

The screen observed today is as follows.

Godot Project Input Verification

The test was conducted in the form of a small Godot project.

The input files were as follows.

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

After uploading, the internal input is expanded in the following form.

# 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
...

# <Relative Path> header is for tracking purposes. This header is not included in the Retriever.

Analysis Results

The summary shown by the web debugger in this test is as follows.

The judgment per file was as follows.

.gd File Processing

.gd files are processed by logic that acts as an AST Parser.

For example, player.gd was divided as follows.

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

The actual chunk includes the function body.

For example, the _process function remains as a single 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)

In enemy.gd, we also found that code that could be a clue for Godot 3 is split into chunks.

extends KinematicBody2D

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

direct chunk processing

project.godot is not sent to the AST Parser but is divided into sections of the settings.

For example, the following content is a direct chunk.

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

player.tscn is also split by resource block units instead of being sent to the AST Parser.

For example, the following content is a direct chunk.

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

The reason for this division is that while .tscn and .godot files are needed to determine a Godot project, they are not subjects for parsing at the AST function level like .gd functions.

Check Retriever Input

As of today, the Retriever input contains only a single chunkText.

For example, the Retriever input for the extends KinematicBody2D chunk is as follows.

{
  "chunkText": "extends KinematicBody2D"
}

File paths, line numbers, prompts, and expected table names are not included in the Retriever input.

File paths and line numbers are information for a human to track in the UI. The search itself must be performed on the chunk text.

DB Search Button per Chunk

At first, table selection could have been placed as a global option, but in practice the table to search may differ for each chunk.

Therefore, the button is placed below the chunk.

docs_chunks search  
api_mapping search  
label_prototypes search  
Validate JSONL

The flow was set up as follows.

Current chunkText
  -> Click the table button below the chunk
  -> Search in the corresponding table
  -> Display JSONL candidates
  -> Verify Qwen with prompt + chunkText + retrieved JSONL

Here, the prompt is not a Retriever input. The prompt is used only in the Qwen verification stage.

What was confirmed today

What was confirmed today can be divided into four main points.

First, the issue where automatic sample code was inserted on a blank screen was removed. Previously, when the page opened, the Mini Dodge sample was automatically loaded, making it look like previous content remained even when an empty folder was uploaded. Now, immediately after a refresh, the source input is empty.

Second, when the same file or folder is uploaded again, the browser triggers the change event again by clearing the upload input value at the moment it is clicked.

Third, to prevent static JS cache from persisting during development, cache-control: no-store was added to the local server responses.

Fourth, when a Godot project is added, .gd becomes an AST chunk, while .godot and .tscn become direct chunks, as verified on the web screen.

Remaining tasks

Chunking by unit seems to have been somewhat successful.

The core to continue with tomorrow is how to perform DB searches.

In particular, the following parts need to be checked.

• When searching docs_chunks with only chunkText, what JSONL is returned
• When searching api_mapping with only chunkText, whether the Godot 3 → 4 rationale is captured correctly
• When searching label_prototypes with only chunkText, whether examples of function usage patterns/call patterns are captured correctly
• How to discard results in the Qwen verification stage when there are no search results or they are irrelevant
• In what format to display the retrieved JSONL on the screen to make judgment easy

The web debugger created today is an observation tool for verifying the next steps. Now that the file splitting is starting to be visible, the next task is to trace what evidence each chunk retrieves from the DB.