Viabilidade técnica GHL

Revisão de 08/09/2026. O escopo é redesign da experiência: identidade, reposicionamento de elementos e mobile web. Pesquisa oficial e inspeção responsiva realizadas; nenhuma skin foi injetada ou salva no CRM.

Conclusão para decidir

Podemos planejar uma experiência própria sobre o Growtify nativo. Não há evidência para prometer liberdade total em todas as páginas. A compra do tema ainda não está tecnicamente liberada.

Frente	Resultado
Análise de mecanismos e riscos	Parecer ampliado, com limites por superfície
Inspeção prática da interface atual	Desktop 1440 px e mobile 390 px; dashboard também a 768 px
Reposicionamento e correção mobile	Estratégia definida; execução da alteração não testada
Temas	Candidatos comparados por edição, componentes e licença
Prova de CSS/JS e reversão	Não executada: a ferramenta disponível permite leitura do DOM, não injeção temporária
Produção	Nenhuma configuração, permissão ou registro alterado

Não confundir: medir a interface atual comprova o problema; testar CSS/JS comprova a solução; o protótipo aprova o visual. São três entregas distintas.

Evidências no Growtify real

Amostra da subconta de referência, com o estado e as personalizações já existentes. Não houve comparação com uma conta limpa; os problemas abaixo não foram atribuídos exclusivamente ao código original do fornecedor. Valores aproximados em pixels CSS.

Tela / estado	Observação	Consequência para o redesign
Sidebar	224 px expandida; 56 px recolhida no mobile; DOM e links nativos acessíveis	Priorizar recolhimento e acesso claro ao menu; não remover módulos
Dashboard a 390 px	Quatro indicadores com cerca de 82 px cada, rótulos cortados e rolagens internas	Grade mobile própria, com uma coluna como primeiro teste
Nova oportunidade a 390 px	Modal ocupa a tela, mas coluna lateral comprime campos; rótulos quebram verticalmente	Navegação do formulário acima do conteúdo; campos em coluna única
Nova oportunidade após carregamento direto em mobile	Compressão repetida; formulário vazio aberto e cancelado nas duas tentativas	Não é apenas uma transição desktop → mobile
Contatos a 390 px	Botão Add Contact começa em x≈368 e tem ≈121 px de largura	Barra de ações precisa reorganizar-se, sem esconder criação/importação
Conversas a 390 px, sem conversa aberta	Lista ≈319 px em x≈108; painel de conversa mede 0 px naquele estado	Testar alternância lista/conversa e retorno; não concluir que toda conversa está quebrada
Calendário a 390 px	Painel Manage view ocupa grande parte da tela; grade e controles comprimidos	Filtros em painel recolhível e visualização adequada à largura
Automações	Lista de workflows em iframe de origem diferente	CSS do documento principal não alcança o conteúdo interno
AI Agents / entrada	Tabela de 600 px dentro da tela de 390 px; canvas presente	Preservar rolagem contextual; canvas não é prova de motor de gráficos
Sites / lista	Superfície principal inspecionada, sem abrir builders	Não extrapolar o resultado da lista para o editor
Gráficos	Agência expõe marcação Highcharts; dashboard da subconta contém iframe externo	Não presumir um motor único nem substituição por BK Lite

A largura total do documento permaneceu em 390 px em várias dessas telas mesmo quando havia conteúdo cortado. Verificar só scrollWidth da página não é um teste visual suficiente. Cobertura: agência/white label, dashboard, oportunidades e modal vazio, contatos, conversas sem abrir mensagem, calendário, lista de automações, entrada de AI Agents e lista de Sites. Não coberto: todos os submenus, estados de erro, perfis de acesso, formulário de contato preenchido, login desautenticado, recuperação/OAuth, editores internos, pagamentos, envio/salvamento e aparelho físico. A sessão do usuário não foi encerrada.

O que podemos mover

A tabela é uma recomendação de engenharia, não uma coleção de alterações já implementadas.

Mudança desejada	Caminho preferencial	Risco / limite
Reordenar e redimensionar widgets	Editor nativo do dashboard, quando disponível	Layout e permissões devem ser conferidos; não foi salvo nenhum layout
Ajustar campos visíveis de cards	Manage Fields e apresentações nativas de oportunidades	Preferências podem ser do usuário/navegador, não distribuição global
Reposicionar ações dentro da mesma barra	Flex/Grid e quebra de linha, preservando os controles originais	Ordem visual deve continuar coerente com teclado e leitor de tela
Sidebar mais clara e compacta	Estilizar raiz existente, estados ativo/expandido e itens nativos	Não clonar um segundo menu nem simular permissões por CSS
Trocar a coluna lateral do modal por navegação superior	Alteração de layout no mesmo componente	Exige teste de foco, rolagem, abas e validação; nenhum campo pode desaparecer
Conversas em um painel por vez no mobile	Aproveitar navegação nativa lista → conversa → voltar	Não reconstruir mensagens, editor ou estado da conversa
Mover componentes entre pais diferentes	Evitar; só estudar se o recurso nativo não resolver	Pode quebrar estado, eventos, menus e renderização do framework
Barra inferior de atalhos	Candidata, não aprovada	Só links/ações existentes e permitidos; não pode duplicar navegação ou esconder recursos
Conteúdo dentro de iframe externo	Apenas mecanismo próprio documentado para essa superfície	CSS do pai não atravessa a origem; não contornar isolamento

O GHL documenta reorganização de widgets e configuração de cards/colunas de oportunidades. Há também List View; usar um recurso nativo existente é preferível a reproduzi-lo por API. A MDN explica que CSS order não altera a ordem de leitura e tabulação. A documentação React alerta para alterações manuais em nós que o framework controla. Isso justifica preservar a estrutura funcional, sem afirmar qual framework governa cada módulo do GHL.

Contrato do mobile

Não é “desktop menor”. Estes são os requisitos de implementação e aceitação:

Navegação e ações

Menu recolhível com rótulos compreensíveis, estado ativo e acesso a todos os módulos permitidos.
Busca e ação principal visíveis; ações secundárias podem ir para menu acessível.
Sem depender de hover. Menu e modal precisam abrir, fechar e devolver o foco.
Meta de produto: alvos principais de toque de 44 × 44 px. Não confundir com o mínimo WCAG 2.2 de 24 × 24 px, que possui exceções.

Formulários, conversas e teclado

Uma coluna nos formulários estreitos; rótulos acima dos campos e erros junto do campo.
Conteúdo rolável sem cortar os botões finais; teclado virtual não pode cobrir o campo ativo ou envio.
Conversas: lista, mensagem e detalhes acessíveis por navegação explícita, preservando rascunho, anexos e retorno.
Não desativar zoom. Testar orientação, barras do navegador e áreas seguras; somente safe-area não resolve teclado virtual.

Dashboard, tabelas, kanban e calendário

Cards legíveis; número, rótulo e unidade não podem depender de tooltip.
Tabelas e kanban podem ter rolagem horizontal contextual; não transformar a página inteira em uma faixa larga.
Preferir lista/agenda nativa quando adequada, mantendo acesso à informação completa.
Filtros recolhíveis e explicação do filtro ativo. Não remover colunas ou ações essenciais só para caber.
Drag-and-drop precisa de alternativa por ação acessível quando a função nativa oferecer essa possibilidade.

Matriz de aceitação

Larguras-alvo: 320, 390, 768, 1024 e 1440 px. Testar carregamento direto e mudança de largura.
Dark/light; conteúdo vazio, longo, carregando, erro e modal aberto.
Teclado e foco; zoom; toque real; iOS/Safari e Android/Chrome.
Não publicar sem conferir ações críticas e saída da skin.
Nesta auditoria foram medidos 390/1440 px e dashboard a 768 px; os outros cenários continuam pendentes.

Referências: W3C — reflow, alvos de toque e MDN — áreas seguras. Não há declaração de conformidade WCAG nesta etapa.

Aplicação, distribuição e limites

CSS/JS nativo
Plugin Marketplace
Iframes, gráficos e login
Fora do caminho escolhido

Os campos Custom CSS/JS foram observados em Company → White Label. A documentação do GHL permite personalização visual, mas alerta para quebras e áreas desaconselhadas, incluindo builders, modais sensíveis e elementos sem seletor estável. O tema nativo da agência não comprova dark/light das subcontas. Fonte oficial.Estratégia: tokens próprios → CSS específico por superfície → JavaScript mínimo, idempotente e reversível apenas quando necessário. Sem importar reset global, Tailwind/Bootstrap inteiro, sobrescrever funções do GHL ou acessar dados internos.O tema comprado será instalado no protótipo. No CRM entram adaptações compatíveis, não um aplicativo React sobre o aplicativo existente.

Prova pendente e segurança

A restrição atual é da ferramenta de teste: ela não oferece injeção temporária de estilos/scripts nesta sessão. Não alterei Custom CSS/JS da agência para contornar isso. Esta limitação não prova impossibilidade no GHL, mas impede encerrar a prova prática.

Preparar teste local de sessão

Usar uma superfície de inspeção que permita estilos temporários no navegador ou ambiente de teste explicitamente isolado. Nenhuma publicação global e nenhuma conta nova sem necessidade. Preservar o código existente em local privado antes de qualquer mudança persistente futura.

Provar o recorte crítico sem tema

Sidebar + barra de ações + modal vazio de oportunidade + grade do dashboard, com CSS neutro mínimo. Medir antes/depois em mobile e desktop; conferir navegação e foco. Identificar separadamente o alcance em frames.

Remover e repetir

Desativar os estilos de teste, recarregar e confirmar retorno à apresentação anterior. Depois validar estados dinâmicos e permissões no ambiente apropriado, sem usar dados comerciais reais para testes de escrita.

Liberar escolha e compra

Entregar matriz passou/falhou. Só então confirmar o pacote, a licença e os componentes da opção visual de Marcelo. O protótipo completo começa após receber o tema.

Na implementação futura, ativação por domínio/rota/conta e recurso desligado por padrão reduzem alcance acidental, mas não substituem permissões. Se uma raiz esperada desaparecer, não aplicar o ajuste daquele módulo; preservar a UI nativa. Sem loops agressivos, reordenação contínua de DOM, requisições extras de negócio ou logs com dados de clientes. Manutenção: testar rotas críticas, versão anterior recuperável, monitoramento sem conteúdo sensível e alertas acionáveis. Correção automática irrestrita não está prometida. Publicação e manutenção. Próximo ponto: viabilizar a prova temporária, não pedir uma compra às cegas. Comparação técnica e visual dos temas.

Projeto