O documento inicial do dia 27 continha muitas descrições de objetos e estruturas, dificultando o rastreamento de como a entrada realmente fluía
Em seguida, ajustei a direção do documento com base no feedback do PR
Modifiquei para que, a partir de # <caminho relativo> expandido, fosse descrito especificamente em qual linha de qual arquivo o AST Parser recebe a entrada
Como em E020‑E034 de player.gd, organizei o fluxo com base em intervalos reais de linhas, mostrando como partes do texto são encaminhadas para a busca do Retriever e a avaliação do LLM
Os caminhos de arquivo são apenas para rastreamento; estabeleci novamente que a busca do Retriever recebe apenas o chunkText do código/trecho, não o caminho completo
docs_chunks, api_mapping e label_prototypes são pesquisados da mesma forma, sem tratamento especial, e o LLM verifica novamente os candidatos de busca
O objetivo do trabalho de hoje foi fixar, por meio de documentação, como a entrada e a saída se conectam em cada ponto, evitando que a IA altere intervalos arbitrariamente ou siga explicações estruturais abstratas antes da implementação real
Para validar o fluxo documentado, implementei a ferramenta web Source Flow Debugger
Executei localmente em http://127.0.0.1:8010/ para inspecionar diretamente a entrada do projeto Godot
Dividi a entrada do projeto expandida por # <caminho relativo> em unidades de arquivo; .gd são tratados como chunks de natureza AST, enquanto .godot e .tscn são divididos em chunks diretos
Testei com um pequeno projeto Godot e confirmei a divisão em 5 arquivos, 14 chunks, AST 9, Direct 5
Arquivos de documentação como README.md são excluídos no modo source-analysis, e a exclusão e seu motivo permanecem visíveis na tela
Anexei a UI de depuração por chunk
Sob cada chunk, posicionei botões de pesquisa docs_chunks, pesquisa api_mapping, pesquisa label_prototypes e Validar JSONL
Em vez de usar caixas de seleção globais, a pesquisa por tabela ocorre imediatamente abaixo do chunk atual
A entrada do Retriever exibe apenas { "chunkText": "..." }, omitindo caminho de arquivo, número da linha e prompt
A validação Qwen é usada apenas na etapa prompt + chunkText + JSONL recuperado
Corrigi problemas encontrados ao usar o depurador web
Removi a inserção automática de código Godot de exemplo ao carregar a página
Mesmo que o mesmo arquivo/pasta seja enviado novamente, o evento change do navegador dispara ao limpar o valor do input de upload no clique
Adicionei cache-control: no-store nas respostas de arquivos estáticos para evitar que scripts JS antigos permaneçam durante o desenvolvimento
Na rota de busca PostgreSQL, protegi a chamada client.end() para que a limpeza ocorra com segurança mesmo se a criação/conexão do cliente falhar
Documentei o resultado da implementação com capturas de tela em um documento separado
Até o momento, a divisão por chunk está razoavelmente bem‑sucedida; o próximo foco será como executar a busca no banco de dados
Precisamos verificar, usando apenas chunkText, quais candidatos JSONL são retornados de docs_chunks, api_mapping e label_prototypes
Também devemos definir como o estágio de validação Qwen decide se o JSONL encontrado está relacionado ao chunk atual e quando descartá‑lo
Antes de integrar a busca ao DB, experimentei prompts de correspondência de evidência com GPT, usando chunks de Godot de demonstração e JSONL relevantes ou irrelevantes
Inicialmente, ao perguntar “Este JSONL contém conteúdo que corresponde ao código‑fonte? Responda apenas Sim/Não”, tanto JSONL relevantes quanto irrelevantes retornavam “Sim”
Depois, limitei a resposta a “Sim” somente se um dos campos source_api, source_pattern, match_terms, required_when_seen_in_code ou before_code coincidisse exatamente com a string/call do SOURCE_CODE
Evitamos que a similaridade semântica ampla ou o conhecimento prévio do LLM sobre Godot influenciem; a decisão baseia‑se apenas nas evidências textuais presentes no JSONL: relevantes → “Sim”, irrelevantes → “Não”
Esse experimento mostrou que, após a busca no DB, a etapa Qwen deve primeiro avaliar “Existe evidência textual direta no JSONL que corresponda ao chunk atual?” em vez de confiar em similaridade de sentido plausível
Amanhã, criarei vários conjuntos de demonstração de chunks Godot com JSONL relevantes e irrelevantes, para testar repetidamente como o Qwen gera “Sim”/“Não” com base nas evidências
