@font-face {
  font-family: 'Manrope';
  src: url('../fonts/Manrope-Regular.woff2') format('woff2');
  font-weight: 400; font-style: normal; font-display: swap;
}
@font-face {
  font-family: 'Manrope';
  src: url('../fonts/Manrope-Medium.woff2') format('woff2');
  font-weight: 500; font-style: normal; font-display: swap;
}
@font-face {
  font-family: 'Manrope';
  src: url('../fonts/Manrope-SemiBold.woff2') format('woff2');
  font-weight: 600; font-style: normal; font-display: swap;
}
@font-face {
  font-family: 'Manrope';
  src: url('../fonts/Manrope-Bold.woff2') format('woff2');
  font-weight: 700; font-style: normal; font-display: swap;
}

:root {
  --fcsmd-verde-saude: #0D3A40;
  --fcsmd-verde-profundo: #07272B;
  --fcsmd-verde-md: #038E83;
  --fcsmd-verde-md-claro: #269E94;
  --fcsmd-verde-cta: #00CCBD;
  --fcsmd-verde-borda-clara: #CCF0E5;
  --fcsmd-verde-claro-fundo: #EEF6F2;
  --fcsmd-bege-claro: #F5F1EA;
  --fcsmd-bege-fosco: #E9E6DF;
  --fcsmd-bege-borda: #E4DCCF;
  --fcsmd-dourado: #CBA58D;
  --fcsmd-marrom: #8A5A2B;
  --fcsmd-cinza-escuro: #3F5658;
  --fcsmd-cinza-texto: #5B6E70;
}

/* Titulos com kerning negativo do layout, sem repetir em cada widget. */
.fcsmd-h1 { letter-spacing: -3px; }
.fcsmd-h2 { letter-spacing: -3px; }
.fcsmd-h3 { letter-spacing: -2px; }

/* Trecho colorido dentro de um titulo: <span class="fcsmd-destaque"> */
.fcsmd-destaque { color: var(--fcsmd-verde-cta); }
.fcsmd-destaque--dourado { color: var(--fcsmd-dourado); }

/* Grafismos decorativos de petala, posicionados sem afetar o fluxo.
   '--tl'/'--br' ficaram sem uso ate a Task 10b (correcao pos-review):
   nenhuma secao do site precisou desses 2 cantos ainda -- mantidos por
   nao fazer mal e poderem servir outra secao futura. '--tr'/'--bl' sao os
   2 realmente usados pelo bloco "A FACULDADE" (tools/06-home.php,
   fcsmd_bloco_a_faculdade()), nos cantos onde o Figma mostra os grafismos
   (superior-direito e inferior-esquerdo, sangrando pra fora do cartao). */
.fcsmd-grafismo {
  position: absolute; pointer-events: none; z-index: 0;
  background-repeat: no-repeat; background-size: contain;
}
.fcsmd-grafismo--tl { top: 0; left: 0; }
.fcsmd-grafismo--br { bottom: 0; right: 0; }
.fcsmd-grafismo--tr { top: 0; right: 0; }
.fcsmd-grafismo--bl { bottom: 0; left: 0; }

/* Marca d'agua +MaterDei sangrando no rodape.
   'opacity' NAO e setado aqui (fica no default 1): o proprio SVG
   (assets/img/logo-materdei-wordmark.svg, <g opacity="0.05">) ja embute
   5% de opacidade no grupo. Uma regra 'opacity: .06' aqui MULTIPLICARIA
   as duas (0.05 x 0.06 = 0.3%), tornando a marca d'agua praticamente
   invisivel -- foi o que aconteceu ate esta correcao (medido com PIL:
   nenhuma variacao de pixel na regiao do rodape, cor uniforme #0D3A40).
   Ver task-7-report.md. */
.fcsmd-watermark {
  position: absolute; left: 0; right: 0; bottom: 0;
  height: 290px; pointer-events: none;
  background: url('../img/logo-materdei-wordmark.svg') no-repeat center bottom / contain;
}
/* CRITICAL 2 do re-review: '.fcsmd-watermark' e filha direta do wrapper do
   widget HTML que a contem (.elementor-element.elementor-widget-html), e
   TODO widget do Elementor e 'position: relative' por padrao
   (elementor/assets/css/frontend.css, regra '.elementor-widget { position:
   relative; }'). Isso faz esse wrapper -- nao o container do rodape -- ser
   o 'offsetParent' de '.fcsmd-watermark'. Como o wrapper so contem um
   filho absolutamente posicionado, sua altura propria colapsa pra ~0 (um
   elemento absoluto nao empurra a altura do pai estatico), entao
   'bottom:0' resolvia contra esse ponto quase-zero logo apos a barra
   legal -- a marca d'agua ficava ancorada ali e nunca alcancava a base
   real do rodape (confirmado com CDP: offsetParent era o
   '.elementor-widget-html', nao '.fcsmd-footer'). Neutralizando a
   posicao desse wrapper especifico (escopado a '.fcsmd-footer' pra nao
   afetar nenhum outro widget HTML do site), o proximo ancestral
   posicionado vira o proprio '.fcsmd-footer' (todo '.e-con' e 'position:
   relative' por padrao), que cobre o rodape inteiro. Ver task-7-report.md. */
.fcsmd-footer .elementor-widget-html {
  position: static;
}

/* Logo da coluna 1 do rodape: 351px de largura pedidos no spec, coluna com
   325px fixos (mesma logica das outras 3 colunas -- ver tools/04-footer.php,
   $coluna_325) -- a logo sangra ~26px pra dentro do respiro entre colunas de
   proposito (nao ha coluna vizinha colada, o conteudo de cada coluna e mais
   estreito que a caixa). O bloqueio veio de fora do nosso CSS: o WordPress
   core carrega 'wp-includes/css/dist/block-library/style.min.css' (Gutenberg)
   em toda pagina, com 'img{max-width:100%!important}' -- o '!important'
   sobrepunha o 'width:351px' que o proprio Elementor ja gerava (medido com
   CDP: renderizava 325x59 em vez de 351x64, exatamente o teto da coluna).
   Precisa de '!important' aqui tambem pra vencer -- entre duas regras
   importantes, ganha a mais especifica. Ver task-7-report.md. */
.fcsmd-footer .elementor-widget-image img {
  max-width: none !important;
}

/* Abaixo de 768px (achado da Task 12): a coluna do rodape que carrega esta
   logo deixa de ter os 325px fixos do desktop -- com o rodape em pilha
   unica (ver 'flex_wrap' em tools/04-footer.php), a coluna encolhe pra
   caber no viewport real de um celular (~343px a 375px, com o gutter
   reduzido). Os 351px fixos da logo (o 'max-width:none!important' acima,
   necessario pra vencer o 'img{max-width:100%!important}' do Gutenberg em
   QUALQUER largura) nunca encolhem sozinhos -- a 375px isso sozinho
   bastava pra estourar o corpo da pagina em 8px, mesmo com a coluna em si
   corrigida. Aqui, restauramos o comportamento responsivo padrao (a logo
   encolhe ate 100% da coluna) só nesta faixa estreita, onde o "sangrar
   26px pra dentro do respiro" do desktop deixa de fazer sentido (nao ha
   coluna vizinha nem respiro sobrando numa pilha de 1 coluna so). */
@media (max-width: 767px) {
  .fcsmd-footer .elementor-widget-image img {
    max-width: 100% !important;
  }
}

/* Barra vertical de acessibilidade fixa. */
.fcsmd-a11y {
  position: fixed; left: 0; top: 50%; transform: translateY(-50%);
  width: 56px; z-index: 900;
  background: var(--fcsmd-verde-saude);
  border-radius: 0 8px 8px 0;
  box-shadow: 0 4px 24px rgba(7, 39, 43, .25);
}
.fcsmd-a11y button {
  display: block; width: 42px; height: 42px; margin: 7px;
  background: none; border: 0; color: #fff; cursor: pointer;
}
.fcsmd-a11y button:focus-visible { outline: 2px solid var(--fcsmd-verde-cta); }
.fcsmd-a11y__sep { height: 1px; width: 30px; margin: 4px 13px; background: rgba(255,255,255,.25); }

/* Botao flutuante de WhatsApp.
   Cor de fundo: #128C7E (verde-petroleo historico da marca WhatsApp), NAO
   o #25D366 mais comum -- medido (branco sobre #25D366) em 1,98:1, abaixo
   do minimo de 3:1 do WCAG 1.4.11 pra icone de controle de interface (quase
   repetindo o CRITICAL do hambúrguer da Task 6, que deu 1,03:1). #128C7E
   da 4,14:1, continua claramente reconhecivel como "verde WhatsApp" e passa
   no minimo. Ver task-7-report.md, secao de contraste. */
.fcsmd-whats {
  position: fixed; left: 20px; bottom: 24px; z-index: 900;
  width: 56px; height: 56px; border-radius: 50%;
  display: grid; place-items: center; background: #128C7E;
  box-shadow: 0 4px 16px rgba(0,0,0,.25);
}
.fcsmd-whats:focus-visible { outline: 2px solid #fff; outline-offset: 2px; }

/* Escala fluida dos titulos, para o kerning negativo nao quebrar no mobile. */
@media (max-width: 1024px) {
  .fcsmd-h1 { font-size: clamp(28px, 4.2vw, 46px); letter-spacing: -1.5px; }
  .fcsmd-h2 { font-size: clamp(24px, 3.4vw, 36px); letter-spacing: -1.5px; }
  .fcsmd-h3 { font-size: clamp(20px, 2.6vw, 26px); letter-spacing: -1px; }
}

@media (max-width: 767px) {
  .fcsmd-a11y { top: auto; bottom: 96px; transform: none; }
}

/* Achado da verificacao de fidelidade da Task 12: a barra de acessibilidade
   e 'position:fixed' (ancorada no VIEWPORT, nao na pagina) -- no mobile ela
   fica em 'bottom:96px' (regra acima), ocupando ~96-266px a partir da base
   da tela em qualquer viewport. Quando o usuario rola ate o fim da HOME,
   essa faixa fixa passa a cair EXATAMENTE sobre a barra legal do rodape
   ("Mapa do site" / "Política de Privacidade" / "Voltar para Rede..."),
   cobrindo links de verdade -- medido por CDP simulando um scroll real ate
   o fim em viewport 375x812 (iPhone-like): barra de acessibilidade em
   Y=554-716px da tela, barra legal em Y=571-633px -- sobreposicao
   confirmada (nao e um artefato de captura, ao contrario do achado do
   heading/tabela abaixo -- este reproduz com scroll real, viewport normal).
   Correcao: dar mais respiro depois da barra legal SO no mobile (empurra a
   barra de acessibilidade a sobrepor apenas a marca d'agua decorativa
   '+MaterDei' -- aria-hidden, sem nenhum link real ali -- em vez dos links
   de navegacao). 179px (padding-bottom base, calibrado no Figma para
   desktop -- ver tools/04-footer.php) nao e alterado; o acrescimo abaixo e
   exclusivo desta faixa. */
@media (max-width: 767px) {
  .fcsmd-footer { padding-bottom: 300px !important; }
}

/* Header fixo a partir do tablet; no mobile o menu vira off-canvas do proprio widget. */
@media (min-width: 768px) {
  .elementor-location-header {
    position: sticky; top: 0; z-index: 800;
  }
}

/* -------------------------------------------------------------------------
 * Correcoes pos-review da Task 6 (ver task-6-report.md, secao "Correcoes
 * pos-review", para o antes/depois em screenshot e a analise completa).
 * ---------------------------------------------------------------------- */

/* CRITICAL 2 -- o <ul> interno do widget nav-menu usa flex-wrap:wrap por
 * padrao (widget-nav-menu.css, .elementor-nav-menu--layout-horizontal
 * .elementor-nav-menu). Sem isso, com pouco espaco sobrando ele quebra os 7
 * itens em varias linhas em vez de manter uma unica linha a 1920px. */
@media (min-width: 1025px) {
  .elementor-location-header .elementor-nav-menu--layout-horizontal .elementor-nav-menu {
    flex-wrap: nowrap;
  }
}

/* CRITICAL 3 -- o widget search-form (skin "minimal") sempre renderiza um
 * <input type="search"> visivel ao lado do icone; nao ha combinacao de
 * settings que produza "so um circulo com lupa". Aqui o campo fica
 * colapsado (largura 0, sem padding, invisivel) dentro de um circulo de
 * 36px, e expande ao ganhar foco -- inclusive via Tab, teclado, sem mouse.
 * Continua sendo o MESMO <input>, so muda a largura visivel: leitor de tela
 * e navegacao por teclado nao sao afetados. */
.elementor-location-header .elementor-search-form--skin-minimal .elementor-search-form__container {
  display: flex;
  align-items: center;
  width: 36px;
  overflow: hidden;
  transition: width .25s ease;
}

/* Alto contraste, acionado pelo botao "contraste" da barra de acessibilidade
   (FCSMD_Floating::render(), wp-content/plugins/fcsmd-core/includes/class-floating.php). */
.fcsmd-alto-contraste { filter: contrast(1.35) saturate(1.15); }
.elementor-location-header .elementor-search-form--skin-minimal .elementor-search-form__input {
  width: 0;
  min-width: 0;
  padding: 0;
  border: 0;
  opacity: 0;
  transition: width .25s ease, opacity .2s ease, padding-inline-start .25s ease;
}
.elementor-location-header .elementor-search-form--skin-minimal .elementor-search-form__container:focus-within {
  width: 220px;
}
.elementor-location-header .elementor-search-form--skin-minimal .elementor-search-form__container:focus-within .elementor-search-form__input {
  width: 160px;
  opacity: 1;
  padding-inline-start: 8px;
}

/* CRITICAL 2 (parte 2) -- todo container do Elementor recebe width:100% por
 * padrao (variavel --width, regra base .e-con). Pela spec de flexbox, um
 * "width" definido vira o flex-basis usado quando flex-basis:auto -- entao
 * mesmo com flex-grow/flex-shrink zerados via '_flex_size' => 'none' nos
 * settings (tools/03-header.php), os dois grupos da barra principal (o da
 * esquerda com logo+menu, e o de CTA) continuavam querendo ocupar 100% da
 * barra cada um. So o 'none' do settings nao bastava (medido com
 * getComputedStyle: flex-grow/flex-shrink iam a 0 corretamente, mas o width
 * calculado continuava sendo 1300px, o valor cheio do container pai).
 * Precisa tambem de 'width: auto' explicito para os dois se dimensionarem
 * pelo proprio conteudo. header.php tem sempre exatamente 2 grupos dentro
 * de cada um dos 2 containers boxed do header (endereco+telefone / EN+
 * links+sociais na topbar; logo+menu / CTA na barra) -- ver
 * tools/03-header.php.
 *
 * Estendido pra nth-of-type(1) (a topbar) na 3a rodada de correcao: o
 * mesmo problema existia la (medido a 900px: os dois grupos da topbar
 * inflavam pra 432px cada, exatos 50% do espaco disponivel, em vez do
 * tamanho real do proprio conteudo) e so apareceu porque nunca tinha sido
 * testado abaixo de 1280px antes -- e o motivo do texto da topbar
 * transbordar por cima um do outro a 900px mesmo com nowrap e gap
 * reduzido: o gap era calculado sobre uma caixa 2x maior que o
 * necessario. */
.elementor-location-header > .e-con-boxed > .e-con-inner > .e-con {
  width: auto !important;
  flex-grow: 0 !important;
  flex-shrink: 0 !important;
}

/* Achado ao testar 1440/1280px: sem isto, os links da topbar ("Portal do
 * Aluno", "Portal do Professor", "Carreira & Alumni") quebram em 2 linhas
 * quando a caixa flexivel de cada text-editor fica mais estreita que o
 * texto -- empurra a topbar de 40px pra ~56px e o cabecalho todo pra
 * ~138px. Nenhum item da topbar deve quebrar linha em nenhuma largura
 * desktop/tablet-paisagem (>=768px -- ver nota abaixo sobre o piso).
 *
 * Escopo ajustado na 3a rodada de correcao (ver bloco "CRITICAL 2, 3a
 * rodada" abaixo): originalmente comecava em 1025px porque, testando
 * 1024px SEM o gutter/gap reduzidos que vieram depois, forcar nowrap
 * sozinho trocava o sintoma -- em vez das duas metades da topbar
 * quebrarem linha, ficavam SOBREPOSTAS, pior ainda. Agora que a faixa
 * 768-1239px tambem ganhou gutter e gap reduzidos (abaixo), nowrap +
 * espacamento apertado cabem sem sobrepor ate 768px (o breakpoint nativo
 * 'mobile' do Elementor, onde a topbar inteira some via
 * 'hide_mobile' => 'hidden-mobile' de tools/03-header.php -- abaixo disso
 * a pergunta fica sem objeto). Confirmado por captura a 900px. */
@media (min-width: 768px) {
  .elementor-location-header > .e-con-boxed:nth-of-type(1) .elementor-widget-text-editor,
  .elementor-location-header > .e-con-boxed:nth-of-type(1) .elementor-widget-text-editor a {
    white-space: nowrap;
  }
}

/* -------------------------------------------------------------------------
 * CRITICAL 2, 2a rodada -- laptops reais (1440px, 1280px) entre o breakpoint
 * "tablet" do Elementor (1024px, onde o nav-menu vira hamburguer) e os
 * 1920px do layout de referencia. Este Elementor so tem os breakpoints
 * 'tablet' (max 1024) e 'mobile' (max 767) ativos -- NAO existe um breakpoint
 * 'laptop' aqui, entao os controles responsivos nativos do Elementor
 * (padding_horizontal_menu_item_tablet etc.) nao alcancam esta faixa. Sem
 * isso, o gutter fixo de 310px de tools/03-header.php (calibrado pra
 * 1920 = 1300 de conteudo) sobra demais em qualquer largura menor: a 1440px
 * a area util cai pra 820px, a 1280px cai pra 660px -- bem menos que os
 * ~1287px que o conteudo do header precisa mesmo na configuracao mais
 * enxuta de 1920px -- e o grupo de CTA (que e width:auto + flex-shrink:0,
 * regra logo acima) literalmente vaza pra fora da tela em vez de quebrar
 * linha (visto e confirmado em captura). As 3 faixas abaixo reduzem gutter
 * + espacamentos internos progressivamente conforme a tela estreita, pra
 * nunca deixar a area util cair abaixo do que o conteudo real precisa.
 * Medido e ajustado com CDP (Runtime.evaluate + getBoundingClientRect) em
 * 1920/1440/1280px -- ver task-6-report.md. */

/* 1600-1919px: gutter menor, mas o espacamento fino (item do menu, logo-menu,
   botoes) do 1920 ainda cabe folgado (conteudo real ~1287px). */
@media (max-width: 1919px) and (min-width: 1600px) {
  .elementor-location-header > .e-con-boxed {
    padding-left: 100px !important;
    padding-right: 100px !important;
  }
}

/* 1367-1599px (cobre 1440, 1512, 1536): gutter ainda menor + respiro do menu
   e dos botoes um pouco mais apertado (conteudo real ~1265px). */
@media (max-width: 1599px) and (min-width: 1367px) {
  .elementor-location-header > .e-con-boxed {
    padding-left: 40px !important;
    padding-right: 40px !important;
  }
  .elementor-location-header .elementor-nav-menu--main .elementor-item {
    padding-left: 4px !important;
    padding-right: 4px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(1) {
    column-gap: 8px !important;
    gap: 8px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(2) {
    column-gap: 3px !important;
    gap: 3px !important;
  }
  .elementor-location-header .elementor-widget-button .elementor-button {
    padding-left: 7px !important;
    padding-right: 7px !important;
  }
}

/* 1270-1366px (cobre 1280, 1366): faixa mais apertada antes do hamburguer.
   Gutter minimo + espacamento no piso do que ainda e legivel (conteudo real
   medido em ~1237.3px + 32px de gutter = precisa de >=1269.3px de viewport;
   1270 arredondado pra cima, com folga). */
@media (max-width: 1366px) and (min-width: 1270px) {
  .elementor-location-header > .e-con-boxed {
    padding-left: 16px !important;
    padding-right: 16px !important;
  }
  .elementor-location-header .elementor-nav-menu--main .elementor-item {
    padding-left: 2px !important;
    padding-right: 2px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(1) {
    column-gap: 4px !important;
    gap: 4px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(2) {
    column-gap: 2px !important;
    gap: 2px !important;
  }
  .elementor-location-header .elementor-widget-button .elementor-button {
    padding-left: 6px !important;
    padding-right: 6px !important;
  }
}

/* 1240-1269px: mesmo piso da faixa anterior, so que empurrado pra baixo ate
   1240px -- o novo limiar do hamburguer (ver bloco seguinte). Medido: o
   conteudo real (~1219.3px) cabe a partir de ~1236px com este
   gutter/espacamento, entao 1240px (a fronteira que escolhemos pro
   hamburguer) fica dentro da faixa que ainda funciona numa linha so, com
   ~4.7px de folga -- por isso o hamburguer entra exatamente ali, e nao
   antes: essa e a menor largura em que o menu horizontal consegue caber
   de verdade. Abaixo de 1240px o menu vira hamburguer (bloco seguinte),
   entao esse espacamento apertado deixa de ser necessario dali pra baixo. */
@media (max-width: 1269px) and (min-width: 1240px) {
  .elementor-location-header > .e-con-boxed {
    padding-left: 8px !important;
    padding-right: 8px !important;
  }
  .elementor-location-header .elementor-nav-menu--main .elementor-item {
    padding-left: 1px !important;
    padding-right: 1px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(1) {
    column-gap: 2px !important;
    gap: 2px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(2) {
    column-gap: 1px !important;
    gap: 1px !important;
  }
  .elementor-location-header .elementor-widget-button .elementor-button {
    padding-left: 5px !important;
    padding-right: 5px !important;
  }
}

/* -------------------------------------------------------------------------
 * CRITICAL 2, 3a rodada -- abaixo de 1240px o conteudo real do menu (medido,
 * nao estimado) nao cabe numa linha so mesmo no piso de espacamento mais
 * apertado que ainda considero legivel. A resposta certa nao e apertar
 * mais (ja tentei: o piso da faixa anterior, extrapolado pra baixo de
 * 1240px, produzia sobreposicao e corte de conteudo -- visto e confirmado
 * em captura a 1100px antes desta correcao). A resposta certa e o menu
 * virar hamburguer ali, adiantando o breakpoint nativo do proprio widget.
 *
 * NAO da pra fazer isso apontando o controle 'dropdown' do nav-menu pro
 * breakpoint 'laptop' do Kit (que teria sido o jeito nativo, e o motivo de
 * eu ter investigado ativa-lo primeiro): 'laptop' e 'widescreen' sao
 * EXPLICITAMENTE excluidos das opcoes desse controle em
 * elementor-pro/modules/nav-menu/widgets/nav-menu.php:344-346 --
 * "Do not include laptop and widscreen in the options since this feature
 * is for mobile devices" -- e o motivo nao e so cosmetico (a lista do
 * dropdown do editor): o CSS que decide o breakpoint real e compilado a
 * partir de um TEMPLATE (elementor-pro/assets/css/templates/
 * widget-nav-menu.css) que so tem placeholders de substituicao pra
 * mobile/mobile_extra/tablet/tablet_extra -- nao existe nenhum
 * ".elementor-nav-menu--dropdown-laptop{...}" pra ser gerado. Confirmei
 * isso lendo o arquivo (`grep -oE
 * '\.elementor-nav-menu--dropdown-[a-z]+'` no template so retorna mobile/
 * mobile_extra/tablet/tablet_extra/none). Ou seja: mesmo gravando
 * settings.dropdown = 'laptop' na marra (contornando a UI, como fazemos
 * com todo o resto deste header), a classe CSS
 * "elementor-nav-menu--dropdown-laptop" existiria no HTML mas nenhuma
 * regra bateria nela em NENHUMA largura -- o menu nunca colapsaria.
 * Por isso NAO ativamos o breakpoint 'laptop' no Kit global: ele nao
 * resolveria o problema (o nav-menu nao aceita esse breakpoint de
 * qualquer forma) e so acrescentaria risco/superficie de mudanca ao site
 * inteiro (Tasks 7/10/11) sem necessidade.
 *
 * A alternativa que usamos: reproduzir A MAO o mesmo par de regras que o
 * Elementor gera pro breakpoint 'tablet' nativo (que ja faz exatamente
 * isso a 1024px), so que no nosso limiar de 1240px. Os valores de
 * `display` abaixo (main:none / toggle:flex / dropdown:block) foram
 * medidos com CDP (getComputedStyle) direto no estado "hamburguer" nativo
 * do widget a 900px e 1024px, pra reproduzir exatamente o mesmo
 * comportamento -- nao inventados.
 *
 * Piso em 768px (nao 1025px): a primeira versao desta faixa parava em
 * 1025px, assumindo que abaixo disso o breakpoint nativo 'tablet' (1024)
 * do Elementor ja cuidava de tudo. Testando 900px descobri que so o
 * nav-menu tem esse cuidado nativo -- o gutter fixo de 310px e o CSS
 * padrao dos botoes/CTA continuavam sem nenhum ajuste abaixo de 1025px
 * (porque nenhuma das nossas proprias faixas alcancava ali), entao a
 * 900px "Inscreva-se" e a busca ainda saiam cortados da viewport. Esta
 * faixa desce ate 768px (o breakpoint nativo 'mobile' do Elementor) pra
 * cobrir esse buraco -- exatamente o mesmo motivo que fez a regra de
 * nowrap da topbar, acima, tambem descer ate 768px nesta rodada. */
@media (max-width: 1239px) and (min-width: 768px) {
  .elementor-location-header .elementor-nav-menu--dropdown-tablet .elementor-nav-menu--main {
    display: none !important;
  }
  .elementor-location-header .elementor-nav-menu--dropdown-tablet .elementor-menu-toggle {
    display: flex !important;
  }
  .elementor-location-header .elementor-nav-menu--dropdown-tablet .elementor-nav-menu--dropdown.elementor-nav-menu__container {
    display: block !important;
  }

  /* Com o menu principal escondido, a barra fica só com logo + botao de
     hamburguer + grupo de CTA -- bem mais leve, com folga de sobra. IMPORTANT
     do review round 4 (task-6-rereview-2.md): o piso original desta faixa
     (8px, herdado por copia da faixa 1240-1269px vizinha, que É apertada de
     verdade) colava o conteudo na borda sem necessidade -- aqui, ao
     contrario daquela faixa, o menu de 7 itens ja está escondido (hamburguer
     ativo), entao sobra muito mais espaço. Medido via CDP no pior caso da
     faixa (768px, a largura mais estreita): grupo logo+hamburguer (~410.75px)
     + grupo de CTA (~287.61px) = ~698.35px de conteudo real contra 768px de
     viewport -- ou seja, ate 34.8px de gutter por lado ainda caberiam sem
     cortar nada. Escolhido 16px (mesmo valor da faixa 1270-1366px) por
     consistencia com as faixas vizinhas e por sobrar folga confortavel
     (752px de conteudo minimo max. vs 736px disponiveis com este padding =
     ~37.65px de respiro entre os 2 grupos, verificado sem overflow em
     768/900/1100/1239px). NAO alterado o piso da faixa 1240-1269px (bloco
     acima, linhas ~292-313): ali o menu horizontal completo (7 itens) ainda
     está ativo com apenas ~4.7px de folga medida a 1240px -- aumentar o
     gutter ali quebraria esse ajuste fino sem tocar em compensacoes fora do
     escopo desta correcao (gap de 10px entre itens do menu, fora de
     escopo). */
  .elementor-location-header > .e-con-boxed {
    padding-left: 16px !important;
    padding-right: 16px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(1) {
    column-gap: 8px !important;
    gap: 8px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(2) > .e-con-inner > .e-con:nth-of-type(2) {
    column-gap: 4px !important;
    gap: 4px !important;
  }
  .elementor-location-header .elementor-widget-button .elementor-button {
    padding-left: 6px !important;
    padding-right: 6px !important;
  }

  /* Topbar: mesmo problema que a barra principal tinha, so que sem um
     "hamburguer" nativo pra aliviar -- os 4 links + EN + 5 icones sociais
     do lado direito, mais o endereco+telefone do lado esquerdo, emendavam
     ("Portal do AlunoPortal do ProfessorCarreira & Alumni") porque nao
     havia gap nenhum entre eles (o unico respiro vinha do padding lateral
     de cada link do menu principal, que e outro widget). Decisao: reduzir
     o espacamento progressivamente (mesma filosofia das faixas da barra
     principal), nao escondemos nenhum item nem deixamos quebrar em 2
     linhas -- a topbar e so 1 linha de texto pequeno (P-SM, 14px), cabe
     com gap reduzido sem precisar cortar conteudo. */
  .elementor-location-header > .e-con-boxed:nth-of-type(1) > .e-con-inner > .e-con {
    column-gap: 6px !important;
    gap: 6px !important;
  }
  .elementor-location-header > .e-con-boxed:nth-of-type(1) .elementor-widget-social-icons {
    --grid-column-gap: 4px !important;
  }
}

/* 768-999px: a topbar (endereco+telefone a esquerda; EN + 3 links + 5
   icones sociais a direita) NAO CABE nesta janela inteira, nao so num
   trechinho estreito logo apos 768px como a rodada anterior desta correcao
   (Task 6) supunha. Achado da verificacao de fidelidade da Task 12, medido
   por CDP largura a largura (Emulation.setDeviceMetricsOverride +
   getBoundingClientRect): mesmo no piso de espacamento mais apertado ja
   tentado aqui (gap 2px, icone 12px -- versao anterior deste bloco), o
   grupo da direita sozinho mede 614-642px; somado aos 285px do grupo da
   esquerda e ao gutter dos dois lados, so passa a caber sem overflow a
   partir de ~1000px de viewport (confirmado: overflow 135px a 800px, 63px
   a 900px, 13px a 950px, ~0 a 1000px). Ou seja, no MELHOR caso a topbar
   precisaria de ~1000px uteis, nao ~800px como a estimativa original
   assumia (feita antes do gutter desta faixa subir de 8px pra 16px numa
   correcao posterior -- Task 7 -- que nunca foi re-conferida contra este
   calculo).
   Apertar ainda mais o espacamento nao fecha essa conta: o que falta (mais
   de 100px em boa parte da faixa) e largura de TEXTO fixo (nomes dos 3
   links + "EN"), que so encolheria reduzindo fonte ou removendo conteudo --
   fora do escopo de um ajuste de gutter/gap. A saida adotada, consistente
   com o padrao ja usado pelo proprio 'hide_mobile' nativo do Elementor
   (que ja esconde esta mesma topbar abaixo de 768px): estender o mesmo
   esconderijo ate 999px. Nenhum link perdido de verdade -- os mesmos 3
   (Portal do Aluno, Portal do Professor) e os icones sociais tambem
   aparecem no rodape da pagina. */
@media (max-width: 999px) and (min-width: 768px) {
  .elementor-location-header > .e-con-boxed:nth-of-type(1) {
    display: none !important;
  }
}

/* -------------------------------------------------------------------------
 * Task 12 (verificacao de fidelidade) -- gutter responsivo GENERICO para
 * QUALQUER container boxed do site, nao so o cabecalho.
 *
 * Achado: tools/03-header.php (topbar/barra), tools/04-footer.php (rodape) e
 * TODAS as 8 secoes de tools/06-home.php usam o mesmo padding lateral fixo
 * de 310px (calibrado pra 1920px: 1920 - 2*310 = 1300px de conteudo, a
 * largura boxed do kit). Nenhuma delas, exceto o cabecalho (bloco acima,
 * corrigido na Task 6), tinha faixa responsiva alguma -- medido por CDP
 * (Emulation.setDeviceMetricsOverride + Runtime.evaluate,
 * document.body.scrollWidth vs window.innerWidth): a partir de ~1350px de
 * viewport, 310px de gutter fixo ja deixa menos de 1300px uteis; abaixo de
 * 768px o padding sozinho (620px) ja excede a tela inteira de um celular
 * real -- o widget loop-carousel da secao Depoimentos, por exemplo,
 * calculava largura 0 a 375px por causa disso, e o body.scrollWidth ia a
 * ~756-2183px conforme a largura testada.
 *
 * Especificidade desta regra ('.elementor > .e-con-boxed', filho direto, 1
 * classe + combinador de filho + 1 classe = (0,2,0)) e a MESMA da regra de
 * PADDING dedicada do cabecalho ('.elementor-location-header > .e-con-boxed',
 * tambem 1 classe + combinador de filho + 1 classe = (0,2,0) -- essa regra
 * de padding especifica NAO leva ':nth-of-type', so as regras de 'gap'
 * vizinhas no mesmo bloco levam). Com especificidade empatada e as duas
 * '!important', quem vence e a que vem DEPOIS no arquivo -- e esta regra
 * generica (Task 12) foi adicionada depois das faixas dedicadas do
 * cabecalho (Task 6). Na pratica isso e inocuo em quase toda a faixa
 * 768-1366px porque os DOIS lados escolheram o MESMO valor (16px) --
 * excecao unica: o piso de 8px da faixa 1240-1269px (bloco acima), que fica
 * dentro do 'max-width:1366px' desta regra generica (16px) e portanto e
 * SOBRESCRITO por ela, nao "nunca sobrescrito" como uma versao anterior
 * deste comentario afirmava. Confirmado por medicao (revisao final,
 * 2026-08-11): padding computado e 16px em 1240/1250/1269px, nao 8px --
 * SEM consequencia funcional (headerScrollOverflow = 0 em toda a faixa,
 * com ou sem o piso de 8px), so um piso calibrado que virou letra morta.
 * O resto desta regra generica so preenche a lacuna onde nao havia NENHUMA
 * regra dedicada: rodape e as secoes da HOME.
 *
 * IMPORTANTE: o seletor e '.elementor > .e-con-boxed' (filho DIRETO do
 * wrapper raiz que o Elementor gera pra cada documento renderizado --
 * '<header class="elementor elementor-{id} elementor-location-header">',
 * '<footer class="elementor elementor-{id} elementor-location-footer">',
 * '<div class="elementor elementor-{id}">' pra paginas normais como a HOME
 * -- SEMPRE com a classe generica 'elementor', independente do ID do post),
 * NAO '.e-con-boxed' sozinho. Primeira versao desta regra usava soh
 * '.e-con-boxed' (sem o filtro de filho direto) e isso pegava TAMBEM
 * containers aninhados fundo adentro que deliberadamente zeram o proprio
 * padding via settings (ex.: 'grupo_esquerdo'/'grupo_cta' em
 * tools/03-header.php, que usam 'padding' => $sem_padding) -- o
 * '!important' desta regra generica vencia esse padding:0 inline e
 * reintroduzia o padding lateral exatamente onde a Task 6 tinha zerado de
 * proposito, quebrando o layout do cabecalho a 1440px/320px (medido por
 * CDP: grupo_cta a 1440px ganhando um padding-left/right de 40px que nao
 * deveria ter, estourando a barra). Restringir a filhos diretos do wrapper
 * '.elementor' cobre exatamente os containers de SECAO (8 da HOME, 1 do
 * rodape, 2 do cabecalho) sem alcancar nenhum sub-container aninhado.
 *
 * Os 2 primeiros tiers reaproveitam os MESMOS valores/faixas medidos para o
 * cabecalho (100px e 40px); dali pra baixo simplificado num piso unico de
 * 16px (em vez dos 4 sub-tiers finos do cabecalho, pensados para caber o
 * menu horizontal completo) -- as secoes da HOME e o rodape nao tem um menu
 * de 7 itens pra espremer, entao nao precisam do mesmo escalonamento fino;
 * 16px e o mesmo piso que o proprio cabecalho usa da faixa 1270px pra baixo
 * -- INCLUINDO a faixa 1240-1269px: o vale de 8px dedicado do cabecalho
 * ali (bloco acima) tem a MESMA especificidade desta regra e vem ANTES no
 * arquivo, entao esta regra generica o sobrescreve na pratica (ver nota
 * detalhada mais abaixo, junto ao seletor '.elementor > .e-con-boxed') --
 * nao ha vale de 8px realmente em vigor em nenhuma largura. */
@media (max-width: 1919px) and (min-width: 1600px) {
  .elementor > .e-con-boxed { padding-left: 100px !important; padding-right: 100px !important; }
}
@media (max-width: 1599px) and (min-width: 1367px) {
  .elementor > .e-con-boxed { padding-left: 40px !important; padding-right: 40px !important; }
}
@media (max-width: 1366px) {
  .elementor > .e-con-boxed { padding-left: 16px !important; padding-right: 16px !important; }
}

/* Achado da verificacao de fidelidade da Task 12: o widget nav-menu do
 * cabecalho, no estado FECHADO do menu hamburguer (abaixo de 1240px), ainda
 * inflava a largura do proprio widget. O container do widget e
 * 'display:flex; flex-direction:column' (regra do proprio Elementor Pro,
 * 'widget-nav-menu.min.css') com 2 filhos empilhados: o botao hamburguer
 * (pequeno) e o painel '.elementor-nav-menu--dropdown.elementor-nav-menu__
 * container' (a lista off-canvas). Fechado, o painel fica com altura 0
 * ('max-height:0; transform:scaleY(0)', regra nativa do plugin) mas NAO
 * largura 0 -- ele mantem a largura intrinseca da lista (~199px, 12em) MESMO
 * invisivel, e como e um item de um flex-column, essa largura ainda decide a
 * largura do widget inteiro (o mais largo entre botao e painel). Numa barra
 * onde o widget fica logo apos o logo (grupo_esquerdo, tools/03-header.php),
 * isso empurrava o widget 199px pra direita da conta -- medido por CDP a
 * 375px: 68px de overflow horizontal so por causa do painel fechado.
 * Selector identico ao que o proprio plugin usa pra decidir o estado
 * fechado ('.elementor-menu-toggle:not(.elementor-active) +
 * .elementor-nav-menu__container', mesmo idem de max-height/transform
 * acima) -- forcamos tambem 'width:0' nesse mesmo estado; quando o menu
 * abre ('.elementor-active' aparece no botao), esta regra deixa de bater --
 * mas "a largura normal volta" (comentario original da Task 12) era
 * exatamente o bug CRITICAL da revisao final: a "largura normal", com o
 * painel em 'position:static', e a largura intrinseca da lista (~199px,
 * 12em) FICANDO DENTRO do fluxo do flex-column -- ela empurra o proprio
 * widget (que fica logo apos o logo, perto da borda esquerda em telas
 * estreitas) para a direita, e o painel sai da tela por baixo do proprio
 * peso. Medido pela revisao a 375px: painel de x=228 a x=426,8 -- 51,8px
 * fora da viewport de 375px, com 'right'/'left' computando 'auto' (no-op)
 * porque nada tira o painel do fluxo estatico. A tentativa registrada em
 * docs/superpowers/verificacao/2026-08-11-home.md 9.5 (so 'position:
 * absolute' + 'right:0') resolveu o horizontal mas quebrou o vertical --
 * porque sem um 'z-index' explicito, um elemento 'position:absolute' com
 * 'z-index:auto' pinta na MESMA camada de empilhamento que qualquer outro
 * descendente posicionado com 'z-index:auto' do documento (CSS2.1 stacking
 * order, nivel 6) -- em ORDEM DE ARVORE. Como as secoes da HOME (Elementor
 * Container) tambem sao 'position:relative' (sem z-index), e vem DEPOIS do
 * cabecalho no DOM, elas passavam a pintar POR CIMA do painel aberto,
 * escondendo-o inteiro atras do banner (confirmado por
 * 'document.elementFromPoint()' no centro do painel: retornava o botao
 * "Ver cursos" do hero, nao um item do menu). */
.elementor-menu-toggle:not(.elementor-active) + .elementor-nav-menu__container {
  width: 0 !important;
}

/* Correcao do CRITICAL 1 da revisao final (menu hamburguer sai da tela no
 * mobile) -- ver final-review.md secao "C1". Estado ABERTO
 * ('.elementor-active' no botao): tira o painel do fluxo do flex-column
 * ('position:absolute') para ele parar de inflar a largura do proprio
 * widget (mesma causa-raiz do bloco 'width:0' acima, so que no estado
 * aberto), e o ancora explicitamente pelo lado direito do PROPRIO widget
 * ('right:0', que ja e 'position:relative' nativamente -- confirmado por
 * getComputedStyle -- e funciona como containing block sem precisar
 * declarar nada a mais). 'top:100%' o mantem logo abaixo do botao
 * hamburguer (mesma posicao vertical que tinha em fluxo normal). 'width:
 * max-content' preserva a largura intrinseca da lista (a mesma ~199px de
 * antes -- os rotulos nao precisam quebrar linha) e 'max-width:calc(100vw -
 * 32px)' e so uma rede de seguranca para telas mais estreitas que a lista
 * inteira (nao e atingido em nenhuma largura testada: 320/375/414/768/
 * 1024/1239px). 'z-index:9997' (o MESMO valor que o proprio Elementor Pro
 * usa em '.elementor-nav-menu--stretch .elementor-nav-menu__container.
 * elementor-nav-menu--dropdown' -- widget-nav-menu.min.css -- para o
 * mecanismo nativo de dropdown 'stretch') garante que o painel pinte acima
 * de qualquer secao da pagina, resolvendo o "quebrou o vertical" da
 * tentativa anterior.
 *
 * Verificado por CDP com CLIQUE REAL no botao (Input.dispatchMouseEvent),
 * nao por inspecao estatica, em 320/375/414/768/1024/1239px: painel sempre
 * dentro de [0, largura_da_viewport] (a 375px: left=62,25, right=261,00; a
 * 414px: identico, pois a largura do painel independe da viewport) e
 * 'document.documentElement.scrollWidth' IDENTICO antes e depois de abrir o
 * menu em todas as larguras (ex.: 375px -> 377 tanto fechado quanto aberto
 * -- os 2px acima do nominal sao ruido pre-existente, presente mesmo sem
 * tocar no menu, dentro da tolerancia de 2px que tests/check-mobile-
 * clipping.mjs ja usa). Confirmado tambem que o painel PINTA por cima do
 * conteudo da pagina ('document.elementFromPoint()' no centro do painel
 * retorna um 'A.elementor-item' do proprio menu, nao mais um elemento do
 * hero). A 1240px+ o botao hamburguer nem existe (menu horizontal, decisao
 * deliberada documentada acima) -- nada a testar ali. */
.elementor-menu-toggle.elementor-active + .elementor-nav-menu__container {
  position: absolute !important;
  top: 100% !important;
  right: 0 !important;
  left: auto !important;
  width: max-content !important;
  max-width: calc(100vw - 32px) !important;
  z-index: 9997 !important;
}

/* Achado adiado da Task 6 para a Task 12 (Important) -- rodape estoura no
 * mobile: ver nota longa em tools/04-footer.php junto ao container
 * '$legal' (barra legal) sobre a causa-raiz real (nao era so o gutter --
 * era tambem o mesmo bug de largura de container aninhado ja documentado no
 * cabecalho, CRITICAL 2 parte 2, faltando aqui). O gutter em si ja e coberto
 * pela regra generica '.e-con-boxed' acima (a mesma faixa usada no
 * cabecalho); esta classe resolve so a parte que a regra generica de
 * 'padding' nao alcanca -- a largura ERRADA (--width:100% do PAI boxed de
 * 1300px, em vez de auto) do sub-container que agrupa os 3 links da barra
 * legal. Mesmo padrao de correcao ja usado em
 * '.elementor-location-header > .e-con-boxed > .e-con-inner > .e-con' logo
 * acima, so que escopado por classe (mais simples que replicar a cadeia de
 * seletores de profundidade do rodape). */
.fcsmd-footer-legal-links {
  width: auto !important;
  /* 'max-width:100%' (alem de 'width:auto'): sem isto, com '_flex_size' =>
     'none' (flex-shrink:0, settings de tools/04-footer.php) o item calcula
     seu proprio tamanho pelo MAX-CONTENT dos 3 links juntos numa linha so
     (~529px a 375px de viewport) e NUNCA aciona o proprio 'flex_wrap' =>
     'wrap' interno, porque a caixa sempre "cabe" o suficiente pra nao
     precisar quebrar -- ela e que estoura o pai. Limitando a 100% do espaco
     que o pai (a barra legal, tambem em wrap) realmente da, o navegador e
     obrigado a quebrar os links internamente em vez de inflar a caixa.
     Medido por CDP: sem isto, ainda sobrava 186px de overflow a 375px. */
  max-width: 100% !important;
  flex-grow: 0 !important;
  flex-shrink: 0 !important;
}

/* -------------------------------------------------------------------- */
/* Widget fcsmd-calendario (Task 8): grade mensal + lista de eventos.   */
/*                                                                        */
/* Nota de contraste (medido, nao suposto -- ver task-8-report.md):     */
/* --fcsmd-verde-md tem so 4.04:1 contra branco, insuficiente para texto */
/* normal (< 18px) que precisa de 4.5:1 (WCAG 1.4.3). Por isso o numero  */
/* do dia com evento, a data da lista lateral e o link/glifo de          */
/* navegacao usam --fcsmd-verde-saude (12.38:1) em vez de                */
/* --fcsmd-verde-md nos lugares onde o texto e pequeno. O ponto indicador */
/* (.fcsmd-cal__ponto) continua em --fcsmd-verde-cta (2.02:1): e          */
/* aria-hidden e puramente redundante -- o dia ja fica em negrito e muda  */
/* de cor sozinho -- entao nao e a unica pista visual de "tem evento" e   */
/* nao caiu sob o crivo de 1.4.11 (nao e a informacao, e reforco dela).   */
/* -------------------------------------------------------------------- */
.fcsmd-cal__titulo { margin: 0 0 24px; }

/* 'minmax(0, 1fr)', NAO '1fr' sozinho: achado da Task 12 (verificacao de
   fidelidade). Uma trilha de grid em '1fr' puro tem piso minimo IMPLICITO
   'auto' -- o item mais largo da coluna (aqui, o <li> "Processo seletivo —
   Pós-graduação Processo seletivo" da lista de eventos, cujo max-content sem
   quebra da ~446px) forcava a trilha inteira a 446px, mesmo com so 343px
   disponiveis a 375px de viewport -- e como e uma UNICA coluna, TODOS os
   <li> ficavam com a mesma largura forcada (medido por CDP: as 5 linhas da
   lista, de conteudos bem diferentes, todas com exatos 446px). 'minmax(0,
   1fr)' zera esse piso, deixando a trilha de fato encolher pro espaco
   disponivel -- o texto quebra normalmente dentro dela, sem estourar. */
.fcsmd-cal__corpo { display: grid; grid-template-columns: minmax(0, 1fr) minmax(0, 1fr); gap: 40px; align-items: start; }

.fcsmd-cal__grade {
  background: #fff; border: 1px solid var(--fcsmd-bege-borda);
  border-radius: 16px; padding: 24px;
}
.fcsmd-cal__nav {
  display: flex; align-items: center; justify-content: space-between;
  margin-bottom: 16px; font-weight: 700; color: var(--fcsmd-verde-saude);
}
.fcsmd-cal__nav a {
  width: 32px; height: 32px; display: grid; place-items: center;
  border: 1px solid var(--fcsmd-verde-md); border-radius: 50%;
  color: var(--fcsmd-verde-saude); text-decoration: none;
}
.fcsmd-cal__nav a:focus-visible { outline: 2px solid var(--fcsmd-verde-saude); outline-offset: 2px; }
/* 'table-layout:fixed': achado da Task 12. Sem isto, uma <table> com
   'width:100%' ainda pode crescer alem do container quando a soma do
   conteudo MINIMO das 7 colunas (numeros do dia, padding de 10px 0 por
   celula) excede o espaco disponivel -- navegadores ignoram o 'width:100%'
   nesse caso (medido a 375px: a tabela crescia pra 396px dentro de um
   cartao com so ~295px uteis, 62px de overflow). 'table-layout:fixed'
   forca as 7 colunas a dividir IGUALMENTE a largura que a tabela de fato
   tem, mesmo que o conteudo tenha que se ajustar dentro de cada celula. */
.fcsmd-cal__tabela { width: 100%; table-layout: fixed; border-collapse: collapse; text-align: center; }
.fcsmd-cal__tabela th {
  font-size: 13px; font-weight: 700; color: var(--fcsmd-cinza-texto);
  padding-bottom: 8px;
}
.fcsmd-cal__tabela td {
  position: relative; padding: 10px 0; font-size: 14px; color: var(--fcsmd-cinza-escuro);
}
.fcsmd-cal__tabela td.tem-evento { font-weight: 700; color: var(--fcsmd-verde-saude); }
.fcsmd-cal__ponto {
  position: absolute; left: 50%; bottom: 4px; transform: translateX(-50%);
  width: 5px; height: 5px; border-radius: 50%; background: var(--fcsmd-verde-cta);
}

.fcsmd-cal__lista { list-style: none; margin: 0; padding: 0; display: grid; gap: 12px; }
.fcsmd-cal__lista li {
  display: flex; gap: 16px; align-items: center;
  background: #fff; border: 1px solid var(--fcsmd-bege-borda);
  border-radius: 12px; padding: 16px 20px;
}
.fcsmd-cal__data {
  display: grid; place-items: center; min-width: 48px;
  color: var(--fcsmd-verde-saude); line-height: 1.1;
}
.fcsmd-cal__data strong { font-size: 20px; letter-spacing: -1px; }
.fcsmd-cal__info { display: grid; gap: 2px; }
.fcsmd-cal__info a { color: var(--fcsmd-verde-saude); font-weight: 700; text-decoration: none; }
.fcsmd-cal__info a:focus-visible { outline: 2px solid var(--fcsmd-verde-saude); outline-offset: 2px; }
.fcsmd-cal__info em { font-style: normal; font-size: 13px; color: var(--fcsmd-cinza-texto); }
.fcsmd-cal__vazio { color: var(--fcsmd-cinza-texto); }

@media (max-width: 1024px) { .fcsmd-cal__corpo { grid-template-columns: minmax(0, 1fr); } }

/* -------------------------------------------------------------------- */
/* HOME (Task 10): secoes 1-4 -- banner, cursos, por-que, depoimentos.  */
/* -------------------------------------------------------------------- */

/* Foto da secao por-que: recorte organico com borda turquesa. */
/* O asset `porque-foto` ja traz a mascara organica, a borda turquesa, os grafismos
   decorativos e o fundo #0D3A40 embutidos nos pixels — foram achatados no Figma e nao ha
   como separa-los. Portanto NAO reaplique border-radius nem border aqui: isso desenharia
   uma segunda borda no retangulo externo. O fundo do container e o mesmo #0D3A40, entao a
   borda do retangulo fica invisivel. */
.fcsmd-foto-organica img {
  display: block; width: 100%; height: auto;
}

/* Faixa de cards que sangra para fora do wrap, como no layout. */
.fcsmd-cards-scroll {
  scrollbar-width: none;
  padding-bottom: 4px;
}
.fcsmd-cards-scroll::-webkit-scrollbar { display: none; }
.fcsmd-cards-scroll > .elementor-element {
  flex: 0 0 200px;
  background: rgba(255,255,255,.04);
  border: 1px solid rgba(255,255,255,.12);
  border-radius: 12px;
  padding: 20px;
}

/* -------------------------------------------------------------------- */
/* Task 10b: templates loop-item (tools/07-loop-items.php) e bloco       */
/* "A FACULDADE" (tools/06-home.php, fcsmd_bloco_a_faculdade()).         */
/*                                                                        */
/* Nota de markup: este Elementor tem o experimento 'e_optimized_markup' */
/* ativo (confirmado em runtime) -- o <div class="elementor-widget-      */
/* container"> auxiliar que existiria "classicamente" dentro de cada     */
/* widget NAO e impresso; css_classes de um widget cai direto no MESMO   */
/* <div class="elementor-element elementor-widget-…"> que ja carrega     */
/* data-id/data-widget_type. Por isso os seletores abaixo miram a classe */
/* custom diretamente (sem ".elementor-widget-container" no meio) e so   */
/* descem para uma classe interna (".elementor-icon", ".elementor-      */
/* heading-title" etc.) quando essa classe e gerada pelo PROPRIO widget, */
/* nao pelo wrapper generico.                                            */
/* -------------------------------------------------------------------- */

/* Curso: foto circular (correcao pos-review -- as 4 fotos reais foram    */
/* exportadas do Figma e viraram imagem destacada de cada curso, ver      */
/* tools/07-loop-items.php e tools/05-seed-conteudo.php) sobreposta a     */
/* borda esquerda da linha.                                               */
.fcsmd-curso-foto { flex-shrink: 0; }
.fcsmd-curso-foto img {
  width: 110px; height: 110px;
  border-radius: 50%;
  object-fit: cover;
  display: block;
}

/* CRITICAL 1 do re-review (task-10-review.md): sem isto o botao da linha */
/* de curso era o unico filho flex de $linha sem controle de encolhimento */
/* -- o navegador aplicava o 'flex-shrink:1' padrao e o texto quebrava em */
/* 2-3 linhas ("Mais Informa/ções" etc.) assim que a linha ficava         */
/* apertada. 'flex-shrink:0' no WIDGET (mesmo padrao de '.fcsmd-curso-    */
/* foto' e de '.fcsmd-depoimento-avatar' acima) trava o tamanho da        */
/* pilula; 'white-space:nowrap' no texto interno e defesa extra (mesmo    */
/* sem encolher, um texto muito longo ainda poderia quebrar por padrao    */
/* do navegador -- nao e o caso aqui, mas e o mesmo par de regras ja      */
/* usado para o CTA do header, ver bloco "CRITICAL 2" mais acima).        */
.fcsmd-curso-botao {
  flex-shrink: 0;
}
.fcsmd-curso-botao .elementor-button-text {
  white-space: nowrap;
}
/* Slot da Tag da linha (widget SEMPRE impresso, mesmo com a tag         */
/* dinamica resolvendo vazia -- ver class-dynamic-tags.php): quando vazio */
/* de verdade (sem nenhum no filho) some do fluxo, em vez de deixar um   */
/* respiro em branco acima do titulo no curso "Graduação".               */
.fcsmd-curso-tag-slot:empty { display: none; }

/* CRITICAL da 2a rodada de re-review: "Capacitação de Curta Duração"
   renderizava "Capacitaçã/o de Curta/Duração" -- quebra DENTRO da
   palavra, entre "ç" e "o", nao no limite de palavra. A revisao anterior
   ja tinha confirmado que o Figma quebra esses titulos em varias linhas
   (correto, nao e defeito) -- mas SEMPRE entre palavras, nunca dentro
   delas. Causa raiz (achada via CDP, getComputedStyle() em cadeia de
   ancestrais partindo do <h3>, nao so leitura de CSS): o proprio
   Elementor PRO carrega uma regra universal em
   'elementor-pro/assets/css/widget-loop-common.min.css':
   '.e-loop-item * { word-break: break-word }' -- aplica a TODO
   descendente de QUALQUER item de loop (pensada pra nao deixar conteudo
   de CMS arbitrariamente longo vazar da grade). 'break-word' e um valor
   legado de 'word-break' que o navegador trata como
   'overflow-wrap: anywhere' -- quebra em QUALQUER ponto (inclusive no
   meio de uma silaba) quando uma palavra sozinha nao cabe na largura
   disponivel, sem respeitar limite de palavra. Confirmado que a regra
   bate direto no <h3> e nos containers acima dele (nao e heranca de um
   ancestral mais distante -- '.e-loop-item *' casa com cada descendente
   individualmente). Fix: neutraliza especificamente para o titulo do
   curso ('.fcsmd-h3', usado so por 'fcsmd_titulo_post' nas 4 linhas) --
   'word-break: normal' + 'overflow-wrap: normal' restauram o
   comportamento padrao do navegador (so quebra em espaco); um titulo que
   nao cabe mesmo assim continua quebrando em VARIAS LINHAS pelas
   palavras (comportamento aceito pela revisao anterior), nunca dentro de
   uma palavra. Nao alterado globalmente (so '.fcsmd-h3'): os outros
   textos dentro de loop-item (paragrafo curto, pilulas, nome/cargo do
   depoimento) sao mais curtos que suas colunas na pratica e nao
   precisaram de override nesta correcao.

   Duas linhas de seletor, nao uma so -- achado por CDP (getComputedStyle
   em cadeia, nao so leitura de CSS): '_css_classes' (o '.fcsmd-h3') cai
   no <div class="elementor-element …"> WRAPPER do widget (markup
   otimizado, ver nota grande acima), nao no <h3
   class="elementor-heading-title"> interno. 'word-break' e uma
   propriedade herdada -- mas '.e-loop-item *' bate DIRETO no <h3>
   tambem (universal selector casa com TODO descendente, nao so o
   wrapper), e uma regra que bate DIRETAMENTE num elemento sempre vence
   um valor apenas HERDADO do pai, independente de especificidade. Setar
   so no wrapper ('.fcsmd-h3') nao bastava -- o <h3> continuava com
   'break-word' aplicado direto nele. Precisa mirar os dois.

   '!important' nas duas propriedades: especificidade empatada
   ('.e-loop-item *' e '.fcsmd-h3'/'.fcsmd-h3 .elementor-heading-title'
   sao todas um-classe-so), entao hoje ganhamos por ORDEM de enqueue
   ('fcsmd-design-system' registrado em 'wp_enqueue_scripts' prioridade 20,
   depois de qualquer CSS de widget do Elementor -- class-assets.php).
   Robusto hoje, mas fragil a uma mudanca futura de prioridade/dependencia
   do enqueue (nada IMPEDE isso de quebrar silenciosamente). Mesmo
   principio ja usado em outros overrides deste arquivo contra CSS de
   terceiros (ex. o bloco "CRITICAL 2" do header, width/flex-grow/shrink
   com '!important') -- aplicado aqui pela mesma razao. */
.fcsmd-h3,
.fcsmd-h3 .elementor-heading-title {
  word-break: normal !important;
  overflow-wrap: normal !important;
}

/* Pilula pequena (Tag da linha de curso / categoria do card de         */
/* noticia): mesma regra serve tanto pro <span> gerado pela tag         */
/* customizada 'fcsmd-pilulas' quanto pro <div> wrapper do widget       */
/* (caso 'post-terms', que nao envolve o texto num elemento com classe). */
.fcsmd-tag-pilula {
  display: inline-block;
  background: var(--fcsmd-verde-borda-clara);
  color: var(--fcsmd-verde-md);
  padding: 4px 12px;
  border-radius: 999px;
  line-height: 1.3;
}

/* Fileira de pilulas de subcategoria (fundo branco, borda bege). O      */
/* proprio <div> do widget vira o flex container -- fica vazio (0px de   */
/* altura, sem padding proprio) quando '_fcsmd_pilulas' esta vazio.      */
.fcsmd-pilulas-row {
  display: flex; flex-wrap: wrap; gap: 8px;
}
.fcsmd-pilula {
  display: inline-block;
  background: #fff;
  border: 1px solid var(--fcsmd-bege-borda);
  color: var(--fcsmd-cinza-escuro);
  font-size: 14px;
  line-height: 1.5;
  padding: 6px 14px;
  border-radius: 999px;
}

/* Depoimento: avatar circular (fallback = placeholder padrao do         */
/* Elementor quando o post nao tem imagem destacada, ver                 */
/* tools/07-loop-items.php) e botao circular "+" no rodape do card.      */
/* flex-shrink:0 no WIDGET (nao so no img): sem isso, o navegador ainda
   distribui uma pequena parte do "encolhimento" padrao da linha pra este
   item mesmo sobrando espaco de sobra nos irmaos (medido via CDP: 42x48px
   em vez de 48x48px) -- trava a caixa no tamanho pretendido. */
.fcsmd-depoimento-avatar {
  flex-shrink: 0;
}
.fcsmd-depoimento-avatar img {
  width: 48px; height: 48px;
  border-radius: 50%;
  object-fit: cover;
  display: block;
}
.fcsmd-depoimento-cta .elementor-icon {
  width: 36px; height: 36px;
  display: flex; align-items: center; justify-content: center;
}

/* Link "LinkedIn": o widget heading so tem controle de cor pro texto    */
/* normal ('title_color', selector '.elementor-heading-title'), sem um   */
/* equivalente ao 'link_color' do text-editor -- a cor do <a> nesse caso  */
/* depende de heranca (que qualquer regra 'a{color:…}' de origem author  */
/* com especificidade igual pode vencer, dependendo da ordem no          */
/* stylesheet). Esta regra mira o <a> tambem, explicitamente, pra nao    */
/* depender dessa heranca. */
.fcsmd-link-verde .elementor-heading-title,
.fcsmd-link-verde .elementor-heading-title a {
  color: var(--fcsmd-verde-md);
  text-decoration: none;
}

/* Noticia: imagem destacada no topo do card, cantos arredondados        */
/* recortados pelo 'overflow: hidden' do container-card (settings do     */
/* proprio container, tools/07-loop-items.php), nao daqui. */
.fcsmd-noticia-foto img {
  display: block;
  width: 100%;
  aspect-ratio: 16 / 10;
  object-fit: cover;
}

/* Bloco "A FACULDADE" (fcsmd_bloco_a_faculdade(), tools/06-home.php):    */
/* card grande com foto de fundo escurecida + grade 3x2 de cards         */
/* translucidos, cada um com um icone em quadrado turquesa no canto.     */
.fcsmd-faculdade-icone .elementor-icon {
  width: 48px; height: 48px;
  display: flex; align-items: center; justify-content: center;
}

/* -------------------------------------------------------------------- */
/* INSTITUCIONAL (Task I2) -- correcao pos-revisao: imagens encolhendo   */
/* abaixo do tamanho pedido dentro de linhas flex.                      */
/*                                                                        */
/* CAUSA-RAIZ (confirmada por CDP, CSS.getMatchedStylesForNode -- nao so  */
/* leitura de codigo): o controle nativo 'width' do widget 'image' so    */
/* gera CSS para '{{WRAPPER}} img' (elementor/includes/widgets/image.php, */
/* linha ~313) -- NUNCA para o proprio WRAPPER, que e o item real da     */
/* flexbox dentro da linha (foto + bloco de texto / selo + card). Sem     */
/* nada travando o WRAPPER, ele encolhe (flex-shrink:1 e o default do     */
/* navegador) espremido pelo irmao que cresce (_flex_grow:1); dai o reset */
/* global 'img { max-width: 100% }' (WordPress/Elementor) corta a largura */
/* pedida de volta ao tamanho do wrapper ja encolhido. Medido por CDP     */
/* antes desta correcao: foto de unidade 155px -> 99px renderizado, selo  */
/* de premio 80px -> 45.5px.                                              */
/*                                                                        */
/* Mesmo padrao ja usado (e correto) em '.fcsmd-curso-foto'/               */
/* '.fcsmd-depoimento-avatar' (mais acima neste arquivo): 'flex-shrink:0'  */
/* no WRAPPER (a classe cai no mesmo elemento do wrapper -- markup         */
/* otimizado, 'e_optimized_markup', ver nota grande sobre isso mais acima) */
/* + largura fixa no <img> via CSS de classe, SEM depender do controle     */
/* nativo 'width' do widget (que continua gravado no JSON, inofensivo,     */
/* mas deixa de ser a fonte de verdade do tamanho renderizado).            */
/*                                                                        */
/* 'height: auto' (nao um valor fixo) na foto de unidade: o asset NAO e   */
/* quadrado (465x522px, ~0.89 de proporcao -- confirmado abrindo o        */
/* arquivo) e ja traz a mascara organica embutida nos pixels; forcar       */
/* height fixo com object-fit:cover cortaria essa mascara de forma         */
/* imprevisivel. Selo de premio e selo de timeline SAO quadrados (240x240  */
/* e 252x252px, confirmado abrindo os arquivos), entao 'height:auto'       */
/* tambem basta ali (resulta no mesmo valor do width, sem precisar          */
/* declarar os dois nem 'object-fit').                                     */
.fcsmd-unidade-foto { flex-shrink: 0; }
.fcsmd-unidade-foto img { width: 155px; height: auto; display: block; }

.fcsmd-premio-selo { flex-shrink: 0; }
.fcsmd-premio-selo img { width: 80px; height: auto; display: block; }

.fcsmd-timeline-selo { flex-shrink: 0; }
.fcsmd-timeline-selo img { width: 84px; height: auto; display: block; }

/* -------------------------------------------------------------------- */
/* INSTITUCIONAL (Task I3) -- mesma ARMADILHA da Task I2 reaplicada em    */
/* 4 imagens novas (o controle nativo 'width' do widget 'image' so trava */
/* o <img>, nunca o WRAPPER que e o item real da linha flex -- ver o      */
/* comentario longo acima, secao "Task I2"): a foto de Reconhecimento     */
/* (1:1598, 308.5x310, quase quadrada -- 'height:auto' basta, sem cortar  */
/* nada) e as 3 fotos de Infraestrutura (1:1613, retangulares e com       */
/* proporcao um pouco diferente entre si nos 3 assets originais --        */
/* 'height' FIXO + 'object-fit:cover' para as 3 saírem com a MESMA altura */
/* lado a lado, como no Figma, em vez de 3 alturas levemente diferentes). */
.fcsmd-reconhecimento-foto { flex-shrink: 0; }
.fcsmd-reconhecimento-foto img { width: 308.5px; height: auto; display: block; }

/* CORRECAO (revisao do coordenador, pos-Task I3): 420x300 e gap 20, nao   */
/* 417x297 e gap 24 -- os primeiros eram medidos por mim na imagem de      */
/* referencia (regua), os segundos sao os valores exatos do Figma          */
/* (get_design_context, 'flex-[1_0_0]': (1300 - 2*20) / 3 = 420).          */
.fcsmd-infra-foto { flex-shrink: 0; }
.fcsmd-infra-foto img { width: 420px; height: 300px; object-fit: cover; border-radius: 12px; display: block; }

.fcsmd-infra-selo-jci { flex-shrink: 0; }
.fcsmd-infra-selo-jci img { width: 170px; height: auto; display: block; }

/* Embed do Google Maps (widget nativo 'google_maps', secao Localização,   */
/* Task I3): confirmado lendo elementor/includes/widgets/google-maps.php   */
/* que o widget so tem controle de ALTURA ('height', responsive slider,     */
/* gera '{{WRAPPER}} iframe { height: ... }') -- NENHUM controle de         */
/* LARGURA. Sem isto, o <iframe> cai no default do proprio navegador       */
/* (300px), bem menor que os 680px do container que o envolve. O           */
/* border-radius/overflow ficam no CONTAINER que envolve o widget (elType  */
/* 'container', controles nativos 'border_radius'/'overflow', sem a        */
/* armadilha do underscore que so existe em WIDGET) -- aqui so falta       */
/* mesmo a largura do iframe.                                              */
.fcsmd-mapa-embed iframe { width: 100%; display: block; }

/* -------------------------------------------------------------------- */
/* INSTITUCIONAL (Task I4) -- MESMA ARMADILHA das Tasks I2/I3 reaplicada  */
/* na galeria da secao Centro de Convenções (1:1676): o controle nativo   */
/* 'width' do widget 'image' so trava o <img>, nunca o WRAPPER que e o    */
/* item real da linha flex -- '_css_classes' trava o wrapper aqui.        */
/* 317.5x230 (Figma 1:1677-1680), borda #E4DCCF, raio 10px (aplicados no  */
/* <img>, com object-fit:cover -- mesma tecnica de '.fcsmd-infra-foto').  */
.fcsmd-conv-foto { flex-shrink: 0; }
.fcsmd-conv-foto img {
  width: 317.5px; height: 230px; object-fit: cover; display: block;
  border-radius: 10px; border: 1px solid #E4DCCF;
}

/* -------------------------------------------------------------------- */
/* INSTITUCIONAL (fechamento de 768px) -- overflow horizontal achado      */
/* ampliando a varredura de larguras alem das 3 ja verificadas            */
/* (1920/1024/375) pra 375/414/600/768/834/1024/1280/1920. 1280px caiu    */
/* bem no meio de uma faixa que o Elementor NAO cobre com nenhum          */
/* breakpoint nativo: 'flex_wrap_tablet'/'width_tablet' (controles         */
/* responsivos do Elementor) so geram CSS ate 1024px (breakpoint          */
/* "tablet"); acima disso o proximo breakpoint e "desktop" sem limite      */
/* superior, entao o layout FIXO de 1920px (3 fotos de 420px = 1300px,    */
/* galeria de 4 fotos de 317.5px = 1300px, bloco flat de 1300px) volta a  */
/* valer a partir de 1025px, sem nenhum encolhimento -- so cabe de verdade */
/* quando a secao boxed tem >=~1350px uteis (medido por CDP: overflow de   */
/* 216px a 1100px, 116px a 1200px, 16px a 1300px, 0px a partir de 1350px). */
/* Habilitar o breakpoint "Laptop" do Kit do Elementor resolveria de forma */
/* nativa, mas e uma mudanca GLOBAL de configuracao (afeta toda pagina do  */
/* site, nao so esta), fora do escopo de um fix pontual desta pagina.      */
/* Em vez disso, mesma tecnica ja usada no resto deste arquivo (classe +   */
/* regra com '!important', ver o cabecalho geral do arquivo): forca o      */
/* mesmo comportamento que ja existe no breakpoint tablet nativo do        */
/* Elementor (wrap / 100% de largura), estendido pra faixa 1025-1366px     */
/* (1366px com folga alem dos ~1350px onde o layout fixo volta a caber     */
/* sozinho, mesmo valor de breakpoint "laptop" ja usado noutro lugar deste */
/* arquivo pro menu). Nao muda nada em 1920px (fora da faixa da regra).    */
@media (min-width: 1025px) and (max-width: 1366px) {
  .fcsmd-infra-fotos-row,
  .fcsmd-conv-galeria-row { flex-wrap: wrap !important; }
  .fcsmd-trabalhe-flat { width: 100% !important; }
}

/* -------------------------------------------------------------------- */
/* PESQUISA E EXTENSÃO (Task P1) -- hero interno + Centro de Iniciação   */
/* Científica (tools/09-pesquisa-extensao.php).                          */
/* -------------------------------------------------------------------- */

/* Pilulas da subnav do hero: container inteiro vira <a> ('html_tag'=>'a',
   mesma tecnica ja usada nos 4 links 'a.doc' da Institucional). Sem
   'text-decoration:none' aqui o navegador sublinharia o texto do heading
   filho (herda de 'a' por padrao); o resto do visual (fundo translucido,
   raio 100px, padding) ja vem das settings do proprio container. */
/* CORRECAO (achada por captura CDP em 1920px, nao so pelo overflow
   numerico -- as 6 pilulas renderizavam como 6 BARRAS DE LARGURA TOTAL
   empilhadas, em vez de pilulas lado a lado): MESMA ARMADILHA "CRITICAL 2
   (parte 2)" ja documentada mais acima neste arquivo para o cabecalho --
   todo container do Elementor recebe 'width: var(--width, 100%)' por
   padrao (regra base '.e-con' do proprio plugin). As settings
   '_flex_grow'/'_flex_shrink' => 0 (tools/09-pesquisa-extensao.php) ja
   geram 'flex-grow:0'/'flex-shrink:0', mas isso sozinho nao muda o
   'width' PRoprio do item -- com 'flex-basis:auto' (default), o
   navegador usa esse 'width:100%' como flex-basis, entao cada pilula
   pedia 100% da LINHA pra si mesma; 'flex_wrap' empurrava a proxima pra
   uma nova linha (nunca lado a lado), produzindo a pilha de barras.
   'width: auto !important' aqui sobrescreve o padrao do plugin,
   deixando cada pilula do tamanho do proprio conteudo (padding + texto). */
.fcsmd-subnav-tag {
  width: auto !important;
  text-decoration: none;
  transition: background-color .2s ease;
}
.fcsmd-subnav-tag:hover,
.fcsmd-subnav-tag:focus-visible {
  background-color: rgba(255, 255, 255, .2) !important;
}
.fcsmd-subnav-tag:focus-visible {
  outline: 2px solid #00CCBD;
  outline-offset: 2px;
}

/* Foto do Centro de Iniciação Científica (Figma 1:3528, 589x310): raio
   ASSIMETRICO -- arredondada nos 3 cantos superior-esquerdo/superior-
   direito/inferior-esquerdo, reta no inferior-direito (confirmado por
   get_design_context: 'rounded-bl-[20px] rounded-tl-[20px] rounded-tr-[20px]',
   sem 'rounded-br'). Mesma ARMADILHA generica do projeto (controle nativo
   'width' do widget 'image' so trava o <img>, nunca o WRAPPER que e o item
   real da linha flex) -- '_css_classes' trava o wrapper aqui, mesmo padrao
   de '.fcsmd-infra-foto'/'.fcsmd-reconhecimento-foto'.
   As 2 camadas cruas do Figma (Rectangle140 + Rectangle141, um overlay sem
   diferenca visual perceptivel -- conferido por get_screenshot) foram
   fundidas num unico asset achatado ('pesq-cic-foto') na importacao, mesma
   decisao ja tomada para fotos "chapadas" da Institucional. */
.fcsmd-cic-foto { flex-shrink: 0; }
.fcsmd-cic-foto img {
  width: 589px; height: 310px; object-fit: cover; display: block;
  border-radius: 20px 20px 0 20px;
}

/* Os 2 grafismos decorativos desta secao (offset vertical fixo, 295px/19px
   medidos do Figma -- ver o comentario longo em
   tools/09-pesquisa-extensao.php) sao posicionados relativo ao TOPO da
   secao. Em telas estreitas o conteudo empilha (foto abaixo do texto,
   'flex_wrap_tablet') e a secao fica bem mais alta que os 740px do
   desktop -- os mesmos 295px/19px fixos passam a cair EM CIMA do
   cabecalho (sobrancelha/H2/paragrafo), competindo visualmente com o
   texto (confirmado por captura CDP em 768px e 375px: os circulos do
   grafismo esquerdo sobrepunham literalmente "Centro de Iniciação
   Científica" e o comeco do H2). Sao elementos puramente decorativos
   (nenhum conteudo/link) -- escondidos abaixo do breakpoint tablet do
   Elementor (<=1024px) em vez de recalcular um offset responsivo, mesma
   logica de "esconder o que so decora e atrapalha em telas pequenas" ja
   aplicada a outros elementos do projeto (ex.: barra de acessibilidade
   fixa reposicionada no mobile). Nao afeta os 8 grafismos da
   Institucional (classe generica '.fcsmd-grafismo' preservada intacta;
   esta regra mira so a classe especifica '.fcsmd-cic-grafismo'). */
@media (max-width: 1024px) {
  .fcsmd-cic-grafismo { display: none; }
}

/* CORRECAO POS-REVISAO (achado Important do revisor, confirmado por diff
   de pixels contra o Figma): os 2 assets SVG foram exportados no desenho
   ORIGINAL do Figma, sem a transformacao que o proprio Figma aplica
   visualmente no wrapper do no (confirmado em get_design_context, classes
   Tailwind do wrapper -- nao do <img> em si):
     - no 1:3505 ("Group 345", grafismo esquerdo, '.fcsmd-cic-grafismo--esq'):
       wrapper com '-scale-x-100' -- espelhamento horizontal.
     - no 1:3531/1:3534 ("grafismos 04", grafismo direito,
       '.fcsmd-cic-grafismo--dir'): wrapper com 'rotate-180'.
   Sem isto, o grafismo direito renderizava de cabeca para baixo e o
   esquerdo espelhado -- so aparente comparando contra o Figma pixel a
   pixel, nao no HTML/JSON cru (a URL do asset e a mesma, so a ORIENTACAO
   visual diverge). Aplicado no proprio container que carrega o
   'background_image' (equivalente visual a transformar soh a imagem,
   ja que a caixa inteira tem tamanho fixo com 'background-size:contain'). */
.fcsmd-cic-grafismo--esq { transform: scaleX(-1); }
.fcsmd-cic-grafismo--dir { transform: rotate(180deg); }

/* -------------------------------------------------------------------- */
/* PESQUISA E EXTENSÃO -- Secao 3, Nossa Atuação (Task P2).             */
/* -------------------------------------------------------------------- */

/* H2 misto (1:3564): so o PESO muda neste trecho -- a cor branca ja vem
   herdada do heading pai ('title_color' => '#FFFFFF'). O trecho dourado
   reusa '.fcsmd-destaque--dourado' (ja existente acima), sem classe nova. */
.fcsmd-atuacao-h2__forte { font-weight: 800; }

/* CORRECAO POS-REVISAO (Important): fundo de 3 camadas de verdade agora
   (foto + '#0D3A40' multiply + 'rgba(13,58,64,0.84)' chapada), nao mais 2
   -- o revisor mediu por amostragem de pixel que a camada de multiply
   fazia diferenca REAL de contraste no trecho dourado do H2 (5,43:1 no
   Figma com multiply contra 3,83:1 sem ela, abaixo do minimo 4,5:1 do WCAG
   1.4.3), nao so uma diferenca cosmetica desprezivel como a primeira
   versao desta secao presumiu sem medir.
   O overlay NATIVO do Elementor ('background_overlay_*', settings do PHP,
   'background_overlay_color' => '#0D3A40' solido) sempre renderiza como
   '::before' do proprio container -- garantido pintar logo apos o
   'background-image' da foto e ANTES de qualquer filho real (grafismos,
   texto), exatamente onde a camada de multiply precisa ficar. So falta o
   'mix-blend-mode', que o Elementor nao expoe como controle -- aplicado
   aqui via CSS puro. */
.fcsmd-secao-atuacao::before {
  mix-blend-mode: multiply;
}
/* A 3a camada (chapada, 'rgba(13,58,64,0.84)') vira um FILHO REAL
   ('$overlay_flat', tools/09-pesquisa-extensao.php) em vez do overlay
   nativo (que agora esta ocupado pela camada de multiply acima) --
   colocado PRIMEIRO entre os filhos reais da secao, entao pinta logo
   depois do '::before' (multiply) e antes dos grafismos/texto: a mesma
   ARMADILHA generica de 'position:absolute' sozinho gerar 'top:0;left:0'
   hardcoded (ja documentada nos grafismos abaixo) exige '!important' em
   toda borda; 'right'/'bottom' tambem setados (o Elementor so hardcoda
   'top'/'left', nao 'right'/'bottom') pra cobrir a secao INTEIRA sem
   depender de nenhum controle nativo de largura/altura (que teriam a
   MESMA ARMADILHA de 'height' documentada mais abaixo). */
.fcsmd-atuacao-overlay-flat {
  position: absolute !important;
  top: 0 !important;
  left: 0 !important;
  right: 0 !important;
  bottom: 0 !important;
  background-color: rgba(13, 58, 64, 0.84);
  pointer-events: none;
}

/* Carrossel horizontal (1:3566, 'div#dcar'): o controle nativo 'overflow'
   do Elementor Container so tem Hidden/Visible (sem 'auto'/'scroll') --
   scroll horizontal e CSS puro. 'overflow-y:hidden' reproduz o
   'overflow-y-clip' do Figma (o 'padding-top:42px' do proprio container,
   settings de tools/09-pesquisa-extensao.php, ja da respiro suficiente pro
   badge negativo dos cards nao ser cortado por este 'hidden'). */
.fcsmd-atuacao-carrossel {
  overflow-x: auto;
  overflow-y: hidden;
}

/* Cada card (1:3567 e irmaos) e o ancestral posicionado do proprio badge --
   'position:relative' explicito aqui so por seguranca/documentacao (todo
   '.e-con' do Elementor ja e 'position:relative' por padrao; ver a
   ARMADILHA do rodape da HOME, que era um WIDGET se metendo no meio da
   cadeia -- aqui e container>container direto, sem esse risco). */
.fcsmd-atuacao-card { position: relative; }

/* Badge (1:3569 e irmaos): 'left:-9px; top:-35px' do Figma -- offset
   NEGATIVO. NAO usa os controles nativos '_offset_x'/'_offset_y' do
   Elementor (mesma ARMADILHA ja documentada pros grafismos da secao CIC:
   offset NAO-ZERO num container 'position:absolute' com largura explicita
   faz 'getComputedStyle' devolver 'left' E 'right' simultaneos, ignorando
   a largura -- com offset NEGATIVO o risco e ainda maior). Largura/altura/
   cor/raio continuam nos controles nativos (settings do PHP), sem risco --
   so a POSICAO vem daqui. */
.fcsmd-atuacao-badge {
  left: -9px !important;
  top: -35px !important;
}

/* Os 2 grafismos decorativos (1:3545 dir / 1:3634 esq) -- posicionados
   relativo a caixa INTEIRA da secao (1920x759px no Figma), nao ao
   conteudo boxed (mesmo CRITICAL 2 ja documentado na secao CIC).
   Escondidos <=1024px (mesma logica ja usada em '.fcsmd-cic-grafismo':
   elementos puramente decorativos, evita qualquer risco de overflow em
   telas estreitas em vez de recalcular posicao responsiva). */
@media (max-width: 1024px) {
  .fcsmd-atuacao-grafismo { display: none; }
}
/* ACHADO NOVO nesta task (verificado por captura CDP contra o Figma --
   ambos os grafismos apareciam encostados no canto SUPERIOR-esquerdo em
   vez de nas posicoes certas): 'position' => 'absolute' (controle nativo
   do Elementor), SOZINHO, ja gera 'top:0px' e 'left:0px' (ou 'right:0px'
   em RTL) HARDCODED no proprio seletor completo, algo como
   '.elementor-4133 .elementor-element.elementor-element-{id}' -- 3
   classes (o id numerico do post, '.elementor-element' generico, e
   '.elementor-element-{id}' especifico), especificidade (0,3,0) --
   CORRECAO de uma imprecisao apontada na revisao: a 1a versao deste
   comentario contava so 2 das 3 classes do seletor. Mesmo sem tocar em
   NENHUM controle de offset. Confirmado lendo o CSS gerado de verdade
   (document.styleSheets, nao so getComputedStyle): a regra existe mesmo
   pra um elemento cujas settings nao tem '_offset_x'/'_offset_y' em lugar
   nenhum. Como essa regra do Elementor tem especificidade MAIOR que uma
   classe unica minha ('.fcsmd-atuacao-grafismo--dir', (0,1,0)), ela vencia
   e todo 'left'/'top' que eu setava aqui era ignorado -- por isso
   '!important' em CADA propriedade de posicao abaixo (nao so estilo, e
   REQUISITO pra vencer a regra nativa). Mesma causa-raiz por tras do badge
   acima (ja tinha '!important' desde o inicio, por isso funcionava) e dos
   grafismos/foto circular da secao 4, mais abaixo. */
/* Direito (1:3545): 'left:1221px' no Figma (canvas de 1920px) cabe a
   1920px (1221+382=1603 < 1920) mas NAO cabe mais estreito -- a secao
   (fundo edge-to-edge) acompanha a VIEWPORT real, nao fica travada em
   1920px; a 1280px (ainda acima do breakpoint de 1024px que esconde o
   grafismo) um 'left' fixo calibrado pra 1920 jogava o grafismo pra fora
   da secao (achado por CDP: 616px de overflow horizontal a 1280px, so
   depois de corrigir o bug do 'left:0' hardcoded acima -- antes disso o
   grafismo nem aparecia na posicao certa pra revelar este 2o problema).
   Fix: ancorar pela DIREITA ('right', convertido do 'left' original:
   1920 - 1221 - 382 = 317px) em vez da esquerda -- fica a mesma distancia
   da borda direita da secao em QUALQUER largura >=1024px (onde o
   grafismo continua visivel), em vez de uma coordenada absoluta valida so
   a 1920px. 'left:auto!important' explicito pelo mesmo motivo do
   'top:auto' no grafismo esquerdo abaixo (evita o par left+right
   simultaneo -- aqui o Elementor so hardcoda 'left:0px' em LTR, entao sem
   isto teria 'left:0' E 'right:317px' ao mesmo tempo, esticando a LARGURA
   pelo vao entre os dois em vez de respeitar o 'width' nativo).
   Transformacao (Global Constraints do plano, conferida de novo em
   get_design_context nesta task): wrapper Figma '-scale-y-100 rotate-180'
   = 'rotate(180deg) scaleY(-1)'. */
.fcsmd-atuacao-grafismo--dir {
  left: auto !important;
  right: 317px !important;
  top: 100px !important;
  transform: rotate(180deg) scaleY(-1);
}
/* ACHADO ADIADO DA TASK P2, FECHADO NA P4 (ver o ledger): um bloco de
   ~6x6px onde este grafismo cruza por TRAS da palavra "ações" (H2, fim da
   1a linha) media so ~2,3:1 de contraste (medido por amostragem de pixel,
   media da linha inteira passava em 5,25:1 -- so o pixel isolado onde o
   traco claro do grafismo cruza atras da letra reprovava). O grafismo ja
   pinta ATRAS do texto (todo '.e-con' do Elementor e 'position:relative'
   por padrao -- ver o comentario de '.fcsmd-atuacao-card' acima -- entao
   '$bloco', ultimo filho real da secao, ja empata em stack level 0 e vence
   por ordem de arvore; nao e um bug de ordem de pintura pra corrigir).
   Confirmado por captura: o traco do grafismo que cruza "ações" fica
   inteiro dentro do quarto SUPERIOR do proprio grafismo (a palavra, medida
   por CDP, ocupa de 16% a 37% da altura de 229px do grafismo -- bem acima
   do centro/base, onde fica o resto do desenho decorativo, sem nenhum
   texto por perto). Em vez de mexer na posicao (arriscar reabrir os bugs
   de offset/overflow ja resolvidos nesta mesma secao) ou no texto,
   reduzida a opacidade SO NESSA FAIXA (mask-image em gradiente vertical,
   transparente nos primeiros 35% de altura, opaco a partir de 55%) -- o
   resto do grafismo (a maior parte da area, ~65% de baixo, onde nao ha
   texto nenhum por perto) continua 100% visivel, sem mudanca. */
.fcsmd-atuacao-grafismo--dir {
  -webkit-mask-image: linear-gradient(to bottom, transparent 0%, transparent 35%, black 55%);
  mask-image: linear-gradient(to bottom, transparent 0%, transparent 35%, black 55%);
}
/* Esquerdo (1:3634): 'bottom:69.06px; right:1714px' no Figma -- convertido
   pra 'left' (1920 - 1714 - 253 = -47px): o proprio Figma ja desenha este
   grafismo SANGRANDO pra fora da borda esquerda da secao (parcialmente
   fora do canvas de 1920px, decorativo). Diferente da ARMADILHA de offset
   negativo dos controles NATIVOS do Elementor (que quebrava a LARGURA por
   causa do par left/right fantasma que o proprio mecanismo de offset
   gerava) -- aqui e CSS puro, um 'left' negativo comum, que nao adiciona
   'scrollWidth' ao documento (overflow horizontal cresce pela DIREITA, nao
   pela esquerda; confirmado por CDP nas 8 larguras antes de fechar esta
   task). Sem transformacao (wrapper Figma sem classe de rotate/scale).
   'top:auto!important' explicito -- sem isto, o 'top:0px' hardcoded do
   Elementor (ver nota acima) e 'bottom:69.06px' ficam os DOIS presentes
   simultaneamente, e o navegador calcula a ALTURA da caixa pelo vao entre
   os dois (759 - 0 - 69.06 = ~690px). CORRECAO de imprecisao apontada na
   revisao: a 1a versao deste comentario dizia que isso acontecia "em vez
   de respeitar o min-height" -- errado, 'min-height' e um PISO, nao um
   teto: ele so barra a caixa de ficar MENOR que o valor setado (254px
   aqui), nunca IMPEDE que ela fique MAIOR. Como o vao calculado (~690px)
   ja e maior que o piso de 254px, o 'min-height' simplesmente nao
   precisava ATIVAR pra "ser respeitado" -- a caixa so cresceu alem dele
   por causa do 'top'+'bottom' simultaneos, nada a ver com o proprio
   'min-height' ter sido ignorado ou nao. Achado ao vivo comparando a
   captura contra o Figma (o grafismo saia esticado verticalmente e
   ancorado no topo, nao do tamanho nem na posicao certa). */
.fcsmd-atuacao-grafismo--esq {
  left: -47px !important;
  top: auto !important;
  bottom: 69.06px !important;
}

/* -------------------------------------------------------------------- */
/* PESQUISA E EXTENSÃO -- Secao 4, Programas de Pesquisa (Task P2).     */
/* -------------------------------------------------------------------- */

/* Foto no topo de cada card "pilar" (1:3664 e irmaos) -- mesma tecnica de
   '.fcsmd-cic-foto'/'.fcsmd-infra-foto': o controle nativo 'width' do
   widget 'image' so mira o <img>, nunca o WRAPPER; aqui o wrapper e um
   filho 'flex_align_items:stretch' do card (settings do PHP), entao so
   precisa travar a altura+object-fit do <img> em si. */
.fcsmd-prog-card-foto img {
  width: 100%;
  height: 162px;
  object-fit: cover;
  display: block;
}

/* Foto circular "Impacto Social" (1:3700, composite achatado
   'pesq-prog-circulo') -- mesma tecnica acima, wrapper ja fixado em
   438x438 via controle nativo (settings do PHP), so o <img> precisa
   preencher 100% aqui. */
.fcsmd-prog-circulo-img img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

/* Cartao "Impacto Social" (1:3693) -- 'backdrop-blur-[5px]' do Figma: sem
   controle nativo equivalente no Elementor Container, aplicado aqui via
   CSS puro (efeito puramente estetico sobre o fundo semi-transparente,
   sem impacto de acessibilidade/conteudo). */
.fcsmd-prog-impacto { -webkit-backdrop-filter: blur(5px); backdrop-filter: blur(5px); }

/* Foto circular (1:3700) e os 2 grafismos (1:3647/1:3683) -- posicionados
   relativo a caixa INTEIRA da secao (1920x1077px no Figma), nao ao
   conteudo boxed (mesmo CRITICAL 2 ja documentado). So a POSICAO
   ('left'/'top') vem daqui -- largura/altura/raio/overflow continuam nos
   controles nativos (settings do PHP), sem risco (a ARMADILHA de offset e
   so dos controles NATIVOS '_offset_x'/'_offset_y' do Elementor, nao de
   CSS puro). */
/* '!important' em toda propriedade de posicao abaixo -- MESMO achado da
   secao 3 (ver comentario longo junto a '.fcsmd-atuacao-grafismo--dir'
   acima): 'position' => 'absolute' sozinho ja gera 'top:0;left:0'
   hardcoded no seletor nativo do Elementor, com especificidade maior que
   uma classe unica minha. Sem '!important' aqui os 4 elementos abaixo
   apareciam todos encostados no canto superior-esquerdo da secao, em vez
   das posicoes do Figma -- so apareceu comparando a captura contra o
   Figma, nao no HTML/JSON cru (settings gravados corretos, so o CSS
   perdia a "queda de braco" de especificidade). */
.fcsmd-prog-circulo-wrap {
  left: 227px !important;
  top: 538.94px !important;
}
.fcsmd-prog-grafismo--esq {
  left: 122px !important;
  top: 559.94px !important;
}
/* Direito (1:3683): so percentuais de inset no Figma ('inset-[2.41%_1.27%_65.84%_89.9%]',
   relativo aos 1920x1077px da secao) -- convertidos aqui pra px:
   top = 2.41% * 1077 = 25.96px; right = 1.27% * 1920 = 24.38px (largura/
   altura finais, ja aplicadas como 'width'/'min_height' nativos no PHP:
   169.54x341.94, calculadas junto com o 'left' original de 1726.08px --
   ver o comentario history no PHP). Ancorado pela DIREITA ('right'), NAO
   pela esquerda: mesmo motivo do grafismo direito da secao 3 (ver
   comentario longo junto a '.fcsmd-atuacao-grafismo--dir' acima) -- um
   'left' fixo calibrado pra 1920px jogava este elemento pra fora da secao
   em larguras mais estreitas (ainda >=1024px, onde continua visivel);
   'right' fixo mantem a mesma distancia da borda direita em qualquer
   largura. 'left:auto!important' evita o par left+right simultaneo
   (mesmo raciocinio do 'top:auto' do grafismo esquerdo da secao 3). */
.fcsmd-prog-grafismo--dir {
  left: auto !important;
  right: 24.38px !important;
  top: 25.96px !important;
}

/* Os 2 niveis dos grafismos rotacionados 90 graus (mesma estrutura do
   proprio Figma: wrapper com a caixa FINAL centralizando via flex + filho
   INTERNO com as dimensoes TROCADAS + o transform -- rotacionar um unico
   elemento ja no tamanho final nao reproduz o resultado, porque a rotacao
   gira o CONTEUDO visual mas nao troca a caixa de LAYOUT do proprio
   elemento). Transformacoes (Global Constraints do plano, conferidas de
   novo em get_design_context nesta task): esq (wrapper Figma
   '-rotate-90 -scale-y-100') = 'rotate(-90deg) scaleY(-1)'; dir (wrapper
   Figma '-rotate-90 -scale-x-100') = 'rotate(-90deg) scaleX(-1)'. */
.fcsmd-prog-grafismo-interno--esq { transform: rotate(-90deg) scaleY(-1); }
.fcsmd-prog-grafismo-interno--dir { transform: rotate(-90deg) scaleX(-1); }

@media (max-width: 1024px) {
  /* Grafismos: puramente decorativos, mesma logica de esconder ja usada
     em '.fcsmd-cic-grafismo'/'.fcsmd-atuacao-grafismo'. */
  .fcsmd-prog-grafismo { display: none; }

  /* Foto circular: e uma FOTO DE CONTEUDO (nao decoracao pura), entao nao
     e escondida -- reflui pro fluxo normal (empilhada ACIMA do cartao
     "Impacto Social", ordem do DOM ja preparada pra isso em
     tools/09-pesquisa-extensao.php: 'foto_circulo' vem logo antes de
     'card_impacto' entre os filhos da secao), centralizada e menor, em
     vez de sobrepor o cartao com coordenadas fixas de desktop (que
     vazariam/deslocariam em qualquer largura menor que 1920px). */
  .fcsmd-prog-circulo-wrap {
    position: static !important;
    width: 220px !important;
    height: 220px !important;
    margin: 0 auto 24px;
  }

  /* Cartao "Impacto Social": sem o circulo sobreposto por cima (regra
     acima), o padding-left de 124px (reservado pro circulo no desktop) e
     o alinhamento 'flex-end' (texto encostado a direita) deixam de fazer
     sentido -- padding uniforme + conteudo centralizado, mesma logica ja
     usada noutros blocos deste site que voltam ao layout empilhado padrao
     abaixo do breakpoint tablet. */
  .fcsmd-prog-impacto {
    padding: 32px 24px !important;
    align-items: center !important;
    text-align: center;
  }
}

/* =====================================================================
   Pagina SETORES (Task S1, tools/10-setores.php). Ver o plano
   `docs/superpowers/plans/2026-08-13-pagina-setores.md`.
   ===================================================================== */

/* Grafismo unico do hero (1:2542) -- posicao em CSS puro (nao os
   controles nativos '_offset_x'/'_offset_y'): mesma ARMADILHA ja
   documentada nos grafismos da Pesquisa e Extensão (offset NAO-ZERO num
   container 'position:absolute' com largura explicita faz o Elementor
   gerar 'left' E 'right' simultaneos). '!important' necessario porque
   'position:absolute' (controle nativo, usado sozinho por ser seguro) ja
   gera 'top:0;left:0' hardcoded no seletor nativo do Elementor, com
   especificidade maior que uma classe unica. Transform: wrapper Figma
   '-scale-y-100 rotate-180' compoe pra scaleX(-1) puro (calculo de
   matriz no comentario de tools/10-setores.php). */
.fcsmd-set-hero-grafismo {
  left: 1384px !important;
  top: 83px !important;
  transform: scaleX(-1);
}

/* Os 2 grafismos da secao "Todos os Setores" (1:2756/1:2769) -- mesma
   logica de posicao em CSS puro. Direito: wrapper '-scale-y-100 rotate-180'
   -> scaleX(-1); esquerdo: wrapper '-scale-y-100' sozinho -> scaleY(-1)
   (flip vertical puro, sem rotacao). */
.fcsmd-set-grafismo--dir {
  left: 1540px !important;
  top: 876px !important;
  transform: scaleX(-1);
}
.fcsmd-set-grafismo--esq {
  left: 0 !important;
  top: -13px !important;
  transform: scaleY(-1);
}

@media (max-width: 1024px) {
  /* Grafismos: puramente decorativos, mesma logica ja usada em
     '.fcsmd-cic-grafismo'/'.fcsmd-atuacao-grafismo'/'.fcsmd-prog-grafismo'. */
  .fcsmd-set-hero-grafismo,
  .fcsmd-set-grafismo {
    display: none;
  }
}

/* Grade 3x3 "Todos os Setores" (div.timeline, 1:2563): bordas entre
   celulas por CSS puro (nth-child), nao os controles nativos de borda do
   Elementor por card -- evitaria 9 configuracoes de borda diferentes so
   pra reproduzir o "sem borda duplicada" que o proprio Figma desenha
   (border-right seletivo nas 2 primeiras colunas + border-top/bottom so
   na linha do meio). Mobile-first: empilhado (1 coluna, cards
   'width_tablet' 100% -- tools/10-setores.php), cada card com
   border-bottom (separador de lista simples), exceto o ultimo. A
   >=1025px (3 colunas, largura fixa dos cards cabe lado a lado) a regra
   muda pro padrao de grade (border-right nas colunas 1-2, border-bottom
   na linha do meio, nth-child(3n)/nth-child(-n+6) sobre os 9 filhos
   diretos). */
.fcsmd-setor-card {
  border-bottom: 1px solid #ECD8CB;
}
.fcsmd-setor-card:last-child {
  border-bottom: none;
}
@media (min-width: 1025px) {
  .fcsmd-setor-card {
    border-bottom: none;
    border-right: 1px solid #ECD8CB;
  }
  .fcsmd-setor-card:nth-child(3n) {
    border-right: none;
  }
  .fcsmd-setor-card:nth-child(-n+6) {
    border-bottom: 1px solid #ECD8CB;
  }
}

/* CORRECAO (Task S2) -- pilula "Acessar →" (1:2589 e irmaos, dentro de cada
   um dos 9 cards de 'fcsmd_set_card_setor()'): renderizava esticada a
   373-374px (92% dos 406px do card) em vez de abracar o texto (~83px no
   Figma). Causa raiz: TODO '.e-con' recebe '--width:100%; width:var(--width)'
   por padrao (ver a regra base '.e-con' em
   wp-content/plugins/elementor/assets/css/frontend.css) -- o UNICO controle
   nativo que sobrescreve isso e' o par 'content_width' => 'full' + 'width'
   (settings do PHP), que este container nunca recebeu (bug de copy-paste do
   padrao do paragrafo irmao, que CORRETAMENTE usa 100%. Ver o comentario
   longo em tools/10-setores.php, fcsmd_set_card_setor()).

   CORRECAO (Task S3, revisao da S2): a regra CSS abaixo ('width: fit-content
   !important') foi REMOVIDA. Ela funcionava, mas '!important' numa folha
   global vence pra sempre qualquer 'width' que um editor futuro tente mudar
   pelo painel do Elementor. O fix definitivo esta' 100% no PHP: o controle
   nativo 'width' do Container aceita 'unit' => 'custom' com uma string
   livre ('width' => ['unit'=>'custom','size'=>'fit-content'] nas settings
   do '$tag', em tools/10-setores.php) -- produz '--width: fit-content;'
   pelo mesmo mecanismo nativo de '$badge'/'$texto', sem CSS solto. */

/* =====================================================================
   Pagina SETORES -- Secao 3, "Setores em destaque" (1:2782, Task S2).
   ===================================================================== */

/* Fundo de 3 camadas (foto + 'rgba(13,58,64,0.8)' multiply + 'rgba(13,58,64,
   0.7)' chapada) -- mesma tecnica ja usada em '.fcsmd-secao-atuacao'
   (Pesquisa e Extensão, ver comentario la): o overlay NATIVO do Elementor
   ('background_overlay_color', settings do PHP) sempre renderiza como
   '::before' do proprio container, garantido pintar logo apos a
   'background-image' e ANTES de qualquer filho real -- soh falta o
   'mix-blend-mode', que o Elementor nao expoe como controle. NAO descartada
   como "aproximacao aceitavel" sem medir (a mesma omissao ja custou
   contraste abaixo do minimo na Pesquisa e Extensão -- licao do plano desta
   pagina); contraste medido depois de aplicar, ver task-S2-report.md. */
.fcsmd-secao-destaque::before {
  mix-blend-mode: multiply;
}
/* 3a camada (chapada) -- FILHO REAL ('$overlay_flat',
   fcsmd_set_secao_destaque()), 'position:absolute' cobrindo a secao inteira
   -- mesma ARMADILHA generica de 'position:absolute' sozinho gerar
   'top:0;left:0' hardcoded (o controle nativo 'position' do Elementor tem
   especificidade maior que uma classe unica), 'right'/'bottom' tambem
   setados (o Elementor so hardcoda 'top'/'left') pra cobrir a secao INTEIRA
   sem depender de nenhum controle nativo de largura/altura. */
.fcsmd-set-destaque-overlay-flat {
  position: absolute !important;
  top: 0 !important;
  left: 0 !important;
  right: 0 !important;
  bottom: 0 !important;
  background-color: rgba(13, 58, 64, 0.7);
  pointer-events: none;
}

/* Carrossel horizontal (div#dcar, 1:2800): scroll nativo -- o controle
   'overflow' do Container so tem Hidden/Visible (sem 'auto'/'scroll'),
   mesma ARMADILHA ja documentada em '.fcsmd-atuacao-carrossel'. */
.fcsmd-destaque-carrossel {
  overflow-x: auto;
  overflow-y: hidden;
}

/* Foto de cada card (238px, borda turquesa, raio 10px, cover) -- '_css_classes'
   trava o WRAPPER do widget 'image' (controle nativo 'width' so mira o
   <img>, ARMADILHA generica do projeto), entao a regra real fica no <img>
   filho. Mesma tecnica de '.fcsmd-conv-foto'/'.fcsmd-infra-foto'
   (Institucional). */
.fcsmd-destaque-card-foto { flex-shrink: 0; }
.fcsmd-destaque-card-foto img {
  width: 100%;
  height: 238px;
  object-fit: cover;
  border-radius: 10px;
  border: 1px solid rgba(0, 204, 189, 0.5);
  display: block;
}

/* Grafismo decorativo (1:2783, 'set-destaque-grafismo'): wrapper Figma
   '-rotate-90 -scale-y-100' -- posicao em CSS puro (mesma ARMADILHA de
   offset nao-zero + largura explicita ja documentada nos grafismos
   anteriores desta pagina), relativa aos 1920x754px da secao INTEIRA (nao
   ao conteudo boxed -- CRITICAL 2). */
.fcsmd-set-destaque-grafismo-wrap {
  left: 23px !important;
  top: 320px !important;
}
.fcsmd-set-destaque-grafismo {
  transform: rotate(-90deg) scaleY(-1);
}

@media (max-width: 1024px) {
  .fcsmd-set-destaque-grafismo-wrap {
    display: none;
  }
}

/* =====================================================================
   Pagina SETORES -- Secao 4, "CPA" (1:2816, Task S2).
   ===================================================================== */

/* Os 2 grafismos decorativos: direito (1:2845) rotacionado -90deg SOZINHO
   (sem scaleY, diferente do grafismo da secao 3 acima); esquerdo (1:2859)
   SEM transformacao nenhuma no wrapper -- soh posicao. Mesma logica de CSS
   puro pra posicao (offset nao-zero + largura explicita). */
.fcsmd-set-cpa-grafismo-dir-wrap {
  left: 1643px !important;
  top: 100.39px !important;
}
.fcsmd-set-cpa-grafismo-dir {
  transform: rotate(-90deg);
}
.fcsmd-set-cpa-grafismo-esq {
  left: -33px !important;
  top: 117.39px !important;
}

@media (max-width: 1024px) {
  .fcsmd-set-cpa-grafismo-dir-wrap,
  .fcsmd-set-cpa-grafismo-esq {
    display: none;
  }
}