Skip to content

Relatórios

O módulo de relatórios do Neemias oferece 11 tipos de análise sobre frequência, engajamento e integridade dos dados. Toda a computação é executada no lado do cliente — funções computeXxx() puras que consomem dados do IndexedDB (Dexie) via useLiveQuery. Isso garante que os relatórios funcionem plenamente offline, sem dependência do servidor.

O acesso à página de relatórios (/reports) exige as roles admin ou relatorios. Os relatórios são renderizados em tempo real conforme os dados locais são atualizados, e cada tipo oferece visão tabular e gráfica com opção de exportação CSV.

Tipos de Relatório

#RelatórioDescrição
1Resumo (Summary)Estatísticas agregadas: total de alunos, total de chamadas, média de presença, faltas no período
2Linha do Tempo (Timeline)Eventos de chamada em ordem cronológica, com filtro por turma e período
3Sessões (Sessions)Listagem de todas as sessões de aula realizadas, com presenças e faltas por sessão
4Semanal (Weekly)Frequência consolidada por semana, comparativo entre turmas e núcleos
5Associação (Membership)Distribuição de alunos por status de membresia familiar (membro, frequentador, visitante)
6Tendência (Trend)Evolução da frequência ao longo do tempo com linha de tendência e projeção
7Engajamento por Turma (Class Engagement)Taxa de presença por turma, ranqueamento e comparativo entre turmas
8Risco de Evasão (Risk Dropout)Alunos com queda acentuada de frequência nas últimas semanas, sinalizando risco de abandono
9Cobertura de Chamada (Call Coverage)Percentual de slots de aula que tiveram chamada efetivamente realizada
10Pico de Frequência (Peak Frequency)Horários e dias da semana com maior concentração de presenças
11Auditoria (Audit)Rastreabilidade completa de alterações: quem criou, alterou ou removeu cada registro, com timestamps e justificativas

Arquitetura Client-Side

Cada relatório é gerado por uma função pura computeXxx() localizada em app/src/modules/reports/. Essas funções recebem os dados brutos do IndexedDB — alunos, turmas, slots, sessões e eventos de presença — e retornam estruturas agregadas. Como a computação é local, o tempo de resposta é inferior a 100ms para volumes típicos (~50 alunos, ~30 eventos por aula), sem latência de rede. O worker do Cloudflare não possui rotas de relatório; ele atua exclusivamente como sink de sincronia, recebendo eventos offline e persistindo no D1.

A decisão de manter relatórios 100% client-side está documentada na análise de rotas de relatório no worker e alinhada ao requisito de continuidade offline do PRD.

⚠️ Seção em expansão.


Fonte: app/src/modules/reports/

Distribuído sob licença MIT.