Brandbook do Painel CLT Murilo

• Versão: 1.0
• Atualizado em: 13 de novembro de 2026
• Escopo: interface web do Painel CLT Murilo
• Estado: manual de referência vigente; publicação em brandbook.grupojohe.com autorizada pelo responsável em 12 de novembro de 2026.

Este documento é a referência visual e de conteúdo para qualquer pessoa ou agente que desenhe, altere ou documente telas do painel. Antes de implementar uma tela, leia este brandbook e confira os arquivos CSS indicados na seção Implementação no repositório.

1. Identidade do produto

O painel é uma ferramenta operacional de crédito consignado. A interface deve transmitir clareza, organização, segurança e controle. O visual usa uma base escura grafite-azulada, superfícies de ardósia e rosa suave para orientar ações e marcar a identidade do produto.

O nome de produto usado na interface e na documentação é Painel CLT Murilo. Este manual descreve a identidade própria do painel; não substitui nem importa automaticamente a identidade de terceiros, fornecedores, bancos ou promotoras.

Personalidade visual

• Organizada e objetiva: cada informação deve ter lugar e hierarquia reconhecíveis.
• Acolhedora e leve: o rosa suaviza a interface escura, sem virar decoração dominante.
• Didática: rótulos explicam o que acontecerá em linguagem de operação.
• Sóbria: números financeiros, status e ações ficam em destaque sem efeitos chamativos.
• Confiável: dados desconhecidos ou pendentes continuam identificados como desconhecidos ou pendentes.

Assinatura visual atual

• A assinatura gráfica existente é o wordmark murilo.clt, em minúsculas, acompanhado do monograma quadrado arredondado m•.
• Wordmark usa Manrope ExtraBold, aproximadamente 21–22px, com espaçamento negativo leve; o ponto depois de “murilo” recebe o rosa de marca.
• Monograma mede 38×38px, raio 12px, fundo --accent e desenho escuro; o ponto interno é claro.
• Aplicações atuais: apresentação do login, cabeçalho da barra lateral e cabeçalho compacto de mobile. Preserve alinhamento, proporção e leitura em cada aplicação.
• Não estique, redesenhe ou substitua o monograma por ícone de banco. Não invente uma nova assinatura sem pedido específico.
• O nome formal do produto para documentação é Painel CLT Murilo; o wordmark curto continua “murilo.clt”.

2. Princípios obrigatórios de interface

1. Cada tela tem uma ação principal clara. A ação principal recebe o botão rosa; ações auxiliares usam botão secundário ou link discreto.
2. Uma pessoa que nunca viu a tela deve entender em poucos segundos o que pode fazer e o que aconteceu depois de agir.
3. Use português simples e direto. Prefira “Consultar CPF”, “Ver detalhes” e “Atualizar roteiro” a termos internos de sistema.
4. Não invente aprovação, margem, valor, prazo, comissão, taxa, elegibilidade, retorno de banco ou atualização da fonte.
5. Estados importantes não podem depender somente de cor. Escreva também o estado e, quando houver, use ícone de confirmação, alerta ou recusa.
6. Mantenha respiro entre texto, controles e bordas. Não reduza o preenchimento interno do card para fazer conteúdo caber; reorganize a composição.
7. Preserve espaço vazio quando ele melhorar a leitura. Não preencha a página com decoração ou métricas fictícias.
8. Use componentes e padrões já presentes no painel antes de criar um padrão novo.

3. Paleta de cores

Os valores abaixo vêm do tema escuro atual (src/theme-ardosia.css) e dos estados visuais já usados nos módulos. Os oito primeiros são os tokens centrais da interface.

Cores funcionais já presentes

As cores funcionais listadas refletem variações específicas já existentes. Em novas telas, comece pelos tokens semânticos (--positive, --negative, --muted) e use os acentos por módulo somente quando o significado estiver explícito. Se houver oportunidade de unificar um tom em CSS, atualize primeiro o token e este documento juntos.

Regras de contraste e significado

• Use --text em fundos --bg, --sidebar-bg, --surface e --surface-deep.
• Use --muted apenas para informação secundária. Não use texto auxiliar para valor, resultado principal, erro ou instrução necessária para concluir uma tarefa.
• Botão rosa usa texto escuro (#251F2A ou tom equivalente já aplicado), evitando texto branco de baixo contraste.
• Rosa é identidade e ação; verde é confirmação; vermelho é recusa/erro; amarelo é atenção/intermediário; azul é informação financeira ou pendência informativa.
• Não use rosa para representar aprovação, nem verde para uma condição apenas “provável”.
• Nunca comunique aprovação, recusa ou conclusão apenas pela cor: inclua rótulo e/ou ícone.
• Gradientes devem ser discretos e servir a uma área específica. Não aplique gradiente rosa em grandes áreas de conteúdo.

4. Tipografia

O HTML carrega fontes Google Fonts em index.html:

• DM Sans: fonte principal de leitura, formulários, botões, tabelas e textos corridos.
• Manrope: títulos, números de destaque e identidade do painel.
• Fallback: sans-serif. Se a fonte remota não carregar, a composição deve continuar utilizável.

Escala tipográfica

Use esta escala como padrão de novas telas. Componentes antigos têm exceções detalhadas na própria folha de estilos.

Hierarquia e leitura

• Uma página tem um título H1, seguido de uma frase curta quando necessária.
• H2 identifica blocos de resultado ou seções; H3 organiza conteúdo interno do card.
• Não pule níveis de título para simular tamanho visual. A hierarquia visual também precisa ser semântica.
• Use Manrope em títulos, nomes de banco e números importantes; não use Manrope em parágrafos longos.
• Use font-variant-numeric: tabular-nums em moeda, percentual, contagem e prazo quando disponível, para facilitar comparação vertical.
• Percentual e valor nominal do ranking aparecem juntos, com o percentual acima e o valor azul abaixo. “Ver detalhes” fica centralizado no card conforme o padrão atual do Ranking Geral.
• Evite caixa alta em frases inteiras. Reserve maiúsculas para eyebrow, etiqueta curta e cabeçalho de tabela.
• Não reduza texto abaixo de 10px; se faltar espaço, quebre em mais linhas, reorganize o card ou mova conteúdo secundário para detalhes.

5. Espaçamento, alinhamento e proporção

Adote uma escala baseada em múltiplos de 4 px. Valores intermediários existentes podem ser mantidos ao editar um componente antigo, mas não devem originar novos padrões sem motivo.

Regras de cards e quadrantes

• Card principal: padding de 20–24px; card compacto: 12–16px.
• Não deixe texto encostar na linha. Preserve pelo menos 12px de padding em telas compactas e 16px ou mais nos cards normais.
• Use min-width: 0 em filhos de grid/flex e overflow-wrap: anywhere para nome, tabela ou mensagem potencialmente longa.
• O card deve crescer para mostrar seu conteúdo. Não corte rótulo, valor ou ação com overflow: hidden; reserve essa regra a mídia decorativa ou a lista com rolagem intencional.
• Quadrantes irmãos na mesma linha devem ter alinhamento, altura visual e padding coerentes. Não force a mesma altura quando isso cortar texto; use align-items: stretch e conteúdo flexível.
• Cards de resultados devem ter informação principal visível sem expansão. Conteúdo de referência, condições longas e detalhes ficam em seção expansível.
• Use valores tabulares e rótulos próximos; não coloque metadados soltos em cantos que pareçam pertencer a outro card.
• Use contornos suaves para delimitar card. Sombras escuras e discretas, sem brilho rosa amplo.

Bordas, raios e sombras

• Card padrão do tema escuro: raio visual de 13px.
• Controle de formulário e mini-card: 8–10px.
• Chip/pílula: 999px.
• Dialog/modal e hero: 14–16px.
• Usar borda 1px solid var(--line); divisores internos podem usar var(--line) com opacidade reduzida.
• Sombras: curtas e de baixa opacidade, por exemplo 0 8px 25px #00000012. Evite sombra colorida em cards; reserve rosa translúcido para foco ou ação.

6. Estrutura da aplicação

Navegação lateral

• Largura desktop de referência: 239px, fixa; fica alinhada ao topo e ocupa a altura da viewport.
• Fundo --sidebar-bg; divisor à direita em --line.
• Marca no topo; navegação em uma coluna; configurações e sair ficam no rodapé da barra.
• Item normal usa texto #B9C2CE, sem fundo forte. Hover usa superfície de ardósia. Item ativo usa fundo --accent-soft, texto --accent e borda rosa de 3px à esquerda.
• Ícones Lucide devem manter o mesmo tamanho e alinhamento do texto; evite misturar estilos de ícone na mesma navegação.
• Em celular, a barra vira navegação horizontal fixa no topo. Os rótulos permanecem roláveis; ferramentas do rodapé ficam compactadas à direita.

Barra superior e conteúdo

• Barra superior: 70px no desktop e 52px em mobile, com divisor inferior.
• Largura máxima da área principal: 1450px, centralizada.
• Padding de conteúdo desktop de referência: 42px 47px 60px; tablet reduz; mobile usa aproximadamente 28px 17px.
• Breadcrumb e identidade do usuário são auxiliares; não competem com o H1.

Cartões principais

• Dashboard: KPIs em quatro colunas no desktop; reorganizar para duas colunas em telas menores e uma coluna quando a largura não comportar leitura.
• Consultas e resultados: usar quadrantes simétricos quando as ações forem equivalentes; cada quadrante apresenta título, descrição curta, controles e ação.
• Comissões: os seletores devem formar um card conciso; resultados ficam na área de ranking. O ranking preserva todas as tabelas e a ordem retornada pela regra de negócio.
• Roteiros: pesquisa e atualização de acervo são evidentes; respostas ficam agrupadas em cards com fonte/data e leitura curta.
• Balcão: não mostrar percentual em Balcão 1. Balcão 2 pode mostrar o valor derivado de 10% da comissão de origem conforme regra já implementada. Não transportar regras ou rótulos de um módulo para outro.

7. Componentes e seus estados

Botão principal

• Fundo --accent; texto escuro de alto contraste; peso 700–800.
• Altura visual mínima de aproximadamente 42–46px; padding horizontal de 15–19px; raio 9–12px.
• Ícone Lucide opcional, alinhado à esquerda do verbo de ação, com gap de 8–12px.
• Hover: rosa #F1BAD0, sem salto superior a 1px.
• Desabilitado: opacidade reduzida e cursor coerente com a ação em andamento.
• Uma ação primária por formulário; botão secundário usa fundo de superfície, borda --line e texto principal.

Inputs e seleção

• Fundo --surface-deep; texto --text; placeholder --muted; borda --line.
• Altura mínima de 40–44px; padding de 9–13px; raio 8–10px.
• Label fica acima do campo, em DM Sans 12–13px e peso 600–700, gap 6–8px.
• Foco recebe contorno de 2px em --accent, com offset de 2–3px; não remova o indicador de foco.
• Valores financeiros formatam-se como R$ 1.234,56 ao sair do campo, mantendo digitação simples enquanto o usuário edita.

Card/ticket de resultado

• Superfície --surface, linha --line, raio 13px, espaço interno mínimo 12–16px.
• Conteúdo tem ordem reconhecível: posição/ícone, nome da instituição, referência da tabela, métrica principal, ação de detalhes.
• Texto e números devem caber no card em desktop e mobile. Em largura estreita, empilhe informações secundárias em vez de recortar.
• Nome do banco e tabela usam texto principal/auxiliar, com quebra ou elipse apenas quando o contexto continuar legível.
• Informações essenciais da classificação aparecem no resumo; detalhes formais e condições podem expandir.
• Área clicável de expansão deve ter foco visível, estado aberto compreensível e rótulo “Ver detalhes”.

Ranking de comissões

• Ordenação por comissão fica definida pela regra de negócio, não por ordenação manual de apresentação.
• Posição visível com numeral ordinal (1º, 2º, 3º).
• A tabela correspondente é obrigatória em cada linha; o mesmo banco pode aparecer mais de uma vez quando a linha/tabela for diferente.
• Comissão percentual tem a ênfase principal; valor nominal fica imediatamente abaixo em azul.
• “Ver detalhes” fica centralizado no card. Dentro da expansão devem aparecer tabela, identificador, convênio, produto/operação, prazo e vigência disponíveis.
• Não substitua ausência de comissão ou de tabela por valor inferido.

Status

O texto do estado deve acompanhar o tom visual. “Pendente” não significa “reprovado”, “Concluído” não significa “aprovado” e “Provável” não significa “Aprovável”.

Progresso e mensagens

• Durante consulta, mostrar indicador com etapa/progresso e texto simples. Não deixar somente um spinner sem contexto em operações demoradas.
• Sucesso usa fundo verde profundo e texto claro; erro usa vermelho profundo e instrução próxima; aviso usa tom quente discreto; neutro usa --surface e --muted.
• Mensagens devem explicar o que ocorreu e qual ação é possível. Erros técnicos detalhados ficam em logs seguros, sem CPF, credenciais ou payload privado.
• Protocolo em estado incerto precisa permanecer identificado como pendente de confirmação; não oferecer botão que dispare nova consulta sem reconciliação.

Ícones e logomarcas

• Ícones da interface: Lucide React, preferencialmente 16–20px para controles e 20–24px para cabeçalho de card.
• Usar traço consistente e ícone semanticamente compatível. Não misturar emoji com Lucide para estados equivalentes.
• Configurações e sair podem aparecer somente como ícone se tiverem aria-label, title ou tooltip acessível.
• Logomarcas de bancos precisam vir de fonte oficial verificada ou dos ativos oficiais aprovados no repositório. Se faltar ativo confiável, usar iniciais legíveis.
• Acabamento prateado/neutro é o padrão das listas de consulta quando não há sinal de marca colorida autorizado. Não transformar logotipo em texto ilegível nem esticar a proporção.
• O banco concedente é o banco retornado pela fonte; não deduzir banco por nome de promotora ou plataforma.

8. Dados, finanças e confiança visual

• Valor, percentual, taxa, prazo, margem e status só aparecem quando retornados ou calculados por regra explícita e identificável.
• Diferencie valor informado, valor estimado, comissão publicada, projeção e valor liberado. A interface não deve fazê-los parecer a mesma coisa.
• Valor nominal em azul é informação financeira/estimativa do componente. Não use azul para aprovação.
• Não arredonde ou altere valor exibido sem uma regra documentada; mostre moeda brasileira e duas casas decimais quando for valor em reais.
• Não publique CPF, e-mail, telefone, token, chave, senha ou dados identificáveis em captura, log, manual público ou arquivo versionado.
• A Central API é chamada pelo servidor; a chave não deve ser enviada ao browser.
• Campanhas são acompanhamento visual. Nenhum padrão de botão do brandbook autoriza envio, publicação ou gasto.

9. Gráficos e dados visuais

• Fundo de gráfico é transparente sobre --surface; grade usa linha discreta próxima de --line.
• Série principal usa rosa --accent; comparação/volume neutro usa azul-ardósia (por exemplo #8292AE).
• Verde e vermelho ficam reservados a estados positivos e negativos confirmados, não para decoração.
• Todo gráfico deve ter título, período/unidade e rótulos/tooltip compreensíveis. Não apresente números fictícios em produção.
• Evite eixos decorativos, muitas séries ou legenda longa. Um gráfico deve responder a uma pergunta operacional.
• KPI mantém o valor em Manrope e o rótulo em DM Sans menor e auxiliar; unidade deve estar próxima do número.

10. Conteúdo e microcopy

• Idioma padrão: português brasileiro (pt-BR).
• Use frase curta, verbo direto e rótulo em sentença: “Consultar”, “Filtrar banco”, “Ver detalhes”.
• Capitalização de títulos segue o nome estabelecido no menu: “Consultar CPF”, “Lead Qualificado”, “Comissões”, “Balcão 1”, “Balcão 2”, “Roteiros”.
• “CLT”, “CPF”, “INSS” e siglas são mantidas em caixa alta.
• Evite linguagem promocional, promessa de aprovação, promessa de valor disponível ou jargão que o operador não vê na fonte.
• Números monetários seguem o padrão R$ 1.234,56; percentual usa vírgula decimal, por exemplo 13,20%; prazo inclui “meses”.
• Estado vazio deve explicar o que falta ou como começar, sem inventar que houve erro de consulta.

11. Responsividade

Os estilos atuais têm pontos de quebra em vários módulos. Para novos layouts, use estes pontos canônicos e valide medidas próximas a cada transição:

Alguns componentes existentes precisam de limites próprios: 720px para a linha responsiva do Ranking Geral, 620px para fichas/Leads e 560px para detalhes de ranking. Não retire esses limites sem testar a largura real do card/container.

Regras:

• Prefira container/grid responsivo a largura fixa para resultados.
• Use repeat(..., minmax(0, 1fr)) e min-width: 0 em colunas de conteúdo.
• Cards podem mudar de uma linha para duas, mas não podem esconder comissão, valor, tabela, nome do banco ou ação.
• Em mobile, mantenha a ação perto do conteúdo a que pertence. Não deixe botão flutuando distante do campo.
• Tabelas com muitas colunas usam rolagem interna claramente delimitada; não comprimem texto até ficar ilegível.
• Validar pelo menos: 1440px, 1024px, 760px, 390px e uma largura intermediária em torno de 700px.

12. Acessibilidade visual e interação

• Garanta foco de teclado visível em botão, link, input, seletor, item expansível e navegação.
• Todo campo tem label visível; placeholder não substitui label.
• Ícone sem texto recebe nome acessível.
• Use região aria-live para resultado de consulta ou progresso, quando apropriado.
• Respeite prefers-reduced-motion em animações não essenciais; movimento não deve ser a única indicação de estado.
• Mantenha contraste legível nos tons muted; se texto deixar de ser lido em monitor de baixo brilho, ele não pode carregar informação essencial.
• Estados mantêm nome textual, ícone e cor alinhados entre ticket, lista e detalhes.

13. Checklist obrigatório para agentes

Antes de encerrar mudança visual, confirme:

• [ ] Li este brandbook e reutilizei o tema escuro/grafite com rosa suave.
• [ ] Usei Manrope para hierarquia e DM Sans para leitura e controles.
• [ ] Mantive cores funcionais fiéis ao significado; status também aparece por texto/ícone.
• [ ] Texto, valor, referência e ação cabem no card sem corte e sem encostar nas bordas.
• [ ] Testei desktop, tablet, mobile e uma largura intermediária do container.
• [ ] Títulos, rótulos, unidades, percentuais e valores têm hierarquia consistente.
• [ ] Não inventei dados ou promessa, nem expus CPF, credenciais ou dados de cliente.
• [ ] A navegação, foco de teclado, estado vazio, erro e carregamento continuam claros.
• [ ] Quando alterar tokens ou regra visual, atualizei este manual e os CSS tokens de forma coerente.
• [ ] Para mudança de código, rodei os testes/build solicitados pelo AGENTS.md antes de publicar.

14. Implementação no repositório

Arquivos que definem a aparência atual:

• src/theme-ardosia.css: tokens de tema escuro, cores, substituições e acabamento atual dos módulos.
• src/styles.css: estrutura base, autenticação, navegação, dashboard, cards genéricos e regras de layout.
• src/unica.css: Roteiros, Comissões, Balcão, rankings, detalhes e resultados da base UNICA.
• src/leads-clt.css: Leads CLT e Lead Qualificado.
• src/presenca-bank.css: consulta Presença Bank.
• src/main.jsx: menu, componentes principais, status e composição das telas.
• src/UnicaKnowledge.jsx: estrutura de roteiros, comissões e linhas de ranking.
• index.html: carregamento de DM Sans e Manrope.

Ordem e manutenção dos estilos

src/main.jsx importa styles.css antes de theme-ardosia.css; portanto, o tema é a camada visual final da estrutura global. Os componentes podem importar suas próprias folhas para regras locais. Ao alterar algo, primeiro encontre a regra responsável e edite o arquivo que é dono daquele componente. Evite duplicar uma regra de tema em uma folha genérica para contornar a cascata.

Tokens para novas telas

Use os tokens existentes em vez de repetir hex:

var(--bg)
var(--sidebar-bg)
var(--surface)
var(--surface-deep)
var(--line)
var(--text)
var(--muted)
var(--accent)
var(--accent-soft)
var(--positive)
var(--negative)

Os acentos de informação financeira, ranking e pendência ainda têm alguns valores locais no CSS. Se um novo estado desse tipo for criado, registre primeiro seu significado, escolha um tom legível, acrescente um token semântico em theme-ardosia.css e atualize a tabela da paleta. Não escolha um hex diferente em cada tela.

15. Governança deste manual

• Este arquivo é a fonte visual única do produto para agentes e contribuidores.
• Toda exceção nova deve dizer qual tela/componente precisa dela e por quê; não deve virar um padrão global por acidente.
• Se uma solicitação literal do responsável do painel divergir de um padrão antigo, implemente a solicitação no escopo pedido e atualize este documento quando ela se tornar padrão.
• Uma revisão futura pode consolidar variações locais de status e espaçamento em tokens CSS; faça essa consolidação em mudança dedicada, preservando os estados e a semântica atuais.
• A publicação deste brandbook em brandbook.grupojohe.com foi autorizada pelo responsável em 12 de novembro de 2026. Essa autorização não inclui publicar o restante do painel ou outros dados do repositório.