Frontends com Vibecoding
Capítulo: Booking: a fronteira entre persuasão que converte e passivo que se acumula
Trechos: 6 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 uma primeira dobra imersiva com teto de peso e plano B declarados
### Onde entra: em página de marca, quando o objetivo da tela é deixar lembrança e não acelerar decisão
### Cuidado: sem o teto declarado no próprio pedido, o agente entrega beleza que reprova em celular lento

Crie uma hero de marca inspirada na escola imersiva (storytelling por scroll e microinteração), mas com as guardas que a tornam segura para produção.

Requisitos de experiência:
- Uma sequência scroll-driven: ao rolar, o título revela em etapas e um elemento visual reage ao progresso (use IntersectionObserver ou scroll progress, não libs pesadas se um efeito simples resolve).
- Microinterações com propósito: hover e foco com transição suave (transform/opacity, nunca propriedades que causam layout).
- Tipografia como protagonista: escala tipográfica generosa, hierarquia clara, espaçamento amplo.

Guardas inegociáveis:
- Respeite prefers-reduced-motion: reduce. Desligue parallax, autoplay e qualquer movimento não essencial, mantendo o conteúdo legível e estático.
- Progressive enhancement: a hero comunica a mensagem e tem o CTA acessível SEM o efeito; a animação é camada extra que degrada com elegância.
- Budget: anime só transform e opacity (composited), nada de animar width/height/top. Alvo de LCP < 2,5 s.
- Acessibilidade: contraste AA do texto sobre o fundo animado (use overlay sólido se preciso); foco visível no CTA; nada de conteúdo essencial preso atrás da animação.

Não use WebGL se um efeito de CSS/Canvas leve entregar a mesma sensação. Justifique a escolha técnica no comentário.


### O que faz: pede o cartão de resultado denso, com nota, comodidades e preço na mesma varredura
### Onde entra: em qualquer lista de resultados que a pessoa precisa comparar rápido
### Cuidado: a nota precisa dizer a escala em voz alta, porque uma caixa colorida não informa nada a quem não a vê

Crie um componente React + Tailwind chamado PropertyCard que reproduza a densidade e a hierarquia de um card de resultado estilo Booking.

Layout:
- Foto da propriedade à esquerda (proporção 4:3), com alt obrigatório descrevendo a propriedade.
- À direita: nome da propriedade como link (cor de destaque azul, via token, não hex cru), localização em texto secundário, bloco de comodidades (Wi-Fi, café, estacionamento) e, na coluna final, o bloco de preço com CTA.
- Badge de score: caixa azul-escura com o número e o rótulo, ex.: "8,4 Excelente", escala de 1 a 10. Use vírgula decimal (pt-BR).

Regras obrigatórias:
- Use CSS custom properties para todas as cores: var(--accent), var(--score-bg), var(--text), var(--text-muted). Nada de hex direto no JSX.
- Contraste mínimo AA em ambos os temas (claro e escuro).
- Estado de foco visível em todos os elementos interativos (link do nome e CTA): outline com offset, nunca outline:none sem substituto.
- O nome é um <a> real navegável por teclado; o CTA é um <button> ou <a> com rótulo descritivo ("Ver disponibilidade em [nome]").
- Densidade alta mas legível: a comparação entre cards deve ser fácil de varrer.

Não adicione nenhum selo de escassez ou urgência neste componente. Ele recebe apenas dados de propriedade.


### O que faz: pede a caixa de busca em destaque e a coluna de filtros acessível
### Onde entra: no topo de uma página de resultados, quando a busca é a ação principal da tela
### Cuidado: o acento amarelo costuma reprovar em contraste; escureça o token ou use texto escuro sobre ele

Crie dois componentes para uma página de resultados estilo Booking.

1) SearchBox: uma caixa de busca destacada sobre o header, com acento amarelo (token var(--highlight)). Campos: destino, datas, hóspedes. É o elemento de maior peso visual da página (search-first). O botão de buscar tem rótulo claro e foco visível.

2) FacetNav: uma navegação facetada acessível, na coluna lateral:
- Grupos de filtros (faixa de preço, estrelas, comodidades, nota mínima).
- Cada faceta é um checkbox com <label> associado e a contagem de resultados ao lado, ex.: "Wi-Fi grátis (128)".
- Use <fieldset> + <legend> por grupo.
- A coluna de filtros é sticky no desktop e vira um drawer acessível no mobile (com trap de foco e fechar por Esc).
- Toda a navegação funciona por teclado: Tab entre checkboxes, Espaço para marcar.

Acessibilidade da contagem dinâmica:
- Inclua uma região aria-live="polite" que anuncia o total quando os filtros mudam, ex.: "312 resultados".
- Não roube o foco ao atualizar a lista.

Use tokens para todas as cores. Garanta contraste AA do acento amarelo contra o texto sobreposto (amarelo claro costuma falhar; escureça o token ou use texto escuro sobre ele).


### O que faz: monta a base de cor e de tipografia com as fontes que já vêm no aparelho
### Onde entra: no arquivo de estilo global, antes de qualquer componente
### Cuidado: a forma abreviada de declarar fonte zera altura de linha e peso em silêncio

Configure o design system base de uma página estilo Booking em CSS puro.

1) Tokens de cor em :root como custom properties: o azul de marca (--brand), o azul de destaque/links (--accent), o amarelo de acento da busca (--highlight), o off-white de fundo (--surface), texto e texto secundário, e os tokens do badge de score. Defina também o tema escuro em [data-theme="dark"] reatribuindo os mesmos tokens, mantendo contraste AA.

2) Font stack de system fonts CORRETO. Use a propriedade font-family com system-ui no topo, seguida dos fallbacks de cada plataforma. NÃO use o shorthand font:, porque a lição da Booking é que o shorthand font: zera propriedades não declaradas (line-height, weight) e quebra herança de forma silenciosa. Declare font-family isolada.

Entregue um bloco :root com os tokens, o bloco [data-theme="dark"], e a regra body com o font stack.


### O que faz: pede o aviso de últimas unidades que só existe quando o estoque confirma
### Onde entra: no cartão de resultado, e em nenhum outro lugar
### Cuidado: se o aviso sobreviver a apagar o dado do sistema, a escassez era fabricada

Crie um componente ScarcityBadge para um card de propriedade. Ele é o caso ético crítico: só pode existir quando o dado real comprovar.

Regras inegociáveis:
- O selo SÓ renderiza quando quartos_restantes vier da API real e for menor ou igual a 3. Caso contrário, renderiza null.
- O número nunca é hardcoded, nunca é decorativo, nunca é um valor de exemplo deixado no código. Vem sempre da resposta da API.
- Nada de contador regressivo que reinicia no reload. Nada de "reservado 3 minutos atrás" fabricado.
- O texto é preciso e concorda em número: "Resta 1 quarto nesta tarifa" no singular, "Restam 2 quartos nesta tarifa" no plural. Só aparece se for verdade.
- Inclua um comentário no topo deixando explícito: nunca hardcode número de escassez; se o dado não confirmar, não renderize nada.
- Exponha a origem do número (campo da API) de forma rastreável, para auditoria.

Use tokens para a cor de alerta (var(--alert)), com contraste AA. O selo é informativo, não um <button>; use role/markup semântico adequado.


### O que faz: monta um teste de duas versões de botão sem plataforma nenhuma
### Onde entra: quando você quer decidir a copy do botão por dado e ainda não tem ferramenta de experimentação
### Cuidado: variante sorteada a cada exibição faz o botão piscar entre versões e transforma o seu dado em ruído

Crie um setup mínimo de teste A/B para o texto de um CTA, espelhando a cultura "tudo é teste" da Booking, mas na escala de quem está começando, sem plataforma de experimentação e sem libs externas.

Requisitos:
- Um hook useVariant(experimentId, userId) que atribui a variante de forma determinística: o mesmo usuário sempre cai na mesma variante (atribuição estável por hash do id, módulo número de variantes). Sem aleatório por render.
- Duas variantes de copy do botão: "Ver disponibilidade" (A) e "Reservar agora" (B).
- Registro de exposição (quando a variante é mostrada) e registro de conversão (quando o CTA é clicado), com o id da variante anexado ao evento.
- Leitura honesta: o evento registrado permite calcular taxa de conversão por variante. Não force vitória; só decida com volume suficiente.

Não use cookies de terceiros. A atribuição depende só de um id estável do próprio usuário/sessão.