/* ds-shell.css — cola entre o tema e o Design System.
   Arquivo NOSSO: ds-app.css e ds-kb.css são cópias intocadas dos arquivos do
   Claude Design, então tudo que é adaptação ao WHMCS mora aqui.

   Os mockups (ui-kit/index.html, suporte.html) não desenham barra superior nem
   rodapé, porque são recortes da área logada. Isso NÃO significa que o site
   perde o cabeçalho: header.nt-nav e footer.nt-footer continuam renderizando
   aqui como em qualquer outra rota — são a identidade da NTWeb.
   O nav é `sticky` com z-index 40 e fundo opaco, então fica acima do shell sem
   precisar de ajuste; o rodapé é opaco e fecha a página embaixo do conteúdo. */

/* <main> do tema é só um invólucro aqui: o espaçamento é do .kb-shell/.shell.
   `display:block` é obrigatório — o tema declara `display:flex` no <main>, o que
   transforma o shell em flex item e o encolhe até a largura do conteúdo
   (grid vira `260px 0px` e o painel some). */
body.nt-ds-app > main#main {
  display: block;
  margin: 0;
  padding: 0;
  max-width: none;
}

/* Nos mockups a coluna de conteúdo é o próprio `<main>`, irmão do
   `<nt-sidebar>` dentro de `.shell`. No WHMCS esse nome já está tomado: o core
   envolve o template inteiro num `<main id="main">`, que fica FORA do shell.
   Então a coluna virou `<div class="ds-main">` e as regras de `main` do
   ds-app.css (linha 74) são repetidas aqui apontando para ela. É a única
   alteração de nome de elemento em toda a importação — sem ela, ou o
   espaçamento vertical não existe, ou ele vaza para o cabeçalho e o rodapé.

   Sem `body` no seletor de propósito: assim a regra pesa 0-2-0 e perde para o
   `body.ds-<slug> .ds-main` que ds-screens.css emite (0-2-1). Isso é o que
   permite ao dashboard e à tela de parceiros usarem o `gap:32px` dos mockups —
   com `body.nt-ds-app .shell > .ds-main` este arquivo venceria, por carregar
   depois, e os 32px seriam silenciosamente descartados. */
.nt-ds-app .ds-main {
  display: flex;
  flex-direction: column;
  gap: 28px;
  min-width: 0;
}

/* As telas do Design System pressupõem cliente autenticado. A Base de
   Conhecimento também responde a visitante anônimo, e aí não há sidebar:
   o grid precisa de uma coluna só, senão o conteúdo ocupa a faixa de 260px
   reservada ao menu. */
body.nt-ds-app .kb-shell--no-sidebar {
  grid-template-columns: minmax(0, 1fr);
  max-width: 1240px;
}

/* Sem sidebar, o conteúdo ia a 1680px e o hero alinhado à esquerda deixava a
   Central de Ajuda puxada para um lado. O bloco fica em 1240px no centro da
   página e o hero volta ao desenho centralizado do mockup (ui-kit/suporte.html
   usa .kb-hero sem a variante .left). Com sidebar, nada muda. */
body.nt-ds-app .kb-shell--no-sidebar .kb-hero.left {
  text-align: center;
  align-items: center;
}
body.nt-ds-app .kb-shell--no-sidebar .kb-hero.left .kb-search {
  max-width: 560px;
}
body.nt-ds-app .kb-shell--no-sidebar .kb-chips {
  justify-content: center;
}

/* No ds-app.css, `input.control` nasce com `padding-left:38px` para abrir espaço
   ao ícone de lupa do campo de busca. Nos formulários não há ícone, e por isso
   todo input dos mockups carrega um `style="padding-left:14px"` inline. Aqui isso
   é uma regra só: mesmo resultado, sem repetir estilo inline em ~40 campos. */
body.nt-ds-app .form-group input.control,
body.nt-ds-app .avatar-row input.control {
  padding-left: 14px;
}

/* `.top-row .panel` nasce com `min-width:320px` no ds-app.css e o desenho não
   tem media query que solte isso. Em 320px o painel fica mais largo que a área
   útil e a página ganha 16px de rolagem horizontal. Medido: o mockup
   ui-kit/parceiros.html estoura exatamente os mesmos 16px, então é limitação do
   app.css e não da importação — mas o projeto exige refluxo sem rolagem lateral
   em 320px, então a correção entra aqui, que é o arquivo de adaptação. */
@media (max-width: 480px) {
  body.nt-ds-app .top-row .panel {
    min-width: 0;
  }
}

/* O seletor de país de /account/contacts vem pronto do core, em $countriesdropdown,
   com `class="form-control"` — e o StatesDropdown.js do WHMCS depende dele assim.
   Não dá para trocar a classe no template, então o visual de `select.control` é
   reaplicado aqui. A seta do .select-wrap não existe nesse caso, por isso o
   `appearance` fica no padrão do navegador. */
body.nt-ds-app .form-group select.form-control {
  width: 100%;
  font: inherit;
  font-size: 14px;
  padding: 11px 14px;
  background: var(--card);
  color: var(--text-1);
  border: 1px solid var(--border);
  border-radius: var(--radius-md);
  cursor: pointer;
}

body.nt-ds-app .form-group select.form-control:focus-visible {
  border-color: var(--accent-border);
}

/* Duas classes do tema sobreviveram em clientareadetails.tpl porque o <style>
   embutido e o profile-details.js dependem delas (o realce `is-attention` e a
   linha de endereço). O Design System não tem equivalente para o asterisco de
   obrigatório nem para a lista de erros de validação, então elas ganham o mínimo
   aqui em vez de eu apagar a marca de campo obrigatório da tela. */
body.nt-ds-app .nt-req {
  color: var(--accent-on-light);
}

body.nt-ds-app .info-box .nt-alert__list {
  margin: 0;
  padding-left: 18px;
}

/* Vários painéis importados agrupam campos em <fieldset> com uma .form-grid por
   linha. A grid tem gap interno, mas nada separa uma linha da outra — sem isto
   as linhas se encostam. */
body.nt-ds-app .panel fieldset {
  border: 0;
  margin: 0;
  padding: 0;
  display: flex;
  flex-direction: column;
  gap: 18px;
}

/* A paginação de /serverstatus.php é servidor: são links GET, não botões. O
   Design System só desenha `.dt-pager button`, então o <a> herda o mesmo visual
   aqui em vez de eu trocar o link por um botão e perder o "abrir em nova aba". */
body.nt-ds-app .dt-pager a {
  font: inherit;
  font-size: 12.5px;
  font-weight: 600;
  padding: 7px 14px;
  background: var(--card);
  color: var(--text-2);
  border: 1px solid var(--border);
  border-radius: var(--radius-sm);
  text-decoration: none;
}

body.nt-ds-app .dt-pager a:hover {
  border-color: var(--accent-border);
  color: var(--accent);
  text-decoration: none;
}

/* Rótulo de acessibilidade usado pelos formulários importados. */
body.nt-ds-app .sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

/* Addons (nt_chips, nt_frete) embrulham o conteúdo no .nt-clientarea-layout
   legado e incluem sidebar.tpl, que no shell entrega a ds-sidebar. O grid
   legado reserva coluna fixa de 280px para a .nt-sidebar antiga; aqui ele segue
   a largura da própria .sidebar (260px aberta, 72px recolhida) e o gap do
   .shell. Abaixo de 860px vira uma coluna, com a sidebar em cima, como nas
   demais telas do Design System. */
body.nt-ds-app .nt-clientarea-layout {
  grid-template-columns: auto minmax(0, 1fr);
  gap: 36px;
}
@media (max-width: 860px) {
  body.nt-ds-app .nt-clientarea-layout {
    grid-template-columns: minmax(0, 1fr);
  }
}

/* Mesma caixa do .shell para as páginas de módulo. Os addons (e os wrappers
   fiscais do header.tpl) montam .nt-section > .nt-container >
   .nt-clientarea-layout: sem isto a página fica no container legado (1280px,
   padding lateral clamp(1rem,4vw,2rem)) com 4rem de padding vertical da
   .nt-section — mais estreita e mais baixa que as telas do Design System.
   Aqui o container assume os números do .shell (ds-app.css linha 13):
   max-width 1680px, padding 32px clamp(1rem,5vw,4rem). */
body.nt-ds-app .nt-section:has(> .nt-container > .nt-clientarea-layout) {
  padding: 0;
}
body.nt-ds-app .nt-container:has(> .nt-clientarea-layout) {
  max-width: 1680px;
  padding: 32px clamp(1rem, 5vw, 4rem);
}