idea_world_labDEV JOURNAL
2026年6月27日土曜日

2026 年 6 月 27 日

  • 26 日に作成した docs/roadmaps/2026-06-26-source-to-ast-input-flow.md を再読し、文書全体の一貫性が不足していると判断
  • 最初に作成した 27 日の文書はオブジェクト説明と構造説明が多く、実際に入力がどのように流れるか追跡しにくかった
    • 以降の PR フィードバックを基準に文書の方向性を再設定
    • # <相対パス> で展開された入力から、どのファイルのどの行が AST Parser に入るかを具体的に記述する形に修正
    • player.gd の E020‑E034 のように実際の行範囲を基準に、該当本文の一部が Retriever 検索と LLM 判定へつながる流れを整理
    • ファイルパスは追跡用で、Retriever 検索にはコード/本文の chunkText のみが入るという基準を再固定
  • docs_chunks, api_mapping, label_prototypes は特別扱いせず同様の方法で検索し、検索候補を LLM が再検証する流れとして整理
  • 本日の作業は実装前に AI が任意に範囲を変更したり抽象的な構造説明に流れないよう、入力と出力がどの地点でどのように接続されるかを文書で先に固定することが目的だった
  • 文書で整理したフローを確認するために Source Flow Debugger Web ツールを実装
    • ローカルで http://127.0.0.1:8010/ として実行し、Godot プロジェクトの入力を直接確認
    • # <相対パス> で展開されたプロジェクト入力をファイル単位で再分割し、.gd は AST 性質の chunk、.godot.tscn は direct chunk として分解
    • 小規模 Godot プロジェクトを入れて 5 files, 14 chunks, AST 9, Direct 5 に分解されることを確認
    • README.md のような文書ファイルは source‑analysis モードで除外し、除外された事実と理由が画面に残るようにした
  • chunk 別デバッグ UI を付加
    • 各 chunk の下に docs_chunks 検索, api_mapping 検索, label_prototypes 検索, Validate JSONL ボタンを配置
    • グローバルテーブルのチェックボックスではなく、現在の chunk 直下でテーブル別検索を実行する形に整理
    • Retriever 入力はファイルパス、行番号、プロンプトを除き { "chunkText": "..." } のみを表示
    • Qwen 検証は prompt + chunkText + retrieved JSONL の段階でのみ使用するよう分離
  • Web デバッガを実際に使用して見つかった問題を修正
    • ページ読み込み時にサンプル Godot コードが自動で入っていた問題を除去
    • 同じファイル/フォルダを再アップロードしてもブラウザの change イベントが再発生するよう、upload input の値をクリック時にクリア
    • 開発中に古い JS が残らないよう、静的ファイル応答に cache-control: no-store を追加
    • PostgreSQL 検索パスで client 作成/接続失敗が起きても cleanup が安全に動作するよう client.end() 呼び出しを防御
  • 実装結果をキャプチャと共に別文書で残す
  • 現時点でチャンク単位の分解はある程度成功したと見なし、次に見るべき核心は DB 検索を実際にどう実行するかに設定
    • chunkText のみで docs_chunks, api_mapping, label_prototypes からどの JSONL 候補が返るかを確認する必要あり
    • 検索された JSONL が現在の chunk と関連しているかを Qwen 検証段階でどう判断し破棄するかを確認
  • DB 検索を組み込む前に GPT でデモ用 Godot チャンクと関連/無関係 JSONL を作成し、根拠マッチングプロンプトを実験
    • 最初は「この JSONL がソースコードに該当する内容を含んでいるか、はい/いいえで答えよ」程度で質問したところ、関連 JSONL と無関係 JSONL が両方とも「はい」と出る問題があった
    • その後 source_api, source_pattern, match_terms, required_when_seen_in_code, before_code のいずれかが実際の SOURCE_CODE 文字列/API 呼び出しと直接一致する場合のみ「はい」と制限
    • 広い語彙類似性や LLM の Godot 事前知識で判断せず、JSONL に記載された文字列根拠のみを見るようにし、関連 JSONL は「はい」、無関係 JSONL は「いいえ」に分岐することを確認
    • この実験により DB 検索後の Qwen 検証段階は「妥当な意味類似度」ではなく「検索された JSONL の中に現在の chunk と直接合致する文字列根拠があるか」を先に判定すべきという基準を得た
    • 観察日誌: JSONL 収集状況ベーステストリポジトリ選定観察日誌
    • 観察日誌: JSONL 根拠マッチングプロンプト観察
    • 回顧: docs/retrospectives/2026-06-27.md
  • 明日は Godot チャンクと関連/無関係 JSONL デモセットを複数作成し、Qwen がどの根拠で「はい」/「いいえ」を導き出すかを繰り返しテストする予定