ADR-0004 — Estratégia de Presença
Status
Aprovado
Contexto
Um dos principais objetivos do sistema EBDbe é registrar a presença dos alunos na Escola Bíblica Dominical (EBD) de forma:
- Confiável
- Simples
- Com baixo atrito para o usuário
- Respeitando a privacidade
- Compatível com uso em dispositivos móveis
A presença não deve depender exclusivamente de ação manual constante do aluno, mas também não pode violar princípios de privacidade ou realizar rastreamento contínuo.
Foi necessário definir uma estratégia híbrida e progressiva.
Decisão
O sistema adotará modelo híbrido de presença, composto por três mecanismos complementares:
- QR Code Dinâmico (mecanismo principal)
- Validação por Rede da Unidade
- Geolocalização Opcional
BLE não será implementado na Fase 1.
1. QR Code Dinâmico (Mecanismo Oficial)
O QR Code será o método padrão de registro de presença.
Funcionamento:
- O professor ou responsável gera QR Code temporário.
- O QR Code é válido apenas para:
- OrganizationalUnit específica (unit_id)
- Lesson específica (lesson_id)
- Intervalo de tempo limitado
- O aluno escaneia via PWA.
- O backend valida:
- Papel do usuário
- Escopo organizacional
- Validade temporal
Vantagens:
- Simples
- Confiável
- Não depende de localização
- Não exige hardware adicional
- Compatível com qualquer dispositivo
2. Validação por Rede da Unidade
Mecanismo complementar.
Se o usuário estiver conectado à rede da unidade (Wi-Fi da igreja), o sistema poderá:
- Detectar IP compatível com faixa cadastrada
- Sugerir confirmação de presença
- Registrar presença após confirmação explícita
Importante:
- Não haverá varredura de redes disponíveis
- Não haverá acesso indevido a informações do dispositivo
- A confirmação sempre dependerá do usuário
3. Geolocalização (Opcional)
Uso opcional e condicionado a consentimento explícito.
Regras:
- Apenas no horário da EBD
- Apenas verificação pontual
- Apenas registro do evento de presença
- Nenhum armazenamento de histórico contínuo
Geolocalização servirá apenas como sugestão de presença.
4. BLE (Bluetooth Low Energy)
Avaliado, porém não implementado na Fase 1.
Motivos:
- Complexidade adicional
- Dependência de hardware
- Limitações em navegadores móveis
- Necessidade potencial de app nativo
Pode ser reavaliado em fases futuras.
5. Princípios Fundamentais
- Presença não deve gerar rastreamento contínuo.
- Backend é autoridade final.
- Sempre haverá validação de escopo organizacional.
- Nenhum mecanismo funcionará sem autenticação.
- Consentimento explícito é obrigatório para localização.
6. Fluxo Simplificado
Fluxo padrão:
Aluno autenticado ↓ Escaneia QR ↓ Cloud Function valida:
- Papel (Role do User)
- ministry_id e unit_id
- lesson_id e validade temporal do QR ↓ Attendance registrado
Fluxo alternativo (rede/localização):
Sistema detecta contexto compatível ↓ Exibe sugestão ↓ Aluno confirma ↓ Backend valida e registra
7. Categoria de Presença (Attendance.category)
Cada registro de Attendance terá uma categoria indicando o tipo de participação (conforme ADR-0005):
- STUDENT — aluno
- VISITOR — visitante
- LEADER — líder
- WORKER — obreiro
- PASTOR — pastor
Isso permite consolidar contagens por categoria (total_students, total_visitors etc.) em Lesson e EbdSession, compatível com relatórios e com fluxos de entrada manual (digitação de totais por categoria, quando QR não for utilizado — cenário herdado do legado).
Consequências
- QR Code será implementado antes dos demais mecanismos.
- Backend centraliza lógica de validação.
- Nenhum mecanismo funcionará offline sem posterior sincronização validada.
- Privacidade é preservada por design.