Agendamento de reunião em três passos

Um painel de vidro na largura da coluna, sem imagem, com três telas que se trocam no mesmo lugar. Na primeira, uma fila de dez dias úteis: dia da semana em caixa alta, número grande em display, mês, e embaixo quantos horários aquele dia tem — o dia lotado continua na fila, apagado e de contorno tracejado. Na segunda, a grade de horários daquele dia, em blocos, com o fuso declarado ali mesmo, numa pílula. Na terceira, o resumo do que foi escolhido — editável em um clique, sem sair da peça — e quatro campos: nome, e-mail, telefone e uma linha de assunto.

O problema editorial é o do atrito da primeira conversa. Uma assessoria não vende no site: o site marca a reunião. E o ponto em que se perde a pessoa é justamente o link que a leva embora — para o Calendly, para o WhatsApp, para o e-mail que ela vai mandar depois. Quem já escolheu quinta às 15h30 preenche o nome; quem tem de sair da página some. Por isso a ordem aqui é invertida em relação a todo formulário de captura: primeiro quando, depois quem. O formulário é a última tela, e chega quando a pessoa já investiu duas decisões na peça.

Quando usar

• Quando o próximo passo do funil é uma reunião com hora marcada, e existe agenda real por trás para sustentá-la.
• No fim da página, depois de a proposta e a prova social já terem sido apresentadas — ou como dobra de destino de um botão "agendar" que vem do topo.
• Quando a agenda é enxuta e curada (dez dias, meia dúzia de horários por dia). Uma agenda de três meses não cabe nesta forma: ali o certo é um calendário de mês, que é outro componente e ainda não existe na biblioteca.
• Uma vez por página. Duas peças de agendamento na mesma rolagem viram dúvida sobre qual é a de verdade.

Quando não usar

• Quando a captura é genérica e a data se combina depois, por e-mail ou telefone: aí o certo é o conversao/cta-formulario-lead. A regra de bolso: se a empresa não tem horário para oferecer agora, pedir que a pessoa escolha um é promessa que não se cumpre — e um horário confirmado que ninguém honra custa mais caro que um lead que demora um dia. Os dois não se substituem; ver o gotcha "qual dos dois usar".
• Quando o que falta é a pessoa se reconhecer antes de falar com alguém: conversao/diagnostico-perfil é a peça do meio da página, e os dois se completam — o diagnóstico termina num botão que pode apontar para cá.
• Como abertura de página. A dobra de topo precisa dizer o que a empresa faz antes de pedir uma quinta-feira.
• Quando a agenda muda de minuto em minuto e a página é estática e cacheada: a peça mostraria vagas que já não existem. Ou a página passa a ser renderizada com a agenda do momento, ou o campo de horário vira janela ("manhã", "tarde") — ver a variação sem o passo de horário.

Padrão editorial

Especificação dos assets

Nenhum. É uma peça de tipografia e contorno: o que ocupa a dobra é a agenda. Uma foto ao lado empurraria a fila de dias para meia coluna, e dez dias em 500px não cabem sem virar trilho já no desktop. O que a seção precisa é de largura — a fila de dez dias mede 1018px a 1440, e é o que a mantém sem rolagem — e de uma âncora de destino para o href="#contato" do botão alternativo.

Compliance

A peça marca uma conversa. Ela não faz diagnóstico, não analisa carteira e não recomenda nada — e o texto tem de dizer isso onde a pessoa lê, não no rodapé.

O que o consumidor tem de trocar antes de publicar:

1. O envio. >>> O FORMULÁRIO NÃO ENVIA NADA. <<< O handler valida, trava e mostra a confirmação, e é só isso: nenhuma requisição sai da página. O ponto de ligar o endpoint está marcado ENVIO no script.js, com o exemplo de fetch e o lembrete de tratar o erro de horário já tomado. Publicar assim significa marcar reuniões que ninguém vê.
2. A disponibilidade. Datas, vagas e horários do markup são exemplo, marcados como CONTEÚDO ILUSTRATIVO. Ou o bloco passa a ser impresso pela agenda de verdade, ou a página vira uma promessa de horário que não existe.
3. O fuso. Está escrito "GMT-3, fuso de Brasília" em dois lugares (a pílula do passo 2 e o rodapé do resumo). Trocar pelo fuso de quem atende. Se o público é internacional, some a obrigação de dizer o fuso do cliente também — e aí o campo vira um select de fuso, que esta peça não traz.
4. A política de privacidade. O .agd-nota do passo 3 diz para que os dados servem. Onde a área jurídica do cliente exigir, ele recebe o link para a política e a menção à LGPD; o lugar é ali, ao lado do botão, e não em letra miúda no fim da página.
5. A voz. Nada de "consultoria gratuita de investimentos": consultoria é atividade regulada, e prometer análise de carteira numa conversa de 30 minutos promete o que só existe com contrato. Nada de retorno, nem insinuado; nada de superlativo de mercado; nenhum nome de instituição real. O texto que está no markup diz o essencial: uma conversa para entender o caso e explicar como a assessoria trabalha e como é remunerada — taxa previamente acordada.
6. A confirmação. O texto de sucesso promete um retorno ("um assessor confirma por e-mail em até um dia útil"). É uma promessa operacional: só deixe no ar se o processo do cliente a sustenta.

Dado pessoal. A peça coleta nome, e-mail e telefone, e não grava nada: sem localStorage, sem sessionStorage, sem cookie. As escolhas vivem nos próprios <input> e morrem no recarregamento. Medido depois do fluxo inteiro, com o formulário já enviado: localStorage 0 chaves, sessionStorage 0 chaves, document.cookie vazio. São dados de contato de alguém com patrimônio — gravar "para não perder o preenchimento" deixaria isso no navegador de um computador que pode ser compartilhado.

Como usar

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

O script precisa do core/motion.js carregado antes (lê LIB.reduce e LIB.onScroll), e a página precisa de uma âncora #contato para o botão alternativo do bloco sem JavaScript.

Ganchos

Variações

• cinco dias em vez de dez — apague blocos .agd-dia e as grades correspondentes; nada no script conta dez.
• sem o passo de horário — dois blocos por dia ("manhã", "tarde") no lugar da grade. É a saída para agenda sem encaixe fixo.
• datas recalculadas a partir de hoje — data-agd-recalcular na seção. Para página estática e para o showroom; nunca para produção com agenda real.
• em seção clara — .sec-paper no lugar de .sec-dark; confira o .glass, que foi desenhado para fundo escuro.
• sem reveal de entrada — apague o data-rv do .agd-painel; a peça passa a valer com o JavaScript da página inteiro desligado.

Gotchas

• Qual dos dois usar, e a pergunta que decide. Este e o conversao/cta-formulario-lead parecem o mesmo componente e não são: lá o formulário é a porta (foto de fundo, lista de benefícios, card de captura, e a data se combina depois); aqui o formulário é o último passo, e o que abre a peça é a agenda. A pergunta que decide não é de design, é de operação: a empresa tem horário para oferecer agora? Se tem, esta peça tira o atrito de duas semanas de e-mail. Se não tem — agenda cheia, equipe pequena, atendimento por triagem —, ela vira uma promessa que o time não honra, e aí o cta-formulario-lead é o certo. Os dois cabem na mesma página em dobras diferentes: capturar quem só quer material, agendar quem já quer conversar.

• A disponibilidade vive no HTML, e essa é a decisão que sustenta a peça. Cada dia é um <input> com value, data-agd-rotulo e data-agd-vagas; cada grade é uma <div data-agd-dia> que casa com o value do dia. O script só reage — ele não sabe o que é um dia útil, não constrói horário e não tem tabela nenhuma. Plugar um backend é imprimir esse mesmo bloco com a agenda de verdade, e nenhuma linha de JavaScript muda. O contrário — a agenda descrita num objeto no script — obrigaria todo consumidor a editar o script.js, que é justamente o arquivo que a biblioteca pede para colar sem tocar.

• O value do horário carrega a data inteira, e não só a hora. 2026-03-12T15:30, não 15h30. Parece redundante, já que o dia tem o próprio radio — e não é: sem JavaScript as oito grades ficam todas visíveis, e nada impede alguém de marcar "quinta, 12" na fila e "10h00" na grade de segunda. Com a data no value, o par chega inteiro do lado de lá mesmo num envio de formulário comum, e o dia marcado vira conferência, não fonte única. É também o que o fetch do exemplo manda: um campo só, sem remontar data no servidor.

• Trocar o dia limpa o horário — sempre, e sem perguntar. Manter "15h30" marcado depois de trocar de quinta para sexta produziria uma reunião que o resumo mostra certa e a agenda não tem: a grade seguinte é outra, e aquele horário pode nem existir nela. Medido: escolhido 12/03 às 15h30, ao escolher 06/03 o .agd-hora-in:checked volta a null e a grade visível passa a 2026-03-06. O que não se perde é o caminho de volta: "Editar" no resumo devolve ao passo 1 com dia e horário intactos — medido, dia 2026-03-12 e hora 2026-03-12T15:30 ainda marcados depois do retorno. Limpar é consequência de trocar, não de voltar.

• 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 o primeiro dia só de passar por ele, e seria levado para a grade de horários antes de chegar no dia 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 com mouse de verdade (Chrome headless, mousedown/mouseup no dia 12): 400ms de espera para o dia marcado acender, mais 260ms de saída, e o passo 2 no lugar com a grade certa e o foco no título novo. Medido por seta: ArrowRight no primeiro dia move a marcação para 03/03 e troca a grade, e 900ms depois a peça continua no passo 1. Mesma decisão do conversao/diagnostico-perfil, e pela mesma razão.

• O botão "Continuar" existe sempre, e não só em movimento reduzido. Nasce disabled e libera quando o passo é respondido — medido nos dois passos. Em movimento reduzido ele é o único caminho: medido com prefers-reduced-motion, um clique de ponteiro no dia deixa a peça no passo 1 mesmo 900ms depois, e o Continuar leva adiante normalmente. Escondê-lo quando o avanço automático está ligado deixaria quem chega de teclado sem controle visível de avanço, já que o avanço dele nunca dispara.

• O dia sem vaga é disabled no <input>, e nada mais. Sem classe de estado, sem pointer-events:none, sem tratamento no script: o disabled já tira o dia da ordem de tabulação e da navegação por seta do grupo de radio, que é comportamento nativo. Medido: focus() no dia lotado não move o activeElement, click() não marca, e o dia que estava escolhido continua escolhido. O CSS só reage — .agd-dia-in:disabled ~ .agd-dia-marca desenha o contorno tracejado e apaga os números. Escrever isso à mão seria reimplementar, pior, o que o navegador já faz.

• A fila de dias é um grid só, e não há breakpoint que a transforme em trilho. grid-auto-columns:minmax(92px,1fr) com overflow-x:auto: enquanto as dez colunas couberem elas crescem e dividem o painel; assim que não couberem, a caixa rola. Medido a 1440: dez dias de 93px num trilho de 1018px que não rola (scrollWidth === clientWidth). Medido a 390: dias de 92px, scrollWidth 1004 contra clientWidth 304, rolagem horizontal dentro da caixa — e a página não acompanha, nem depois de rolar o trilho até o fim (document.scrollWidth === clientWidth, window.scrollX 0). Os 92px não são gosto: são o que "4 horários" pede em 10,5px com tracking, mais o respiro. Encurtar esse texto é o que permite baixar o número.

• O trilho tem padding:6px, e é por causa do anel de foco. O :focus-visible do core sai 3px para fora do dia com 2px de traço; sem esse respiro, a própria caixa de rolagem cortaria o anel — justamente em quem depende dele para saber onde está. Medido no primeiro dia: 2px solid rgb(198,206,170) com offset 3px, numa caixa de 93×118 — o dia inteiro, não um quadradinho de radio perdido no canto.

• No celular, voltar ao passo 1 traz o dia escolhido de volta à vista. Um trilho de 1004px rolado até o dia 9 e depois devolvido ao começo faria a pessoa procurar a própria escolha. O script recentra o dia marcado — mas só quando há rolagem de verdade (scrollWidth > clientWidth), porque no desktop os dez dias cabem e um scrollLeft forçado seria movimento sem motivo. Medido a 390: depois de "Editar", scrollLeft 700 e o dia escolhido inteiro dentro da caixa.

• O piso do palco cobre os passos 1 e 2, e deixa o 3 crescer. Sem piso, cada troca daria um solavanco e a página inteira dançaria sob quem está lendo. Com um piso que coubesse o passo 3 — um formulário de quatro campos —, sobrariam mais de 200px de vão morto embaixo da fila de dias. clamp(292px,32vh,360px) é o meio-termo: medido a 1440, os passos 1 e 2 ficam ambos em 292px, e o 3 passa disso por conta própria. É a diferença para o conversao/diagnostico-perfil, onde o piso é medido pelo script: lá as cinco telas são do mesmo tipo e só variam com a quebra de linha do enunciado, e nenhum clamp acerta; aqui os três passos são de tipos diferentes, e igualá-los seria esconder essa diferença.

• O .is-in é tirado e reposto a cada entrada de passo. Se ficasse, voltar ao horário depois de trocar o dia mostraria a grade nova já montada, sem entrada nenhuma — a classe já estava lá, e a transição não roda de novo. Entre tirar e repor há um void entra.offsetWidth: sem esse reflow o navegador junta o "deixou de ser display:none" e o "ganhou .is-in" no mesmo recálculo, e a animação simplesmente não acontece. Medido no meio da entrada: blocos de horário em opacity 0.815, escalonando.

• A troca de passo não usa data-rv, e não pode usar. O data-rv do core é observer de entrada na tela: dispara uma vez, desobserva e nunca mais volta. Uma peça que troca de conteúdo três vezes no mesmo lugar precisa de transição por classe. O que o core continua fazendo aqui é o que ele sabe: revelar o painel quando a dobra chega. Por isso o painel fica em opacity:0 se o core/motion.js estiver fora do ar — medido a 390 antes de rolar: painelOpacidade 0; depois de rolar: 1. Vale para todo componente da biblioteca, não é desta peça; quem precisa sobreviver a bloqueador de script usa a variação sem reveal de entrada.

• .agd [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 grid e flex em oito lugares. Sem essa regra, os passos escondidos reapareceriam empilhados, com o atributo lá no inspetor. Mesma pegadinha que o .hgal-nav[hidden] da midia/galeria-scroll-horizontal documenta.

• O estado sem JavaScript é o estado de PARTIDA do markup, e não um <noscript>. Tudo nasce visível; quem esconde os passos 2 e 3, a trilha, o Continuar e o resumo é o script. Medido com o script.js bloqueado (o core vivo): 3 passos visíveis, 10 dias (8 habilitados), 8 grades, 35 blocos de horário, 4 campos e o botão de confirmar de pé; trilha, ações, resumo e mensagem de sucesso escondidos; a nota do .agd-sem-js visível com o botão para #contato; seção de 2720px a 1440 e 3255px a 390, sem estouro horizontal em nenhum dos dois. 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 existe para marcar reunião.

• A recalibragem de datas é opcional, e tem de continuar sendo. Com data-agd-recalcular na seção, o script reescreve os dez dias como os dez próximos dias úteis a partir de amanhã, mantendo posição por posição a disponibilidade que o markup declarou. Medido em 06/09/2026 (um domingo): o primeiro dia vira 2026-09-07 / "Segunda, 7 de setembro" / "Seg 07 set", o terceiro continua "Sem vaga" (2026-09-09), o último vira 2026-09-18, os value dos 35 horários acompanham a data nova e nenhuma grade fica órfã. Sem o atributo, nada disso roda e o markup é a verdade — que é o padrão, porque um arquivo cujo conteúdo só existe depois de executar JavaScript deixa de ser legível para quem revisa. E a recalibragem não inventa disponibilidade: quem sabe quais horários existem é a agenda do assessor.

• Os nomes de dia e mês são arrays no script, não toLocaleDateString('pt-BR'). O resultado do toLocale depende do ICU que o navegador embarca: "seg." com ponto numa versão, "segunda-feira" por extenso em outra. A fila tem 92px de largura por dia — uma abreviação a mais quebra o desenho, e quebraria sem aviso, meses depois, numa atualização de navegador.

• O <input> está esticado sobre o dia inteiro com appearance:none, e não escondido com opacity:0. Com opacity:0 o anel de foco some junto com o widget e quem navega por teclado perde o indicador. Do jeito que está, o :focus-visible do core cai em volta do dia inteiro, e o clique em qualquer ponto chega ao input sem depender de for/id — que colidiria se o componente aparecesse duas vezes na mesma página. O rótulo para o leitor de tela vem de aria-label no próprio input ("Segunda, 2 de março, 4 horários livres"), porque o conteúdo visual é uma sigla de três letras e um número solto.

• A validação é à mão porque o <form> declara novalidate. A bolha nativa do navegador não é estilizável, aparece fora do painel e some sozinha — num formulário que vive dentro de um passo que troca, ela vira fantasma. O script para no primeiro campo vazio (ou e-mail malformado), marca a caixa com .is-erro, leva o foco e anuncia: medido, .agd-campo.is-erro em 1 campo, foco em nome, aria-live com "Falta preencher Nome completo." — e a mensagem de sucesso continua escondida, porque nada foi enviado.

Histórico

Origem. Não há referência única e não há uma linha copiada. O padrão — fila horizontal de dias com número grande, grade de horários em blocos e formulário curto no fim — aparece em três famílias: as ferramentas de agendamento embutidas (Calendly, Cal.com e parentes), a marcação de consulta de clínica e de laboratório, e o passo de horário de entrega no checkout de e-commerce. O que a biblioteca tirou de todas foi a ordem das telas, não o código. Nunca rodou em produção nossa; o primeiro site que usar deixa a marca aqui. O registro consolidado vai em projetos/autorais.md.

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

• A disponibilidade mora em atributos do HTML e o script só reage — é o que permite plugar um backend sem reescrever a peça.
• Dias e horários são <input type="radio"> reais dentro de <label>, sem for/id, com o input esticado sobre o bloco em appearance:none. Setas, Home/End e disabled são o comportamento nativo do grupo de radio; nada disso é reimplementado.
• O painel consome a primitiva .glass do core, a região viva consome .visually-hidden, o fuso consome .pill/.pill-accent, os botões consomem .btn, a ressalva consome .nota — nenhuma das cinco é recopiada (§6 do contrato).
• A quinta primitiva, .field, veste o wrapper de cada campo — a régua de 1px em --rule-2, o respiro de 16px/12px e o acender no :focus-within vêm do core, e o desligamento em movimento reduzido também. Fica local só o que é daqui: o rótulo, porque o wrapper é o <label> (sem for/id, pelo mesmo motivo dos radios) e por isso o rótulo é um <span class="agd-rot">, que o seletor descendente .field label não alcança. Histórico que vale registrar: entre a criação da primitiva e esta linha, no mesmo dia, .field input trazia outline:none — que com (0,1,1) vencia o ::focus-visible (0,1,0) do próprio core e mataria o anel de teclado deste campo. Este componente foi o único dos três que originaram a receita a manter o anel, e foi por isso que o erro apareceu antes de virar problema de alguém. O core parou de zerar o outline, e a adoção deixou de custar nada.
• Zero cor crua: contorno, texto, vagas, erro e ressalva leem --rule, --rule-2, --accent, --accent-2, --fg, --fg-2 e --fg-muted do escopo da seção. O realce do bloco marcado sai de color-mix(in srgb,var(--accent) 9%,transparent), que é token e não cor.
• 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; escalonamento pelo índice no style de cada bloco, nunca por :nth-child. Em prefers-reduced-motion o escalonamento morre (medido: transition-duration: 0s nos blocos) e o avanço automático não existe — a peça continua inteira e navegável.
• O componente não registra listener de scroll próprio: a primeira tela acende assinando o LIB.onScroll do core (§7.4), com a assinatura se desfazendo assim que acende.
• Acessibilidade: fieldset + legend por passo, foco levado ao título novo com preventScroll, role="group" com aria-label em cada grade, aria-label por dia, região role="status" aria-live="polite" anunciando passo, dia e horário, trilha decorativa em aria-hidden, foco levado à confirmação depois do envio (o botão que a pessoa apertou é travado, e sem isso o foco cairia no <body>), e passos fora de cena com hidden — nunca só opacity.