/* ===================================================================
   desktop.css — adaptação para telas grandes.

   REGRA DE OURO (a mesma do mobile.css): todo o conteúdo deste arquivo
   vive dentro de uma @media (min-width: ...). Em celular nenhuma regra
   daqui é aplicada, então a tela do instalador continua EXATAMENTE
   como estava. Isso não é detalhe: o app nasceu mobile-first porque é
   em campo que ele é mais usado, e essa parte já estava boa.

   Ordem de carga no base.html:
       style.css  →  mobile.css  →  desktop.css
   As faixas não se sobrepõem (mobile ≤640px, desktop ≥1024px), mas o
   desktop vem por último para vencer qualquer empate de
   especificidade com o style.css.

   O PROBLEMA QUE ESTE ARQUIVO RESOLVE
   O app inteiro vive dentro de `.wrap{max-width:720px}`. Num monitor
   de 1920px isso deixa ~600px de fundo azul vazio de cada lado: o
   cabeçalho ocupa a tela toda e o conteúdo fica espremido numa coluna
   central. 720px é largura de tablet.

   Isso pesa mais aqui do que pareceria, porque o gestor trabalha no
   desktop e a tela principal dele é um MAPA — o conteúdo que mais
   sofre com pouca largura.

   O QUE ESTE ARQUIVO NÃO FAZ (decisão de projeto)
   A meta não é esticar tudo até 100% da tela. Campo de texto com
   1000px de largura é pior de preencher, não melhor. A meta é matar a
   faixa vazia e usar a largura onde há conteúdo que se beneficia dela:
   mapa, grades de cards, listas. Ver a seção "Campos de formulário"
   no fim do arquivo.
   =================================================================== */


/* ====================== DESKTOP (≥1024px) ====================== */
@media (min-width: 1024px) {

  /* ---------- estrutura geral ----------
     720 → 1180px. Não é a tela inteira de propósito: acima de ~1400px
     a linha fica longa demais para o olho achar o começo da linha
     seguinte. 1180px + padding lateral maior mata a faixa vazia sem
     criar o problema oposto. */
  .wrap { max-width: 1180px; padding: 30px 32px 70px; }

  /* O cabeçalho é full-bleed (a faixa clara vai de ponta a ponta), mas
     o conteúdo dele precisa alinhar com o `.wrap` das páginas — senão
     a logo fica colada na borda enquanto o título começa 32px adentro,
     e o desalinhamento salta aos olhos. */
  .topbar { padding: 14px 0; }
  .topbar .tb-logo { margin-left: max(32px, calc((100vw - 1180px) / 2 + 32px)); }
  .topbar .right  { margin-right: max(32px, calc((100vw - 1180px) / 2 + 32px)); }
  .topbar img { height: 42px; }

  /* ---------- escala tipográfica ----------
     As fontes foram calibradas para celular, a ~40cm do rosto. Num
     monitor a ~70cm o mesmo tamanho em px aparenta menor. Os aumentos
     são modestos de propósito: a meta é conforto de leitura, não um
     app "grandão". */
  .hero { margin-bottom: 28px; }
  .hero h1 { font-size: 34px; }
  .hero .desc { font-size: 14px; margin-top: 10px; }
  .crumb { font-size: 13px; margin-bottom: 18px; }

  .card { padding: 20px 22px; margin-bottom: 14px; }
  .card .name { font-size: 18px; }
  .card .meta { font-size: 13px; }

  .panel { padding: 24px 26px; }
  .panel h3 { font-size: 15px; }

  .hint { font-size: 14px; padding: 13px 16px; }
  .section-t { font-size: 13px; }

  /* ---------- MAPA DAS OBRAS (painel do gestor) ----------
     O maior ganho da faixa desktop. A altura era 460px para uma
     largura de 720px (1,6:1). Mantida a mesma altura numa caixa de
     1116px, o mapa vira uma fresta de 2,4:1 — e o Espírito Santo é um
     estado ALTO e estreito, então é justamente a altura que decide
     quantas obras cabem na tela sem dar zoom.

     560px devolve a proporção para ~2:1 com o mapa maior nas duas
     dimensões. */
  .mapa-wrap { height: 560px; }

  /* Mapa de marcação do ponto da obra (formulário).
     Aqui a largura é útil de verdade: marcar um ponto exige enxergar
     as ruas em volta. Mas o container é o `.panel`, que estica, e
     300px de altura numa caixa de ~1060px daria 3,5:1. */
  .mapa-sel { height: 420px; }

  /* ---------- grades que ganham colunas ----------
     Todas já usam `auto-fill`/`auto-fit` com minmax, então criam
     colunas sozinhas conforme sobra espaço. O que faltava era o
     espaço. Só entram aqui as que precisam de ajuste no minmax. */

  /* Indicadores do painel: com minmax(150px) numa faixa de 1116px
     saem 7 colunas e os cartões viram tijolinhos baixos, com o número
     grande desproporcional à caixa. */
  .kpis { grid-template-columns: repeat(auto-fill, minmax(180px, 1fr)); gap: 12px; }

  /* Etapas da obra na home: com 170px de minmax as seis etapas passam
     a caber numa fileira só a partir de ~1100px. O funil inteiro, de
     Contratada a Entregue, numa olhada — que é exatamente para isso
     que o bloco existe. Nenhuma regra necessária além da largura;
     fica registrado aqui para não parecer esquecimento. */

  /* Atalhos dentro da obra (Diário, Evidências, Documentos...):
     mesma história, resolvem sozinhos com a largura nova. */

  /* ---------- LISTAS: LINHA LARGA, NÃO DUAS COLUNAS ----------
     Decisão deliberada. Os cards de obra e de cliente têm ALTURA
     VARIÁVEL: o nome pode ou não trazer o código, a meta pode ter
     cliente + tipo + cidade ou só o tipo. Num grid de duas colunas as
     linhas se alinham pelo card mais alto e abrem buracos irregulares.
     Além disso o card tem o selo de status empurrado para a direita e
     o chevron depois: em coluna dupla eles se atropelam.

     O efeito colateral aceito: numa lista larga o nome da obra fica na
     esquerda e o status do outro lado. Se isso incomodar na prática, o
     conserto é no template (trazer o selo para junto do nome), não
     aqui. */

  /* ---------- CAMPOS DE FORMULÁRIO ----------
     O contrapeso de tudo acima. Um <input> de 1000px é pior que um de
     500: o rótulo fica num canto da tela e o cursor no outro, e o olho
     precisa varrer a tela inteira para achar onde está digitando.

     Os formulários já organizam a maioria dos campos em `.grid2` e
     `.grid3`, que se auto-limitam. O problema é só o campo SOLTO
     (Endereço, Observações), que ocupa a linha inteira.

     A trava usa `calc(50% - 6px)`, que é exatamente a largura de uma
     célula do `.grid2` (metade, menos metade do gap de 12px). Assim o
     campo solto alinha com a coluna da esquerda dos campos de cima em
     vez de escolher uma largura própria — e continua alinhando se o
     container mudar de tamanho.

     O `:not()` é o que protege os campos que JÁ estão numa grade: sem
     ele, um input dentro de `.grid2` viraria 50% da célula. */
  .panel form > div:not(.grid2):not(.grid3) > input[type=text],
  .panel form > div:not(.grid2):not(.grid3) > input[type=password],
  .panel form > div:not(.grid2):not(.grid3) > input[type=email],
  .panel form > div:not(.grid2):not(.grid3) > input[type=number],
  .panel form > div:not(.grid2):not(.grid3) > select,
  .panel form > div:not(.grid2):not(.grid3) > textarea {
    max-width: calc(50% - 6px);
  }
  /* O mapa é a exceção: ele É o campo e quer a largura toda. Como é uma
     <div> e não um <input>, a regra acima já não o alcança — a nota
     fica para o próximo que for mexer aqui. */

}


/* ==================== DESKTOP LARGO (≥1600px) ====================
   Monitores grandes e ultrawide. O container ganha mais um degrau, mas
   só o mapa e as grades aproveitam: texto corrido e campo de digitação
   continuam onde estão. */
@media (min-width: 1600px) {
  .wrap { max-width: 1360px; }
  .topbar .tb-logo { margin-left: calc((100vw - 1360px) / 2 + 32px); }
  .topbar .right  { margin-right: calc((100vw - 1360px) / 2 + 32px); }

  /* Com 1296px de largura útil o mapa aguenta mais altura sem virar
     faixa: 620px mantém a proporção em ~2:1. */
  .mapa-wrap { height: 620px; }
}