El documento del día 27, redactado inicialmente, contenía muchas descripciones de objetos y estructuras, lo que dificultaba rastrear cómo fluía realmente la entrada
Posteriormente, se ajustó la dirección del documento basándose en la retroalimentación del PR
Se modificó a un formato que indique específicamente, en la entrada expandida con # <ruta relativa>, qué línea de qué archivo ingresa al AST Parser
Al estilo de E020‑E034 de player.gd, se organizó el flujo basándose en rangos de líneas reales, mostrando cómo esa parte del texto conduce a la búsqueda del Retriever y a la evaluación del LLM
Las rutas de archivo se usan solo para rastreo; se reafirmó que en la búsqueda del Retriever solo se incluye el chunkText del código/texto
docs_chunks, api_mapping y label_prototypes se tratan de la misma manera, buscándolos sin tratamiento especial y dejando que el LLM verifique nuevamente los candidatos
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 rangos arbitrariamente o describa estructuras abstractas
Se implementó la herramienta web Source Flow Debugger para validar el flujo descrito en el documento
Se ejecutó localmente en http://127.0.0.1:8010/ para inspeccionar directamente la entrada del proyecto Godot
La entrada del proyecto expandida con # <ruta relativa> se divide nuevamente por archivo; los archivos .gd se convierten en chunks de tipo AST y los .godot y .tscn en chunks directos
Con un pequeño proyecto Godot se verificó la descomposición 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 exclusión y su razón permanecen visibles en pantalla
Se añadió una UI de depuración por chunk
Bajo cada chunk se colocaron los botones docs_chunks 검색, api_mapping 검색, label_prototypes 검색, Validate JSONL
En lugar de una casilla global, la búsqueda por tabla se realiza justo debajo del chunk actual
La entrada del Retriever muestra solo { "chunkText": "..." }, excluyendo ruta de archivo, número de línea y prompt
La validación con Qwen se limita a la fase prompt + chunkText + retrieved JSONL
Se corrigieron problemas detectados al usar el depurador web
Se eliminó la inserción automática de código de ejemplo de Godot al cargar la página
Al volver a subir el mismo archivo/carpeta, se vacía el valor del input de carga al hacer clic, de modo que el evento change del navegador se dispare nuevamente
Se añadió cache-control: no-store a las respuestas de archivos estáticos para evitar que quede JS antiguo durante el desarrollo
En la ruta de búsqueda de PostgreSQL, se protegió la llamada client.end() para que la limpieza sea segura aun cuando falle la creación/conexión del cliente
Se archivó el resultado de la implementación con capturas en un documento separado
Con base en el estado actual, se considera que la descomposición por chunk ha tenido éxito razonable; el siguiente objetivo es definir cómo se realizará la búsqueda en la base de datos
Se debe comprobar, usando solo chunkText, qué candidatos JSONL devuelven docs_chunks, api_mapping y label_prototypes
También es necesario determinar, en la fase de validación con Qwen, cómo juzgar si el JSONL encontrado está relacionado con el chunk actual y cuándo descartarlo
Antes de integrar la búsqueda en la base de datos, se experimentó con GPT creando JSONL relacionados y no relacionados con chunks de Godot de demostración, para probar los prompts de coincidencia de evidencia
Al principio, al preguntar “¿Este JSONL contiene contenido que corresponde al código fuente? Responde solo sí o no”, tanto los JSONL relevantes como los irrelevantes respondían “sí”, lo cual era problemático
Luego se restringió la respuesta a “sí” solo cuando al menos uno de source_api, source_pattern, match_terms, required_when_seen_in_code, before_code coincidía exactamente con la cadena del CÓDIGO FUENTE o la llamada a la API
Se evitó que la similitud semántica amplia o el conocimiento previo de LLM sobre Godot influyeran; solo se consideró la evidencia textual presente en el JSONL, resultando en “sí” para JSONL relevantes y “no” para los irrelevantes
Este experimento mostró que la fase de validación Qwen después de la búsqueda en la base de datos debe juzgar primero “¿Existe evidencia textual dentro del JSONL que coincida directamente con el chunk actual?” en lugar de una “similitud de significado plausible”
Mañana se crearán varios conjuntos de demostración de chunks de Godot con JSONL relacionados y no relacionados, para probar repetidamente cómo Qwen genera la evidencia para “sí” o “no”
