Skip to content
EBDbe

ADR-0004 — Estratégia de Presença

Status

Section titled “Status”

Aprovado

Contexto

Section titled “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

Section titled “Decisão”

O sistema adotará modelo híbrido de presença, composto por três mecanismos complementares:

  1. QR Code Dinâmico (mecanismo principal)
  2. Validação por Rede da Unidade
  3. Geolocalização Opcional

BLE não será implementado na Fase 1.

1. QR Code Dinâmico (Mecanismo Oficial)

Section titled “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

Section titled “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)

Section titled “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)

Section titled “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

Section titled “5. Princípios Fundamentais”
  1. Presença não deve gerar rastreamento contínuo.
  2. Backend é autoridade final.
  3. Sempre haverá validação de escopo organizacional.
  4. Nenhum mecanismo funcionará sem autenticação.
  5. Consentimento explícito é obrigatório para localização.

6. Fluxo Simplificado

Section titled “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)

Section titled “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

Section titled “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.