StratHUB
Da metodologia em PDF a uma especificação de estratégia verificável.
Fluxos e contratos conferidos no código. As etapas de documentos, embeddings e validação são distinguíveis; não foi publicado resultado medido de qualidade, lucro ou latência.
O problema e o objetivo
O StratHUB explora como transformar metodologias de trading descritas em documentos em regras explícitas e verificáveis. Um PDF pode misturar explicações, gráficos e critérios de entrada, saída e risco; essa informação precisa de estrutura antes de ser consumida por outro sistema.
O projeto conecta processamento documental, IA aplicada e engenharia de sistemas financeiros. A proposta é produzir uma Strategy Spec: uma representação declarativa em JSON, vinculada às fontes, que possa ser validada e identificada de forma consistente entre serviços.
Arquitetura: três runtimes, um contrato
O monorepo separa a interface Next.js/TypeScript, a API e os workers Python/FastAPI e um executor em Rust. O pacote compartilhado strategy-spec concentra o JSON Schema e suas implementações em TypeScript, Python e Rust. Essa divisão permite que cada camada trabalhe com o mesmo contrato sem depender de objetos internos da outra linguagem.
Supabase participa da autenticação, persistência e armazenamento; PostgreSQL/pgvector armazena os dados e embeddings. Redis e Arq sustentam o processamento assíncrono. Docker Compose e Dockerfiles organizam o ambiente local e o empacotamento dos serviços.
Ingestão: do upload às páginas de origem
A API organiza jobs, registro de PDFs, confirmação de upload e envio para processamento. O worker lê os arquivos do armazenamento, extrai conteúdo e acompanha o estado dos documentos. Essa etapa permanece fora da requisição principal, pois extração, embeddings e chamadas a modelos podem demorar.
A extração usa PyMuPDF. Páginas com pouco texto nativo podem passar por OCR com Tesseract, quando disponível. O processamento registra página de origem, confiança de OCR e sinaliza páginas com pouco conteúdo textual. Isso explicita uma limitação: gráficos e imagens não viram automaticamente regras confiáveis apenas porque o arquivo é um PDF.
Segmentação e embeddings: contexto com proveniência
O texto é segmentado por páginas em janelas de palavras com sobreposição, preservando identificadores do documento e da página. Os embeddings são gerados em lotes e armazenados com texto, modelo, dimensão e proveniência. No worker, armazenamento dos embeddings e geração da especificação podem ocorrer concorrentemente.
Na implementação analisada, o compilador envia um conjunto limitado de chunks diretamente ao LLM. Os vetores armazenados são uma base para recuperação, mas esse fluxo não demonstra, por si só, busca semântica integrada a um pipeline RAG completo. A página distingue a preparação dos dados da recuperação efetivamente utilizada.
LLM como compilador, não como executor
O orquestrador integra modelos via OpenRouter e solicita saída estruturada por JSON Schema. O contexto inclui o contrato, documentos disponíveis e trechos com referência às páginas. O material enviado pelo usuário é tratado no prompt como dado não confiável, separado das instruções do sistema.
A resposta passa por parsing, validação estrutural, checagens semânticas e verificação de referências documentais. Quando uma resposta falha na validação, a tentativa seguinte recebe os erros para reparo, dentro de um número limitado de tentativas e modelos configurados. A saída desejada é uma DSL JSON restrita; código Python gerado pelo modelo não é executado.
Strategy Spec e reprodução entre linguagens
A especificação descreve elementos de estratégia permitidos pelo contrato, em vez de aceitar lógica arbitrária. Validações semânticas complementam o schema: um JSON bem formado ainda pode conter regras inconsistentes. Campos decimais relevantes usam strings, reduzindo ambiguidades na troca entre runtimes.
O spec_hash usa SHA-256 sobre uma representação canônica da especificação, sem o próprio campo de hash. As implementações ordenam chaves, preservam a ordem dos arrays e normalizam a serialização. Fixtures e testes verificam a identidade do contrato entre TypeScript, Python e Rust. O hash identifica o artefato; não comprova a qualidade ou rentabilidade da estratégia.
Paper execution, eventos e controles de risco
O código Rust inclui um caminho de paper validation que recebe dados de mercado via WebSocket e trabalha com execução virtual. Há componentes de broker de simulação, intenções de ordem, fills, estado persistido e outbox para acompanhar o ciclo de execução. Decimal, limites de risco, controle de reconexão e monitoramento de desvio de relógio compõem essa fundação.
A API recebe eventos em lotes e atualiza heartbeats. O scorecard produz razões de aprovação ou falha a partir de critérios como quantidade de operações, duração, drawdown, slippage e erros. Há lógica de idempotência, limites de concorrência, orçamento e TTL para registros de validação. Isso descreve componentes no código, não uma validação financeira real concluída.
Interface e isolamento de responsabilidades
A interface inclui login, hub, criação de jobs e páginas de revisão e validação. Route handlers do Next.js intermediam chamadas ao serviço Python, mantendo credenciais de infraestrutura no lado servidor. Migrações organizam entidades de documentos, estratégias, embeddings e execuções, com políticas de acesso por usuário.
O repositório contém superfícies ainda em construção. A página de revisão humana, por exemplo, é um scaffold para uma etapa mais completa; não deve ser apresentada como um fluxo de aprovação final pronto. Da mesma forma, metadados de provisionamento para validação não comprovam que máquinas externas tenham sido efetivamente criadas e operadas.
Testes, contratos e integração contínua
O repositório possui testes de ingestão, jobs, validação estrutural e semântica, eventos e scorecards, além de fixtures para o contrato compartilhado. Os testes da API usam mocks para dependências externas em cenários específicos; isso permite verificar regras sem consumir serviços pagos, mas não substitui uma execução integrada real.
O workflow de CI define checks para Rust, Python e Node, incluindo formatação, análise estática, testes e build/typecheck da interface. Também há varredura de segredos e revisão de migrações destrutivas. Esta análise verificou o conteúdo das suítes e workflows, sem atribuir números de cobertura ou resultados de execução não medidos.
Estado atual e próximos passos
O código analisado está além do scaffold descrito no README principal: contém ingestão, geração estruturada, contratos e partes de paper validation. Ainda assim, o dispatch de backtest permanece como placeholder e o modo live está bloqueado até controles adicionais. Não há base nesta análise para afirmar operação com capital real ou resultados financeiros validados.
Os próximos passos técnicos são completar a revisão humana, integrar e validar o interpretador de backtest, comprovar o fluxo ponta a ponta e revisar os controles antes de qualquer operação real. O valor demonstrado pelo projeto está na integração entre documentos, contratos tipados, processamento assíncrono e infraestrutura de execução inspecionável.