📄 Documento de Execução — Card 13: [M3] Chamada Digital (4 status)

🎯 1. O que foi implementado

Substituído o protótipo mock da página /professor/chamada (que usava students de @/data/mock, inicializava todos como PRESENTE, e tinha o botão "Marcar todos presentes" que o cliente proibiu) por uma implementação real e completa da Chamada Digital, conectada ao banco via tRPC.

O professor agora registra a frequência dos alunos por turma/data/aula, com 4 status clicáveis (Presente, Atrasado, Falta, Justificada), sem botão "marcar todos" (regra explícita do cliente — cada aluno é marcado individualmente). Cada marcação é salva automaticamente (auto-save via optimistic UI), com feedback imediato.

O sistema respeita todas as regras confirmadas pelo cliente: atraso = mais de 15 minutos (registra arrivalTime), faltas geram notificação aos responsáveis (prazo de justificativa de 3 dias), justificativas aprovadas aparecem inline no registro, frequência mínima 75%, e validação de que o professor só faz chamada nas turmas onde foi formalmente vinculado (ClassTeacher).

O seletor de data (default hoje, não permite futuro) + número da aula (1-4) permite registrar chamadas de aulas passadas ou múltiplas aulas no mesmo dia. O resumo mostra presentes/atrasados/faltas/justificados + taxa de presença em tempo real.

✅ Critérios de aceite validados

📁 2. Arquivos criados/modificados

Criados

Modificados

🗄️ 3. Schema do banco (mudanças)

Nenhuma mudança de schema — reutilizado:

• Model Attendance (com @@unique([studentId, classId, date, lessonNumber]) — garante 1 chamada por aluno/aula)
• Enum AttendanceStatus { PRESENT, ABSENT, JUSTIFIED, LATE }
• Model AttendanceJustification (status PENDING → aprovada por LOCAL/Coordenação)
• Model ClassTeacher (validação de acesso pedagógico)

🔌 4. Handoff para o próximo card

Procedures tRPC disponíveis (professor.attendance.*)

• listByClass({classId, date, lessonNumber}) → { classInfo, students[], records[] }
• mark({studentId, classId, date, lessonNumber, status}) → {id, status} (auto-save, LATE registra arrivalTime, ABSENT notifica responsáveis)
• batchMark({classId, date, lessonNumber, entries[]}) → {upserted} (lote)
• history({classId, from?, to?}) → { history: [{date, lessonNumber, total, counts}] }

Componentes reutilizáveis

• StatusButton + STATUS_CONFIG + STATUS_ORDER — reusar em qualquer lugar que mostre frequência (relatórios, dashboard, painel do pai)
• resolveTeacher() (do Card 12) — autorização padrão para todos os procedures do professor

Regras de negócio aplicadas (decisões do cliente)

📋 5. Checklist do Trello — status por item

Entregas (4/4)

• Lista de alunos da turma
• 4 status clicáveis
• Observação por aluno (justificativa aprovada mostrada inline)
• Sincronização com frequência

Especificação Técnica (19/24 implementados)

Não implementados nesta iteração (refinamento futuro):

• markAllPresent — intencionalmente não implementado (cliente proibiu botão "marcar todos")
• Job Bull attendance-alert → WhatsApp (Card 29, quando integrar WhatsApp Business API)
• Push notification (Card 11/18, quando integrar Web Push)
• Evento Socket attendance:updated (tempo real, quando adicionar Socket.io)
• Remarcar após erro até 24h (atualmente permite editar qualquer data passada sem restrição de 24h)

🚀 6. Deploy DEV

• URL seleção: https://sistemaescolar.wellka.com.br/professor/chamada
• URL chamada: https://sistemaescolar.wellka.com.br/professor/chamada/{classId}
• Login demo: carla.prof@genioon.com.br / Prof@2026
• Profª Carla Mendes: turma "6º A", 5 alunos ativos
• Commit: 6dab52b
• PM2: genioon-dev reload ✓ (smoke test HTTP 200)

🧠 7. Contexto gerado para próximas etapas

1. STATUS_CONFIG + STATUS_ORDER (em StatusButton.tsx) são a fonte canônica de cores/labels de status de frequência — reusar em relatórios, dashboard, painel do pai.
2. Fluxo ABSENT → Notification → responsável está pronto. Quando integrar WhatsApp (Card 29), substituir/adicionar o envio do template de falta. Quando integrar Web Push (Card 11/18), disparar push também.
3. attendance.history (groupBy) está disponível para o dashboard da unidade (Card 17) consolidar frequência da turma.
4. Justificativa aprovada aparece inline no registro do professor (campo justified da query). O fluxo de aprovação em si está no Card 9 (painel do pai /pais/faltas + LOCAL aprova).
5. Auto-save via optimistic UI: padrão que funcionou bem aqui — aplicar nos próximos formulários do professor (Card 14 tarefas, Card 15 plano de aula).

🎯 8. Próximo card

Card 14 [M3] Tarefas & Avaliações

• Spec: docs/execucao/14-m3-tarefas-avaliacoes.md
• Foco: professor cria tarefas/avaliações (Task/Exam), define prazos, anexa materiais
• Reuso: ProfessorShell, resolveTeacher(), validação ClassTeacher, model Task/Exam
• O aluno já entrega tarefas (Card 7) — este card é o painel do professor para criar/corrigir