Reorganicé la dirección del modelo de codificación de Godot 4 desde un aprendizaje simple de preguntas y respuestas a una perspectiva de aprendizaje de trayectorias de agentes SWE.
Determiné que con solo pequeñas instrucciones Q&A es difícil manejar solicitudes a nivel de proyecto como “crea un mapa”.
Concluí que un agente de codificación real necesita una trayectoria que incluya exploración del repositorio, selección de archivos relevantes, modificación de código, pruebas/validación y generación de parches.
Registré palabras clave relacionadas como Long-context repository-level software engineering agent training y SWE-agent trajectory training.
Como casos de referencia, enumeré trayectorias de agentes SWE, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai dataset.
Documenté todo el roadmap de desarrollo del LLM de Godot en imágenes y texto.
Estructuré el flujo completo como datos → chatbot RAG de primera fase → SFT → DPO → agente SWE.
Dividí desde la fase de preparación Stage 0 hasta la mejora continua Stage 6, cubriendo recolección/estructuración de datos, chatbot RAG de primera fase, etiquetado de datos, entrenamiento del modelo, desarrollo del agente SWE y operación/re‑entrenamiento.
El punto clave es crear primero un chatbot RAG de primera fase como experto en la documentación de Godot, usar ese chatbot para etiquetar y procesar datos de GitHub, y luego ampliar a entrenamiento del modelo y agente SWE.
Añadí una nota sobre la estructura de generación de datos basada en el verificador RAG de Godot.
En lugar de delegar la decisión final de la etiqueta al LLM, la etiqueta y su validación son determinadas por la tubería del sistema.
El LLM solo asume roles de asistencia generativa, como código corregido, explicaciones, preguntas/respuestas SFT, respuestas negativas DPO y borradores de parches.
Documenté el flujo que parte de la base de datos de mapeo de API, la base de vectores de la documentación oficial y la base de prototipos de etiquetas, pasando por extracción de símbolos, búsqueda, puntuación de etiquetas, ensamblado/validación de JSONL.
Clasifiqué los conjuntos de datos objetivo en ocho categorías: clasificación de versiones, mapeo de API, corrección de migraciones, instrucción SFT, preferencia DPO, explorador de repositorios, generación de parches y verificación de metadatos.
Registré por separado el flujo MVP que conecta el verificador RAG de Godot con el modelo de codificación Qwen 3.6.
Desde la preparación del documento original godot_docs_full.zip hasta el chunking inicial con chunk_docs.py, el post‑procesamiento exclusivo de Godot y la construcción de la infraestructura de búsqueda local.
Combino Vector DB, índice de palabras clave, reranker, base de datos de mapeo de API y base de datos de prototipos de etiquetas para que el sistema decida las etiquetas.
Después de estructurar los datos de GitHub, ejecuto el verificador RAG y separo el rol del LLM a asistencia generativa (código corregido, explicaciones, muestras de QA).
En la primera fase SFT con Qwen 3.6, el objetivo es priorizar Godot 4, generar salidas básicas de GDScript y rechazar la API de Godot 3; luego se continúa con DPO y expansión al agente SWE.
Resolví el problema de reflejo del “grass” de GitHub ajustando la configuración de autor/email de Git.
Cambié la configuración global de Git a yyeongjin <appsky1888@gmail.com>.
Detecté que los correos de autor/committer en el historial main estaban mezclados entre el correo local, un correo de Naver y los noreply de GitHub.
Uniformé autor y committer del historial main a yyeongjin <appsky1888@gmail.com> y lo empujé al remoto.
El estado anterior a la reescritura quedó guardado en la rama local de respaldo backup/before-author-email-rewrite-2026-06-17.