Files

T

tiagoandClaude Sonnet 5 323912748f Frontend completo (Etapas 11-18) e extensões de backend (Etapas 13 e 18)

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>

2026-08-16 09:41:13 -03:00

4.7 KiB

Raw Permalink Blame History

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

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.
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).
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.
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).
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).
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

4.7 KiB Raw Permalink Blame History Unescape Escape