O documento inicial de 27 continha muitas descrições de objetos e estruturas, dificultando o rastreamento de como a entrada realmente fluía
Ajustei a direção do documento com base no feedback do PR
Modifiquei para que, a partir de entradas expandidas com # <caminho relativo>, fosse descrito especificamente em qual linha de qual arquivo o conteúdo entra no AST Parser
Como em player.gd (E020‑E034), usei intervalos de linhas reais para organizar o fluxo que vai do trecho do documento à busca do Retriever e ao julgamento do LLM
Reafirmei que o caminho do arquivo serve apenas para rastreamento; a busca do Retriever recebe apenas o chunkText do código/trecho
docs_chunks, api_mapping e label_prototypes são pesquisados da mesma forma, sem tratamento especial, e o LLM revalida os candidatos encontrados
O objetivo do trabalho de hoje foi fixar, antes da implementação real, a documentação que descreve exatamente onde e como a entrada e a saída se conectam, evitando que a IA altere intervalos ou use descrições abstratas
Para validar o fluxo documentado, implementei a ferramenta web Source Flow Debugger
Executada localmente em http://127.0.0.1:8010/, permite inspecionar diretamente a entrada do projeto Godot
Divide a entrada do projeto expandida com # <caminho relativo> por arquivos; .gd são tratados como chunks de tipo AST, enquanto .godot e .tscn são 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 sua razão permanecem visíveis na tela
Adicionei UI de depuração por chunk
Sob cada chunk, posicionei botões de docs_chunks 검색, api_mapping 검색, label_prototypes 검색 e Validate JSONL
Em vez de usar caixas de seleção globais, a busca por tabela ocorre imediatamente abaixo do chunk atual
A entrada para o Retriever mostra apenas { "chunkText": "..." }, omitindo caminho do arquivo, número da linha e prompt
A validação Qwen ocorre exclusivamente na etapa prompt + chunkText + retrieved JSONL
Corrigi problemas encontrados ao usar o depurador web
Removi o carregamento automático de código Godot de exemplo na inicialização da página
Mesmo ao reenviar o mesmo arquivo/pasta, o evento change do navegador é disparado novamente 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 antigos permaneçam
Na rota de busca PostgreSQL, protegi a chamada client.end() para garantir que o cleanup ocorra mesmo se a criação/conexão do cliente falhar
Documentei os resultados da implementação em um documento separado, com capturas de tela
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 retornam de docs_chunks, api_mapping e label_prototypes
Também devemos definir, na etapa de validação Qwen, como determinar se o JSONL encontrado está relacionado ao chunk atual e quando descartá‑lo
Antes de integrar a busca no DB, experimentei prompts de correspondência de evidência com GPT, usando chunks de Godot 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, restrinigi a resposta a “Sim” somente se ao menos um dos campos source_api, source_pattern, match_terms, required_when_seen_in_code ou before_code coincidisse exatamente com a string do código‑fonte ou chamada de API
Evitamos confiar em similaridade semântica ampla ou no conhecimento prévio do LLM sobre Godot; a decisão baseia‑se exclusivamente nas evidências textuais presentes no JSONL: relevantes → “Sim”, irrelevantes → “Não”
Esse experimento mostrou que, após a busca no DB, a validação Qwen deve primeiro checar “Existe evidência textual no JSONL que corresponda diretamente ao chunk atual?” em vez de avaliar apenas similaridade de sentido
Amanhã, criarei vários conjuntos de demo de chunks Godot com JSONL relevantes e irrelevantes, para testar repetidamente quais evidências levam o Qwen a responder “Sim” ou “Não”
