Conteúdo de teste para validar blog, busca e categorias.
CODEX, vamos executar uma build funcional focada em fazer o Dashboard CCATI carregar dados reais completos a partir do pacote CSV ativo.
Nome da build:
CCATI Dashboard Data Pipeline Fix V1
Fase:
Fase 1 – Fundação de Dados / Dashboard Funcional
Objetivo:
Diagnosticar e corrigir a esteira de dados que alimenta o Dashboard, garantindo que o pacote CSV ativo gere ordens, trades reconstruídos, KPIs, resultado diário, curva de capital, rankings, carteiras/ambientes, importações recentes e últimos trades.
Esta task não é de layout.
Não fazer redesign.
Não ajustar UX visual além do mínimo necessário para expor dados corretamente.
O Dashboard pré-premium UX está congelado por enquanto.
Contexto observado no ambiente publicado:
O Dashboard está conectado à API e reconhece o pacote ativo.
Estado atual visível:
- Pacote ativo: #13
- Arquivo importado: lista de odens.csv
- Data/hora da importação: 30/05/2026, 11:18:03
- Período detectado no CSV: 04/05/2026 09:00:19 até 20/05/2026 11:09:34
- Ordens: 7.668
- Trades: 0
- Carteiras: 16
- Carteira selecionada no filtro: ATIBOT_LinearOrder_R1
- KPIs aparecem zerados ou vazios
- Curva de capital aparece sem dados consolidados
- Resultado diário aparece aguardando importação de trades
- Últimos trades aparece vazio
- Top/Piores mostra linhas parciais, mas sem performance real consistente
Diagnóstico provável:
O sistema está importando ordens e reconhecendo carteiras, mas a reconstrução/consolidação de trades não está populando corretamente os dados usados pelo Dashboard.
A esteira a validar é:
CSV Profit → import_batches → raw_orders → trades reconstruídos → métricas agregadas → Dashboard
Escopo obrigatório:
- Confirmar batch ativo
- Identificar o batch ativo real usado pelo Dashboard.
- Confirmar se o batch #13 existe em import_batches.
- Confirmar campos do batch:
- id
- arquivo
- container
- imported_at
- detected_start/detected_end ou equivalentes
- total_orders
- total_trades
- total_portfolios
- status
- Confirmar se o Dashboard está buscando o batch correto.
- Confirmar raw_orders
- Contar raw_orders do batch ativo.
- Confirmar se existem 7.668 ordens reais vinculadas ao batch.
- Verificar campos essenciais das ordens:
- data/hora
- ativo
- lado
- quantidade
- preço
- status
- conta
- corretora
- carteira/estratégia/robô
- identificador de ordem quando houver
- Verificar se os campos vindos do CSV Profit estão normalizados de forma compatível com a reconstrução.
- Confirmar carteiras/robôs
- Verificar como as 16 carteiras detectadas foram criadas.
- Confirmar se ATIBOT_LinearOrder_R1 existe.
- Confirmar se raw_orders dessa carteira existem.
- Confirmar se o filtro de carteira do Dashboard usa o mesmo identificador esperado pelo backend.
- Validar se portfolio_id, portfolio_name, robot_name ou campo equivalente está consistente entre raw_orders, trades e dashboard.
- Diagnosticar reconstrução de trades
- Descobrir por que o batch possui ordens, mas mostra Trades: 0.
- Localizar o serviço/função responsável por reconstruir trades a partir de raw_orders.
- Verificar se ele é chamado após a importação.
- Verificar se ele falha silenciosamente.
- Verificar se ele ignora ordens por status, lado, quantidade, ativo, conta ou carteira.
- Verificar se o CSV atual possui formato diferente do esperado.
- Verificar se há ordens executadas suficientes para formar trades.
- Verificar logs/erros controlados quando disponíveis.
- Corrigir reconstrução se necessário
Se o problema for reconstrução:
- Corrigir pareamento mínimo de ordens em trades.
- Preservar regra atual se já houver contrato documentado.
- Não inventar regra financeira avançada.
- Implementar apenas o necessário para o Dashboard receber trades consolidados.
- Garantir que cada trade tenha, quando possível:
- abertura
- fechamento
- ativo
- lado
- quantidade
- preço entrada
- preço saída
- resultado bruto
- resultado líquido se disponível ou calculável com regra atual
- carteira/robô
- conta/corretora quando disponível
- batch_id
- Se não for possível reconstruir trades com segurança, documentar exatamente o bloqueio e quais campos faltam.
- Confirmar métricas do Dashboard
Após corrigir ou confirmar a reconstrução, validar os dados que alimentam:
- Resultado Líquido
- Resultado Bruto
- Trades
- Win Rate
- Payoff
- Fator de Lucro
- Lucro Médio/Trade
- Tempo Médio/Trade
- Curva de Capital
- Resultado Diário
- Top/Piores Robôs
- Carteiras/Ambientes
- Importações Recentes
- Últimos Trades
- Validar filtros do Dashboard com dados reais
Testar:
- sem filtros
- por período
- por carteira
- por robô
- por ambiente
- por ativo
- por conta
- por corretora
- por container/batch quando aplicável
Critério:
Os filtros não podem zerar tudo indevidamente quando há dados compatíveis.
- Validar estado vazio correto
Quando um filtro não tiver dados:
- mostrar vazio controlado
- não quebrar
- não retornar erro 500
- não gerar SQL inválido
- não deixar o Dashboard travado em “aguardando importação” se o problema for apenas filtro sem resultado
- Validar rotas envolvidas
Testar rotas usadas pelo Dashboard:
- GET /dashboard
- GET /dashboard/summary se existir fallback
- endpoints de importações recentes se existirem
- endpoints de trades recentes se existirem
- endpoints de rankings se existirem
- Corrigir bugs necessários
Pode corrigir:
- rebuild não chamado
- rebuild falhando silenciosamente
- raw_orders sem vínculo com carteira
- trades sem vínculo com carteira
- batch ativo inconsistente
- query do Dashboard buscando campos errados
- filtros zerando dados indevidamente
- aliases divergentes entre frontend e backend
- contadores de batch incorretos
- latest_trades vazio apesar de trades existirem
- ranking calculado em cima de fonte errada
- resultado diário sem dados apesar de trades existirem
- Não fazer nesta task
Não implementar:
- novo layout
- premium UX
- ATIA real
- multiusuário
- ranking comunitário
- loja de setups
- nova stack
- Laravel
- troca estratégica para CSV de desempenho como fonte primária
- refatoração grande fora da esteira de dados atual
Observação sobre CSV de desempenho:
Existe hipótese futura de usar CSV de desempenho consolidado por carteira/estratégia como fonte primária do Dashboard, deixando CSV de ordens como auditoria/drilldown.
Não implementar agora.
Nesta task, corrigir a esteira atual baseada na lista de ordens.
Critérios de aceite:
- Batch ativo identificado corretamente.
- raw_orders do batch ativo confirmadas.
- Carteiras/robôs do batch confirmados.
- Causa de Trades: 0 identificada.
- Reconstrução de trades corrigida ou bloqueio documentado com precisão.
- Dashboard deixa de mostrar KPIs zerados quando houver trades reconstruídos.
- Resultado Diário passa a receber dados reais quando houver trades.
- Curva de Capital passa a receber dados reais quando houver trades.
- Últimos Trades passa a receber dados reais quando houver trades.
- Top/Piores passa a refletir performance real quando houver trades.
- Filtros funcionam sem zerar dados indevidamente.
- Estados vazios continuam controlados.
- Nenhuma alteração visual relevante fora de correções mínimas.
- Nenhuma alteração em config real ou credenciais.
- Nenhuma mudança de stack.
Testing esperado:
- php -l em arquivos PHP alterados.
- node –check se JS for alterado.
- git diff –check.
- Teste de /health.
- Teste de /dashboard sem filtro.
- Teste de /dashboard com filtros.
- Consulta/validação do batch ativo.
- Contagem de raw_orders por batch.
- Contagem de trades por batch antes/depois.
- Teste de reconstrução de trades com o CSV/pacote ativo.
- Teste de Dashboard após rebuild.
- Documentar resultados com números:
- total de ordens
- total de trades reconstruídos
- total de carteiras
- total por carteira principal quando possível
Entrega esperada:
- resumo técnico.
- causa encontrada para Trades: 0.
- arquivos alterados.
- tabelas verificadas.
- queries/rotas testadas.
- batch ativo validado.
- raw_orders contadas.
- trades antes/depois.
- métricas do Dashboard antes/depois.
- filtros validados.
- bugs corrigidos.
- pendências restantes.
- commit.
- PR para revisão.