Gio – Agendador de Estudos Inteligente para o ENEM

Gio é um agendador de estudos com IA criado para uma aluna real se preparando para o ENEM. Em vez de uma lista linear, ele usa um algoritmo de prioridade multi-fator para decidir o que estudar a cada dia entre 45+ tópicos, reorganiza o cronograma automaticamente toda noite via GPT-4o-mini, e aplica repetição espaçada baseada na autoavaliação de confiança. A aluna define a data do exame e as horas disponíveis; o Gio distribui todos os tópicos até o prazo e se adapta diariamente.

A preparação para o ENEM abrange meses e dezenas de disciplinas com dificuldades e frequências históricas muito diferentes. A maioria dos alunos segue um plano linear rígido (que ignora o que já dominam) ou estuda reativamente. Nenhuma abordagem otimiza a relação tempo-nota. Era necessária uma solução que raciocine sobre dificuldade, frequência, confiança e recência ao mesmo tempo — e se recupere quando a aluna pula um dia.

Construir uma aplicação de dois serviços (frontend Next.js + backend Express) que: (1) calcule uma lista diária priorizada de estudos; (2) apresente um único tópico 'Foco do Dia'; (3) rastreie confiança por tópico após cada sessão; (4) reconstrua automaticamente o cronograma da semana toda noite com GPT-4o-mini; (5) visualize o progresso via planejador semanal e heatmap de calendário.

• ◈Desenvolvedor solo — arquitetura, frontend, backend, banco de dados, integração IA

1. 01Score de prioridade multi-fator — score = difficulty_weight + enem_frequency_weight + (5 − avg_confidence) × 0.6 + days_since_studied × 0.1. Quatro sinais independentes combinados em um número: evita que tópicos de dificuldade média mas alta frequência no ENEM sejam despriorizados por um ranking puramente por dificuldade.
2. 02GPT-4o-mini para reorganização noturna — implementar um algoritmo de satisfação de restrições (3 tarefas/dia, ≤195 min total, disciplinas balanceadas) é difícil de manter. O GPT-4o-mini raciocina sobre todas as restrições em linguagem natural, produz um cronograma JSON estruturado e explica o raciocínio. Temperature 0.2 mantém saída consistente; JSON-mode força respostas parseáveis.
3. 03node-cron às 23:30 para reorganização automática — alunos não verificam o app no fim do dia. Um cron server-side reconstrói os próximos 7 dias toda noite para que a aluna acorde com um cronograma realista que já considera o que foi e não foi feito.
4. 04Supabase (região São Paulo) como banco de dados — sem necessidade de DevOps, RLS disponível, subscriptions em tempo real prontas para features futuras. A escolha regional minimiza latência para usuários brasileiros.
5. 05Frontend/backend separados — Next.js App Router na Vercel, Express em host separado. Permite escalar independentemente e evita latência de cold-start no backend Node com restrições serverless.
6. 06Confiança (0–5) como métrica central — a maioria dos apps rastreia conclusão (binário). Confiança captura nuances: uma aluna pode 'completar' uma sessão mas sentir confiança 2/5. Os intervalos de repetição espaçada diminuem quando a confiança é baixa, garantindo revisitas mais frequentes em tópicos fracos.
7. 07Foco do Dia como alívio de decisão — quando sobrecarregada, a aluna precisa de uma resposta clara. A API calcula o tópico de maior prioridade e o apresenta de forma proeminente, reduzindo a paralisia decisória e aumentando a adesão.

• →A reorganização com IA deve ser desenhada para modos de falha: o GPT-4o-mini ocasionalmente omite tópicos ou produz JSON malformado. Um algoritmo de fallback local (score de prioridade puro, sem IA) roda quando a API falha ou retorna saída inválida — a aluna sempre recebe um cronograma.
• →Confiança como estado é mais honesto que conclusão: o beta de duas semanas mostrou alunos marcando tarefas como concluídas com confiança 2/5 frequentemente. Adicionar uma avaliação de confiança obrigatória após cada sessão mudou o comportamento — eles passaram a revisar tópicos que achavam que já 'terminaram'.
• →node-cron em um processo Express de longa duração é mais simples que funções serverless agendadas para este caso: um destino de deploy a menos, sem cold-start no job noturno, e o contexto de reorganização já está em memória.
• →O RLS do Supabase deve ser projetado desde o início: desativá-lo no desenvolvimento e retroativamente aplicá-lo causou um refactor de schema. A lição é modelar o acesso por linha junto com o modelo de dados, não depois.

Funcional — usado por uma aluna real em preparação ativa para o ENEM