/* * Tema Kybalion — casca visual das telas de login/UPDATE_PASSWORD/UPDATE_PROFILE. * Spec: specs/E-UX-ext-tema-visual-keycloak/spec.md (FR-124 a FR-128) * Plan: specs/E-UX-ext-tema-visual-keycloak/plan.md (seção "CSS/paleta") * Redesign FR-838: specs/E14-migracao-design-system-polaridade-3d/ * addendum-calendario-login-unidade.md §3 — linguagem "Polaridade 3D" * (atmosfera de veios radiais, sombra de tinta de marca em repouso, * microlabels, alvos de toque ≥44px), CSS-only, zero mudança de FTL/texto. * * Carregado DEPOIS do CSS base do keycloak.v2 (ver theme.properties, * styles=css/styles.css css/kybalion-login.css — o caminho do CSS pai é * declarado literalmente porque a interpolação "${parent.styles}" NÃO * funciona no Keycloak 26, achado empírico registrado no theme.properties) — * só sobrescreve cor/logo/tipografia via cascade normal, nunca remove * estrutura/acessibilidade do tema pai. Nenhuma regra aqui toca texto de * mensagem funcional (FR-127) — só seletores de cor/layout. * * Compartilhado pelos 3 fluxos em escopo (login.ftl, login-update-password.ftl, * login-update-profile.ftl) — garante FR-128 (consistência) por construção, * já que é um único arquivo CSS. * * Paleta espelha os tokens de specs/design-system-frontend.md §3: * --primary do app = hsl(221 83% 53%) = #2563EB (mesmo azul de * --kybalion-blue). As receitas .tile-3d (dark) e .veio-marca de * apps/admin-web/src/app/globals.css são traduzidas aqui para CSS puro * com rgba(37, 99, 235, …) — este tema não tem acesso aos tokens hsl do app. */ :root { --kybalion-navy: #0A1226; --kybalion-blue: #2563EB; --kybalion-blue-hover: #3B82F6; --kybalion-white: #FFFFFF; --kybalion-error: #EF4444; /* Microlabel apagada, mas AA sobre branco (slate-600, ~7.5:1) */ --kybalion-label: #475569; --kybalion-placeholder: #6B7280; --kybalion-input-border: #CBD5E1; /* Raio de campo/botão (0.625rem) e de card (1.25rem — mesmo raio do .tile-3d do design system §9.1) */ --kybalion-radius: 0.625rem; --kybalion-radius-card: 1.25rem; --kybalion-font: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif; /* Microlabels monoespaçadas (eco de Tile3DMicroRotulo, §9.1 item 5) — stack de sistema, sem webfont/request externo (plan.md) */ --kybalion-mono: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; /* Tinta de marca para sombras/atmosfera — rgb de #2563EB */ --kybalion-ink: 37, 99, 235; } /* Tipografia — fonte de sistema, sem webfont/request externo (plan.md) */ body#keycloak-bg, .pf-v5-c-login, .pf-v5-c-form, .pf-v5-c-button, .pf-v5-c-title { font-family: var(--kybalion-font); } /* Atmosfera de fundo — mosaico triangulado azulado (decisão do usuário, 2026-08-11, substitui os veios radiais do FR-838 NESTA regra apenas; o resto do redesign FR-838 — microlabels, glow do card, cores — permanece). Inspiração: tema clássico/legado "keycloak" do próprio Keycloak, cujo fundo low-poly ("diamantado") em tons de cinza foi extraído do jar org.keycloak.keycloak-themes-26.0.8.jar da imagem oficial quay.io/keycloak/keycloak:26.0 (theme/keycloak/login/resources/img/ keycloak-bg.png, PNG 1920x1080, licença Apache 2.0 — uso legítimo) e salvo como ../img/keycloak-bg-mosaico.png. O PNG é cinza puro (degradê de cinza médio no canto sup. esquerdo a quase-preto no inf. direito). Feedback do usuário, 3ª iteração (2026-08-11): o fundo deve ser "O MESMO DO TEMA AZUL ESCURO DAS PÁGINAS" — ou seja, bater com o tema dark do admin-web (design system Polaridade 3D), não um azul inventado. Tokens de referência copiados de apps/admin-web/src/app/globals.css (bloco .dark): - base = --background: 222 45% 6% (~#080D16) — bem mais escuro que o --kybalion-navy #0A1226 (que é o --sidebar-background, não o fundo de conteúdo); - veios = .dark .veio-marca (2 radiais de --primary dark, hsl(217 91% 60%), alphas 0.2/0.09) — copiados literalmente, é a mesma "atmosfera de marca" das páginas escuras do app (e era a receita que o FR-838 já tinha traduzido para cá antes do mosaico). ABORDAGEM ABANDONADA — NÃO REPETIR (achado real, 2026-08-11, 5ª/6ª iteração): mover a composição de fundo para um pseudo-elemento ".pf-v5-c-login::before" com position:fixed + "filter: brightness(0.55) saturate(1.3)" (para escurecer multiplicativamente) renderizava CORRETO no Chromium headless do Playwright, mas NÃO renderizava no Chrome REAL do usuário: o DevTools confirmou que a resposta HTTP do CSS continha literalmente "brightness(0.55) saturate(1.3)" (servidor/cache 100% descartados — inclusive trocando a URL para kybalion-login.v2.css), e mesmo assim nada do efeito aparecia (nem escurecimento, nem mosaico — só um gradiente azul liso). A estrutura ::before + position:fixed + filter é frágil o suficiente para divergir entre headless e navegador real; causa exata não investigada a fundo (custo > benefício). Por isso NÃO usar pseudo-elemento, NÃO usar filter e NÃO validar esta tela confiando apenas em screenshot Playwright — a validação final é sempre o navegador real do usuário. Abordagem vigente (6ª iteração): background multi-camada DIRETO no body e em .pf-v5-c-login com background-attachment: fixed — a MESMA estrutura das 4 primeiras iterações, que comprovadamente renderizava no Chrome real. O "escurecer mais sem apagar o mosaico" (pedido do usuário após aprovar a visibilidade do mosaico na receita de véu 0.55/0.35) é feito DENTRO do próprio background-blend-mode: uma camada de CINZA NEUTRO com blend "multiply" — multiplicar por cinza g escala os 3 canais igualmente, ou seja, é exatamente brightness(g) implementado sem filter, preservando o contraste RELATIVO entre facetas (ao contrário do véu alpha, que comprime tudo para uma cor só — véu 0.65/0.45 já tinha sido testado e apagava as facetas no centro/direita). Com o multiply assumindo o papel de escurecer, o véu alpha CAI de 0.55/0.35 para 0.30/0.15 (só um leve degradê direcional). Nota: escurecer a TINTA da camada "color" (#1E3A8A→#2563EB) NÃO escurece nada — o blend "color" transfere só matiz/saturação e mantém a luminosidade do fundo; foi considerado e descartado por matemática. Camadas (background-blend-mode aceita um modo POR camada, topo→base): 1-2. os 2 radiais do .dark .veio-marca (blend "normal") — glow azul sutil nos cantos, consistência visual com o resto do app; 3. véu escuro rgba(8,13,22, 0.30→0.15) (blend "normal") — leve degradê direcional (alpha maior no canto onde o PNG é mais claro); knob SECUNDÁRIO de escuridão — subir demais comprime o contraste das facetas (0.65/0.45 já apagava o centro, testado); 4. linear-gradient cinza neutro #3A3A3A→#4A4A4A (blend "multiply") — brightness ~0.23→0.29 sem filter; É O KNOB PRIMÁRIO de escuridão de agora em diante (cinza mais escuro = fundo mais escuro, contraste relativo das facetas preservado). Calibração medida em screenshot 1440x900 (luminância média da faixa esquerda do fundo; alvo = --background dark do app #080D16 ≈ 12.6): #5F5F5F/#737373 → ~31; #474747/#575757 → ~24; #3A3A3A/#4A4A4A → ~20 com mínimo 12.6 (= exatamente o token) e facetas ainda distinguíveis — escolhido por ser o mais próximo do "navy quase preto" pedido sem virar chapado; 5. linear-gradient #1E3A8A→#2563EB (blend "color") — pega SÓ matiz/saturação e tinge as facetas de azul sem achatar o claro/escuro dos triângulos; 6. url(mosaico) (blend "screen") sobre a base hsl(222 45% 6%) — levanta a luminância das facetas do PNG cru (escuro demais: sem esse lift o fundo saía preto com textura invisível, testado empiricamente via screenshot Playwright/Chrome). Histórico das iterações (1ª-4ª validadas/reprovadas com screenshot real E confirmadas renderizando no Chrome real do usuário): "multiply"/"overlay" DA IMAGEM contra navy escuro (sugestão inicial) afogavam o mosaico em quase-preto (multiplicar dois escuros — diferente do multiply por cinza MÉDIO da camada 4 atual, que só escala); screen+color puro (2 camadas, tinta #1D4ED8→#2563EB) ficou "muito claro"/vibrante para o usuário; véu navy 0.62→0.40 sobre isso ainda ficou mais claro que o tema das páginas; base #080D16 com véu 0.80→0.62 acertou o tom mas "engoliu" o mosaico (4ª iteração — o usuário confirmou que QUER o mosaico visível); véu 0.55/0.35 acertou o mosaico mas ficou claro demais → daí o filter (abandonado, ver acima) → daí a receita multiply atual. Aplicada no body (com !important — achado original: o CSS base do keycloak.v2 pinta o body e precisa ser vencido) e repetida em .pf-v5-c-login (elemento que cobre o viewport no layout PF v5), com background-attachment fixo NOS DOIS (com imagem, os dois precisam do fixed para as camadas coincidirem e o mosaico não "rolar"/desalinhar em telas baixas). A cor de fallback fica na última camada — se o PNG falhar em carregar, o fundo degrada para o navy quase-preto do tema dark do app, nunca branco. */ .login-pf body, body#keycloak-bg { /* REVERTIDO para a receita da 4ª iteração (decisão do usuário, 2026-08-11: "volta pra versão que tinha mosaico mas era mais clara" — ver histórico acima. A camada de cinza "multiply" da 6ª iteração foi removida; véu volta a 0.55/0.35. Mais clara que a 6ª, mas é a última versão com o mosaico confirmado como aceitável pelo usuário antes das tentativas de escurecimento. */ background: radial-gradient(1100px 520px at 82% -10%, hsl(217 91% 60% / 0.2), transparent 60%), radial-gradient(900px 420px at -10% 110%, hsl(217 91% 60% / 0.09), transparent 55%), linear-gradient(135deg, rgba(8, 13, 22, 0.55), rgba(8, 13, 22, 0.35)), linear-gradient(135deg, #1E3A8A, #2563EB), url("../img/keycloak-bg-mosaico.png") hsl(222 45% 6%) !important; background-size: cover !important; background-position: center !important; background-attachment: fixed !important; background-blend-mode: normal, normal, normal, color, screen; } .pf-v5-c-login { background: radial-gradient(1100px 520px at 82% -10%, hsl(217 91% 60% / 0.2), transparent 60%), radial-gradient(900px 420px at -10% 110%, hsl(217 91% 60% / 0.09), transparent 55%), linear-gradient(135deg, rgba(8, 13, 22, 0.55), rgba(8, 13, 22, 0.35)), linear-gradient(135deg, #1E3A8A, #2563EB), url("../img/keycloak-bg-mosaico.png") hsl(222 45% 6%); background-size: cover; background-position: center; background-attachment: fixed; background-blend-mode: normal, normal, normal, color, screen; } /* Logo. * * DIVERGÊNCIA vs. tentativa inicial (achado real, testado empiricamente, * 2026-07-30): a primeira versão mirava "div.kc-logo-text" (classe que * aparece no HTML do Realm "master" built-in do Keycloak, cujo * "displayNameHtml" tem literalmente o valor * "
Keycloak
" configurado no * próprio Realm master). Testado com o realm-export.json real desta spec * (Realm "kybalion", sem "displayName"/"displayNameHtml" definido): o * template.ftl renderiza `${kcSanitize(msg("loginTitleHtml", realm.displayNameHtml!''))}` * e a mensagem padrão `loginTitleHtml={0}` (base/login/messages/messages_en.properties) * não envolve nenhum HTML — o header vira só o texto puro "kybalion" (nome * técnico do realm), SEM a div.kc-logo-text. Confirmado via screenshot real * (Chrome headless contra Keycloak 26.0 com o realm-export.json importado): * a logo não aparecia, só o texto "KYBALION" da fonte padrão do tema. * * Correção: mirar "#kc-header-wrapper" diretamente — esse ID é sempre * renderizado pelo template.ftl (ver extração do JAR keycloak-themes-26.0.8, * theme/keycloak.v2/login/template.ftl), independente do conteúdo de * "displayNameHtml" do Realm. O texto (seja "kybalion", "Keycloak" ou * qualquer outro) é escondido via "font-size: 0" (mantém acessível a leitores * de tela, que não dependem do tamanho visual da fonte) e o logo é aplicado * via background-image no próprio wrapper. Retestado com screenshot real * após a correção — logo aparece corretamente. * * FR-838 (2026-08-10, substitui FEAT-EUX-ext-02): o `position: fixed` * incondicional de 320px colidia com o card em telas estreitas (diagnóstico * do addendum §3). A versão FR-838 era responsiva: <768px no fluxo normal * centralizada acima do card; ≥768px fixa no canto superior esquerdo via * position:fixed + padding-top de 6.5rem em .pf-v5-c-login como reserva. * * REVERSÃO PARCIAL do FR-838 (decisão do usuário, 2026-08-11): a logo volta * a ficar CENTRALIZADA, ACIMA DO CARD, NO FLUXO NORMAL do documento em * TODOS os breakpoints — inspirada na tela de login do tema clássico/legado * do próprio Keycloak (logo grande centralizada sobre o fundo de mosaico * triangulado), que o usuário escolheu como referência ao adotar o fundo * mosaico azulado (ver bloco "Atmosfera de fundo" acima). Reverte-se * ESPECIFICAMENTE a posição fixa/canto de ≥768px do FR-838 (e o padding-top * de compensação em .pf-v5-c-login, que só existia por causa do logo fixo); * todo o resto do redesign FR-838 (microlabels, glow do card, cores, * alvos ≥44px) permanece intacto. Em telas grandes a logo apenas CRESCE * (media queries de width/height abaixo), nunca sai do fluxo — é o mesmo * comportamento "hero" da versão original validada por screenshot em * 2026-07-30, agora para todos os tamanhos de tela. * * DIVERGÊNCIA vs. FEAT-EUX-ext-02 (defesa em profundidade do fundo): a * versão anterior pintava background-color navy sólido no wrapper para * casar com o fundo então chapado. Com o fundo agora em gradiente (veios), * um retângulo navy sólido atrás do logo viraria ele próprio um artefato * visível — por isso o background-color sólido foi removido de propósito. */ #kc-header-wrapper { position: static; display: block; width: min(240px, 64vw); height: 60px; margin: 0 auto 1.5rem; background-image: url("../img/logo-kybalion.png"); background-repeat: no-repeat; background-position: center; background-size: contain; padding: 0; font-size: 0; line-height: 0; color: transparent; } /* ≥768px: só cresce, continua centralizada no fluxo (reversão 2026-08-11 — sem position:fixed, sem padding-top de compensação em .pf-v5-c-login) */ @media (min-width: 768px) { #kc-header-wrapper { width: 280px; height: 70px; margin-bottom: 2rem; } } @media (min-width: 1200px) { #kc-header-wrapper { width: 340px; height: 85px; } } /* Painel/card do formulário (FR-838) — superfície clara sobre o navy (spec seção 6: "formulário em superfície clara", sem dark mode), agora com identidade EM REPOUSO (design-system §9.1): sombra com tinta de marca visível numa screenshot estática — glow azul contido + camada próxima azulada + sombra preta profunda (receita .dark .tile-3d, traduzida para rgba porque o card claro flutua sobre fundo escuro) — borda azul quase invisível (~0.10) e raio 1.25rem. Nunca sombra cinza genérica. */ .pf-v5-c-login__main { background-color: var(--kybalion-white); border: 1px solid rgba(var(--kybalion-ink), 0.10); border-radius: var(--kybalion-radius-card); padding: clamp(2rem, 4.5vw, 2.75rem); box-shadow: 0 0 30px -8px rgba(var(--kybalion-ink), 0.30), 0 2px 6px rgba(var(--kybalion-ink), 0.12), 0 28px 52px -26px rgba(2, 6, 23, 0.70); } /* Título — hierarquia forte (FR-838): peso 700, tracking apertado */ .pf-v5-c-login__main-header .pf-v5-c-title, #kc-page-title { color: var(--kybalion-navy); font-weight: 700; letter-spacing: -0.02em; } /* Achado real (testado via screenshot Chrome headless, 2026-07-30): o template.ftl herdado do keycloak.v2 alterna a classe ".pf-v5-theme-dark" no via JS conforme "prefers-color-scheme" do navegador/SO do usuário — sem override explícito, labels e inputs ficavam brancos sobre o card branco (ilegíveis) quando o SO está em dark mode. Como a spec (seção 6) exige um único tema, sem variação dark/light, força-se a aparência clara sempre, com !important e cobrindo também o seletor ".pf-v5-theme-dark", independente da preferência do SO/navegador. FR-838: labels agora em MICROLABEL (eco de Tile3DMicroRotulo, §9.1 item 5) — caixa alta, tracking largo, tamanho reduzido, cor apagada mas AA sobre branco (slate-600 ≈ 7.5:1). text-transform é puramente visual: o texto/HTML do label do tema pai não muda (FR-127). Fonte revertida de monoespaçada (--kybalion-mono) para a fonte padrão do tema (--kybalion-font, mesma usada no resto da página) — decisão do usuário, 2026-08-11: a mono era só um eco decorativo do design system, não um requisito; o padrão de marca é a fonte de sistema comum. */ .pf-v5-c-form__label, .pf-v5-theme-dark .pf-v5-c-form__label, .pf-v5-c-form__label-text, .pf-v5-theme-dark .pf-v5-c-form__label-text { color: var(--kybalion-label) !important; } .pf-v5-c-form__label-text, .pf-v5-theme-dark .pf-v5-c-form__label-text { font-family: var(--kybalion-font); font-size: 0.6875rem; font-weight: 600; text-transform: uppercase; letter-spacing: 0.12em; } /* Inputs — raio de marca + fundo/texto claros forçados (ver achado acima). * * Achado real (2026-08-04, evidência de teste manual: texto digitado em * "Nome de usuário ou e-mail"/"Senha" aparecia cinza-claro, como se o campo * estivesse desabilitado). Causa: no Keycloak 26 (keycloak.v2), a classe * ".pf-v5-c-form-control" é aplicada ao WRAPPER do campo, não ao * em si — o real não tem nenhuma classe (confirmado via * HTML servido: ``). Regras de COR DE TEXTO precisam mirar o `` filho * (`.pf-v5-c-form-control input`); regras de fundo/borda/raio ficam no * wrapper (que é quem desenha o "campo"). Nunca usar * `input.pf-v5-c-form-control` (exige a classe NO PRÓPRIO input — nunca * casa neste DOM). */ .pf-v5-c-form-control, .pf-v5-theme-dark .pf-v5-c-form-control { border-radius: var(--kybalion-radius); background-color: var(--kybalion-white) !important; border: 1px solid var(--kybalion-input-border) !important; } /* FR-838: alvo de toque ≥44px (2.75rem) e texto confortável no filho (ver achado do wrapper acima) */ .pf-v5-c-form-control input, .pf-v5-theme-dark .pf-v5-c-form-control input { color: var(--kybalion-navy) !important; background-color: transparent !important; min-height: 2.75rem; padding-top: 0.5rem; padding-bottom: 0.5rem; font-size: 1rem; } /* Mesma correção de alvo do bloco acima — "::placeholder" só existe em * elementos de formulário de verdade (input/textarea), nunca no * wrapper ".pf-v5-c-form-control"; sem efeito prático até agora, mas * corrigido para não regredir se algum browser mudasse o fallback. */ .pf-v5-c-form-control input::placeholder, .pf-v5-theme-dark .pf-v5-c-form-control input::placeholder { color: var(--kybalion-placeholder) !important; } /* Focus ring azul de marca, 2px (FR-838) — no wrapper, que desenha o campo */ .pf-v5-c-form-control:focus-within { border-color: var(--kybalion-blue) !important; box-shadow: 0 0 0 2px rgba(var(--kybalion-ink), 0.35); } /* Botão de mostrar/ocultar senha (olho) — combina com o input claro e acompanha a altura ≥44px do campo */ .pf-v5-c-button.pf-m-control, .pf-v5-theme-dark .pf-v5-c-button.pf-m-control { background-color: var(--kybalion-white) !important; color: var(--kybalion-navy) !important; border: 1px solid var(--kybalion-input-border) !important; min-height: 2.75rem; } /* Botão de ação primária — azul de marca com sombra de tinta em repouso (FR-838, mesma filosofia §9.1: identidade sem hover) e alvo ≥44px */ .pf-v5-c-button.pf-m-primary { background-color: var(--kybalion-blue); border-radius: var(--kybalion-radius); border-color: var(--kybalion-blue); min-height: 2.75rem; font-size: 1rem; font-weight: 600; box-shadow: 0 10px 24px -10px rgba(var(--kybalion-ink), 0.55), 0 2px 6px rgba(var(--kybalion-ink), 0.25); } .pf-v5-c-button.pf-m-primary:hover, .pf-v5-c-button.pf-m-primary:focus { background-color: var(--kybalion-blue-hover); border-color: var(--kybalion-blue-hover); box-shadow: 0 12px 28px -10px rgba(var(--kybalion-ink), 0.65), 0 2px 6px rgba(var(--kybalion-ink), 0.30); } /* Anel de foco visível do botão sobre o card branco (teclado) */ .pf-v5-c-button.pf-m-primary:focus-visible { box-shadow: 0 0 0 2px var(--kybalion-white), 0 0 0 4px var(--kybalion-blue), 0 10px 24px -10px rgba(var(--kybalion-ink), 0.55); } /* Transições suaves — só com movimento permitido pelo SO */ @media (prefers-reduced-motion: no-preference) { .pf-v5-c-form-control { transition: border-color 0.2s ease, box-shadow 0.2s ease; } .pf-v5-c-button.pf-m-primary { transition: background-color 0.2s ease, box-shadow 0.2s ease; } } /* Links — azul de marca (ex.: "esqueci minha senha", "registrar") */ .pf-v5-c-login a, .pf-v5-c-login__main a { color: var(--kybalion-blue); } .pf-v5-c-login a:hover, .pf-v5-c-login__main a:hover { color: var(--kybalion-blue-hover); } /* Mensagens de erro nativas — só a cor semântica (vermelho de marca), nunca o texto/lógica (FR-127) — segue a paleta de erro de specs/design-system-frontend.md §3.2 */ .pf-v5-c-alert.pf-m-danger { border-color: var(--kybalion-error); background-color: #FEF2F2; } .pf-v5-c-alert.pf-m-danger .pf-v5-c-alert__icon, .pf-v5-c-alert.pf-m-danger .pf-v5-c-alert__title { color: var(--kybalion-error); } .pf-m-error.kc-feedback-text, .pf-v5-c-helper-text__item-text.pf-m-error { color: var(--kybalion-error); } /* Erro em nível de campo (ex.: AC-04 "usuário/senha inválidos" — confirmado via submissão real: o Keycloak marca o do input com ".pf-v5-c-form-control.pf-m-error", não um alert de página) — precisa de especificidade maior que a regra de input "clara" acima para o vermelho aparecer. */ .pf-v5-c-form-control.pf-m-error, .pf-v5-theme-dark .pf-v5-c-form-control.pf-m-error { border: 1px solid var(--kybalion-error) !important; } .pf-v5-c-form-control.pf-m-error .pf-v5-c-form-control__icon { color: var(--kybalion-error); } /* Rodapé (links de idioma/voltar) — mantém legibilidade sobre o navy */ .pf-v5-c-login__main-footer, .pf-v5-c-login__main-footer-links-item-link { color: var(--kybalion-white); }