Regras do Design System

Para garantir que o produto seja consistente e escalável, todos os membros do time (Design, Front-End e QA) devem seguir estas regras.

O que é PROIBIDO 🚫

• Usar cores fora da paleta de tokens.
• Criar novos componentes para resolver problemas que os componentes existentes já resolvem.
• Ignorar os estados de interação (Hover, Focus, Pressed).
• Usar valores de espaçamento ímpares ou fora do grid de 8px.
• Desviar dos padrões de acessibilidade (contraste baixo, áreas de toque pequenas).

O que é OBRIGATÓRIO ✅

• Usar Auto Layout no Figma em todos os componentes e telas.
• Nomear camadas de forma clara e organizada.
• Seguir a estrutura de Leading / Content / Trailing para componentes compostos.
• Definir estados de erro e loading para todas as ações assíncronas.
• Validar novos componentes com o líder de Design/Front antes de implementá-los oficialmente.

Quando criar algo novo? 🤔

Antes de criar um novo componente ou estilo, passe por este checklist:

1. [ ] Existe algum componente que faz algo similar?
2. [ ] Posso resolver isso usando Slots em um componente existente?
3. [ ] Essa necessidade se repete em mais de 3 telas diferentes?
4. [ ] O componente novo segue os fundamentos (01_DESIGN_FOUNDATIONS)?

Se as respostas indicarem que um novo componente é realmente necessário, ele deve ser criado primeiro como um "Organismo" na tela e depois promovido ao Design System após validação.

Processo de Validação

1. Ideação: Designer propõe a solução.
2. Sync: Designer e Dev discutem a viabilidade técnica e impacto no código.
3. Handoff: Documentação clara das variantes, tokens e slots.
4. Review: QA e Design validam a implementação final.

---

Como fazer vs Como não fazer

✅ Como fazer

• Utilize o checklist acima antes de cada nova task de UI.
• Mantenha o arquivo do Figma sempre atualizado com a última versão do componente no código.
• Se encontrar uma inconsistência no sistema, reporte e ajude a corrigir.

❌ Como não fazer

• "Arrumar" um componente apenas em uma tela específica (cria dívida técnica).
• Implementar no código algo que não foi definido ou validado no design.
• Deixar para pensar na responsividade apenas no final do processo.