Conta do comprador

Área do comprador V3

O manifesto pode declarar account: "templates/account.json". O Aura usa esse papel para entrada, cadastro, conta, pedidos, detalhe, dados e senha, diferenciados por buyer.view. A descoberta/validação/distribuição considera esse template e seus components como parte integral de uma nova revisão. Nunca sobrescrever a revisão ativa para adicionar páginas; restaurar o Aura oficial cria outro rascunho para revisão/publicação explícita. Tema anterior sem o papel recebe conta desabilitada e mantém as páginas comerciais; não deve anunciar atalhos de conta.

buyer é um DTO privado: enabled, authenticated, profile (nome, e-mail, telefone, documento, tipo), address (principal, em Meus dados/checkout), view, orders/order autorizados e contexto anti-CSRF. Cadastro, alteração e recuperação exigem senha não vazia com no máximo 128 caracteres (até 512 bytes), sem mínimo de 12. Os formulários oficiais mantêm required e maxlength="128", sem minlength nem a descrição antiga. O e-mail de acesso não é editável nesta entrega. O perfil não é fonte de valores históricos de pedidos. O layout deve passar buyer: buyer ao header Liquid; components renderizados isoladamente não herdam esse argumento automaticamente.

Na view cadastro, buyer.registrationFields reflete o painel “Personalizar campos da página de cadastro” (loja_cliente_config e loja_cliente_campo_config):

buyer.registrationFields = {
  standard: {
    phone, document, birthDate, sex, address, whereFound, stateRegistration,
  }, // booleanos: campo habilitado no painel
  custom: [{ id, name, type, required }], // campos personalizados ativos da loja
};

O painel informa quais campos podem aparecer, mas a IA pode remover campos do formulário de cadastro no Liquid sem alterar o painel. O tema mostra cada campo que decidir manter somente quando habilitado e usa exatamente estes nomes: phone, document, birthDate, sex, stateRegistration, whereFound (0 a 6) com whereFoundOther, o endereço (postalCode, street, number, complement, neighborhood, city, state) e custom_<id> para cada campo personalizado. O servidor aceita a ausência de qualquer campo removido do formulário, mesmo que esteja habilitado no painel. Telefone, documento e endereço completo são validados quando enviados; campos personalizados com required não podem ser enviados vazios. Um campo desligado no painel é recusado mesmo que o navegador o envie. Sem a linha de configuração da loja, todos os campos básicos ficam ativos, como o painel os exibe. A prévia do editor usa uma configuração fictícia (padrões históricos e um campo personalizado). A revisão publicada do tema é uma cópia: lojas publicadas antes de o tema-base receber esta marcação precisam restaurar o original ou editar account.liquid para exibir os campos.

O reCAPTCHA está temporariamente suspenso no servidor. Entrada, cadastro, solicitação de recuperação e redefinição de senha dispensam token; o runtime oculta o hook sem carregar o Google. CSRF, origem e demais regras de conta permanecem ativos. O tema não controla essa decisão.

Quando reativados pela plataforma, esses fluxos usam reCAPTCHA v2 checkbox obrigatório no backend. Posicione <div data-recaptcha></div> dentro do respectivo data-buyer-form; o runtime carrega o Google, obtém a chave pública da plataforma e envia o token junto da requisição protegida por CSRF. data-recaptcha-theme="dark" e data-recaptcha-size="compact" ajustam a aparência do widget. Não inclua scripts, chaves ou callbacks no Liquid. Na prévia o hook é demonstrativo e não há comunicação com o Google. Omitir o hook faz o runtime acrescentá-lo ao formulário, sem dispensar a verificação no servidor. O contrato detalhado, renovação e falhas estão na seção de conta do manual de runtime. capabilities.account reflete suporte do bundle e disponibilidade do backend.

Todos os comportamentos funcionais estão no runtime da plataforma. Os hooks de formulários, erros, visibilidade de senha e retorno ao checkout estão na seção Conta de docs/storefront-theme-runtime.md. Links passam por storefront_url, inclusive /conta, /conta/entrar, /conta/cadastro, /conta/pedidos, /conta/dados e /conta/senha. Sair é formulário POST protegido, nunca link GET. Não colocar credenciais em arquivos do tema, URLs ou storage do navegador.

O seletor do editor e laboratório oferece Carrinho (/carrinho) e Cadastro (/conta/cadastro) ao lado das páginas comerciais. Ambos usam a mesma sessão temporária e o mesmo rascunho, inclusive após uma proposta da IA. No editor, ações guiadas como cores, banner e seção aparecem antes da conversa. O carrinho é sempre vazio e suas mutações ficam desabilitadas; o cadastro usa campos e perfil fictícios. Ao pedir uma edição à IA nessas telas, o contexto semântico enviado é cart ou account com view: cadastro, sem itens de carrinho, senhas ou dados particulares no pedido.

O editor/laboratório aceita navegação de conta e contexto semântico account com view validada. Usa exclusivamente buyerPreview() e pedido fictício 1001; não consulta compradores, sessões ou pedidos reais. O engine substitui qualquer buyer recebido em preview e o runtime impede operações antes da rede. A IA recebe somente contexto descritivo da página, sem senhas, sessões ou dados particulares. Não mudar esses limites para demonstrar telas. No storefront, conta/pedidos e qualquer página personalizada são private,no-store e não podem ir para cache compartilhado. Consulte docs/buyer-v3.md para implantação e limites de segurança.

Formulários de conta e checkout devem declarar método POST e destino interno explícitos no HTML, mesmo quando o runtime intercepta o submit. Não admitir GET com senha ou dados pessoais; o servidor pode recusar o POST nativo sem JavaScript. A navegação pública anônima recebe somente flags de conta, sem CSRF ou perfil. Contexto individual é produzido apenas onde necessário; revisões sem account não carregam essa personalização no catálogo. Formulários privados e páginas personalizadas mantêm private,no-store.

No checkout, checkout.attemptId já corresponde a uma tentativa persistida pelo servidor com loja e proprietário inicial. O tema transmite esse UUID sem gerar outro e sem criar cookies de tentativa. Revisões anteriores funcionam com o mesmo contrato. A conta é comprovada somente pelo cookie normal de sessão validado no servidor. Login em outra aba não vincula uma tentativa visitante à conta; é preciso entrar e reabrir o checkout. Retries mantêm o UUID, inclusive após resposta perdida. Não substituir automaticamente uma tentativa recusada nem transferir seu pedido. A apresentação atualizada do Aura deve ser aplicada por nova revisão, como descrito acima; nenhuma revisão publicada é reescrita para essa mudança de autorização.