/* =====================================================================
   Portal Contracheques — Employee Shell (Phase 3)

   Composição LOCAL do Portal sobre os tokens/componentes do Hebreus
   Product Design System (hb-tokens.generated.css, hb-foundation.css,
   hb-components.css). Não é parte do design system canônico: toda cor,
   espaçamento, raio, fonte e duração aqui referencia um token já
   publicado — nenhum valor visual novo é introduzido. Segue o mesmo
   padrão de composição local do admin-shell.css (Phase 2).

   Consumido só pelas telas do colaborador migradas nesta fase: login,
   register, forgot-password, reset-password, change-password, home
   (index.html) e erro_download.
   ===================================================================== */

/* ---------------------------------------------------------------------
   Superfície da tela — papel como fundo, nunca branco de página inteira
   (missão §3). `min-height: 100vh` evita o papel "vazar" para o branco
   do <html> em telas curtas de conteúdo.
   --------------------------------------------------------------------- */
.hb-employee-shell {
  background: var(--hb-color-paper);
  /* dvh com fallback vh: em navegador mobile `100vh` é a altura da
     viewport COM a barra de endereço retraída, então uma tela cujo
     conteúdo cabe inteiro ainda ganhava ~100px de rolagem só por causa
     desta regra. `100dvh` acompanha a barra dinâmica. */
  min-height: 100vh;
  min-height: 100dvh;
}

/* ---------------------------------------------------------------------
   Telas curtas (login, recuperação, redefinição) — missão pós-release
   "mobile auth + password modal polish" §2/§3. Causa raiz medida no
   browser (Playwright, 390x844/360x800/320x700): abaixo de 1024px
   .hb-portal-focus/.hb-login-split não tinham NENHUMA regra de
   centralização vertical — só um padding-top fixo de 28px
   (--hb-space-gutter-focus) — então o bloco (logo+hero+form+links)
   ficava ancorado no topo e sobrava até ~491px de vazio embaixo em
   telas com pouco conteúdo. Cadastro (register.html) não usa esta
   classe de propósito: o formulário dele já enche/excede a viewport
   (whitespace medido: -169px a +9px), então não recebe (nem precisa
   de) este ajuste — mesma causa raiz, sintoma só aparece em conteúdo
   curto. justify-content (eixo principal em coluna) centraliza o bloco
   inteiro sem mexer no align-items/stretch que mantém CPF/senha com
   largura total; min-height com fallback dvh cobre a barra de endereço
   dinâmica do navegador mobile. Sem risco de corte: se o conteúdo algum
   dia superar a viewport, min-height cede (não é max-height) e o bloco
   volta a crescer normalmente. */
@media (max-width: 1023.98px) {
  .hb-employee-shell--short {
    display: flex;
    flex-direction: column;
    justify-content: center;
    min-height: 100vh;
    min-height: 100dvh;
  }
}

/* ---------------------------------------------------------------------
   Telas de foco único (login, cadastro, recuperação, troca de senha).
   Coluna estreita centralizada, sem Card — o papel é a superfície
   principal (missão §6). 420px é decisão LOCAL de layout, não um token
   novo: mesmo raciocínio do breakpoint 1024px do admin-shell.css.
   --------------------------------------------------------------------- */
.hb-portal-focus {
  max-width: 420px;
  margin: 0 auto;
  padding: var(--hb-space-gutter-focus) var(--hb-space-gutter-content) var(--hb-space-9);
  /* Safe area (notch/barra de gestos): o gutter continua sendo o piso —
     `max()` só acrescenta quando o aparelho realmente reserva a área.
     Sem isto o conteúdo encosta na borda arredondada em iPhone/Android
     com display curvo, em paisagem principalmente. */
  padding-left: max(var(--hb-space-gutter-content), env(safe-area-inset-left));
  padding-right: max(var(--hb-space-gutter-content), env(safe-area-inset-right));
  padding-bottom: max(var(--hb-space-9), env(safe-area-inset-bottom));
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-8);
}

@media (min-width: 600px) {
  .hb-portal-focus {
    padding-top: var(--hb-space-9);
  }
}

/* Abertura Editorial — exatamente uma frase por tela (missão §4). */
.hb-editorial-opening {
  font-family: var(--hb-typography-scale-title-font-family);
  font-size: var(--hb-typography-scale-title-font-size);
  font-weight: var(--hb-typography-scale-title-font-weight);
  letter-spacing: var(--hb-typography-scale-title-letter-spacing);
  line-height: var(--hb-typography-scale-title-line-height);
  color: var(--hb-color-text-primary);
  margin: 0;
  /* Sem isto, uma palavra longa ("contracheques") não quebra e estoura
     o contêiner em viewports efetivos muito estreitos (zoom 200%+ em
     390px) — achado no teste de zoom real da Phase 3. */
  overflow-wrap: break-word;
}

/* Texto de apoio Interface — instrução/explicação abaixo da abertura. */
.hb-portal-lede {
  font-family: var(--hb-typography-scale-body-font-family);
  font-size: var(--hb-typography-scale-body-font-size);
  line-height: var(--hb-typography-scale-body-line-height);
  color: var(--hb-color-text-secondary);
  margin: calc(var(--hb-space-6) * -1) 0 0;
}

.hb-form {
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-6);
}

.hb-form-error {
  font-family: var(--hb-typography-scale-body-small-font-family);
  font-size: var(--hb-typography-scale-body-small-font-size);
  color: var(--hb-color-danger-text);
  margin: 0;
}

/* Botão de largura total — modificador de layout local, nenhuma cor ou
   token novo (o próprio .hb-btn--primary/.hb-btn--secondary continua
   fazendo todo o trabalho visual). */
.hb-btn--block {
  width: 100%;
}

/* Campo de senha com botão de revelar — a linha some, a leitura fica na
   mesma altura do underline (missão §19: o glifo não altera a altura). */
.hb-password-field__row {
  display: flex;
  align-items: center;
  gap: var(--hb-space-2);
}

.hb-password-field__row .hb-input--underline {
  flex: 1 1 auto;
  /* min-width padrão de item flex é `auto` (tamanho de conteúdo do
     input), não 0 — sem isto o campo nunca cede espaço ao botão de
     revelar e a linha estoura em viewports efetivos muito estreitos
     (zoom 200%+ em 390px). Mesmo achado do Definition Row (hb-components.css). */
  min-width: 0;
}

/* O botão de revelar nunca cede espaço: alvo de 48px é ergonômico
   (missão §19), não estético — quem cede é o campo de texto acima. */
.hb-password-field__row .hb-password-toggle {
  flex-shrink: 0;
}

.hb-portal-links {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: var(--hb-space-4);
  text-align: center;
}

/* ---------------------------------------------------------------------
   Logo do login — proporção do arquivo aprovado preservada (missão de
   branding §2). 180px é decisão LOCAL de layout, mesmo raciocínio do
   420px de .hb-portal-focus; max-width:100% é a rede de segurança que já
   reduz de forma limpa em qualquer viewport sem precisar da logo
   compacta (só existe motivo para trocar de asset se isto não bastar).
   --------------------------------------------------------------------- */
.hb-portal-logo {
  display: block;
  width: 180px;
  max-width: 100%;
  height: auto;
}

/* ---------------------------------------------------------------------
   Bloco de abertura do login (logo + título + hero). Existe para que os
   três sejam UM conjunto visual, não três irmãos soltos com o mesmo gap
   do formulário: o espaçamento interno é menor que o externo, que é o
   que faz o olho ler "um bloco" em vez de "três coisas empilhadas".
   No mobile o conjunto inteiro é centralizado horizontalmente (a logo
   ficava alinhada à esquerda porque `align-items: stretch` do flex
   column não move um item de largura fixa); no desktop o alinhamento à
   esquerda da coluna do split é preservado como estava.
   --------------------------------------------------------------------- */
.hb-login-intro {
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-6);
}

/* ---------------------------------------------------------------------
   Login split-screen (missão de branding §4/§5). Abaixo do breakpoint
   desktop o painel de hero desktop nem existe visualmente — quem aparece
   no mobile é a faixa .hb-login-hero-mobile logo abaixo (missão de
   integração hero mobile), não o split de 3 heroes.
   --------------------------------------------------------------------- */
.hb-login-hero {
  display: none;
}

/* ---------------------------------------------------------------------
   Hero mobile compacta — fixa (não sorteada), só existe <1024px. É
   background-image dentro de media query (não <img>): a media query só
   bate <1024px, então o navegador nunca baixa hero-mobile-compact.png em
   desktop, do mesmo jeito que login-hero.js evita baixar as 3 heroes
   desktop à toa no mobile (mesmo raciocínio de performance, missão §10).
   Proporção real do arquivo aprovado (missão de polish final §3):
   2172×724 (~3:1, faixa bem horizontal) — aspect-ratio preserva isso;
   max-height é quem faz a faixa ficar "compacta" (missão §4) e crop
   leve de bordas via background-size:cover é aceitável desde
   que rosto/celular/documento (centro da composição) não sejam cortados
   — background-position:center garante isso.
   --------------------------------------------------------------------- */
.hb-login-hero-mobile {
  display: none;
}

@media (max-width: 1023.98px) {
  .hb-login-hero-mobile {
    display: block;
    width: 100%;
    aspect-ratio: 2172 / 724;
    /* A altura acompanha a viewport em vez de ser fixa em 160px: numa
       tela alta (412×915) sobravam ~140px de papel vazio em cima E
       embaixo do conjunto centralizado, e a hero é o único elemento que
       pode ocupar essa folga sem esticar campo nenhum. `clamp` mantém o
       piso de 96px (tela baixa) e o teto de 200px (não vira banner). */
    max-height: clamp(96px, 22dvh, 200px);
    border-radius: var(--hb-radius-container);
    background-image: url('/static/img/login/hero-mobile-compact.png');
    background-size: cover;
    background-position: center;
  }

  /* Espaçamento vertical mais justo só no login mobile (não mexe em
     register/forgot-password/etc — .hb-login-split__form é exclusivo
     desta tela) para abrir espaço pra hero sem gerar scrollbar
     desnecessária em 390×844/375×812/360×800 (missão §5). */
  .hb-login-split__form.hb-portal-focus {
    gap: var(--hb-space-6);
  }

  /* Logo, título e hero centralizados como um conjunto único. */
  .hb-login-intro {
    align-items: center;
    text-align: center;
    gap: var(--hb-space-5);
  }

  .hb-login-intro .hb-portal-logo {
    margin-inline: auto;
  }

  .hb-login-intro .hb-login-hero-mobile {
    align-self: stretch;
  }

  /* Padding vertical simétrico quando o bloco é centralizado pelo shell:
     com 28px em cima e 40px embaixo o conjunto ficava opticamente
     empurrado para cima mesmo com `justify-content: center` resolvido. */
  .hb-employee-shell--short .hb-portal-focus {
    padding-top: var(--hb-space-gutter-focus);
    padding-bottom: max(var(--hb-space-gutter-focus), env(safe-area-inset-bottom));
  }
}

/* 320×700 é o caso mais restrito (missão §6): formulário completo tem
   prioridade sobre a hero. Combina max-width E max-height (não só
   largura) — reduz a hero e o espaçamento em vez de escondê-la, que já
   é suficiente pra caber sem scroll indevido. */
@media (max-width: 1023.98px) and (max-height: 700px) {
  .hb-login-hero-mobile {
    max-height: 84px;
  }

  .hb-login-split__form.hb-portal-focus {
    padding-top: var(--hb-space-6);
    padding-bottom: var(--hb-space-7);
    gap: var(--hb-space-5);
  }
}

@media (min-width: 1024px) {
  /* height (não min-height): min-height:100vh deixa a altura da row
     indefinida para fins de porcentagem — .hb-login-hero__img (max-height:
     100%) não tinha base pra resolver e o navegador caía no tamanho
     NATURAL da imagem (ex.: 928px), estourando a viewport em telas como
     1440×900/1366×768 mesmo com todo o conteúdo cabendo (scroll vertical
     indevido, achado na inspeção manual). height:100vh dá à row (e por
     stretch, a .hb-login-hero) uma altura definida, então max-height:100%
     passa a valer de verdade. overflow continua visible (nenhum
     overflow-y:hidden) — se o CONTEÚDO realmente precisar de mais espaço
     (zoom, texto maior), ele ainda transborda a box e o scroll aparece. */
  /* Missão de composition polish §5: form e hero liam longe demais.
     Causa raiz medida no browser (1440×900): a coluna do form ia até
     480px enquanto .hb-portal-focus (o conteúdo real) só usa até
     420px — 60px de coluna "morta" antes da hero sequer começar. Teto
     ajustado para 420px (o próprio max-width de .hb-portal-focus, sem
     folga) e um column-gap explícito e deliberado substitui esse
     espaço solto por um espaçamento medido/consciente. */
  .hb-login-split {
    display: grid;
    grid-template-columns: minmax(360px, 420px) 1fr;
    column-gap: var(--hb-space-8);
    height: 100vh;
    /* Sem isto a coluna 1fr da hero ia até a borda direita da viewport
       — em telas largas (1440px+) isso não "centraliza o conjunto",
       cria uma hero cada vez mais larga (mais imagem, mais margem
       interna proporcional do próprio PNG) empurrando o desenho pra
       ainda mais longe do form. 1280px mantém o mesmo raciocínio de
       largura de conteúdo do resto do Portal, centralizado como bloco
       único — o par form+hero, não cada metade. */
    max-width: 1280px;
    margin-inline: auto;
  }

  /* Fallback de imagem quebrada (missão §11) — login-hero.js aplica este
     modificador no erro do <img> e esconde o <aside>; o formulário volta
     a ocupar a tela inteira em vez de deixar a segunda coluna vazia. */
  .hb-login-split--no-hero {
    grid-template-columns: 1fr;
  }

  /* Centraliza o bloco de login verticalmente na coluna alta do split.
     justify-content (não align-items): esta div já é flex-direction:column
     por causa de .hb-portal-focus (empilha logo/h1/form/links) — usar
     align-items aqui centralizaria o eixo CRUZADO (largura dos campos),
     não a altura. justify-content atua no eixo principal (vertical),
     sem mexer no stretch que mantém CPF/senha com largura total. */
  .hb-login-split__form {
    display: flex;
    justify-content: center;
  }

  .hb-login-hero {
    display: flex;
    align-items: center;
    justify-content: center;
    padding: var(--hb-space-9);
    /* Lado que encosta no form, mais enxuto: o column-gap acima já é
       quem separa os dois painéis de forma deliberada — o padding
       cheio dos dois lados era espaço duplicado (missão §5.2). */
    padding-left: var(--hb-space-6);
    background: var(--hb-color-paper);
    overflow: hidden;
  }

  .hb-login-hero__img {
    max-width: 100%;
    max-height: 100%;
    width: auto;
    height: auto;
    /* Sem crop, sem distorção — a ilustração inteira sempre cabe (missão
       §5); as heroes já vêm com Warm Paper de fundo, então não há costura
       visível contra .hb-login-hero. */
    object-fit: contain;
  }

  /* [hidden] tem especificidade de atributo (igual a uma classe) e o
     default do browser pra ele já é display:none — mas author-CSS sempre
     vence UA-CSS, então o `display: flex` logo acima ganhava do `hidden`
     que login-hero.js seta no erro de imagem. Precisa de uma regra local
     mais específica pra fallback (missão §11) realmente esconder o painel. */
  .hb-login-hero[hidden] {
    display: none;
  }
}

/* ---------------------------------------------------------------------
   Home / Meus Contracheques — hierarquia documental (missão §11/§12).
   --------------------------------------------------------------------- */
.hb-portal-home {
  max-width: var(--hb-breakpoint-max-width-content);
  margin: 0 auto;
  padding: var(--hb-space-gutter-content) var(--hb-space-gutter-content) var(--hb-space-9);
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-8);
}

.hb-portal-home__header {
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-3);
}

.hb-portal-home__greeting {
  font-family: var(--hb-typography-scale-body-font-family);
  font-size: var(--hb-typography-scale-body-font-size);
  color: var(--hb-color-text-secondary);
  margin: 0;
}

.hb-portal-home__actions {
  display: flex;
  flex-wrap: wrap;
  gap: var(--hb-space-5);
}

/* Filtros — Select continua OPEN no Hebreus DS (§22.7): o controle
   nativo do navegador não é redesenhado, só recebe o tratamento de
   contorno já autorizado para campo (.hb-input--outlined também serve a
   um <select>, é CSS genérico, não um componente novo). */
.hb-payslip-filters {
  display: flex;
  flex-wrap: wrap;
  align-items: flex-end;
  gap: var(--hb-space-5);
}

.hb-payslip-filters .hb-field {
  flex: 1 1 140px;
}

.hb-payslip-filters select.hb-input--outlined {
  appearance: auto;
}

.hb-payslip-list {
  list-style: none;
  margin: 0;
  padding: 0;
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-5);
}

.hb-payslip-card {
  background: var(--hb-color-surface);
  border: var(--hb-border-hairline);
  border-radius: var(--hb-radius-container);
  padding: var(--hb-space-6);
  display: flex;
  flex-direction: column;
  gap: var(--hb-space-2);
}

.hb-payslip-card__download {
  align-self: flex-start;
  margin-top: var(--hb-space-4);
}

.hb-payslip-card--hidden {
  display: none;
}

.hb-payslip-empty-filter {
  font-family: var(--hb-typography-scale-body-small-font-family);
  font-size: var(--hb-typography-scale-body-small-font-size);
  color: var(--hb-color-text-secondary);
  text-align: center;
  margin: 0;
}

/* ---------------------------------------------------------------------
   Responsive Pair local para os pares de campo (nome/e-mail, senha
   nova/confirmação) — mesma regra de empilhar em telas estreitas do
   .hb-pair canônico, mas para <div class="hb-field"> específicos desta
   composição. Reutiliza .hb-pair diretamente nos templates; nenhuma
   regra nova é necessária aqui.
   --------------------------------------------------------------------- */