Fundamentação técnica e teórica
Base de cada decisão do site
Critério de aceitação
Cada elemento em produção é avaliado por três critérios: o problema que resolve está identificado; a resolução foi medida; a decisão se apoia em referência bibliográfica ou normativa. Um item é considerado concluído quando os três critérios estão registrados e a verificação em produção consta nas notas de versão. Todos os itens abaixo atendem aos três critérios. Itens que não integram esta versão estão marcados como fora de escopo por decisão registrada, e não como pendência de construção.
Duas restrições atravessam toda a implementação. A primeira é de processo, fixada no briefing 3.0 e no memorando de 3 de setembro de 2026: a versão 3.0 é a base, e as versões seguintes (3.1 a 3.15) são ajustes pontuais em rodada única, sem reconstrução. A segunda é de compliance: o site não recomenda produto, não promete retorno e não fala em nome do BTG Pactual nem da GWM Investments além do que o aviso legal permite. Todo item foi filtrado por essas restrições antes de qualquer critério estético.
Resumo de estado
| Item | Versão | Estado |
|---|---|---|
| Posicionamento e voz | 3.0 · 3.1–3.2 | Implementado e verificado |
| Estrutura da home (§1–§45 do briefing) | 3.0 | Implementado e verificado — tabela de conformidade em /notas-de-versao |
| Largura de coluna e tipografia | 3.5 · 3.7 | Implementado e medido em 1440 e 1600 px |
| Títulos no celular | 3.14 | Implementado e medido em 375 px |
| Benchmark do setor | 3.7 | Medido e aplicado |
| Imagens com pessoas em situação (29 de 29) | 3.6 · 3.12 · 3.13 | Implementado e verificado em produção (HTTP 200) |
| Sequência em três quadros e texto recolhido | 3.6 | Implementado e verificado |
| Nota "O que isso não resolve" e FAQ | 3.0 | Implementado e verificado |
| Formulário e registro do lead | 2.0 · 3.0 · 3.15 | Implementado e verificado (gravação, pontuação, e-mail) |
| Interações | 3.4 · 3.15 | Implementado e verificado |
| Paleta e tipografia institucional | 3.3 | Implementado e verificado |
| Compliance e privacidade | 2.2 · 3.5 · 3.14 | Implementado e verificado |
| Verificabilidade (notas, meta, llms.txt, backups) | 2.1 em diante | Implementado e verificado |
| Assistente do site | 3.16 (prevista) | Construído e testado (32 testes); fora do escopo desta versão até a infraestrutura de banco existir |
| Foto real de página inteira no hero | — | Fora de escopo por decisão registrada (§30 do briefing; depende de sessão de fotos) |
Sumário
- Posicionamento e voz
- Estrutura da home
- Largura de coluna e tipografia
- Títulos no celular
- Benchmark do setor
- Imagens com pessoas em situação
- Sequência em três quadros e texto recolhido
- Nota de limitação e dúvidas frequentes
- Formulário e registro do lead
- Interações
- Paleta e tipografia institucional
- Assistente do site
- Compliance e privacidade
- Verificabilidade
- Delimitação de escopo
1. Posicionamento e voz
Implementação
O site se dirige a um perfil definido: quem já construiu patrimônio e passou a lidar com decisões interdependentes (caixa da empresa, crédito, câmbio, sucessão, previdência, investimento). O registro é formal, em terceira pessoa quando o assunto é o assessor, sem "te", sem "a gente", sem promessa. A franqueza é descrita como resposta ("se a conclusão for que está tudo bem como está, essa será a resposta"), não como atitude.
Fundamento
Um público definido torna a conversa de diagnóstico um serviço, e não um pretexto de venda. A revisão de tom das versões 3.1 e 3.2 retirou coloquialismos e fechos impositivos porque contradiziam esse posicionamento. As respostas do assistente do site (seção 12) foram escritas no mesmo registro, para que não haja troca de interlocutor percebida.
Verificação
Passada de tom registrada nas notas 3.1 e 3.2; filtro de voz aplicado ao seed do assistente por teste automatizado (rejeita "te" e "a gente"). Estado: concluído.
2. Estrutura da home
Implementação
Ordem fixa: hero (o problema em uma frase), para quem é, três blocos temáticos (empresa e patrimônio pessoal, internacional, liquidez), atendimento pessoal com estrutura institucional, seis áreas de solução, quatro perguntas, experiência, método em cinco passos, dúvidas frequentes, contato. Um único pedido ao visitante, repetido: "Agendar uma conversa". Menu fixo com marcação da seção atual e o mesmo pedido como botão.
Fundamento
Cada seção prepara a seguinte: as soluções aparecem depois do reconhecimento do perfil; o método aparece depois das perguntas que justificam a existência do método; o formulário aparece depois das dúvidas que costumam impedir o contato. Cada bloco responde a uma pergunta só. É a aplicação de dividir processos complexos em etapas menores e destacar uma opção por vez.
Verificação
Tabela de conformidade §1–§45 do briefing 3.0 em /notas-de-versao, cada exigência apontando para a âncora que a atende. Estado: concluído.
3. Largura de coluna e tipografia (versões 3.5 e 3.7)
Implementação
Em telas a partir de 1000 px: títulos e hero sem teto de largura, com quebra natural; coluna de leitura de 920 px (era 720 na 3.0 e 800 na 3.5); nas páginas de solução, todos os blocos em 1080 px, entregas em três colunas, caixas numeradas e dores em duas; nota de limitação e respostas do FAQ em duas colunas de texto. Parágrafo isolado mantém teto próximo de 85 caracteres por linha.
Fundamento
Diagnóstico medido: teto de 22em nos títulos e quebra balanceada (text-wrap: balance) deixavam frases de duas linhas em quatro e a grade abaixo mais larga que o título. A correção concilia dois fatos: lateral vazia prejudica a composição; linha longa demais prejudica a leitura. A solução separa o que pode esticar do que não pode — título, grade e caixa ocupam a largura toda; o parágrafo permanece curto, mas nunca isolado no centro da tela: fica ao lado de uma figura, em uma grade ou dividido em colunas. É a mesma regra observada no benchmark da seção 5.
Verificação
Medido em 1440 e 1600 px: título "Para quem já construiu patrimônio…" alinhado à borda da grade de perfis; entregas em três colunas de 315 px; sem estouro horizontal. Estado: concluído.
4. Títulos no celular (versão 3.14)
Implementação
Até 640 px: hero em 32 px (era 38), títulos de seção e dos blocos editoriais em 27 px (era 30), todos com quebra balanceada. Nas páginas de solução, o mesmo até 560 px. Os quatro números do case em /metodo em uma coluna.
Fundamento
Medição em 375 px (coluna de 331 px) após a 3.7: hero com seis linhas; três títulos editoriais com cinco ou seis; última linha de vários títulos entre 100 e 150 px — uma palavra isolada. A regra que resolveu o desktop (sem teto, sem balance) criou o problema no celular, onde a coluna já é o limite. A correção é por faixa de tela e não altera o desktop. Após a correção: hero em cinco linhas cheias; últimas linhas entre 200 e 315 px; nenhum estouro horizontal. Parágrafos não mudaram: a 16,8 px em 331 px já ficavam em 40 a 45 caracteres por linha, dentro da faixa preferida.
Verificação
Auditoria por script em home, /solucoes/investimentos, /metodo, /cambio e /conteudos: contagem de linhas e largura da última linha por título, largura de rolagem igual à do viewport. Estado: concluído.
5. Benchmark do setor (versão 3.7)
Implementação
Quatro sites de wealth management medidos em 1440 px por script (largura de h1, mediana e máximo de parágrafos, número de imagens, imagens de página inteira): J.P. Morgan Private Bank (América Latina), BTG Pactual Wealth Management, UBS Wealth Management Brasil e Julius Baer.
Fundamento
Resultado: nenhum dos quatro usa coluna única estreita. O padrão comum é imagem de página inteira no topo com título sobreposto, muitas imagens (16 a 44 por página, com pessoas em situação) e parágrafo curto (450 a 650 px) que nunca fica isolado — está ao lado de uma foto, em cartão ou em par com o título à esquerda. A 3.7 aplicou essa regra à largura; as versões 3.6 a 3.13 aplicaram-na às imagens.
Verificação
Números registrados nas notas 3.7; regra aplicada e medida nas seções 3 e 6. Estado: concluído.
6. Imagens com pessoas em situação (versões 3.6 a 3.13)
Implementação
Vinte e nove ilustrações geradas por IA em formato editorial, paleta azul do site, pessoas de costas, de perfil fora de foco ou do ombro para baixo. Cada página de solução tem três quadros que descrevem um arco: situação de hoje (o cliente sozinho ou no balcão do banco), virada (a conversa com o assessor, o problema desenhado no papel) e depois (o cliente no controle, a família tranquila). A home tem uma figura ao lado de cada bloco temático. Fotos do assessor permanecem apenas reais.
Fundamento
O briefing 3.0 (§30 a §32) veda imagem de banco de imagens e admite apenas fotos reais; a exceção para ilustração gerada, registrada em 11 de setembro de 2026, impõe três regras: sem rosto identificável, paleta do site, sem texto nem logotipo. A primeira leva (objetos: extratos, pastas, celular) foi substituída pela leva com pessoas em situação porque a cena comunica proximidade e conflito antes do texto. A regra do rosto protege duas coisas: a imagem não pode ser confundida com cliente real (LGPD e compliance) e não pode competir com a única pessoa apresentada no site.
Verificação
29 de 29 imagens em versão com pessoas, conferidas uma a uma pelas três regras; em produção, as 18 imagens das páginas de solução respondem HTTP 200 e as versões anteriores foram removidas (notas 3.12 e 3.13). Estado: concluído.
7. Sequência em três quadros e texto recolhido (versão 3.6)
Implementação
Nas páginas de solução, os quatro textos longos de "Como funciona na prática" ficam recolhidos em cinco linhas com "Continuar lendo". No celular, os três quadros rolam lateralmente com encaixe. Sem JavaScript, o texto aparece integral.
Fundamento
As páginas de solução eram consideradas longas desde a 2.2. Cortar texto removeria o que o compliance exige explicar (custódia, suitability, remuneração). Recolher preserva o conteúdo e entrega primeiro o que cabe em uma tela. As páginas ficaram com cerca de metade da altura anterior.
Verificação
Recolhimento e expansão testados por clique e por ausência de JavaScript; rolagem lateral verificada em 375 px. Estado: concluído.
8. Nota de limitação e dúvidas frequentes
Implementação
Cada página de solução tem a caixa "O que isso não resolve": alocação não elimina perda, arquitetura aberta não anula conflito de interesse, se o problema é dívida cara o investimento não é a conversa adequada. As dúvidas frequentes respondem às perguntas que impedem o contato ("meu dinheiro fica com você?", "você pode me dizer em que investir?") dentro do que a norma permite.
Fundamento
A objeção não verbalizada é a que decide o agendamento. Registrá-la antes, com resposta direta, retira sua força; a nota de limitação é o que torna crível o restante da página.
Verificação
Presente nas oito páginas de solução; texto alinhado ao aviso legal (3.5). Estado: concluído.
9. Formulário e registro do lead
Implementação
Ordem dos campos: situação atual (sete opções em botão), faixa de patrimônio (opcional), nome, WhatsApp, e-mail opcional, consentimento. O lead é gravado no servidor antes de o WhatsApp abrir, pontuado, e notificado por e-mail. Honeypot e tempo mínimo de preenchimento bloqueiam robôs; limite de cinco envios por IP a cada dez minutos bloqueia abuso. Na 3.15, indicador de progresso das etapas e tela de próximos passos após o envio.
Fundamento
A pergunta de situação vem primeiro por ser a de menor custo para o visitante e a de maior informação para o assessor; nome e telefone vêm por último, depois de o valor ter sido demonstrado. A gravação anterior ao WhatsApp existe porque, sem ela, quem não confirmava o envio no aplicativo não deixava registro.
Verificação
Gravação, pontuação e e-mail testados em produção; validação coberta por teste automatizado (Lead::registrar, 200/422). Estado: concluído.
10. Interações (versões 3.4 e 3.15)
Implementação
Entrada de blocos com fade e deslocamento de 8 a 12 px em 250 a 400 ms, apenas abaixo da dobra; âncoras do menu param abaixo do cabeçalho fixo; FAQ abre e fecha por evento ou por tempo; o botão do menu vira X, o menu fecha com Esc e clique fora; foco visível em links, resumos e botão do menu. Na 3.15: os números da trajetória contam até o valor real e param; o formulário mostra o progresso das etapas; após o envio, a tela informa o que acontece em seguida.
Fundamento
Duração e amplitude são as do briefing 3.0 (§34). Animação indica continuidade, não chama atenção: curta e única por elemento. Foco visível e teclas de fechar são acessibilidade básica. A 3.15 estabelece um limite explícito: em site de assessoria regulada, recompensa variável (o mecanismo de jogo e rede social) não entra; entra antecipação com fim conhecido — o número para, a barra completa, o próximo passo é informado.
Verificação
Notas 3.4 e 3.15; testado em 1440 e 375 px. Estado: concluído.
11. Paleta e tipografia institucional (versão 3.3)
Implementação
Azul-marinho profundo (#05132A) como base; azuis institucionais em degraus (#0B2859, #10408D, #154D9F); branco e cinza quente. Uma família tipográfica (Inter) em dois papéis. Sem dourado, sem serifa decorativa, sem segunda fonte.
Fundamento
O briefing 3 determina alinhamento visual ao BTG Pactual e retira o dourado e a serifa da 2.0. Uma família em dois pesos reduz o número de decisões visuais por tela; os degraus de azul dão contraste entre blocos sem introduzir cor nova.
Verificação
Tokens de cor centralizados em styles.css; contraste conferido em blocos claros e escuros. Estado: concluído.
12. Assistente do site
Implementação
Assistente automático em todas as páginas, empilhado acima do botão de WhatsApp. Responde por uma árvore de respostas escritas previamente (23 nós de partida), casa a pergunta digitada por similaridade de texto (TF-IDF com cosseno, radical e distância de edição), recusa qualquer pedido de recomendação citando a Resolução CVM 178, colhe interesse, faixa, nome e WhatsApp pelo mesmo pipeline do formulário e encaminha ao assessor com código de conversa. Sem modelo de linguagem. Dado pessoal mascarado antes de gravar. Conversas apagadas após 90 dias. Admin por token para edição da árvore e leitura das perguntas sem resposta. 32 testes automatizados.
Fundamento
Três razões, em ordem de peso. Regulatória: o assessor responde pelo que o site afirma; um modelo de linguagem gera rentabilidade, comparação e recomendação — com fluência — no exato ponto em que a norma proíbe. Segurança: um modelo exposto ao público aceita instrução embutida na pergunta do visitante e pode revelar o que não deveria; uma árvore não possui esse vetor. Operacional: o mesmo desenho está em produção em outro projeto desde 6 de setembro de 2026 e demonstrou que a árvore cobre a maior parte das perguntas; o restante vira lista para o dono completar sem depender de programação. A opção de modelo de linguagem na cauda longa está registrada como fase 2, condicionada à leitura do log, e nunca para a recusa de recomendação.
docs/superpowers/specs/2026-09-12-chatbot-assistente-design.md e docs/superpowers/plans/2026-09-12-chatbot-assistente.md.Verificação
Construção concluída e revisada (revisão por tarefa e revisão final do branch, sem achados críticos remanescentes); 32 testes verdes com e sem banco; fluxo completo verificado em navegador em 1440 e 375 px (abertura, botão, recusa CVM, lead em quatro passos gravado com consentimento). Publicação (versão 3.16) está fora do escopo desta versão até existir banco MySQL e chaves de configuração no servidor — dependência de infraestrutura, não de construção.
13. Compliance e privacidade
Implementação
Aviso legal em todas as páginas com o texto do vínculo (assessor vinculado à GWM Investments, escritório credenciado ao BTG Pactual, Resolução CVM 178/2023). Nenhum número institucional de BTG ou GWM sem confirmação. Nenhuma promessa de retorno. Página de privacidade que descreve exatamente o que é guardado: cópia do lead do formulário, conversas do assistente por 90 dias, hash do IP para limite de abuso.
Fundamento
Os números institucionais entraram na 2.0 com marcação de compliance pendente e saíram na 2.2; a regra desde então é não reintroduzi-los. A página de privacidade afirmava, até a 3.14, que o site "não tem banco de dados e não grava nada", o que deixou de ser verdade quando o lead passou a ser gravado; a correção acompanhou a seção do assistente, porque uma política que se contradiz não cumpre função. A LGPD exige que o titular saiba o que é coletado, para quê e por quanto tempo; as três respostas constam na página.
Verificação
Aviso legal conferido nas 18 páginas, na política de privacidade, no llms.txt e nos dados estruturados (3.5); política de privacidade alinhada ao comportamento real do código (3.14). Estado: concluído.
14. Verificabilidade
Implementação
Toda publicação tem entrada nas notas de versão, com o pedido que a originou e o que mudou; a home carrega <meta name="version">; /llms.txt descreve o site seção a seção; a tabela de conformidade §1–§45 do briefing 3.0 aponta cada exigência para a âncora que a atende; cada versão publicada tem backup da anterior; o assistente tem suíte de testes.
Fundamento
Avaliações externas frequentemente partem de uma versão em cache. O registro permite que qualquer avaliador — humano ou automatizado — parta do estado real e atribua cada característica observada a uma decisão datada. É também o que permite a esta página existir: cada item tem versão, medida e diff.
Verificação
Notas de versão da 2.1 à 3.15; meta de versão conferida em produção após cada publicação; backups de 2.2 a 3.15 em deploy/. Estado: concluído.
15. Delimitação de escopo
Todos os requisitos do briefing 3.0 (§1 a §45) têm implementação e verificação registradas. Não há item de construção em aberto nesta versão. Os itens abaixo estão fora do escopo por decisão registrada e não constituem pendência:
- Publicação do assistente do site (3.16)
- Construído, testado e revisado. Depende de infraestrutura (banco MySQL, chaves de configuração, agendamento da retenção). Após a publicação, a árvore é mantida pelo dono a partir do log de perguntas sem resposta, sem alteração de código.
- Foto real de página inteira no hero
- Único item do benchmark não aplicado. O briefing 3.0 (§30) já o permite; depende de sessão de fotos.
- Revisão formal dos textos institucionais pela GWM (§44)
- Externa ao projeto. É a única instância que pode exigir alteração de texto sem pedido do dono.
- Conteúdos novos
- A página /conteudos recebe itens novos com o mesmo cartão. Não há sistema de blog, por decisão: publicação editorial, não estrutural.
- Regra de mudança
- Ajuste pontual, em rodada única, registrado nas notas. Reconstrução exige briefing novo e decisão explícita.