﻿/*
  NormaOne — Sidebar principal (ETAPA 4H.33, correção pós-revisão)

  *** ATENÇÃO — DEFEITO REAL ENCONTRADO E CORRIGIDO NESTA REVISÃO: este bloco de comentário estava
  MALFORMADO — havia três marcadores de fechamento de comentário para um único marcador de abertura,
  deixando dois parágrafos inteiros (as antigas "TERCEIRA" e "QUINTA CAUSA RAIZ", inseridas em
  revisões anteriores por edições que quebraram a estrutura do comentário) como TEXTO CSS INVÁLIDO
  fora de qualquer comentário — com um marcador de fechamento solto, sem abertura correspondente.
  Isso é um erro de sintaxe CSS real: dependendo de como o parser do navegador se recupera de um erro
  desses, o conteúdo logo em seguida (que incluía o bloco de variáveis de largura e as regras de
  sincronização da Topbar) podia deixar de ser aplicado — explica por que a Topbar continuava
  desalinhada mesmo com a regra "certa" presente no arquivo (uma busca por texto confirma que os
  bytes estão lá; não confirma que o CSS é válido). Consolidado num único comentário bem formado
  abaixo — nenhum conteúdo foi perdido, só a estrutura foi corrigida. Nota para quem editar este
  comentário no futuro: nunca escrever os dois caracteres de abertura ou fechamento de comentário CSS
  juntos dentro do próprio texto do comentário, nem para descrevê-los — quebra o parser exatamente
  como aconteceu aqui. ***

  Arquivo GLOBAL (sem `::deep`, sem escopo do Blazor) — necessário pelo mesmo motivo documentado em
  `user-menu.css`, mas descoberto aqui numa forma diferente: NÃO é um portal do MudBlazor desta vez,
  é que `::deep` só consegue alcançar elementos DENTRO da própria árvore escopada do componente (isto
  é, descendentes do que o próprio arquivo .razor escreveu literalmente) — nunca um ANCESTRAL de fora
  dela. `.app-sidebar` é a classe no próprio <MudDrawer>, que é renderizado por MudLayout (um
  componente de terceiros) como IRMÃO de <MudAppBar> — nenhum elemento literal de MainLayout.razor
  fica entre os dois na árvore real, então nenhuma regra `::deep .app-sidebar` em
  MainLayout.razor.css jamais conseguia casar (confirmado inspecionando o HTML servido: <aside
  class="... app-sidebar"> nunca carrega nenhum atributo b-xxxxxxx, nem ele nem seus ancestrais).
  Da mesma forma, `.mud-drawer--closed` fica no PRÓPRIO <aside> — um ANCESTRAL de tudo que
  NavMenu.razor escreve, nunca um descendente — então `::deep .mud-drawer--closed .algo` em
  NavMenu.razor.css também nunca casava (a direção do seletor gerado pelo Blazor exige o oposto).

  SEGUNDA CAUSA RAIZ — descoberta ao investigar por que o item ativo/itens "Em breve" não pareciam
  bater com o esperado mesmo com os seletores corretos: `MudBlazor.min.css` carrega DEPOIS do bundle
  escopado deste app (RDOOne.Web.styles.css) no <head>, mas ANTES deste arquivo. Duas
  regras built-in do MudBlazor usam `!important`:
    `.mud-nav-link.mud-nav-link-disabled{color:...!important}` (especificidade 0,2,0)
    `.mud-nav-link.active:not(.mud-nav-link-disabled){font-weight:500!important}` (especificidade 0,3,0)
  Quando a regra deste app tinha a MESMA especificidade e também `!important`, o empate se resolve
  pela ORDEM DE CARREGAMENTO — e como o bundle escopado carregava ANTES do MudBlazor.min.css, o
  MudBlazor vencia esses empates (ex.: cor do item desabilitado voltava para o cinza padrão do
  MudBlazor, não para o branco translúcido pedido aqui). Consolidar essas regras aqui, no arquivo que
  carrega por ÚLTIMO (depois de MudBlazor.min.css), resolve os empates a favor deste app de forma
  definitiva, sem depender de qual arquivo escopado carrega primeiro. Por isso todo o estilo
  interativo dos itens do menu (não só o fundo da sidebar) vive aqui agora, não em NavMenu.razor.css.

  Um arquivo global comum não tem restrição de escopo do Blazor: casa por classe, na árvore real, não
  importa a relação de ancestralidade com o componente que a declarou. Carregado por último em
  App.razor (depois de MudBlazor.min.css, density.css, module-sidebar.css e user-menu.css).

  TERCEIRA CAUSA RAIZ (revisão de largura) — investigando por que a largura visual não batia com o
  parâmetro Width do MudDrawer: o valor realmente aplicado NÃO vem de um atributo style no próprio
  <aside> (confirmado vazio: <aside class="... app-sidebar" style="">) — MudDrawer grava as custom
  properties --mud-drawer-width-left/--mud-drawer-width-mini-left inline no <div class="mud-layout"
  style="--mud-drawer-width-left:...px;...">, um ANCESTRAL de <aside>, e a regra
  `.mud-drawer-mini...{width:var(--mud-drawer-width-left)}` deveria herdar esse valor por cascata
  normal de custom property. Não encontrei nenhuma regra conflitante no MudBlazor.min.css que devesse
  sobrescrever isso — mas para não depender dessa cadeia de herança entre três arquivos CSS diferentes
  (que já se mostrou frágil demais nesta sidebar), a largura passou a ser garantida diretamente aqui.

  QUARTA CAUSA RAIZ (texto "sobrando" no estado recolhido) — o MudBlazor tem uma regra própria para
  esconder o texto do item quando a sidebar recolhe:
    `.mud-drawer--closed.mud-drawer-mini>.mud-drawer-content>.mud-navmenu .mud-icon-root:first-child+.mud-nav-link-text{display:none}`
  Essa regra exige `.mud-drawer-content` como PAI DIRETO (`>`) de `.mud-navmenu`. Só que
  NavMenu.razor insere `.nav-menu-shell` e `.nav-menu-scroll` ENTRE os dois
  (`.mud-drawer-content > .nav-menu-shell > .nav-menu-scroll > ... > .mud-navmenu`) — o seletor do
  MudBlazor nunca bate mais, e o texto de cada item nunca foi escondido de verdade; só ficava cortado
  visualmente pelo `overflow:hidden` do container, que é exatamente o efeito de "texto aparecendo
  parcialmente" relatado. Nunca existiu uma regra PRÓPRIA deste app para `.mud-nav-link-text` — a
  suposição de que o MudBlazor cuidava disso sozinho estava errada. Corrigido com regras explícitas e
  incondicionais (não dependem de nenhuma relação de pai-direto), a única forma correta de garantir
  isso dado que a estrutura teve que ganhar wrappers próprios para o layout da sidebar.

  ÚNICA FONTE DE VERDADE (revisão de proporções) — --nav-width-open/--nav-width-mini abaixo são os
  ÚNICOS lugares onde os números 212px/64px aparecem neste arquivo; toda regra de largura (as próprias
  variáveis herdadas do MudBlazor E os overrides diretos em pixel) referencia essas duas variáveis, em
  vez de repetir o literal. Trocar a largura da sidebar no futuro é mudar só estas duas linhas — nunca
  fica um valor dessincronizado entre MudDrawer, conteúdo principal e AppBar. Os parâmetros
  Width="212px"/MiniWidth="64px" em MainLayout.razor precisam continuar batendo com estes dois
  números manualmente (o Blazor não lê CSS), mas a partir daqui, dentro do CSS, é uma fonte só.

  QUINTA CAUSA RAIZ (desalinhamento Sidebar × Topbar × conteúdo) — o MudBlazor nativo já teria
  sincronizado os três a partir das mesmas variáveis --mud-drawer-width-left/--mud-drawer-width-mini-left
  (confirmado: as regras `.mud-drawer-open-mini-md-left.mud-drawer-left-clipped-never .mud-appbar` e
  `.mud-drawer-close-mini-md-left .mud-main-content` existem e usam exatamente essas variáveis, que já
  estavam redeclaradas corretamente aqui). Duas causas concorrentes foram identificadas e corrigidas:
  (a) `.mud-appbar` e `.mud-main-content` têm `transition:margin 225ms/width 225ms` no MudBlazor.min.css
  — ao carregar a página, a margem/largura desses dois elementos ANIMA por 225ms até o valor final,
  enquanto `.mud-drawer` não tem transição nenhuma e já aparece na posição final instantaneamente,
  criando uma janela onde uma captura de tela mostra a Topbar/conteúdo "atrasados"; (b) o comentário
  malformado descrito no topo deste arquivo — se o parser do navegador não se recuperou corretamente
  do erro de sintaxe, as regras logo abaixo (incluindo estas de sincronização) podiam nunca ter sido
  aplicadas de verdade, independente do que o texto do arquivo dissesse. Corrigidas as duas: transição
  eliminada (sem animação, não há janela para capturar um estado intermediário) E o comentário
  reestruturado para ser sintaticamente válido, garantindo que as regras abaixo sejam efetivamente
  parseadas. Topbar e conteúdo principal também reforçados com `!important`, usando as MESMAS duas
  variáveis --nav-width-open/--nav-width-mini do drawer — os três elementos (drawer, appbar, conteúdo)
  passam a ler literalmente a mesma fonte, sem depender de qual seletor nativo do MudBlazor bate
  primeiro nem de o comentário acima estar bem formado.
*/
:root {
    --nav-width-open: 212px;
    --nav-width-mini: 64px;
    --mud-drawer-width-left: var(--nav-width-open);
    --mud-drawer-width-mini-left: var(--nav-width-mini);
}

/* Sem transição = sem janela de 225ms onde Topbar/conteúdo podem estar visualmente "atrasados" em
   relação à sidebar (que nunca teve transição). Elimina a causa raiz do desalinhamento na origem, em
   vez de só reforçar o valor final. */
.mud-appbar,
.mud-main-content {
    transition: none !important;
}

/* Reforço direto: Topbar e conteúdo principal usando as MESMAS variáveis do drawer, com !important,
   independente de qual seletor nativo do MudBlazor (por breakpoint xs/sm/md/lg/xl/xxl) bate primeiro —
   [class*="..."] casa qualquer um deles sem precisar repetir a regra 6 vezes. */
.mud-layout[class*="mud-drawer-open-mini-"] .mud-appbar,
.mud-layout[class*="mud-drawer-open-mini-"] .mud-main-content {
    margin-left: var(--nav-width-open) !important;
}

.mud-layout[class*="mud-drawer-open-mini-"] .mud-appbar {
    width: calc(100% - var(--nav-width-open)) !important;
}

.mud-layout[class*="mud-drawer-close-mini-"] .mud-appbar,
.mud-layout[class*="mud-drawer-close-mini-"] .mud-main-content {
    margin-left: var(--nav-width-mini) !important;
}

.mud-layout[class*="mud-drawer-close-mini-"] .mud-appbar {
    width: calc(100% - var(--nav-width-mini)) !important;
}

/* Cores da sidebar. O azul-marinho vem do tema (DrawerBackground em AppTheme.cs); o item ativo deixou
   de ser um bloco azul cheio e passou a ser fundo translúcido com uma barra de 3px à esquerda na cor de
   ação clareada — o bloco cheio competia com os botões da tela pela mesma cor. O quadrado da marca
   ("R") usa a cor de ação do tema. */
.app-sidebar {
    --sidebar-bg: var(--mud-palette-drawer-background, #0B2038);
    --sidebar-bg-elevated: rgba(255, 255, 255, 0.08);
    --sidebar-active-bg: rgba(255, 255, 255, 0.10);
    --sidebar-active-bar: #60A5FA;
    --sidebar-marca-bg: var(--mud-palette-primary, #2563EB);
    --sidebar-text: rgba(255, 255, 255, 0.92);
    --sidebar-text-muted: rgba(255, 255, 255, 0.55);
    --sidebar-border: rgba(255, 255, 255, 0.08);

    background-color: var(--sidebar-bg);
    border-right: none;
    box-shadow: 1px 0 4px rgba(17, 24, 39, 0.18);
}

.app-sidebar.mud-drawer--open {
    width: var(--nav-width-open) !important;
    min-width: var(--nav-width-open) !important;
    max-width: var(--nav-width-open) !important;
}

.app-sidebar.mud-drawer--closed {
    width: var(--nav-width-mini) !important;
    min-width: var(--nav-width-mini) !important;
    max-width: var(--nav-width-mini) !important;
}

/* Estado recolhido (DrawerVariant.Mini com _drawerOpen=false → .mud-drawer--closed no próprio
   <aside>). Nada aqui depende de o MudBlazor esconder texto sozinho — ver quarta causa raiz acima:
   toda a remoção de texto neste estado é explícita e incondicional (display:none, nunca
   opacity/visibility, que deixariam a área ainda reservada no layout). */
.mud-drawer--closed .nav-menu-logo {
    align-items: center;
    padding-left: 0;
    padding-right: 0;
}

/* Sem versão compacta sensata para o wordmark (imagem larga, 6:1) — some no estado recolhido e dá
   lugar ao "N" de sempre (.nav-menu-logo-mini, ver NavMenu.razor.css: escondido por padrão). Bloco de
   marca não tem mais texto nenhum (nome/subtítulo removidos do markup nesta revisão — pedido
   explícito); textos da ajuda e nome/versão do rodapé continuam escondidos aqui. */
.mud-drawer--closed .nav-menu-logo-marca-img,
.mud-drawer--closed .nav-menu-ajuda-textos,
.mud-drawer--closed .nav-menu-rodape-nome,
.mud-drawer--closed .nav-menu-rodape-versao {
    display: none;
}

.mud-drawer--closed .nav-menu-logo-mini {
    display: flex;
}

/* Caixa de ajuda recolhida: só o ícone, centralizado, em uma área aproximadamente quadrada — mesmo
   tratamento dado aos itens do menu logo abaixo. */
.mud-drawer--closed .nav-menu-ajuda {
    justify-content: center;
    margin-left: 10px;
    margin-right: 10px;
    padding-left: 0;
    padding-right: 0;
}

.mud-drawer--closed .nav-menu-rodape {
    padding-left: 4px;
    padding-right: 4px;
}

/* Texto de cada item (PAINEL, COLABORADORES, NR-10...) e seta de expandir/recolher grupo — nunca
   escondidos automaticamente pelo MudBlazor nesta estrutura (ver quarta causa raiz). display:none
   incondicional: remove completamente do layout, não deixa nenhuma área reservada nem texto cortado
   visualmente por overflow. */
.mud-drawer--closed .mud-nav-link-text,
.mud-drawer--closed .mud-nav-link-expand-icon {
    display: none !important;
}

/* Ícone sozinho, centralizado numa área quadrada (~44px de lado dentro dos 64px da sidebar recolhida,
   descontada a margem lateral de 10px repetida do estado aberto) — sem padding lateral competindo com
   a centralização, sem encostar na borda por causa da margem. Item 5 do pedido do usuário: nada nesta
   regra ou nas duas seguintes mudou nesta revisão — só os números de largura em .app-sidebar acima. */
/* Mesma correção de especificidade da regra .app-sidebar .mud-nav-link (ver nota mais abaixo, terceira
   rodada): sem !important aqui, a regra nativa .mud-nav-group * .mud-navmenu .mud-nav-item .mud-nav-link
   (padding-left:36px, especificidade 0,4,0) também venceria no estado recolhido — o ícone nunca
   ficaria realmente centralizado (padding-left:36px real vs padding-right:0 real, apesar de
   justify-content:center). Não é uma mudança de comportamento visado — 0 sempre foi a intenção aqui;
   isso só garante que o valor pretendido realmente vence. */
.mud-drawer--closed .mud-nav-link {
    justify-content: center;
    padding-left: 0 !important;
    padding-inline-start: 0 !important;
    padding-right: 0;
}

/* Sem indentação extra de subitem no estado recolhido — todos os ícones centralizados na mesma
   coluna, independente de estarem dentro de um MudNavGroup ou não. */
.mud-drawer--closed .mud-nav-group .mud-nav-link {
    margin-left: 10px;
    margin-right: 10px;
}

/* --- Itens do menu (MudNavLink/MudNavGroup) — consolidados aqui, ver nota acima --- */

/* ETAPA 4H.33 (revisão) — terceira rodada: a causa raiz real de o ícone continuar longe da borda,
   apesar do ajuste anterior, é uma regra NATIVA do MudBlazor com especificidade maior que a minha:
     .mud-nav-group * .mud-navmenu .mud-nav-item .mud-nav-link { padding-left:36px; padding-inline-start:36px; ... }
   4 seletores de classe (0,4,0) — é a indentação padrão do MudBlazor para item de 1 nível dentro de
   grupo, e bate com a estrutura real de QUALQUER item nosso (.mud-nav-group > ... > .mud-navmenu >
   .mud-nav-item > .mud-nav-link). Minha regra anterior (.app-sidebar .mud-nav-group .mud-nav-link,
   0,3,0 — só 3 classes) tinha especificidade MENOR, então nunca vencia de verdade: o padding-left real
   sempre foi 36px do MudBlazor, não os 8px que eu vinha ajustando — o ícone nunca se moveu.
   `!important` abaixo resolve isso de forma definitiva, independente de contagem de classes; também
   sobrescrevo `padding-inline-start` explicitamente (a MESMA borda física em LTR, que o MudBlazor
   também define — sem sobrescrever essa também, ela concorre com padding-left na mesma resolução de
   cascata e podia continuar vencendo mesmo com o padding-left físico corrigido). */
.app-sidebar .mud-nav-link {
    border-radius: 10px;
    margin-top: 2px;
    margin-bottom: 2px;
    margin-left: 8px;
    margin-right: 10px;
    min-height: 40px;
    padding-top: 8px;
    padding-bottom: 8px;
    padding-left: 8px !important;
    padding-inline-start: 8px !important;
    padding-right: 14px;
    font-size: 13px;
    gap: 10px;
    align-items: center;
    color: var(--sidebar-text, rgba(255, 255, 255, 0.92)) !important;
}

.app-sidebar .mud-nav-link .mud-nav-link-text {
    text-align: left;
    white-space: normal;
    line-height: 1.3;
    text-transform: uppercase;
}

.app-sidebar .mud-nav-link .mud-icon-root {
    font-size: 19px;
    color: inherit;
}

.app-sidebar .mud-nav-link:hover {
    background-color: var(--sidebar-bg-elevated, rgba(255, 255, 255, 0.08));
}

/* Itens "Em breve" (Disabled="true") — legíveis, mas visivelmente mais discretos que os ativos. */
.app-sidebar .mud-nav-link.mud-nav-link-disabled,
.app-sidebar .mud-nav-link.mud-nav-link-disabled .mud-icon-root {
    color: rgba(255, 255, 255, 0.48) !important;
    opacity: 1 !important;
}

/* Todo item real fica dentro de algum MudNavGroup (PRINCIPAL/GESTÃO/CONTROLE/EM BREVE) — esta regra,
   mais específica que a base .app-sidebar .mud-nav-link, é quem de fato vence para eles; precisa do
   MESMO valor de margin-left para o ajuste de posição do ícone (acima) realmente valer para todos os
   itens, não só para um item hipotético fora de qualquer grupo. */
.app-sidebar .mud-nav-group .mud-nav-link {
    margin-left: 8px;
}

/* ETAPA 4H.33 (revisão) — títulos de grupo (PRINCIPAL/GESTÃO/CONTROLE/EM BREVE) escondidos por
   pedido explícito do usuário, em ambos os estados (aberto e recolhido) — antes só sumiam quando
   recolhido.

   CAUSA de uma tentativa anterior não ter funcionado: a classe ".mud-nav-group-title" NÃO EXISTE no
   HTML real desta versão do MudBlazor (confirmado inspecionando a página servida) — o texto do
   cabeçalho de grupo é renderizado dentro de ".mud-nav-link-text", a MESMA classe usada pelo texto de
   qualquer item comum. A distinção real na árvore real é estrutural: o botão de cabeçalho de cada
   grupo é FILHO DIRETO de "nav.mud-nav-group" (`<nav class="mud-nav-group" aria-label="PRINCIPAL">
   <button class="mud-nav-link ...">`), enquanto todo item de verdade (Painel, Colaboradores...) fica
   bem mais fundo, dentro do wrapper de recolhimento do grupo — nunca filho direto. `>` (combinador de
   filho direto) isola exatamente o botão de cabeçalho, sem tocar nos itens.

   display:none no botão inteiro (não só no texto) remove também a seta de expandir/recolher — pedido
   explícito do resultado desejado (nenhuma seta sobrando) — e por tirar o botão da interação, cada
   grupo permanece permanentemente no estado Expanded="true" que já tinha (nunca era alternado por
   nenhum teste/uso até aqui), sem afetar a estrutura lógica do MudNavGroup nem os itens dentro dele
   (ícone, texto, ativo, hover, desabilitado — nada disso muda). */
.app-sidebar .mud-nav-group > .mud-nav-link {
    display: none;
}

/* Item ativo — fundo translúcido de ponta a ponta da sidebar, com a barra de 3px na borda esquerda
   (box-shadow inset, para não deslocar o conteúdo nem mexer no border-radius). !important +
   carregamento por último garante que vence tanto por especificidade quanto por ordem qualquer regra
   built-in do MudBlazor (".mud-nav-link.active{color:var(--mud-palette-primary)...}", sem essa
   garantia o texto renderizaria na cor primária do tema em vez de branco). */
/* Pedido do usuário (após aprovar a posição do ícone): o fundo do item ativo deve cobrir toda a
   largura útil da sidebar, não só o conteúdo (ícone+texto) com respiro nas duas pontas. Zerando
   margin-left/right só PARA O ITEM ATIVO (nunca os inativos) o fundo vai de ponta a ponta; para
   o ícone não se deslocar (ficaria 8px mais à esquerda que os itens inativos, quebrando o alinhamento
   vertical entre eles), o padding-left cresce na mesma medida que a margin-left perdida (8px), e o
   padding-right cresce pela margin-right perdida (10px) — mesma lógica, sem inventar um novo eixo de
   alinhamento. !important necessário pelo mesmo motivo de especificidade documentado nas notas acima
   (a regra nativa do MudBlazor para padding de item dentro de grupo tem 0,4,0; aqui, além dela, ainda
   compete com .app-sidebar .mud-nav-group .mud-nav-link, que é 0,3,0 — mesma especificidade desta
   regra — só !important garante a vitória de forma incondicional). */
.app-sidebar .nav-menu-ativo .mud-nav-link {
    background-color: var(--sidebar-active-bg, rgba(255, 255, 255, 0.10)) !important;
    box-shadow: inset 3px 0 0 0 var(--sidebar-active-bar, #60A5FA);
    border-radius: 0;
    color: #FFFFFF !important;
    font-weight: 600 !important;
    margin-left: 0 !important;
    margin-right: 0 !important;
    padding-left: 16px !important;
    padding-inline-start: 16px !important;
    padding-right: 24px !important;
}

/* CAUSA REAL de o fundo azul continuar sem alcançar a borda direita mesmo com margin-right:0 acima:
   cada item vem envolto em <MudTooltip>, que renderiza <div class="mud-tooltip-root mud-tooltip-inline">
   — e o MudBlazor define, para essa classe, width:auto (a caixa encolhe para caber só o conteúdo, não
   estica para preencher a sidebar). ".mud-nav-link{width:100%}" sempre foi 100% DESSE wrapper
   encolhido, nunca 100% da largura real da sidebar — nenhum ajuste de margin/padding no próprio
   .mud-nav-link poderia ter corrigido isso, porque o problema é uma camada acima. Forçar width:100%
   no wrapper do tooltip (só dentro da sidebar — .app-sidebar escopa isso, sem afetar tooltips em
   qualquer outra tela do app) resolve para todo item, ativo ou não; nos inativos não muda nada
   visualmente (eles continuam com a própria margem/padding de sempre criando o mesmo respiro de
   antes) — só o ativo, com margin:0, agora realmente alcança as duas bordas. */
.app-sidebar .mud-tooltip-root {
    width: 100% !important;
}

.app-sidebar .nav-menu-ativo .mud-nav-link .mud-icon-root {
    color: #FFFFFF !important;
}
