Componentes e design system
Trechos do capítulo · alexandrecaramaschi.com/educacao/frontends-com-vibecoding

Leia o LEIA-ME.txt desta pasta antes de usar qualquer trecho.

### O que faz: pede o componente de campo com fonte de tokens, variantes, histórias e nota de versão numa entrega só
### Onde entra: conversa com o agente, num projeto que já tem biblioteca de componentes começando a crescer
### Cuidado: peça as quatro entregas juntas; separadas, elas nascem desacopladas e você paga o encaixe depois

Estou escalando nosso design system. Para o componente Field (label + input + mensagem de erro):

1. Crie a fonte de tokens em tokens/color.json no formato DTCG ($value/$type), com accent e danger, e um style-dictionary.config.ts que gere saídas para CSS, JS, iOS (Swift) e Android (XML). NÃO edite os arquivos gerados em build/.
2. Implemente src/components/ui/field.tsx com tailwind-variants (tv): use slots (base, label, input, erro) e uma variante `invalido` que altere AO MESMO TEMPO o input e o label. Consuma os tokens via var(--...), zero hex solto.
3. Gere field.stories.tsx com uma story por estado (normal, com erro, desabilitado), uma play function que digite no campo e verifique aria-invalid, e parameters.a11y.test = "error" para que violações de acessibilidade quebrem o teste.
4. Adicione um changeset (minor) descrevendo a adição do Field.

Critérios: contraste AA; foco de teclado visível via focus-visible; o painel de acessibilidade do Storybook deve passar sem violações.

### O que faz: converte os tokens do projeto para o formato aberto e publica o design system como catálogo instalável
### Onde entra: conversa com o agente, quando um segundo projeto passa a consumir as mesmas peças
### Cuidado: os critérios de aceite no fim são a parte que vale; sem eles a entrega parece pronta e o contraste reprova no tema escuro

Vou converter e distribuir nosso design system. Faça em quatro entregas:

1. Converta os tokens atuais do projeto para o formato DTCG em tokens/tokens.json ($value/$type), com cor em OKLCH, aliases semânticos (accent, danger, success) e dois temas (light e dark).
2. Configure o Terrazzo para emitir custom properties escopadas por [data-theme="light"] e [data-theme="dark"] a partir desse tokens.json. NÃO edite os arquivos gerados; trate a pasta de saída como build.
3. Ligue o bloco de tema do Tailwind às custom properties geradas, sem nenhum hex solto no código.
4. Crie um registry.json na raiz expondo nosso KPI card e as convenções de projeto como itens instaláveis pela CLI do shadcn.

Critérios de aceite: o contraste de texto sobre fundo passa em WCAG 2.2 AA nos DOIS temas (me mostre os pares medidos); nenhuma cor hexadecimal aparece fora do tokens.json; e a instalação do nosso KPI card num projeto limpo termina sem erro.