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

   REGRA DE OURO (espelha a do mobile.css): todo o conteúdo deste
   arquivo vive dentro de uma @media (min-width: ...). Em celular
   nenhuma regra daqui é aplicada, então o layout mobile — que já
   estava bom — continua EXATAMENTE o mesmo de antes.

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

   PROBLEMA QUE ESTE ARQUIVO RESOLVE
   O portal 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, não de desktop.

   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
   1900px de largura é pior de ler, não melhor. A meta é eliminar a
   faixa vazia e usar a largura onde há conteúdo que se beneficia
   dela (grids de cards, listas, tabelas). Formulários de leitura
   vertical continuam com largura controlada — ver a seção
   "Páginas que não devem esticar" 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 acompanhar do fim de uma
     linha ao começo da 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 (fundo claro 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. Estes
     aumentos são modestos de propósito: o objetivo é 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; }
  .voltar { font-size: 14px; margin-bottom: 18px; }

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

  .sysblock > .head { padding: 15px 22px; font-size: 15px; }
  .cond { padding: 14px 22px; }
  .cond .cname { font-size: 15px; }

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

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

  /* ---------- grids de cards ----------
     `auto-fill` com minmax(210px) já cria colunas sozinho conforme
     sobra espaço; o que faltava era o espaço. Com o .wrap a 1180px
     a home passa de 3 para 4 colunas naturalmente. O minmax maior
     evita que num monitor ultrawide os cards virem 6 tijolinhos. */
  .apps-grid { grid-template-columns: repeat(auto-fill, minmax(250px, 1fr)); gap: 18px; }
  .app-card { min-height: 170px; padding: 34px 20px; }
  .app-card .t { font-size: 20px; }

  /* ---------- barra de competência ---------- */
  .period-form { padding: 14px 18px; }

  /* ═══════════════ FASE 2 — grids que ganham colunas ═══════════════
     Só entram aqui os conteúdos em que a coluna dupla AJUDA: blocos
     compactos, de altura parecida, que hoje empilham verticalmente e
     desperdiçam a largura nova. Onde a linha larga é a forma certa
     (ver "Páginas que continuam em linha única" abaixo), não mexemos. */

  /* Painel do gestor — 6 controles.
     `auto-fit` já criava colunas sozinho; o minmax maior evita que num
     monitor grande os 6 cards virem uma fileira de tijolinhos baixos. */
  .ctrl-grid { grid-template-columns: repeat(auto-fit, minmax(260px, 1fr)); gap: 18px; }
  .ctrl { padding: 30px 20px; }
  .ctrl .c-t { font-size: 17px; }

  /* Checklist — cards de sede (Galpão T.I., MG09, Azular, CL).
     Blocos compactos e de mesma altura: nome + pill + barra de
     progresso. Caso ideal para 2 colunas. O `.site-grid` foi criado
     em chk_home.html; no celular ele não vira grid (regra só aqui). */
  .site-grid { display: grid; grid-template-columns: 1fr 1fr; gap: 14px; }
  .site-grid .card { margin-bottom: 0; }

  /* Ocorrências — os 5 KPIs de status.
     Já são grid de 5 colunas; com a largura nova cabem os rótulos sem
     reticências, então liberamos o texto e damos mais respiro. */
  .oc-kpis { gap: 14px; margin-bottom: 26px; }
  .oc-kpi { padding: 15px 12px 13px 17px; }
  .oc-kpi .k-num { font-size: 26px; }
  .oc-kpi .k-lbl { font-size: 10px; white-space: normal; }

  /* Gestor › Sistemas e Condensadoras — linhas de cadastro.
     Já é grid de 4 colunas (nome / modelo / tag / ação). Não muda o
     número de colunas: só aproveita a largura para os campos de texto
     pararem de espremer o nome do sistema. */
  .cond-row, .add-cond { gap: 12px; }

  /* ═══════════════ FASE 3 — editor de rascunho (rel_rascunho) ═══════════════
     A página mais complexa do app: acordeão de sistemas, autosave de 700ms,
     tabela de peças e modal de orçamento.

     LARGURA DOS CAMPOS DE LAUDO/SERVIÇOS — decisão revista.
     A 1ª versão desta fase travava os textareas em 46em, para que a linha
     que quebra na tela fosse a mesma que quebra no card do PPTX (o contador
     "5 de ~6 linhas" dependia disso). Na prática ficou ruim: o campo
     editável e o bloco do mês anterior — que mostram O MESMO texto — viviam
     em larguras diferentes, e o trabalho real da tela é justamente comparar
     os dois. Por decisão do time, os campos voltaram à largura TOTAL do
     card e o contador foi removido (ver comentário no <script> do template).

     O limite do PPTX continua existindo do lado do servidor: o texto que
     exceder `espaco_texto_in()` é cortado na geração. O que se perdeu foi
     só o aviso prévio na tela. */

  /* Cabeçalho do editor: os botões de ação já têm min-width:190px e
     justify-content:space-between — com mais largura eles simplesmente
     param de quebrar em duas fileiras. Nada a fazer além do container. */

  /* Tabela de peças — o maior ganho da Fase 3.
     As colunas são fixas (table-layout:fixed) e somam 528px; a descrição
     leva o que sobra. A 720px sobravam ~124px e o texto da peça vivia
     truncado com reticências. A 1180px sobram ~556px: a descrição inteira
     passa a caber. Só precisamos deixar de esconder o overflow.

     COMPARTILHADO DE PROPÓSITO: `.pecas-tbl`, `.desc-btn` e `.modal` são
     definidos em DOIS templates — rel_rascunho.html e corr_home.html
     (Orçamentos e Peças) — com a mesma estrutura de colunas e o mesmo
     modal (.mrow flex + .mfield min-width:140px). As regras abaixo valem
     para os dois, e é o comportamento desejado: as duas telas sofrem do
     mesmo aperto na descrição. Se um dia divergirem, prefixar por página. */
  .pecas-card { padding: 20px 20px 18px; }
  .pecas-tbl { font-size: 13px; }
  .pecas-tbl .c-sis { width: 170px; }
  .pecas-tbl .c-st  { width: 130px; }
  .pecas-tbl .c-orc { width: 180px; }
  /* a descrição deixa de ser um botão truncado e mostra o texto real.
     ATENÇÃO: ao liberar o `white-space:nowrap` do template precisamos do
     overflow-wrap junto — sem ele uma descrição sem espaços (código de
     fabricante) não acha ponto de quebra e alarga a coluna, deformando a
     tabela inteira (que é table-layout:fixed). Mesmo motivo do .msnap. */
  .desc-btn { white-space: normal; overflow-wrap: anywhere; word-break: break-word;
    font-size: 13px; padding: 9px 12px; }

  /* Modal do orçamento — 540px numa tela de 1180px fica apertado para
     descrição + valores. Os campos internos usam flex com min-width:140px,
     então a largura extra vira 2 colunas sozinha. Vale para os dois
     modais (rel_rascunho e corr_home), que são idênticos. */
  .modal { max-width: 680px; padding: 26px 28px; }

  /* Acordeão de sistemas: cabeçalho com mais respiro e nome maior. O corpo
     não muda de estrutura — a leitura continua vertical. */
  .sis .cab { padding: 15px 20px; }
  .sis .nome { font-size: 15.5px; }
  .sis .corpo { padding: 6px 20px 22px; }

  /* Barra de progresso e filtros acompanham o container */
  .barra { padding: 16px 18px; }
  .filtros { gap: 9px; margin-bottom: 16px; }

  /* ---------- PÁGINAS QUE CONTINUAM EM LINHA ÚNICA ----------
     Decisão deliberada, não esquecimento:

     · rel_home (.sede) — cada linha carrega tags + até 3 botões
       (Editar / Baixar PPTX / Re-upload). Em 2 colunas sobram ~570px
       por card e os botões quebram para uma terceira fileira: fica
       PIOR que a linha larga. Mantém full-width.
     · oc_lista (.oc-card) — os cards têm altura variável (título,
       selo de status, local e grade de pessoas). Em 2 colunas
       o grid alinha pelo mais alto e abre buracos irregulares.
     · chk_site (.sysblock) — lista de condensadoras por sistema; a
       leitura é vertical, uma condensadora por linha.
     (rel_rascunho saiu desta lista: seus campos de laudo/serviços agora
     usam a largura total do card — ver a nota da Fase 3 acima.) */

  /* ---------- PÁGINAS QUE NÃO DEVEM ESTICAR ----------
     Formulários de leitura/preenchimento vertical e a prévia do
     laudo. Aqui a largura extra ATRAPALHA:

     · oc_form — o técnico preenche campo a campo de cima para
       baixo. Um <input> de 1100px força o olho a varrer a tela
       inteira para achar o cursor, e a tela não tem nenhuma grade
       que justifique a largura.
     · oc_relatorio — o `.rl-wrap` de 760px existe para imitar a
       folha do PDF. Esticar quebraria a correspondência visual com
       o laudo impresso.

     Estas páginas recebem a tipografia e o alinhamento de cabeçalho
     da Fase 1, mas mantêm a coluna estreita e CENTRALIZADA.

     chk_form SAIU desta lista: ver a seção abaixo. */
  .wrap.wrap-form { max-width: 820px; }
  .rl-wrap { max-width: 820px; padding: 30px 32px 70px; }

  /* ---------- CHECKLIST DE PREENCHIMENTO (chk_form) ----------
     Esta tela usa a largura cheia do `.wrap` (1180px), alinhada com o
     resto do app — o container centralizado de 820px deixava a página
     recuada 180px em relação à logo e a todas as outras telas, e o
     degrau saltava aos olhos.

     Mas largura sozinha PIORARIA a tela: os três botões C / N/C / N/A
     usam `flex:1`, então esticavam com o container — a 820px cada um já
     tinha 239px de largura para exibir a letra "C". Por isso a largura
     extra vai para a GRADE de itens, e os campos de digitação são
     organizados em DUAS COLUNAS em vez de esticarem.

     Escopo em `.wrap-chk` e não em `.item` solto de propósito: `.item`
     é classe global e o rel_rascunho também a usa, redefinida como
     flex. Aquele template usa `.wrap` puro, logo fica fora do alcance
     destas regras. */

  /* Item: texto à esquerda, resposta numa COLUNA FIXA à direita. Além de
     economizar uma linha por item (~29px × 23 a 30 itens), alinha os "C"
     verticalmente — achar o único N/C no meio de 28 itens vira imediato,
     o que era impossível com a resposta em posição variável. */
  .wrap-chk .item { display: flex; align-items: center; gap: 16px; }
  .wrap-chk .item .txt { flex: 1; min-width: 0; margin-bottom: 0; max-width: 740px; }
  /* 740px: o item mais longo do checklist tem 97 caracteres (~690px), então
     cabe em uma linha; acima disso a medida ficaria desconfortável e é
     melhor quebrar. `margin-left:auto` mantém a coluna de respostas no
     mesmo lugar mesmo quando o texto é curto. */
  .wrap-chk .item .seg { flex: none; width: 300px; margin-left: auto; }

  /* Campos: a largura extra não vira campo gigante — vira SEGUNDA COLUNA.
     Limitar cada campo e deixar o resto vazio (primeira tentativa) resolvia o
     campo largo mas deixava a metade direita da tela em branco, o que é outro
     tipo de problema. */

  /* Coluna estreita à esquerda com OS em cima e Data embaixo; Observação
     interna à direita, ocupando a altura dos DOIS campos. A versão anterior
     punha OS e Data lado a lado e sobrava para a observação uma caixa de uma
     linha só — larga e rasa, desproporcional ao espaço que ela ocupa.

     `stretch` + flex na coluna da direita: o textarea cresce até a base do
     campo Data. Feito assim, e não com altura fixa em px, para continuar
     casando se a fonte, o padding ou o tamanho dos rótulos mudarem. */
  .wrap-chk .chk-topo { display: grid; grid-template-columns: 400px 1fr;
    gap: 0 22px; align-items: stretch; margin-bottom: 18px; }
  /* `display:block` desfaz o lado a lado do template; os `width`/`flex` dos
     dois campos precisam ser anulados junto, senão a Data continua com os
     150px fixos e a coluna fica desalinhada. */
  .wrap-chk .chk-topo .chk-linha { display: block; }
  .wrap-chk .chk-topo .chk-os,
  .wrap-chk .chk-topo .chk-data { width: auto; max-width: none; }
  .wrap-chk .chk-topo .obs-interna { margin: 0; display: flex; flex-direction: column; }
  /* min-height é piso de segurança, não a altura pretendida: se algum
     navegador não esticar a célula, a caixa não colapsa. Com a célula
     esticada o flex a leva à base do campo Data. */
  .wrap-chk .chk-topo .obs-interna textarea { flex: 1; min-height: 96px; resize: vertical; }

  /* Avarias e Ação tomada lado a lado: são o par de campos livres do laudo,
     preenchidos na mesma passada. Em coluna única sobrava metade da tela e
     ainda obrigava a rolar de um para o outro. */
  .wrap-chk .chk-obs { display: grid; grid-template-columns: 1fr 1fr;
    gap: 20px; align-items: start; }
  .wrap-chk .chk-obs label { margin-top: 0; }
  .wrap-chk .chk-obs textarea { min-height: 110px; }

  /* Abrir ocorrência: a caixa ocupa a faixa toda, e os campos internos viram
     duas colunas quando ela abre — senão o título ficaria com 1080px. */
  .wrap-chk .oc-campos { display: grid; grid-template-columns: 1fr 1fr;
    gap: 0 18px; align-items: start; }
  .wrap-chk .oc-campos .oc-hint { grid-column: 1 / -1; }
  .wrap-chk .oc-campos .oc-linha { margin-bottom: 0; }
  .wrap-chk .oc-campos textarea { min-height: 84px; }

}


/* ==================== DESKTOP LARGO (≥1600px) ====================
   Monitores grandes e ultrawide. O container ganha mais um degrau,
   mas o texto corrido continua limitado: só os grids e listas
   aproveitam. */
@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); }
  .wrap.wrap-form { max-width: 820px; }

  /* As 4 sedes cabem numa fileira só — a competência inteira numa
     olhada, sem rolar. Abaixo de 1600px seriam colunas de ~280px e o
     nome longo ("Centro Logístico") apertaria contra a pill. */
  .site-grid { grid-template-columns: repeat(4, 1fr); }
}