Frontends com Vibecoding
Capítulo: Stripe: quando a interface reduz o custo de conformidade
Trechos: 7 pedidos prontos para colar no seu agente

Leia o LEIA-ME.txt desta pasta antes de usar. A página do capítulo explica a
decisão; estes trechos só executam o que a página já decidiu.


### O que faz: pede um checkout em que o número do cartão nunca toca o seu código
### Onde entra: no agente, quando você já instalou os pacotes de pagamento no projeto React
### Cuidado: se o agente devolver um input próprio para o cartão, recuse a entrega inteira

Crie um formulário de pagamento React com @stripe/react-stripe-js que isole o cartão por design.

Estrutura obrigatória:
- Crie a Promise do loadStripe UMA vez, fora do componente, usando apenas a publishable key (pk_).
- Envolva o formulário no provider <Elements> recebendo essa Promise.
- Use um único <PaymentElement> para capturar o pagamento (um campo, muitos métodos).
- Deixe explícito em comentário: a secret key (sk_) cria o PaymentIntent no SERVIDOR e nunca aparece no frontend.

Regras inegociáveis:
- O número do cartão vive no iframe do Stripe Elements; o JSX nunca lê nem armazena o número.
- Mostre estado de erro e de sucesso ligados aos eventos do Elements, com mensagem anunciada por aria-live.
- Foco visível no botão de pagar; contraste AA; cores por token, sem hex cru.

Não capture o cartão num <input> próprio: isso quebra o isolamento PCI e encarece a conformidade.


### O que faz: pede um herói com gradiente de aurora feito só em CSS, sem WebGL
### Onde entra: na primeira dobra de uma página de marca, quando você quer a sensação premium sem custo de shader
### Cuidado: o teste de contraste mira o ponto mais escuro do gradiente, nunca a média

Crie uma seção hero "premium calma" em React + CSS que evoque a aurora estilo Stripe sem copiar a marca.

Fundo:
- Use APENAS CSS: um conic-gradient e dois radial-gradient sobrepostos para sugerir profundidade de aurora.
- Anime somente a posição do fundo (background-position), nunca largura, altura ou layout.
- Aplique um skewY leve no container como gesto geométrico, com overflow: hidden.
- NÃO use canvas, WebGL, shader nem qualquer biblioteca de gradiente animado.

Cores e tipografia:
- Todas as cores vêm de tokens (var(--accent), var(--accent-dark), var(--card), var(--text)); zero hex cru no código.
- Uma única cor de acento; o resto é tipografia sobre fundo claro. Título em peso 300-400, muito espaço em branco.

Guardas inegociáveis:
- Sob prefers-reduced-motion: reduce, desligue a animação e entregue um fundo estático equivalente.
- O gradiente é decorativo: marque-o como aria-hidden; o conteúdo e o CTA funcionam sem ele.
- Contraste AA do texto: teste o ponto MAIS escuro do gradiente, não a média.
- Foco visível no CTA, com outline e offset.

Comente por que você animou só background-position (composited, sem reflow).


### O que faz: pede um campo de pagamento com os quatro estados visuais e semânticos casados
### Onde entra: em qualquer formulário sensível, não só de cartão
### Cuidado: borda vermelha sozinha não chega a quem não enxerga cor

Crie um campo de pagamento React acessível com quatro estados visuais e semânticos: vazio, digitando, erro e sucesso.

Contrato obrigatório:
- Label associado ao input (for/id ou aria-label); nunca dependa só do placeholder.
- Foco visível no estado de digitação: outline com offset, jamais outline:none sem substituto.
- aria-invalid="true" no estado de erro, removido nos demais.
- aria-describedby ligando o input à mensagem de erro.
- Região aria-live="polite" que anuncia a mensagem de erro sem roubar o foco; role="alert" só entra no estado de erro.

Regras:
- Estado visual e estado semântico andam juntos: a borda vermelha SEMPRE vem acompanhada de aria-invalid e mensagem anunciada.
- Cores por token (var(--border), var(--accent), var(--card), var(--text)) e tons semânticos de status; contraste AA.
- Não use cor sozinha para indicar erro: combine com ícone ou texto.


### O que faz: pede a página de documentação de duas colunas, com abas de linguagem e botão de copiar acessíveis
### Onde entra: na documentação pública de um produto que tem cliente técnico
### Cuidado: aba que só muda de cor não chega a quem não distingue cor

Crie um componente React + Tailwind chamado DocLayout que reproduza a documentação de duas colunas estilo Stripe: prosa à esquerda, código à direita.

Layout:
- Coluna esquerda: explicação em prosa clara, sem jargão de vendas.
- Coluna direita: bloco de código sobre fundo escuro, com tabs de linguagem (ex.: Node, Python, Ruby).
- No desktop, as colunas ficam lado a lado; no mobile, empilham (prosa primeiro, depois código).

Regras obrigatórias de acessibilidade:
- As tabs de linguagem são navegáveis por teclado: implemente o padrão ARIA tablist (role="tablist", role="tab", role="tabpanel", aria-selected), com navegação por setas e Home/End.
- Botão "copiar" acessível: é um <button> real com aria-label descritivo ("Copiar exemplo em Node"); ao copiar, anuncia o sucesso por uma região aria-live="polite" ("Copiado"), sem roubar o foco.
- Contraste AA do código sobre o fundo escuro: use tokens (var(--code-bg), var(--code-text)), nunca hex cru no JSX.
- Foco visível em tabs e no botão copiar: outline com offset, nunca outline:none sem substituto.

Não use cor sozinha para indicar a tab ativa; combine cor com peso ou borda inferior, para não depender de percepção cromática.


### O que faz: pede um aviso de chave de teste que ensina higiene de segredo no próprio texto
### Onde entra: na página de primeiros passos de uma documentação de API
### Cuidado: o componente precisa recusar chave de produção em vez de exibi-la

Crie um componente ApiKeyCallout para uma página de documentação. Ele exibe uma chave de API de TESTE pessoal e ensina, no próprio texto, a higiene de segredos.

Comportamento:
- Mostra uma chave de teste (prefixo pk_test_ ou sk_test_) que a plataforma injeta com segurança no contexto do usuário logado. Deixe explícito no texto que é uma chave de TESTE, nunca de produção.
- Inclui um botão "copiar" acessível (<button> com aria-label, confirmação por aria-live), igual ao da documentação.
- Um aviso claro e calmo: a chave real (de produção) é injetada pela plataforma no servidor; NUNCA deve ser colada no frontend nem commitada no repositório.

Regras inegociáveis:
- O componente NUNCA recebe nem renderiza uma chave secreta de produção (sk_live_). Se receber algo que comece com sk_live_, renderiza um erro de segurança em vez da chave.
- Inclua um comentário no topo: segredo de produção jamais trafega pelo front; ele é injetado no backend pela plataforma.
- Use tokens para as cores (var(--card), var(--text), var(--accent)); contraste AA; foco visível no botão copiar.

O tom é didático e tranquilo, não alarmista: explica a razão, não só a proibição.


### O que faz: pede um mural de logotipos de clientes que é honesto por construção
### Onde entra: na página inicial, abaixo da primeira dobra
### Cuidado: logotipo sem permissão de uso e número sem origem não entram, e o componente precisa impedir isso sozinho

Crie um componente LogoWall que exiba logos de clientes como prova social, de forma honesta por construção.

Layout:
- Uma faixa discreta com logos em tons neutros (grayscale por padrão), alinhados em grade responsiva.
- Um título sóbrio, ex.: "Usado por equipes de engenharia".

Regras de honestidade inegociáveis:
- Cada logo recebe o nome real da empresa em alt (ex.: alt="Logo da Acme"); logo decorativo sem nome não entra.
- O componente só aceita logos de clientes que deram permissão de uso: cada item tem um campo permissao: true; itens sem permissão são filtrados e NÃO renderizam.
- NÃO inventar métrica. Se for exibir um número ("usado por N empresas"), ele vem por prop a partir de dado real e auditável; sem o dado, o número não aparece.
- Nada de logo de empresa que está só em trial apresentado como cliente pagante.

Acessibilidade:
- Os logos são imagens com alt textual; se a faixa for puramente ilustrativa, agrupe sob um aria-label de seção.
- Contraste AA do título e de qualquer texto; cores por token.
- Se houver animação de carrossel, respeite prefers-reduced-motion e ofereça controle de pausa.

Inclua um comentário deixando claro: só logos com permissão; nenhuma métrica inventada.


### O que faz: pede a paleta de comandos que abre por atalho e funciona inteira pelo teclado
### Onde entra: em documentação e em painel administrativo com muitas rotas
### Cuidado: é o componente que mais vira armadilha de teclado, porque o foco fica no campo e a seleção anda pela lista

Crie um componente CommandPalette acessível (estilo paleta de comandos), para busca e navegação rápida em uma página de documentação.

Comportamento:
- Abre por atalho (ex.: Ctrl/Cmd+K) e por um botão visível.
- Um campo de busca filtra uma lista de comandos/links em tempo real.
- Setas para cima/baixo movem a seleção; Enter ativa; Esc fecha e devolve o foco a quem abriu.

Regras de acessibilidade inegociáveis (padrão combobox/listbox ARIA):
- O campo tem role="combobox", aria-expanded, aria-controls apontando para a lista (role="listbox").
- Cada item é role="option" com id; o item destacado é indicado por aria-activedescendant no campo (o foco do DOM fica no input, a seleção "virtual" anda pela lista).
- Trap de foco enquanto aberta; ao fechar, o foco volta ao gatilho.
- Esc sempre fecha. Clique fora fecha. Sem fechar, nenhuma interação por trás vaza.
- Contraste AA do item destacado (não dependa só de cor; combine com peso ou marcador); foco e destaque visíveis.
- Respeite prefers-reduced-motion em qualquer transição de abertura.

Use tokens para todas as cores. Anuncie a contagem de resultados por aria-live discreta.