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
Julguei que apenas pequenas instruções de Q&A não conseguem lidar com solicitações de nível de projeto, como “crie um mapa”
Concluí que um 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, SWE-agent trajectory training
Documentei casos de referência como SWE-agent trajectories, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai dataset
Registrei todo o roadmap de desenvolvimento do Godot LLM em imagens e documentos
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 operação/re‑treinamento
O ponto central é criar primeiro o chatbot RAG de 1ª fase como 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 validaçã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/validação 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 alvo 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
Do preparo do documento original godot_docs_full.zip ao 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
Estruturei a separação de papéis: após estruturar os dados do GitHub e executar o julgador RAG, o LLM só auxilia na geração de código/modificações/QA
Na primeira fase SFT com Qwen 3.6, o objetivo é priorizar Godot 4, gerar saída GDScript básica e rejeitar APIs do Godot 3; depois segue para DPO e expansão para 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 o histórico main continha emails de autor/committer misturados (localhost, naver, noreply do GitHub, etc.)
Uniformizei autor/committer do histórico main para yyeongjin <appsky1888@gmail.com> e empushei a mudança ao remoto
O estado antes da reescrita foi salvo na branch local de backup backup/before-author-email-rewrite-2026-06-17