tiagoandClaude Sonnet 5
323912748f
Adiciona o frontend Next.js em frontend/ (setup, design system, autenticação/tema, layout/navegação, área master, área tenant completa: clientes, produtos, vendas, recebimentos, whatsapp, e-mail, alertas, equipe e perfil). Estende o backend de forma aditiva e autorizada: cookie httpOnly para refresh token (Etapa 13) e CRUD de equipe + edição de perfil do tenant (Etapa 18, módulo src/modules/equipe/ novo e PUT /tenant/perfil). Detalhes completos em Etapas/V2/*. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
99 lines
4.7 KiB
Markdown
99 lines
4.7 KiB
Markdown
# 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
|