Reorganizei a direção do modelo de codificação do Godot 4, não como aprendizado simples de Q&A, mas sob a perspectiva de aprendizado de trajetória de agente SWE
Concluí que apenas pequenas instruções de Q&A não conseguem lidar com solicitações de nível de projeto, como “crie um mapa”
O agente de codificação real precisa de uma trajetória que inclua exploração de repositório, seleção de arquivos relevantes, modificação de código, teste/validação e geração de patch
Registrei as palavras‑chave Long-context repository-level software engineering agent training e SWE-agent trajectory training
Como casos de referência, organizei SWE‑agent trajectories, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai dataset
Documentei todo o roadmap de desenvolvimento do Godot LLM em imagens e texto
Estruturei o fluxo completo como dados → chatbot RAG de 1ª fase → SFT → DPO → agente SWE
Dividi do estágio 0 (preparação) ao estágio 6 (melhoria contínua), cobrindo coleta/estruturação de dados, chatbot RAG de 1ª fase, rotulagem de dados, treinamento de modelo, desenvolvimento do agente SWE e fluxo de operação/re‑treinamento
O ponto central é transformar primeiro o chatbot RAG de 1ª fase em um especialista em documentação do Godot e, usando‑o, rotular/processar dados do GitHub antes de expandir para treinamento de modelo e agente SWE
Adicionei como nota a estrutura de geração de dados baseada no julgador RAG do Godot
Em vez de delegar a decisão final de rótulo ao LLM, a rotulagem e a verificação são determinadas por um pipeline de sistema
O LLM assume apenas papéis auxiliares de geração, como código corrigido, explicações, perguntas/respostas SFT, respostas ruins DPO e rascunhos de patch
Registrei o fluxo que vai da extração de símbolos, busca, pontuação de rótulo, montagem/verificação de JSONL, usando DB de mapeamento de API, DB vetorial da documentação oficial e DB de protótipos de rótulo
Classifiquei os conjuntos de dados a serem gerados em 8 categorias: classificação de versão, mapeamento de API, correção de migração, instrução SFT, preferência DPO, explorador de repositório, geração de patch e verificação de metadados
Documentei em nota separada o fluxo MVP que parte do julgador RAG do Godot para o modelo de codificação Qwen 3.6
Registrei o caminho desde a preparação do documento original godot_docs_full.zip, chunking inicial com chunk_docs.py, pós‑processamento específico do Godot e construção da infraestrutura de busca local
Combinei Vector DB, Keyword Index, Reranker, API Mapping DB e Label Prototype DB para que o sistema decida os rótulos
Após estruturar os dados do GitHub, executei o julgador RAG e separei o papel do LLM para apenas auxiliar na geração de código corrigido, explicações e amostras de QA
No SFT inicial do Qwen 3.6, foquei em priorizar Godot 4, saída básica de GDScript e rejeição de API do Godot 3; depois, planejei a extensão para DPO e agente SWE
Resolvi o problema de refletir o “grass” do GitHub ajustando as configurações de autor/email do Git
Alterei a configuração global do Git para yyeongjin <appsky1888@gmail.com>
Detectei que os e‑mails de autor/committer no histórico main estavam misturados entre e‑mail local, e‑mail da Naver e noreply do GitHub
Uniformizei autor/committer do histórico main para yyeongjin <appsky1888@gmail.com> e empushei a mudança para o remoto
O estado antes da reescrita foi preservado no branch de backup local backup/before-author-email-rewrite-2026-06-17