2026-07-28 Informe de búsqueda de código fuente real del Flow Debugger

Propósito

En el registro anterior se indicaba que el proyecto real de Godot se había dividido en 134 fragmentos y se había buscado, y que la documentación relacionada estaba incluida en los resultados superiores. Solo con esa expresión no se podía saber qué se devolvió en cada fragmento, si el JSONL devuelto existía realmente en SQLite, o si la documentación más directa estaba en SQLite pero había sido relegada en la clasificación.

Este informe registra por separado las siguientes tres preguntas.

¿Qué candidato JSONL devolvió el Source Flow Debugger para cada fragmento?
¿El candidato devuelto coincide exactamente con el JSONL original verificado en SQLite?
¿La evidencia directa encontrada en todo SQLite apareció en los primeros lugares, o es necesario mejorar la clasificación?

El punto final de Qwen está interrumpido, por lo que esta vez solo se ejecutaron la búsqueda y la comparación con SQLite. No se registró la clasificación de versiones de Godot de Qwen ni los resultados de aprobación/rechazo de candidatos, y el hecho de que apareciera un candidato de búsqueda no se consideró una verificación final exitosa.

Entrada fija

Repositorio:
godotengine/godot-demo-projects
Licencia: MIT
Commit: cae8dc567a56d3e7936f171bcb85f0ccb9634ad0
Proyecto: 2d/hexagonal_map
Archivos de entrada: project.godot, map.tscn, tileset.tres,
tileset_edit.tscn, troll.gd, troll.tscn
Número de archivos de entrada: 6
Número de fragmentos generados: 134
Fragmentos AST: 3
Fragmentos directos: 131

El SQLite usado en la ejecución es
outputs/godot-rag-sqlite/godot-rag.sqlite3, y en el momento de la ejecución contenía
docs_chunks 2 265 entradas, api_mapping 1 133 entradas,
label_prototypes 2 entradas y 3 399 embeddings.

Estado de la ejecución

Etapa	Estado	Significado de esta ejecución
SQLite FTS5 + Okapi BM25	Ejecutado	Se buscaron los 134 fragmentos completos
embedding	No ejecutado	No se configuró la clave de la API de embedding
reranker	No ejecutado	No se configuró la clave de la API del proveedor
Qwen validator	No ejecutado	El punto final de Qwen está detenido

Por lo tanto, la clasificación siguiente no es la clasificación final de la estrategia F completa, sino el resultado de la fase lexical/BM25.

Resultados de la comparación total

Ítem	Resultado
Fragmentos	134
Candidatos BM25 devueltos por fragmento	80
Candidatos devueltos comparados con SQLite	10 720
Candidatos sin duplicados	844
Candidatos no encontrados en SQLite	0
Candidatos cuyo provenance no es `verified`	0
Candidatos cuyo `raw_json` devuelto difiere del original en SQLite	0
Devoluciones de `docs_chunks`	10 713
Devoluciones de `api_mapping`	7
Devoluciones de `label_prototypes`	0

La consistencia de los datos devueltos era correcta. Cuando se consultaron en SQLite las tablas e IDs mostrados por el Source Flow Debugger, los 10 720 registros existían, su provenance era verified y el raw_json devuelto coincidía con el almacenado.

Sin embargo, eso no significa que la calidad de la búsqueda fuera perfecta. Como los 134 fragmentos llenaron todos los 80 candidatos máximos, los candidatos lexicales no se redujeron lo suficiente. Además, en 9 fragmentos la protección del ancla de nombre de archivo hizo que un documento con puntuación BM25 más baja ascendiera al primer puesto.

Resultados representativos de fragmentos

Casos bien buscados

Fragmento	Resumen de entrada	Resultado devuelto	Comparación con SQLite
1	Descripción del formato del archivo `project.godot`	`Manually editing project.godot` posición 1	ID y texto original coinciden
13	`TileMapLayer`, `tile_map_data`, `TileSet`	`TileMapLayer` atributo posición 1, método posición 2, `TileData` posición 3	Todos verificados en `docs_chunks`
42	`TileSetAtlasSource`, región de textura	`TileSetAtlasSource` posición 1, `TileSetSource` posición 2	Evidencia de clase directa
125	`_physics_process`, `Input.get_axis`, `move_and_slide`	`Physics process` posición 1, documentos de movimiento 2D posiciones 5‑7, `CharacterBody2D` posición 8	Documentos de movimiento/física presentes
130	Nodo `CharacterBody2D`	Clase `CharacterBody2D` posición 1	Evidencia de clase directa

El documento en posición 1 del fragmento 1 no alcanzó el primer puesto solo por la puntuación BM25, sino que se mantuvo gracias a la protección del ancla lexical project.godot. En este caso, la descripción del formato del archivo coincidía directamente, por lo que la protección resultó válida.

Casos que necesitan mejora de clasificación

Chunk 123: `extends CharacterBody2D`

Real 1.º: Collision exceptions
Documentación de la clase CharacterBody2D: 17.º
Mapeo KinematicBody2D -> CharacterBody2D: 6.º

Aunque SQLite tenía la documentación exacta de la clase CharacterBody2D, quedó ubicada después de la documentación amplia de colisión y movimiento. No se trata de falta de datos, sino de un problema de clasificación. En chunks de declaración corta es necesario tratar el nombre de la clase y los campos estructurales que coinciden perfectamente con mayor fuerza que los tokens de contexto general.

Chunk 124: `tan(deg_to_rad(30))`

Real 1.º: Setting up the spring arm and camera
Evaluating expressions: 2.º y 3.º

Aunque la documentación número 1 también contiene un ejemplo de uso de deg_to_rad, no está completamente desconectada, pero el tutorial 3D superó a la documentación que explica la propia llamada. Es necesario reordenar para distinguir la explicación de la API de los ejemplos de uso simples.

Estructuras candidatas que requieren re‑validación de Qwen

Chunk 13: `PackedByteArray` incluido en `map.tscn`

El mapeo PackedByteArray -> byte[] apareció en el puesto 48. El JSONL de guardado describe la migración de colecciones en C#, pero la entrada es un recurso de escena GDScript. Los tokens coinciden, pero el lenguaje y el contexto de aplicación difieren, por lo que no debe aprobarse en la fase de búsqueda.

Chunk 130: Nodo que ya usa `CharacterBody2D`

El mapeo KinematicBody2D -> CharacterBody2D quedó en el puesto 3. Este mapeo es relevante para la detección de versiones, pero el chunk actual no contiene la API anterior KinematicBody2D. No es un candidato para advertencia de migración; Qwen debe ver el JSONL y el chunk original y clasificarlo como evidencia de Godot 4 o como no aplicable.

El texto original del JSONL de SQLite para ambos casos se conservó tal cual en reviewCases del informe de lectura automática.

Por qué `label_prototypes` tiene 0 resultados

Los prototipos en SQLite son solo los siguientes dos:

enum PlaneSemanticLabel
class OpenXRSpatialComponentPlaneSemanticLabelList

En el chunk hexagonal_map no había ninguno de los dos patrones de entrada. Por lo tanto, que label_prototypes sea 0 en esta ejecución no es una omisión, sino el resultado de que el filtro de evidencia estructural actuó directamente.

Conclusión actual

La consistencia de datos entre los candidatos devueltos y el texto original de SQLite se confirmó.
Configuraciones de proyecto representativas, TileSet, TileMapLayer y búsquedas de funciones de movimiento incluyeron la documentación relevante en los primeros puestos.
No todos los chunks alcanzaron el límite superior de 80 candidatos, por lo que la reducción de candidatos no fue suficiente.
En declaraciones de clases cortas y llamadas a funciones únicas, se observó que la documentación más directa quedó relegada.
Los mapeos estructurales pueden entrar como candidatos solo por tokens relacionados, de modo que Qwen no puede decidir la aprobación mientras está inactivo.

Criterios para la próxima re‑ejecución

Cuando el endpoint de Qwen esté listo, se usarán los mismos 134 chunks del mismo commit y se añadirán los siguientes valores:

Clasificación de cada candidato estructural en Godot 3, Godot 4, No relacionado, Evidencia insuficiente
Decisión de rechazo para candidatos con desajuste de contexto lingüístico, como PackedByteArray -> byte[]
Rechazo de candidatos de migración en chunks que ya usan la API objetivo
Decisión de rechazo para JSONL de control negativo no relacionado
Cambios en la posición de la documentación directa antes y después de aplicar embedding y reranker

Estrategia F 2026-08-01 y re‑validación de Qwen

Se volvió a insertar el mismo commit del repositorio externo y los 6 archivos originales de 2d/hexagonal_map en la GUI del Source Flow Debugger. Con los criterios de chunk actualizados, se generaron 146 chunks en total. En la auditoría completa de búsqueda, ejecutando BM25, embedding, unión y reranker en ese orden, los 146 chunks se completaron, sin registros devueltos faltantes en SQLite, sin provenance no verificado y sin JSONL distinto al original.

Archivo real	Chunk	Alcance de verificación
`project.godot`	20	Búsqueda híbrida completa, verificación Qwen completa, re‑verificación individual de chunks fallidos
`map.tscn`	6	Búsqueda híbrida completa y verificación Qwen
`tileset.tres`	54	Auditoría completa de búsqueda, verificación representativa de atlas source y recurso final
`tileset_edit.tscn`	54	Auditoría completa de búsqueda, verificación representativa del nodo raíz y nodo sprite
`troll.gd`	3	Búsqueda híbrida completa y verificación Qwen
`troll.tscn`	9	Búsqueda híbrida completa y verificación Qwen

Resultados al separar búsqueda y verificación

La declaración y los nodos CharacterBody2D devolvieron la documentación de la clase y el mapeo KinematicBody2D -> CharacterBody2D. Qwen adoptó solo los mapeos que coincidían con la API objetivo como evidencia de versión y los clasificó como Godot 4.
PackedScene, Node2D, Sprite2D, TileSetAtlasSource, etc., devolvieron la documentación de clases relacionadas, pero esa documentación no demostraba exclusividad de versión mayor, por lo que permanecieron como Evidencia insuficiente.
La configuración run/main_scene coincidió directamente con la documentación Setting the main scene y el texto original de SQLite. Fue rechazada en la primera verificación porque la explicación en lenguaje natural no repetía literalmente la notación de la configuración; sin embargo, al añadir que la documentación describía directamente la clave y su valor estructurado, se ajustó la regla de verificación para aceptarla como evidencia.
doc_version o godot_version_tags son solo versiones de recopilación de documentos y no prueban automáticamente la exclusividad de versión del código. La regla de verificación se ajustó para confirmar la versión solo cuando el cuerpo del JSONL explica explícitamente la diferencia de versión mayor.

Vacíos de datos confirmados por comparación total con SQLite

Se volvió a buscar en docs_chunks, api_mapping y label_prototypes de SQLite. Ningún registro que incluyera las siguientes expresiones se encontró:

scene resource header
script external resource declaration
project format version setting
untyped declaration warning setting
window stretch aspect setting
default clear color setting

Estos casos no son omisiones de JSONL correcto en SQLite, sino ausencia de evidencia directa en los JSONL recopilados actualmente. Por eso el verificador no sustituyó arbitrariamente un resultado de No relacionado por Godot 3 o Godot 4.

Las modificaciones a las reglas de verificación se repartieron en los commits d504f50 y 2222634, y pasaron todas las 33 pruebas del Source Flow Debugger. No se incluyeron listas específicas de sintaxis de código, nombres de API o claves de configuración en las reglas.