idea_world_labDEV JOURNAL
суббота, 27 июня 2026 г.

27 июня 2026 г.

  • 26‑го числа был перечитан docs/roadmaps/2026-06-26-source-to-ast-input-flow.md, и было решено, что в документе не хватает согласованности

    • Вместо того чтобы просто добавлять новый материал, посчитано необходимым создать документ, который заново систематизирует ту же тему по состоянию на 27‑е число
    • Поэтому был создан новый документ docs/roadmaps/2026-06-27-source-to-ast-input-flow.md

  • Первоначальный документ от 27‑го числа содержал много описаний объектов и их структуры, из‑за чего было трудно отследить, как именно происходит поток ввода

    • Затем, опираясь на обратную связь в PR, была скорректирована направленность документа
    • Было изменено оформление: в раскрытом вводе # <относительный‑путь> теперь конкретно указывается, из какой строки какого файла попадает код в AST‑парсер
    • Как в примере player.gd (E020‑E034), поток был описан на основе реального диапазона строк, где часть текста переходит к поиску Retriever и последующей оценке LLM
    • Путь к файлу служит только для отслеживания, а в поиске Retriever учитывается лишь chunkText‑фрагмент кода/текста, что было зафиксировано как правило

  • docs_chunks, api_mapping, label_prototypes обрабатываются без особых исключений тем же способом, а LLM проверяет найденные варианты

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

  • Чтобы проверить описанный поток, был реализован веб‑инструмент Source Flow Debugger

    • Запускается локально по адресу http://127.0.0.1:8010/, где можно непосредственно просмотреть ввод проекта Godot
    • Ввод проекта, раскрытый как # <относительный‑путь>, разбивается по файлам; файлы .gd превращаются в chunk‑ы AST‑типа, а .godot и .tscn — в прямые chunk‑ы
    • При загрузке небольшого проекта Godot было подтверждено разбиение на 5 файлов, 14 chunk‑ов, AST 9, Direct 5
    • Файлы типа README.md исключаются из режима source‑analysis, и факт исключения с причиной отображается на экране

  • Добавлен UI отладки для каждого chunk‑а

    • Под каждым chunk‑ом размещены кнопки docs_chunks 검색, api_mapping 검색, label_prototypes 검색, Validate JSONL
    • Вместо глобального чекбокса таблицы поиск выполняется непосредственно под текущим chunk‑ом
    • Ввод Retriever показывает только { "chunkText": "..." }, исключая путь к файлу, номер строки и подсказку
    • Проверка Qwen используется только на этапе prompt + chunkText + retrieved JSONL

  • При практическом использовании веб‑отладчика были исправлены обнаруженные проблемы

    • Удалено автоматическое подгружение примера кода Godot при загрузке страницы
    • При повторной загрузке того же файла/папки событие браузера change теперь срабатывает, так как значение поля загрузки очищается при клике
    • Чтобы старый JS не оставался в кэше, к статическим файлам добавлен заголовок cache-control: no-store
    • В случае ошибки создания/подключения клиента PostgreSQL в пути поиска, вызов client.end() защищён, чтобы очистка происходила безопасно

  • Реальный результат реализации оставлен в отдельном документе с скриншотами

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

  • Скриншот: Source Flow Debugger Godot экран анализа

  • На текущий момент разбор по чанкам считается отчасти успешным, а дальше ключевым будет вопрос, как именно выполнять поиск в базе данных

    • Нужно проверить, какие кандидаты JSONL возвращаются из docs_chunks, api_mapping, label_prototypes только по chunkText
    • Нужно определить, как на этапе проверки Qwen решать, относится ли найденный JSONL к текущему чанку, и как его отбрасывать

  • Прежде чем добавлять поиск по базе данных, с помощью GPT создали демонстрационные JSONL, связанные и не связанные с чанком Godot, и протестировали запросы сопоставления доказательств

    • Сначала спросили примерно: «Этот JSONL содержит содержание, соответствующее исходному коду? Ответьте только «да» или «нет»», но получили проблему, когда как связанные, так и несвязанные JSONL отвечали «да».

  • После этого ограничиваем «да», только если один из source_api, source_pattern, match_terms, required_when_seen_in_code, before_code точно совпадает с реальной строкой SOURCE_CODE или вызовом API

  • Не полагайтесь на широкую схожесть слов или предзнание LLM о Godot, а смотрите только на строковые доказательства, записанные в JSONL; соответствующий JSONL помечаем «да», нерелевантный — «нет»

  • В результате этого эксперимента мы пришли к выводу, что этап проверки Qwen после поиска в базе данных должен оценивать не «правдоподобное семантическое сходство», а наличие в найденных JSONL строковых доказательств, непосредственно соответствующих текущему чанку

  • Журнал наблюдений: Журнал наблюдений по выбору тестового репозитория на основе статуса сбора JSONL

  • Журнал наблюдений: Наблюдение за подсказкой сопоставления доказательств JSONL

  • Ретроспектива: docs/retrospectives/2026-06-27.md

  • Завтра планирую создать несколько наборов демонстрационных JSONL, связанных/не связанных с Godot chunk, и многократно протестировать, на каких основаниях Qwen выводит да/нет.