Запись реализации Source Flow Debugger

Дата создания: 27 июня 2026 г.

Цель

Этот документ — запись о том, как был реализован и проверен поток, описанный в docs/roadmaps/2026-06-27-source-to-ast-input-flow.md, в реальном веб‑отладчике.

Ключевые моменты, проверенные сегодня, следующие.

Ввод проекта Godot
-> Развёртывание файлов по относительному пути
-> Определение типа файла
-> .gd разбивается на фрагменты кода с характером AST
-> .godot, .tscn такие текстовые ресурсы разбиваются на прямые чанки

-> Отображать только chunkText каждого chunk как ввод Retriever  
  -> Предоставить кнопку поиска docs_chunks / api_mapping / label_prototypes под chunk

-> Соединить найденный JSONL со структурой, которую можно прикрепить к запросу проверки Qwen

Это реализация не завершённого Retriever, а веб‑отладчик для визуального отслеживания взаимодействия между Retriever и вводом AST. То есть, прежде чем оценивать качество поиска в базе данных, он служит для предварительной проверки, какие файлы разбиваются на какие фрагменты и какой текст попадает в ввод поиска Retriever.

Реализованный веб‑поток

Веб‑отладчик был запущен по адресу http://127.0.0.1:8010/.

Области, видимые на экране, следующие:

• Область ввода конечной точки БД
• Область ввода проверки Qwen
• Область ввода исходного подсказки
• Область ввода расширенного источника
• Показатели резюме файлов/чанков
• Результаты включения/исключения по файлам
• Оригинальный текст по чанку, ввод Retriever, кнопка поиска в БД, предварительный просмотр запроса Qwen

Экран, проверенный сегодня, выглядит следующим образом.

Проверка ввода проекта Godot

Тест проводился в виде небольшого проекта Godot.

Входной файл выглядел следующим образом.

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

После загрузки внутренний ввод разворачивается в следующем виде.

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

# <상대경로> Заголовок используется для отслеживания. В Retriever этот заголовок не включается.

Анализ результатов

В этом тесте резюме, показанное веб‑отладчиком, выглядит следующим образом.

Файловый вывод был следующим.

Обработка файлов .gd

Файлы .gd попадают в логику, выполняющую роль AST‑парсера.

Например, player.gd был разделён следующим образом.

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

Фактический chunk включает тело функции.

Например, функция _process сохраняется как один 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)

В enemy.gd я обнаружил, что код, который может быть подсказкой для Godot 3, также разделяется на чанки.

extends KinematicBody2D

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

direct chunk обработка

project.godot не отправляется в AST Parser, а делится на секции настроек.

Пример: следующий контент — прямой фрагмент.

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

Также player.tscn не отправляется в AST Parser, а делится на блоки ресурсов.

Для примера следующий контент является прямым фрагментом.

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

Причина такой разбивки в том, что файлы .tscn, .godot также необходимы для определения проекта Godot, но они не являются объектами парсинга на уровне функций AST, как функции .gd.

Проверка ввода Retriever

На текущий день ввод Retriever состоит только из одного chunkText.

Например, ввод Retriever для чанка extends KinematicBody2D выглядит следующим образом.

{
  "chunkText": "extends KinematicBody2D"
}

Не включайте путь к файлу, номер строки, подсказку, предполагаемое имя таблицы в ввод Retriever.

Путь к файлу и номер строки — это информация для отслеживания человеком в UI. Сам поиск должен выполняться по тексту чанка.

Кнопка поиска в БД по чанку

Сначала можно было разместить выбор таблицы как глобальную опцию, но на практике таблица, по которой нужно искать, может различаться для каждого чанка.

Поэтому кнопка размещена под чанком.

Поиск docs_chunks  
Поиск api_mapping  
Поиск label_prototypes  
Validate JSONL

Поток был установлен следующим образом.

текущий chunkText
-> нажмите кнопку таблицы ниже
-> Поиск в этой таблице
-> JSONL кандидат отображение
-> prompt + chunkText + проверка Qwen с помощью JSONL

Здесь prompt не является вводом Retriever. Prompt используется только на этапе проверки Qwen.

Что проверено сегодня

Сегодня было проверено четыре основных момента.

1. Удалена проблема, когда на пустом экране автоматически вставлялся пример кода. Раньше при открытии страницы автоматически загружался пример Mini Dodge, и даже после загрузки пустой папки казалось, что предыдущий контент остался. Теперь сразу после обновления ввод source пуст.

2. При повторной загрузке того же файла или папки браузер снова генерирует событие change, потому что значение поля загрузки очищается в момент клика.

3. Чтобы во время разработки не оставался статический кэш JS, к ответу локального сервера добавлен заголовок cache-control: no-store.

4. При загрузке проекта Godot выяснилось, что файлы .gd обрабатываются как AST‑chunk, а .godot и .tscn — как direct‑chunk, что подтверждено на веб‑странице.

Что ещё осталось

Разбиение на чанки, кажется, выполнено в достаточной мере.

Завтра продолжим работу над тем, как выполнять поиск в базе данных.

Особенно нужно проверить следующие части:

• Что возвращает JSONL при поиске docs_chunks только по chunkText.
• Правильно ли определяется переход Godot 3 → 4 при поиске api_mapping только по chunkText.
• Корректно ли находятся примеры использования функций/шаблоны вызовов при поиске label_prototypes только по chunkText.
• Как отбрасывать результаты в этапе проверки Qwen, если поиск ничего не нашёл или вернул нерелевантные данные.
• В каком виде отображать найденный JSONL на экране, чтобы было удобно оценивать результаты.

Созданный сегодня веб‑отладчик служит инструментом наблюдения для проверки следующего шага. Теперь видно, как файлы разбиваются на части, и в дальнейшем нужно будет отслеживать, какие основания каждый чанк получает из базы данных.