El documento inicial del día 27 contenía muchas descripciones de objetos y estructuras, lo que dificultaba rastrear cómo fluía realmente la entrada
Luego, basándome en la retroalimentación del PR, redefiní la dirección del documento
Modifiqué el formato para describir específicamente, en la entrada expandida con # <ruta relativa>, qué línea de qué archivo se envía al AST Parser
Al estilo de los rangos de líneas E020‑E034 en player.gd, organicé el flujo a partir de rangos de líneas reales, mostrando cómo esa parte del texto pasa a la búsqueda del Retriever y a la evaluación del LLM
La ruta del archivo sirve solo para rastreo; establecí que en la búsqueda del Retriever solo se incluye el chunkText del fragmento de código/texto
docs_chunks, api_mapping y label_prototypes se buscan de la misma manera, sin tratamiento especial, y el LLM verifica nuevamente los candidatos encontrados
El objetivo del trabajo de hoy era, antes de la implementación real, fijar por escrito cómo la entrada y la salida se conectan en cada punto, evitando que la IA cambie arbitrariamente los rangos o recurra a explicaciones estructurales abstractas
Implementé la herramienta web Source Flow Debugger para validar el flujo descrito en el documento
Se ejecuta localmente en http://127.0.0.1:8010/ y permite inspeccionar directamente la entrada del proyecto Godot
La entrada del proyecto expandida con # <ruta relativa> se divide nuevamente por archivos; los .gd se tratan como chunks de tipo AST, mientras que .godot y .tscn se descomponen en chunks directos
Con un pequeño proyecto Godot verifiqué que se descompone en 5 files, 14 chunks, AST 9, Direct 5
Los archivos de documentación como README.md se excluyen del modo de análisis de origen, y la pantalla muestra que fueron excluidos y por qué
Añadí una UI de depuración por chunk
Debajo de cada chunk coloqué los botones docs_chunks 검색, api_mapping 검색, label_prototypes 검색 y Validate JSONL
En lugar de una casilla de verificación global, la búsqueda por tabla se realiza justo bajo el chunk actual
La entrada del Retriever muestra solo { "chunkText": "..." }, excluyendo la ruta del archivo, número de línea y prompt
La validación con Qwen se limita a la fase prompt + chunkText + retrieved JSONL
Corrigí los problemas encontrados al usar el depurador web
Eliminé la inserción automática de código de ejemplo de Godot al cargar la página
Vacío el valor del input de carga al hacer clic, de modo que volver a subir el mismo archivo o carpeta dispare nuevamente el evento change del navegador
Añadí cache-control: no-store a las respuestas de archivos estáticos para que no queden restos de JS antiguo durante el desarrollo
En la ruta de búsqueda de PostgreSQL, protegí la llamada client.end() para que la limpieza se ejecute de forma segura aun cuando falle la creación/conexión del cliente
Documenté los resultados de la implementación con capturas de pantalla en un documento separado
Con base en el estado actual, considero que la descomposición por chunks está razonablemente lograda; el siguiente paso clave será definir cómo ejecutar realmente la búsqueda en la base de datos
Necesitamos comprobar, usando solo chunkText, qué candidatos JSONL devuelven docs_chunks, api_mapping y label_prototypes
También debemos determinar, en la fase de validación con Qwen, cómo decidir si el JSONL encontrado está relacionado con el chunk actual y, de no ser así, descartarlo
Antes de integrar la búsqueda en la base de datos, experimenté con GPT creando chunks de Godot de demostración y JSONL relacionados o no relacionados, para probar prompts de coincidencia de evidencia
Al principio pregunté algo como “¿Este JSONL contiene contenido que corresponde al código fuente? Responde solo sí o no”, y tanto los JSONL relevantes como los irrelevantes respondían “sí”
Luego restringí la respuesta a “sí” solo cuando al menos uno de source_api, source_pattern, match_terms, required_when_seen_in_code o before_code coincidiera exactamente con la cadena del CÓDIGO FUENTE o la llamada a la API
Evité que la evaluación se basara en similitud semántica amplia o en conocimientos previos de LLM sobre Godot; la decisión se tomó únicamente con la evidencia textual presente en el JSONL: los relevantes dieron “sí”, los irrelevantes “no”
Este experimento mostró que la fase de validación con Qwen después de la búsqueda debe juzgar primero “¿existe evidencia textual directa en el JSONL que coincida con el chunk actual?” en lugar de una mera similitud de significado plausible
Mañana crearé varios conjuntos de demostración de chunks de Godot con JSONL relacionados y no relacionados, para probar repetidamente cómo Qwen genera “sí” o “no” basándose en la evidencia
