# Etapa 19 — Polimento, Acessibilidade e Testes E2E

## Contexto do projeto

Etapa final do frontend do **SeConectai Vendas**. Todas as telas de
negócio das áreas master e tenant já estão implementadas (Etapas 11–18).
Esta etapa é uma auditoria completa e o fechamento com testes
automatizados, antes de considerar o frontend pronto para produção.

## Objetivo desta etapa

Revisão sistemática de responsividade e acessibilidade em todas as
telas, ajustes de performance, e uma suíte de testes E2E cobrindo os
fluxos críticos do sistema.

## Tarefas

1. **Auditoria de responsividade**
   - Percorrer **todas** as rotas do mapa de rotas (master e tenant) nos
     três breakpoints de referência (375px, 768px, 1280px) e registrar/
     corrigir qualquer:
     - overflow horizontal
     - texto cortado ou sobreposto
     - touch target menor que 44x44px em mobile
     - tabela que não virou card corretamente
     - modal que não se adaptou (tela cheia/bottom sheet) no mobile
   - Prestar atenção especial às telas mais densas: `/app/vendas/nova`,
     `/master/tenants/:id`, dashboards com gráficos.

2. **Auditoria de acessibilidade**
   - Rodar um checador automatizado (ex: axe-core) em todas as rotas
     principais e corrigir violações críticas e sérias.
   - Verificar manualmente: navegação completa por teclado (Tab/Shift+Tab)
     em pelo menos um fluxo completo por área (ex: criar um cliente
     inteiro só com teclado), foco visível em 100% dos elementos
     interativos, contraste de texto mínimo AA em todos os textos
     (incluindo sobre a cor primária dinâmica do tenant).
   - Confirmar que `prefers-reduced-motion` é respeitado em todas as
     transições/animações implementadas ao longo do projeto.
   - Textos alternativos em imagens relevantes (logo do tenant, ícones
     que carregam significado além do decorativo).

3. **Estados de loading, erro e vazio**
   - Conferir que **toda** listagem e todo formulário do sistema trata
     corretamente: carregando (skeleton), erro de rede/API (mensagem
     clara com ação de tentar novamente quando fizer sentido), e vazio
     (EmptyState com ação sugerida). Nenhuma tela pode ficar em branco
     silenciosamente em caso de erro.

4. **Performance**
   - Rodar Lighthouse (ou equivalente) nas rotas principais, mobile e
     desktop, e corrigir problemas de maior impacto (ex: imagens sem
     otimização, JS não utilizado sendo carregado antecipadamente,
     ausência de `next/image` onde aplicável).
   - Garantir `loading="lazy"` em imagens fora da dobra inicial (ex:
     logos em listagens longas, se aplicável).

5. **Testes E2E (Playwright ou Cypress — escolher um e justificar)**
   - Fluxo 1: login master → criar tenant → confirmar que o
     `tenant_admin` criado consegue logar.
   - Fluxo 2: login tenant → cadastrar cliente → cadastrar produto →
     criar venda com parcelas → marcar uma parcela como paga → conferir
     que o dashboard financeiro reflete o pagamento.
   - Fluxo 3: alteração de logo/cor no perfil do tenant e confirmação
     visual de que o tema mudou na sidebar.
   - Fluxo 4: tentativa de acesso não autenticado a rota protegida
     (`/app/dashboard` sem login) redireciona corretamente para
     `/login`.
   - Rodar a suíte pelo menos no viewport mobile e no desktop (Playwright
     permite configurar múltiplos projetos/viewports).

6. **Revisão final de conteúdo/copy**
   - Passar por todos os textos de botão, mensagem de erro, empty state
     e confirmação verificando: voz ativa, consistência de nome de ação
     (o botão "Salvar" deve gerar uma confirmação que também fala em
     "salvo", não "criado" ou outra variação), e nenhuma mensagem de
     erro genérica onde a API já fornece detalhe suficiente para ser
     específica.

## Critérios de aceite

- [ ] Nenhuma rota do mapa de rotas tem overflow horizontal em 375px,
      768px ou 1280px
- [ ] Checador de acessibilidade automatizado sem violações críticas ou
      sérias nas rotas principais
- [ ] Um fluxo completo (ex: cadastro de cliente) realizado do início ao
      fim apenas com teclado, com foco sempre visível
- [ ] Contraste de texto validado sobre a cor primária dinâmica em pelo
      menos 3 tenants de teste com cores diferentes (incluindo uma cor
      clara, para forçar o ajuste automático de contraste)
- [ ] Todas as listagens e formulários tratam loading/erro/vazio
      corretamente — testado forçando erro de rede manualmente
- [ ] Lighthouse mobile e desktop nas rotas principais sem alertas de
      performance de alto impacto
- [ ] Suíte de testes E2E dos 4 fluxos descritos passa em mobile e
      desktop
- [ ] Revisão de copy concluída, sem mensagens de erro genéricas onde a
      API fornece detalhe específico