Reorganizei o papel de docs_chunks, api_mapping e label_prototypes no pipeline de análise de código‑fonte do Godot
docs_chunks é usado no fluxo de geração de explicações de código. Busca trechos da documentação oficial com base em AST/fragmentos de código e prompts, descarta evidências irrelevantes e cria JSONL de explicações.
api_mapping armazena como nomes de funções, classes e símbolos mudaram do Godot 3 para o Godot 4.
label_prototypes guarda padrões de transformação para casos em que não apenas o nome mudou, mas a forma de uso da função, a composição de argumentos e o padrão de chamada foram alterados integralmente.
Estruturei a análise de projetos GitHub ou do sistema de arquivos local por fragmentos de AST/código, chamando o Retriever necessário e, em seguida, invocando o Qwen 3.6 sob demanda
A documentação oficial em Markdown é classificada, conforme o tipo de conteúdo, em docs_chunks (texto explicativo), api_mapping (alterações de nomes/símbolos) ou label_prototypes (mudanças de uso/chamadas), sendo salva em JSONL.
Resultados de busca do Retriever, validações por LLM e aprovações do Validator são armazenados como fluxo JSONL/score DB.
Ainda não defini as colunas, método de agregação ou rótulos de classificação do score DB; por enquanto ele funciona apenas como repositório de resultados preliminares antes da classificação por sistema de arquivos.
Futuramente, usaremos o sistema de arquivos classificado como base para criar fontes de SFT e DPO.
Ao documentar o método de classificação por LLM, percebi que, ao contrário do requisito original, o LLM estava enviando apenas os primeiros 3 000 caracteres do Markdown; corrigi para que todo o documento fosse transmitido.
Essa tarefa reforçou que a documentação não é mero registro, mas um processo de verificação do comportamento real do código.
Durante a conversão Markdown → JSONL, o servidor RunPod parou inesperadamente; ao reiniciar o app Streamlit, verifiquei que o estado anterior não foi reiniciado e continuou a partir do ponto onde parou.
Após reiniciar o app, o arquivo em processamento voltou ao estado pending; ao retomar, o resultado de classificação já existente foi reutilizado e o processamento continuou a partir desse arquivo.
Para trabalhos de conversão longos, concluí que é necessário configurar alertas que avisem antecipadamente sobre encerramento ou indisponibilidade do servidor RunPod.