Diagnóstico de perfil em cinco perguntas

Uma dobra escura, sem imagem, em que a pergunta é a peça gráfica: enunciado na .display-xl do core, e abaixo três ou quatro respostas como linhas grandes — número, texto e um filete que acende na cor de marca. Sem cartão, sem caixa, sem barra de progresso: a lista é o desenho. Um contador 01 / 05 num canto, um "Voltar" pequeno, e o movimento da peça é a própria troca de pergunta — a que sai desaparece com blur e subida, a que entra vem palavra a palavra. No fim, um perfil nomeado entre quatro, com um parágrafo de leitura, três traços e uma faixa de alocação em texto.

O problema editorial é o do primeiro contato que não é um formulário. Quem chega ao site de uma assessoria não quer preencher nome, e-mail e telefone para descobrir se aquilo é para ele; quer se reconhecer. Cinco perguntas de uma linha, respondidas em menos de um minuto, entregam duas coisas ao mesmo tempo: a pessoa sai com um vocabulário para descrever o próprio caso, e o assessor começa a conversa em outro ponto. É por isso que a peça termina num botão e não num campo — a captura é trabalho do conversao/cta-formulario-lead, e a separação entre os dois é o que mantém este componente fora do terreno de dado pessoal.

Quando usar

• No meio da página, depois de a proposta já ter sido apresentada e antes do bloco de conversão. É uma pausa ativa entre duas dobras de leitura passiva.
• Quando o produto é uma conversa, e não uma compra: o resultado precisa de um humano depois dele.
• Quando o público não é homogêneo e a página fala com todos ao mesmo tempo. O diagnóstico é o que permite dizer coisas diferentes a pessoas diferentes sem escrever quatro páginas.
• Uma vez por página. Dois assistentes na mesma rolagem cansam antes do segundo.

Quando não usar

• Quando a peça é um cálculo com números que a pessoa digita: conversao/calculadora-projecao e dados/comparador-cenarios resolvem isso, e com o cuidado de compliance que número exige.
• Quando o que se quer é um painel ao lado de uma foto, com campos variados e um gráfico no fim: conversao/simulador-carteira. Ver o gotcha sobre por que os dois não são o mesmo componente.
• Como abertura de página. A dobra de topo precisa dizer o que a empresa faz antes de perguntar qualquer coisa. E quando as perguntas são de resposta livre ou múltipla escolha: aqui todo passo é escolha única, e é o que sustenta o avanço automático e a navegação por seta.
• Quando o objetivo é qualificar lead para o comercial, ou quando as respostas precisam sobreviver ao recarregamento. Isto não é um formulário disfarçado: nada sai do navegador e nada é gravado — decisão, não limitação. Para qualificar, use o conversao/cta-formulario-lead e pergunte lá, com consentimento.

Padrão editorial

Especificação dos assets

Nenhum. É a única peça desta leva sem imagem, e isso é a forma: o que ocupa a dobra é tipografia. Uma foto ao lado da pergunta transformaria o componente no irmão simulador-carteira. O que a seção precisa é de espaço vertical — a 1440×900 ela mede 1202px de altura, com um palco de 515px que não muda entre as cinco perguntas — e de uma âncora de destino para o href="#diagnostico" do botão final.

Compliance

O que o consumidor tem de trocar antes de publicar:

1. Os pesos e as faixas. data-perf-peso em cada resposta (0 a 3) e data-perf-min / data-perf-max em cada perfil são exemplo editorial, marcados no markup com <!-- CONTEÚDO ILUSTRATIVO -->. Recalibrar com a área técnica do cliente.
2. As faixas de alocação. São ilustrativas e têm de sair como faixa, nunca como percentual cravado: 62% lê como carteira recomendada, 45–65% lê como ponto de partida de conversa. Se o compliance do cliente preferir, troque por rótulo qualitativo ("peso maior em renda fixa") e apague os percentuais.
3. A ressalva. O .perf-nota fica no passo do resultado, onde a pessoa lê o perfil — não em letra miúda no rodapé. O texto que está lá diz o essencial: leitura de conversa, não substitui o questionário de perfil do investidor exigido na abertura de conta, não é recomendação e não promete rentabilidade. Passar pela área de compliance do cliente antes de publicar.
4. A voz dos textos. Nenhum superlativo de mercado, nenhum nome de instituição real, nenhuma menção a rentabilidade — nem no perfil, nem nas respostas.

Dado pessoal. A peça não coleta nome, e-mail nem telefone, e não grava nada: as respostas vivem nos próprios <input> e morrem no recarregamento. Sem localStorage, sem cookie, sem envio. São dados financeiros de alguém, e captura é trabalho do cta-formulario-lead, para onde o botão do resultado aponta.

Como usar

<link rel="stylesheet" href="componentes/conversao/diagnostico-perfil/estilo.css">
<script src="componentes/conversao/diagnostico-perfil/script.js" defer></script>

O script precisa do core/motion.js carregado antes (lê LIB.reduce, LIB.onScroll e LIB.scan), e a página precisa de uma âncora #diagnostico.

Ganchos

Variações

• três ou sete perguntas — acrescente ou tire um .perf-passo. Nada no script conta cinco; só as faixas dos perfis precisam ser reescaladas.
• dois perfis — apague dois .perf-perfil e cubra 0 a 15 sem buraco entre as faixas.
• sem avanço automático — AVANCO = 0 no script. O botão Continuar já é o caminho completo.
• em seção clara — .sec-paper no lugar de .sec-deep; tudo inverte por token, mas confira o contraste do filete aceso.
• sem reveal de entrada — apague o data-rv do .perf-painel; a peça passa a valer com o JavaScript da página inteiro desligado.
• resultado que abre o formulário — o botão final revela o cta-formulario-lead na mesma dobra, em vez de rolar até ele.

Gotchas

• O estado sem JavaScript é o estado de PARTIDA do markup, e não um <noscript>. As cinco perguntas nascem visíveis e empilhadas; quem esconde os passos 2 a 5, a barra e o botão é o script. Medido com o script.js bloqueado: 5 fieldset visíveis, 18 radios, resultado e barra escondidos, a nota do .perf-sem-js de pé com o botão para #diagnostico, seção de 2889px, sem estouro horizontal. O inverso — CSS escondendo e script mostrando — dá uma casca vazia quando o script falha, que é o pior estado possível numa peça que ocupa uma dobra inteira.

• Com o core/motion.js também fora, o painel fica em opacity:0. É o data-rv do core, que só ganha .in por JavaScript, e vale para todo componente da biblioteca — não é desta peça. Medido: painelOpacity: 0. Quem precisa sobreviver a bloqueador de script usa a variação sem reveal de entrada.

• O avanço automático é só para quem clica, e essa é a decisão mais importante do arquivo. Seta em grupo de radio move e marca ao mesmo tempo: quem navega por teclado marcaria a primeira opção só de passar por ela e seria levado à pergunta seguinte antes de chegar na resposta que queria. O script guarda a modalidade da última interação (pointerdown liga, keydown desliga) e só agenda o avanço quando veio de ponteiro. Medido: por mouse de verdade, 654ms do clique até a pergunta nova no lugar (380ms de espera para a linha marcada acender, mais 260ms de saída); por ArrowDown, nada acontece nem depois de 900ms. Avanço automático é agradável para quem clica e é hostil para quem navega devagar — a saída não é escolher um dos dois, é servir cada um pelo caminho dele.

• O botão "Continuar" existe sempre, e não só em movimento reduzido. Ele nasce disabled e libera quando o passo é respondido — medido em todos os cinco passos. Em movimento reduzido ele é o único caminho (o avanço automático não roda: medido, 1000ms depois do clique a peça continua no passo 01). Escondê-lo quando o avanço automático está ligado deixaria quem chega de teclado sem nenhum controle visível de avanço, já que o avanço dele nunca dispara.

• O radio está esticado sobre a linha inteira com appearance:none, e não escondido com opacity:0. Dois motivos, e o segundo é o que decide: com opacity:0 o anel de foco some junto com o widget — o elemento inteiro fica invisível, contorno incluído — e quem navega por teclado perde o indicador. Do jeito que está, o :focus-visible que o core desenha cai exatamente em volta da resposta: medido, 2px em --accent numa caixa de 625×59. E o clique em qualquer ponto da linha chega ao input sem depender de for/id, o que deixa o componente aparecer duas vezes na mesma página sem colisão de id.

• O legend e o nome do perfil levam width:fit-content, e é por causa do anel de foco. Um legend em bloco ocupa a coluna inteira: medido, 1096px de anel em volta de um enunciado de 667px. Quem chega de teclado via um retângulo solto, não a pergunta marcada. Com fit-content o anel abraça o texto. Vale o mesmo para o h3 do resultado, onde a diferença é entre um anel de 1096px e um em volta da palavra "Navegador".

• O piso do palco é medido pelo script, e nenhum clamp de CSS faz esse trabalho. As cinco perguntas medem 483, 515, 366, 397 e 366px: sem piso, cada avanço dá até 149px de solavanco e a página inteira dança sob quem está lendo. A altura de cada passo depende de quantas linhas o enunciado quebra, que muda com o corpo da letra, com a face do tema e com a tradução do texto — um número cravado erraria em metade das larguras. O script mostra e reesconde os cinco passos no mesmo bloco síncrono (o navegador só pinta no fim da tarefa, então nada pisca), escreve o maior em --perf-palco-medido, e refaz a conta quando a largura muda, assinando o laço único do core em vez de registrar listener próprio. Medido depois: 515px em todos os cinco passos.

• O --perf-topo mora no passo, não no palco. É o respiro entre a barra e o enunciado, e parece detalhe. Não é: o script mede a altura do passo para calcular o piso, e padding no palco ficaria de fora da conta — o piso sairia curto pela exata medida do respiro, e os dois passos mais altos continuariam empurrando a página. Aconteceu, e o sintoma foi um palco que ficava em 479px enquanto o passo 02 pedia 515px.

• A media query de celular escreve --perf-palco-min, e não --perf-palco-medido. O script põe a medida no style da seção, e style inline vence qualquer regra de folha. Escrever o mesmo nome na media query não desligaria o piso no celular — a variável intermediária é o que permite ao CSS ter a última palavra sobre a medida do script. E o piso é desligado abaixo de 560px de propósito: ali a pergunta já ocupa a tela inteira, e o piso só abriria um vão morto embaixo da resposta mais curta.

• A troca de passo não usa data-rv, e não pode usar. O data-rv do core é observer de entrada na tela: ele dispara uma vez, desobserva e nunca mais volta. Uma peça que troca de conteúdo cinco vezes no mesmo lugar precisa de transição por classe. O que o core continua fazendo aqui é o que ele sabe fazer: revelar o painel na chegada da dobra, e revelar os blocos do resultado quando ele aparece — para isso o script tira o .in de uma rodada anterior e chama LIB.scan(), que é idempotente.

• A primeira pergunta acende quando a dobra chega, e não na carga. Se acendesse na carga, a animação palavra a palavra terminaria invisível numa peça que fica no meio da página, e a pessoa receberia a pergunta pronta. Quem resolve isso é LIB.onScroll — o laço único do core, que o §7.4 do contrato manda assinar em vez de registrar listener próprio —, com a assinatura se desfazendo assim que acende.

• O índice da palavra vai no style de cada .perf-w, e isso não é valor cru no markup. É --perf-i:3, um número que o CSS multiplica pelo --perf-w-passo. Cravar o escalonamento em :nth-child amarraria o atraso à posição, e reescrever a pergunta (que é o que todo projeto faz) desalinharia a animação sozinho. Mesmo recurso do --frase-cor do conteudo/manifesto-com-imagens.

• .perf [hidden]{display:none} no topo do arquivo não é redundância. O [hidden] da folha do navegador tem especificidade (0,1,0) e perde para qualquer classe que declare display — e o componente declara display:grid e display:flex em vários lugares. Sem essa regra, os passos escondidos reapareceriam empilhados. É a mesma pegadinha que o .hgal-nav[hidden] da midia/galeria-scroll-horizontal documenta.

• min-inline-size:0 no fieldset é obrigatório. A folha do navegador dá min-inline-size:min-content ao fieldset, e uma resposta longa que não quebra estoura a coluna em tela estreita. Medido a 390px depois: overflowX: ok, nenhum elemento passando da borda.

• Isto não é uma variação do conversao/simulador-carteira, apesar de os dois serem assistentes. Aquele é um painel ao lado de uma foto, na dobra de topo, com campos de tipos diferentes (radio em cartão, select, stepper, chips) e uma rosca de alocação no fim — a forma diz "ferramenta". Este é tipografia na largura da coluna, no meio da página, sem imagem, com um tipo de campo só e um perfil em texto — a forma diz "conversa". Os dois cabem na mesma página sem se repetir, e trocar a forma de um pelo outro apaga a razão de existirem dois.

• A pontuação é uma soma linear, e isso é uma simplificação assumida. Cinco perguntas de peso 0 a 3, faixas em 0–4, 5–8, 9–11 e 12–15. Medido: todas as primeiras respostas dão 0 → Guardião; as segundas dão 7 → Construtor; uma combinação de terços dá 10 → Navegador; todas as últimas dão 15 → Legado. Uma soma linear trata as cinco perguntas como igualmente informativas, o que não é verdade — horizonte pesa mais que expectativa sobre o assessor. Quem for calibrar de verdade multiplica o peso por pergunta, e a conta continua cabendo no data-perf-peso.

Histórico

Origem. Não há referência única e não há uma linha copiada. O padrão — uma pergunta por dobra em corpo de manifesto, respostas como linhas clicáveis numeradas, contador discreto e um perfil nomeado no fim — aparece em três famílias de site: onboarding de banco digital e de corretora (perfil de investidor, abertura de conta), assistente de recomendação em e-commerce de alto valor, e quiz editorial de veículo de imprensa. O que a biblioteca tirou de todas foi a forma da tela, não o código. Status externo: nunca rodou em produção nossa. O primeiro site que usar promove, e a ficha registra qual. O registro consolidado vai em projetos/autorais.md.

Decisões da tradução para o contrato:

• O enunciado consome a primitiva .display-xl do core pelos dois parafusos, em vez de recopiar as seis linhas de título display (§6 do contrato). A entrelinha sobe de .95 para 1.02 porque aqui há frase com descendente, e não título de uma palavra.
• Respostas são <input type="radio"> reais dentro de <label>, sem for/id: o par for/id colidiria se o componente aparecesse duas vezes na página, e o contrato proíbe id no CSS e no JS.
• Zero cor crua: filete, texto marcado, número e ressalva leem --rule, --accent, --fg, --fg-2 e --fg-muted do escopo da seção.
• O respiro entre cabeçalho e painel sai de calc(var(--sec-gap) * .34) — a fonte única do ritmo vertical (§4), não um clamp solto.
• Movimento: entrada do painel pelo data-rv do core; troca de passo por transição própria com filter:blur() indo a zero, como o §5 exige; e nada anda sozinho em prefers-reduced-motion — medido, transition-duration: 0s na palavra e no filete, troca em 33ms, avanço automático desligado.
• A região aria-live consome a primitiva .visually-hidden do core em vez de recopiar as seis linhas de esconder-do-olho-mas-não-do-leitor (§6). É o primeiro consumidor dela na biblioteca.
• Acessibilidade que o padrão original raramente traz: fieldset + legend por passo, foco levado ao enunciado novo com preventScroll, região aria-live com "Pergunta 3 de 5", contador com aria-hidden, passos fora de cena com hidden (nunca só opacity), e o fluxo inteiro percorrido só por teclado — 1 Tab do corpo até a primeira resposta, setas para escolher, Enter ou Tab+Enter no Continuar para avançar, 2 Tab do resultado até o "Refazer".