# Contrato · LinkButton

> Segue o modelo de `contratos/ruler.md`. Implementado em
> `app/src/componentes/LinkButton/LinkButton.tsx`, com CSS em
> `estilo/20-popover-torrada.css` (`.pular`) — a **mesma** folha que o
> protótipo carrega.

> **Não é um dos 7 componentes da Fase 1** — mesma nota de escopo de
> `contratos/toggle.md`. Tem página própria em `/componentes/botao-link`
> desde 27/ago/2026, além da vitrine.

O "Responder depois" do onboarding: uma ação secundária, de baixa ênfase, ao
lado de uma ação primária (`Button variant="primary"`).

## Por que não é uma `variant` do `Button`

`contratos/button.md` documenta a base de `.btn`: `padding:10px 15px`,
`border-radius: var(--r-s)`, `border:1px solid transparent` — essa borda
transparente existe **especificamente** para trocar de variant não mudar a
altura da caixa em 2px. `.pular` não participa dessa caixa nenhuma: sem
padding, sem raio, sem borda, `font-size:12px`, cor `var(--t4)`, ganha só
sublinhado no hover. É outra arquitetura de CSS, não outro valor do mesmo
eixo. Forçar os dois na mesma `cva` faria a base de `Button` precisar de um
`padding: unset` condicional só para este caso — a base deixaria de
significar "a caixa que toda variant compartilha".

Confirmado direto no HTML do protótipo: `<button class="pular" id="onb-pular">`,
**sem** `class="btn"` junto.

## Props

| Prop | Tipo | Obrigatória | Observação |
|---|---|---|---|
| `children` | `ReactNode` | sim | o texto — sempre visível, nunca ícone-só |

Sem eixo nenhum (tom, peso, tamanho): `.pular` no CSS não varia. Se surgir uma
segunda necessidade (por exemplo, uma versão de risco), é decisão de design
nova — não adicione prop especulativa agora, mesmo critério da Regra 7.

## Estados (Regra 4)

| Estado | Como |
|---|---|
| normal | padrão |
| hover | `.pular:hover` — sublinhado, cor sobe pra `--t2` |
| foco | anel global (`:focus-visible`), nenhum CSS de foco próprio aqui |
| desabilitado | `disabled` nativo do `<button>` — `.pular` não tem regra `[disabled]` própria no CSS; o navegador aplica o comportamento padrão (sem clique, sem foco por Tab). Ver Pendências |

Não existe "selecionado": `LinkButton` é uma ação, não um controle com estado
persistente — mesma distinção que `Badge` faz entre estático e clicável.

## Acessibilidade

- `<button type="button">` nativo — nome acessível vem do texto visível
  (`children`), nunca de `aria-label` solto, então comando de voz e leitor de
  tela concordam sobre o que o elemento é (WCAG 2.5.3, mesmo critério já
  registrado na story `Interativo` do Botão).
- Foco e ativação por teclado são nativos do `<button>`, nenhum código extra.

## Contraste, medido e corrigido durante a construção

`.pular` usava `color:var(--t4)`. O `test:vitrine` (axe em Chromium real)
reprovou: **4,19:1** contra o fundo da vitrine, abaixo do 4,5:1 exigido pra
texto de 12px — o mesmo defeito que `contratos/block.md` já registra pra
`--t3`/`--t4`. Corrigido para `--t2` (7,95:1). O `:hover` já usava `--t2`;
agora normal e hover têm a mesma cor, e o hover distingue só pelo sublinhado
— não é regressão, é o hover deixar de ser a única forma de alcançar
contraste válido.

## Fora do contrato

- **Não é um link real (`<a>`).** No protótipo, "Responder depois" fecha o
  onboarding — é uma ação, não navegação para outro endereço. Se algum uso
  futuro precisar de `href`, é um componente diferente (`<a>` estilizado),
  não uma prop nova aqui.

## Pendências deste componente

- **`.pular` não tem `[disabled]` visual próprio no CSS.** O `<button
  disabled>` já bloqueia clique e foco (comportamento nativo), mas a cor não
  muda — mesmo problema que `.tgl` tinha antes desta entrega, só que aqui não
  foi corrigido: nenhum uso real de `LinkButton` desabilitado apareceu no
  protótipo para confirmar a aparência esperada, e inventar uma sem
  referência seria o mesmo erro que `contratos/toggle.md` evita no hover.
- ~~Sem página de documentação própria, sem entrada na barra lateral.~~
  **Resolvido** — ver nota no topo do contrato. Achado desatualizado na
  auditoria de 21/set/2026.