Source Flow Debugger 実装記録
作成日: 2026年 6月 27日
目的
この文書は docs/roadmaps/2026-06-27-source-to-ast-input-flow.md で整理したフローを実際のウェブデバッガで実装し確認した記録です。
本日確認した重要点は次のとおりです。
Godot プロジェクト入力
-> 相対パス基準でファイルを展開
-> ファイル種類の判別
-> .gd は AST 性質のコード片に分解
-> .godot、.tscn のようなテキストリソースは direct chunk に分解
-> 各 chunk の chunkText のみを Retriever 入力として表示
-> chunk の下で docs_chunks / api_mapping / label_prototypes の検索ボタンを提供
-> 検索された JSONL を Qwen 検証リクエストに付けられる構造に接続今回の実装は完成した Retriever ではなく、Retriever と AST 入力の間を目で追跡するためのウェブデバッガです。つまり DB 検索品質を判断する前に、どのファイルがどの断片に分割され、どのテキストが Retriever 検索入力として入るかをまず確認する用途です。
実装されたウェブフロー
ウェブデバッガは http://127.0.0.1:8010/ で実行しました。
画面で確認できる領域は次のとおりです。
- DB エンドポイント入力領域
- Qwen バリデーション入力領域
- Source Prompt 入力領域
- Expanded Source 入力領域
- ファイル/チャンク要約指標
- ファイル別 含む/除外 結果
- チャンク別 原文、Retriever Input、DB 検索ボタン、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 にはこのヘッダーは入りません。
分析結果
今回のテストでウェブデバッガが示した要約は次のとおりです。
| 項目 | 値 |
|---|---|
| Files | 5 |
| Included | 4 |
| Excluded | 1 |
| Chunks | 14 |
| AST | 9 |
| Direct | 5 |
| Retriever Inputs | 14 |
ファイル別の判定は次のとおりでした。
| ファイル | 判定 | 処理 |
|---|---|---|
minidodge/project.godot |
included | project_config, direct chunk |
minidodge/scripts/player.gd |
included | gdscript, AST chunk |
minidodge/scripts/enemy.gd |
included | gdscript, AST chunk |
minidodge/scenes/player.tscn |
included | scene, direct chunk |
minidodge/README.md |
excluded | source-analysis モードで文書ファイルを除外 |
.gd ファイル処理
.gd ファイルは AST Parser 役割のロジックに入ります。
例えば player.gd は次のように分かれました。
extends Area2D
signal hit
@export var speed = 400
var screen_size
func _ready():
func _process(delta):
func start(pos):実際のチャンクは関数本体を含みます。
例えば、_process 関数は1つのチャンクとして保持されます。
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 KinematicBody2Dfunc _physics_process(delta):
velocity = move_and_slide(velocity)direct chunk 処理
project.godotは AST Parser に送られず、設定セクション単位に分割される。
例えば次の内容は direct chunk です。
[application]
config/name="Mini Dodge Upload Test"
run/main_scene="res://scenes/player.tscn"player.tscnも AST Parser に送らずに resource block 単位で分割される。
例えば、次の内容は direct chunk です。
[node name="Player" type="Area2D"]
script = ExtResource("1")このように分けた理由は、.tscn、.godot ファイルも Godot プロジェクトの判定には必要ですが、.gd 関数のように AST 関数単位でパースする対象ではないからです。
Retriever 入力の確認
本日基準で Retriever の入力は chunkText が 1 つだけです。
例えば extends KinematicBody2D チャンクの Retriever 入力は次のとおりです。
{
"chunkText": "extends KinematicBody2D"
}ファイルパス、行番号、プロンプト、予想テーブル名は Retriever の入力に入れないでください。
ファイルパスと行番号は UI で人が追跡するための情報です。検索自体は chunk テキストで実行する必要があります。
chunk別 DB 検索ボタン
最初はテーブル選択をグローバルオプションのように置くこともできましたが、実際には chunk ごとに検索すべきテーブルが異なることがあります。
そのため、ボタンは chunk の下に配置しました。
docs_chunks 検索
api_mapping 検索
label_prototypes 検索
Validate JSONL流れは次のように設定した。
現在 chunkText
-> chunk の下のテーブルボタンをクリック
-> 該当テーブルで検索
-> JSONL 候補を表示
-> prompt + chunkText + 取得した JSONL で Qwen を検証ここで prompt は Retriever 入力ではない。prompt は Qwen 検証段階でのみ使用する。
今日確認したこと
今日確認したことは大きく四つある。
空画面で自動サンプルコードが入っていた問題を除去した。以前はページが開くと
Mini Dodgeサンプルが自動で入って、空フォルダをアップロードしても以前の内容が残っているように見えていた。今はリロード直後には source 入力が空になっている。同じファイルやフォルダを再アップロードしたときにブラウザが
changeイベントを再度発生させるよう、アップロード input の値をクリック時点でクリアする。開発中に静的 JS キャッシュが残らないよう、ローカルサーバのレスポンスに
cache-control: no-storeを付加した。Godot プロジェクトを入れたとき
.gdは AST チャンク、.godotと.tscnは direct チャンクに分かれることをウェブ画面で確認した。
まだ残っていること
チャンク単位で分割することはある程度成功したようだ。
明日以降に続く重要課題は DB 検索をどう実行するかだ。
特に次の部分を確認する必要がある。
chunkTextだけでdocs_chunksを検索したときにどのような JSONL が返ってくるかchunkTextだけでapi_mappingを検索したときに Godot 3 → 4 の根拠が正しく取れるかchunkTextだけでlabel_prototypesを検索したときに関数使用方法/呼び出しパターンの例が正しく取れるか- 検索結果が無い、または的外れなときに Qwen 検証段階でどう破棄するか
- 検索された JSONL をどのような形で画面に表示すれば判断しやすいか
今日作ったウェブデバッガはこの次の段階を確認するための観察ツールだ。これでファイルがどう分割されるかが見え始めたので、次は各チャンクが DB でどの根拠を取得するかを追跡しなければならない。