Files
SeConectai_Vendas/Etapas/V2/12-frontend-design-system.md
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

106 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Etapa 12 — Sistema de Design e Componentes Base
## Contexto do projeto
Continuação do frontend do **SeConectai Vendas**. A Etapa 11 entregou o
projeto Next.js configurado com Tailwind, tokens de design e estrutura
de pastas. Nenhum componente de UI reutilizável existe ainda.
Referência obrigatória: seção 6 (tokens) e seção 7 (lista de
componentes) do `10-frontend-schema-arquitetura.md`.
## Objetivo desta etapa
Construir a biblioteca de componentes base (`components/ui/`) que será
usada por **todas** as telas de negócio das próximas etapas. Tudo aqui
deve já nascer responsivo e acessível — as telas de negócio só vão
compor esses componentes, não reimplementar comportamento responsivo
caso a caso.
## Tarefas
1. **Base a partir do shadcn/ui**
- Instalar e configurar shadcn/ui, mas customizar cada componente
usado para consumir os tokens do projeto (não deixar cores/spacing
hardcoded vindos do template padrão).
- Justificar no código (comentário curto) qualquer componente que
fugir do padrão shadcn por necessidade específica do projeto.
2. **Componentes a construir** (todos em `components/ui/`, cada um com
suas variantes documentadas via comentário ou arquivo `.stories`
opcional):
- **Button**: variantes `primary` (usa `--color-primary`),
`secondary`, `destructive`, `ghost`; tamanhos `sm`/`md`/`lg`; estado
`loading` (spinner substituindo o label, sem mudar a largura do
botão); estado `disabled`.
- **Input / Textarea**: com label, texto de ajuda, estado de erro
(borda + mensagem), prefixo/sufixo opcional (ex: "R$" para campos
de valor).
- **Select**: nativo estilizado ou baseado em Radix (via shadcn),
com busca para listas longas (ex: seleção de cliente/produto).
- **DatePicker**: seleção de data única e, quando necessário, período
(usado nos filtros de dashboard/listagens).
- **FormField**: wrapper que padroniza label + input + mensagem de
erro + texto de ajuda — todo formulário do sistema deve usar esse
wrapper, nunca montar label/erro manualmente.
- **Table**: **componente central desta etapa**. Recebe colunas e
dados de forma genérica (tipado com generics em TypeScript).
Abaixo do breakpoint `md`, renderiza automaticamente como lista de
**Cards empilhados** (cada linha vira um card com pares
rótulo:valor, permitindo destacar 1–2 campos principais e colapsar
o resto). Suporta: ordenação por coluna, estado de loading
(skeleton), estado vazio (usa o `EmptyState`), paginação integrada.
- **Modal / Sheet**: um único componente que se comporta como modal
centralizado no desktop e como tela cheia (ou bottom sheet, definir
e justificar qual) no mobile, controlado pelo mesmo breakpoint `md`.
- **Toast**: sistema de notificação temporária (sucesso, erro, aviso,
info), empilhável, com auto-dismiss configurável.
- **Badge / StatusPill**: variantes semânticas mapeadas para os
status de negócio já existentes no backend (`pendente`, `pago`,
`atrasado`, `cancelado`, `ativo`, `inadimplente`, `suspenso`,
`trial`, `confirmada`, `concluida`, `orcamento`) — cada status com
cor e label em português já resolvidos aqui, para não repetir esse
mapeamento em cada tela.
- **Card**: contêiner base usado em dashboards e nas listas
responsivas da Table.
- **Pagination**: controles de página, compatível com os parâmetros
de paginação da API do backend.
- **EmptyState**: ilustração/texto + ação sugerida, usado em toda
listagem vazia (ex: "Nenhum cliente cadastrado ainda" + botão
"Cadastrar cliente").
- **Skeleton**: blocos de carregamento reutilizáveis (linha de texto,
card, linha de tabela).
- **Tabs**: navegação em abas (usado, por exemplo, no detalhe de
venda: Itens / Parcelas / Histórico).
3. **Acessibilidade (obrigatório, não opcional)**
- Todos os componentes interativos com foco de teclado visível
(`outline` customizado com a cor de foco do design system, não o
padrão do navegador nem `outline: none` sem substituto).
- Componentes baseados em Radix/shadcn já trazem boa parte da
semântica ARIA — não remover isso ao customizar.
- Respeitar `prefers-reduced-motion` em qualquer transição/animação.
- Touch targets mínimos de 44x44px nos componentes interativos.
4. **Página de showcase**
- Criar uma rota de desenvolvimento (ex: `/dev/componentes`, não
exposta em produção) que renderiza todos os componentes acima com
suas variantes, para revisão visual rápida em qualquer breakpoint
sem precisar montar uma tela de negócio primeiro.
## Critérios de aceite
- [ ] Todos os componentes listados existem, tipados em TypeScript, com
as variantes descritas
- [ ] `Table` alterna corretamente entre tabela (≥768px) e cards
empilhados (<768px) na página de showcase
- [ ] `Modal/Sheet` alterna corretamente entre modal centralizado
(desktop) e tela cheia/bottom sheet (mobile)
- [ ] `StatusPill` cobre todos os status de negócio listados, com cor e
label em português
- [ ] Navegação por teclado (Tab) percorre todos os componentes
interativos da página de showcase com foco visível
- [ ] Nenhum componente quebra ou tem overflow horizontal em 375px
- [ ] Página de showcase acessível apenas em ambiente de desenvolvimento