Critérios de Sucesso

O Neemias é considerado bem-sucedido quando atinge os 6 critérios abaixo. Cada critério possui uma meta mensurável que orienta as decisões de produto e engenharia.

1. Resiliência Offline

Usuários continuam trabalhando sem internet, sem perda de dados.

• O aplicativo deve iniciar e operar completamente offline, incluindo criação de alunos e marcação de presença.
• Nenhuma ação do usuário pode ser perdida por falta de conectividade — toda escrita é armazenada localmente no IndexedDB e enfileirada para sincronização.
• A transição online/offline deve ser transparente, sem necessidade de ação manual do usuário.

2. Confiabilidade da Sincronização

Mudanças feitas offline são sincronizadas com segurança e sem corrupção de dados.

• Conflitos são resolvidos deterministicamente pela regra ADMIN_PRECEDENCE (ou LAST_TIMESTAMP_WINS em empate).
• Eventos perdedores são preservados e marcados com isConflictLoser: true — nunca descartados silenciosamente.
• Idempotência garante que reenvios acidentais não dupliquem dados.
• A fila de sincronização usa backoff exponencial para não sobrecarregar o servidor.

3. Acessibilidade WCAG Nível AA

A experiência atende aos critérios de acessibilidade WCAG 2.1 Nível AA.

• Contraste de cores, navegação por teclado, texto alternativo em imagens e compatibilidade com leitores de tela.
• Feedback visual e auditivo em ações de sucesso e falha.
• Fotos de alunos com descrição textual para identificação acessível.

4. Conformidade com a LGPD

O produto respeita os princípios da Lei Geral de Proteção de Dados.

• Dados pessoais são protegidos com criptografia em repouso (AES-GCM) e em trânsito (HTTPS).
• Trilha de auditoria imutável (audit_logs) registra toda operação com actor_user_id, correlation_id e detalhes.
• Soft-delete preserva o histórico sem destruir dados pessoais.
• Justificativa obrigatória para exclusão de alunos garante rastreabilidade da decisão.
• Princípio do menor privilégio aplicado em todos os papéis.

5. Desempenho

Captura de presença com o menor número possível de etapas e feedback imediato.

• A marcação de presença de um aluno deve levar no máximo 2 interações (buscar + confirmar).
• O tempo de resposta percebido para operações locais deve ser inferior a 200 ms.
• Fotos de alunos devem ser exibidas durante a busca sem delay perceptível.
• A PWA deve carregar em menos de 3 segundos no primeiro acesso (3G) e instantaneamente em acessos subsequentes (Service Worker).

6. Satisfação do Usuário

Um novo usuário entende o propósito e o funcionamento do sistema apenas pela documentação.

• A documentação cobre instalação, papéis, fluxo de chamada e perguntas frequentes.
• A interface segue padrões familiares para usuários com pouca experiência em software.
• O produto permanece pequeno, modular e amigável para contribuidores open-source — fator essencial para sustentabilidade de longo prazo.

---

Fonte: PRD §10

Baseline atual (medido em 2026-06-23)

Performance

• Lighthouse CI: pendente de configuracao no pipeline de deploy
• Tempo de resposta API: < 100ms (testado via curl, p95)
• Carregamento PWA: pendente de medicao formal

Acessibilidade

• axe-core integrado nos testes E2E (spec 11-accessibility)
• Pages testadas: Login, Dashboard, Students, Attendance, Classes
• Cobertura: 5 paginas principais

Pos-MVP (nao medido)

• Tempo de resposta percebido < 200ms — pendente de Lighthouse CI
• Carregamento em 3G < 3s — pendente de Lighthouse CI
• 2 interacoes para marcar presenca — pendente de teste de usabilidade
• Novo usuario entende o sistema pela documentacao — pendente de teste de usabilidade