Concluí a coleta e conversão de 1.422 de 1.550 documentos oficiais para JSONL usando o Markdown → JSONL Converter
Continuei a execução do Qwen Validation Debugger do item 46 ao 50, verificando código gerado, inspeção do motor Godot 3/4 e resultados de validação JSONL
No item de log de depuração 50, finalizei a validação de código comum e JSONL; o carregamento dinâmico de recursos da cena 48 falhou porque o caminho de recurso fixo gerado não existia, sendo rejeitado pela inspeção do motor
Ao re‑tentar, passei o diagnóstico do motor anterior e melhorei o depurador para usar uma seed estável diferente a cada rodada, sem registrar manualmente sintaxe ou respostas por item
Carreguei o JSONL atual do coletor 8501 em outputs/godot-rag-sqlite/godot-rag.sqlite3 e comparei as 1.570 URLs originais, domínios e SHA‑256 de pages.zip com as fontes dos registros
Configurei tabelas docs_chunks, api_mapping, label_prototypes, provenance original e índice de busca FTS5 no SQLite, permitindo criar snapshots novamente com o mesmo builder antes da coleta completa
Comparei dump de SQLite e vetor DB com o formato para subir JSONL ao Git, preservando registros e provenance originais e escolhendo SQLite que pode ser regenerado/compartilhado sem servidor adicional
Inicialmente adicionei SQLite apenas como artefato de saída para o Git; a estratégia F do Source Flow Debugger continuou apontando para PostgreSQL, gerando inconsistência ao precisar refletir o mesmo JSONL em ambos
Para eliminar a dupla gestão, consolidei os dados de referência da estratégia F e o repositório de execução em um único SQLite comitado, removendo configurações e caminhos de migração do PostgreSQL
A candidata BM25 agora é lida do FTS5 do SQLite, calculada como Okapi BM25 no Node; embeddings são armazenados em record_embeddings do mesmo SQLite com modelo, dimensão, SHA‑256 do conteúdo do registro e vetor Float32, re‑indexando apenas registros modificados
O Source Flow Debugger agora verifica diretamente a revisão, contagem de registros e número de embeddings do SQLite comitado, e os vetores armazenados são pesquisados no Node via similaridade de cosseno
Dumps de vetor DB dependem do modelo de embedding, dimensão e implementação do índice, portanto não são mantidos como dados de referência separados; são gerados sob demanda como índices derivados no mesmo SQLite quando necessário