/* Shell-Chrome-Styles der geteilten AppShell (Adepto.UI.Shell) — von BEIDEN Apps geladen
   (Kunden-App + Admin). Hierher extrahiert aus Adepto.UI/wwwroot/css/app.css (Etappe 5),
   damit die Admin-Shell 1:1 identisch rendert. */

/* --- Hauptinhalt: Platz fuer die fixierte Bottom-Nav (Mobile) --- */
/* Die MobileBottomNav ist `fixed bottom-0` (~53px) und ueberlagert den Inhalt -> ohne Reserve wird der
   untere Seiteninhalt (z.B. Team-Mitgliederliste) verdeckt. Nur unter lg (Nav ist lg:hidden);
   + env(safe-area-inset-bottom) fuer Geraete mit Home-Indicator. */
@media (max-width: 1023.98px) {
    .adepto-mobile-navpad {
        /* 4rem statt 3.5rem: deckt die ~53px-Nav auch bei reduzierter Mobile-Root-Schrift (s.u.) ab. */
        padding-bottom: calc(4rem + env(safe-area-inset-bottom));
    }
}

/* --- DataGrid-Toolbar: globales Suchfeld verbreitern (PO-Feedback: zu schmal) --- */
/* Lumeo setzt am <input> direkt `max-w-56` (14rem) - Quelle: Lumeo.DataGrid/UI/DataGrid/
   DataGridToolbar.razor (`<div data-slot="datagrid-toolbar">...<div class="relative">
   <input type="text" class="... max-w-56 ...">`). Der Attribut-Selektor hier hat hoehere
   Spezifitaet als die einzelne Tailwind-Utility-Klasse und gewinnt unabhaengig von der
   Stylesheet-Reihenfolge. Nur der Suchfeld-Input traegt type="text" innerhalb der Toolbar -
   die Filter-Chips daneben sind reine <span>/<button>, kein zweiter Treffer moeglich. */
[data-slot="datagrid-toolbar"] input[type="text"] {
    /* width zusaetzlich zu max-width: der Input ist w-full in einem content-sized Wrapper -
       ein reines max-width-Anheben aendert die tatsaechliche Breite dann nicht (im Browser
       gemessen ~238px). Die feste width zwingt auch den Wrapper auf. */
    width: 18rem;
    max-width: 18rem;
}

/* --- Sidebar-Nav volle Breite --- */
/* Lumeos <Tooltip> rendert einen `relative inline-flex`-DIV (content-breit) um den Trigger. Der
   SidebarMenuButton ist intern zwar w-full, kann diesen content-breiten Tooltip-Wrapper aber nicht
   sprengen -> das Active-Highlight bleibt schmal. Tooltip hat keinen Class-Parameter, daher per CSS:
   den Tooltip-Wrapper der Nav-Items (Marker .adepto-nav an der SidebarMenu-<ul>) auf volle Breite. */
.adepto-nav > li > .relative.inline-flex {
    display: flex;
    width: 100%;
}

/* Horizontale Trenner (Sidebar-Header, Sidebar-Footer/Account, Folder-Header, Trash-Footer)
   nicht ganz durchziehen ("weniger blocky"): Linie links/rechts 0.75rem eingerueckt statt randlos
   bis an die vertikalen Spalten-Trenner - die Trennung bleibt sichtbar, die Ecken wirken weicher.
   Die vertikalen Spalten-Linien (border-r) bleiben voll durchgezogen wie in der Referenz. */
.inset-divider-b {
    position: relative;
}
.inset-divider-b::after {
    content: "";
    position: absolute;
    left: 0.75rem;
    right: 0.75rem;
    bottom: 0;
    height: 1px;
    background: var(--color-border);
    pointer-events: none;
}
.inset-divider-t {
    position: relative;
}
.inset-divider-t::after {
    content: "";
    position: absolute;
    left: 0.75rem;
    right: 0.75rem;
    top: 0;
    height: 1px;
    background: var(--color-border);
    pointer-events: none;
}

/* WASM-Boot-Splash: Adepto-Logo + Fortschrittsbalken (Etappe 5.1, aus Kunden-app.css hierher
   verschoben, da BEIDE Apps denselben Splash nutzen - Single Source fuer die geteilte Shell). */
.adepto-splash {
    position: fixed;
    inset: 0;
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: 1.5rem;
    background: var(--color-background);
}

.adepto-splash-logo {
    height: 56px;
    width: auto;
}

.adepto-splash-bar {
    width: 200px;
    height: 3px;
    background: var(--color-muted);
    border-radius: 999px;
    overflow: hidden;
}

.adepto-splash-bar-fill {
    height: 100%;
    width: var(--blazor-load-percentage, 5%);
    background: var(--color-primary);
    transition: width 0.2s ease-out;
}

/* Unsaved-Changes-Bar (Discord-Muster, Portal-Savebar-Etappe): Basis-Position + Einblend-Keyframe -
   von Adepto.UI/wwwroot/css/app.css hierher verschoben, da BEIDE Apps (Kunden-App + Admin-Portal) die
   UnsavedChangesBar/UnsavedChangesTracker jetzt aus Adepto.UI.Shell nutzen (siehe dortige Klassen-
   Kommentare). Als eigene Klasse statt bottom-[calc(...)]-Utility, weil die Tailwind-CLI die
   calc()+env()-Kombination nicht generiert (gleiche Falle wie bei .adepto-mobile-navpad).
   Die MOBILE Sonderposition (ueber der fixierten Bottom-Nav) bleibt bewusst in Adepto.UI/wwwroot/
   css/app.css: nur die Kunden-App hat eine MobileBottomNav, das Admin-Portal nicht - dort gilt daher
   auch mobil die Desktop-Position (kein Override noetig). */
.adepto-unsaved-bar {
    bottom: 1.5rem;
}

@keyframes unsaved-bar-in {
    from {
        opacity: 0;
        transform: translateY(0.75rem);
    }
    to {
        opacity: 1;
        transform: translateY(0);
    }
}

/* Chromium-Repaint-Artefakt bei fraktionalem DPR (Windows-Skalierung 125/150%): beim
   Weganimieren von border-/outline-color bleiben Haarlinien-Reste des Fokus-Rings stehen
   (teils ausserhalb der Border-Box). Fokus ist ein diskreter Zustand - Transition auf
   Rahmenfarben von Form-Controls bringt nichts und provoziert nur das Artefakt. */
input:not([type="checkbox"]):not([type="radio"]),
textarea {
    transition-property: color, background-color;
}

/* Lumeo-Bug (mind. seit 4.1.0-preview.4, weiterhin in 4.2.0): lumeo.css setzt fuer JEDES <form>,
   das direktes Kind eines role="dialog"-Overlays ist, `flex: 1 1 0` (Kommentar dort:
   "EditForm-in-Sheet/Dialog flex compatibility" - Zweck: Footer soll in Sheet/Dialog unten pinnen).
   Sheet und Dialog haben dafuer immer eine DEFINITE Hoehe (volle Sheet-Seite bzw. Dialog max-height) -
   Drawer aber nicht: Drawer sized to content (h-auto, nur mit max-h-[96vh] gedeckelt; laut Lumeo-Doku
   "Drawer sizes to its content and ignores [Size]"). flex-basis:0 in einem h-auto-Flex-Container hat
   nichts zum Messen -> das <form> (und damit der gesamte sichtbare Inhalt) kollabiert auf ~0px Hoehe;
   sichtbar bleibt nur der oberste Drag-Handle-Balken (~30px) - der Drawer wirkt komplett leer/unsichtbar.
   Reproduziert + verifiziert per Live-Browser-Test an "Vertrieb kontaktieren" (Adepto.UI, Abrechnung ->
   Overlay.ShowDrawerAsync<EnterpriseInquiryForm> + OverlayPresets.DrawerForm): Panel-Hoehe 30px ohne
   Fix, 373px mit Fix (kurzer Inhalt) bzw. korrekt an 96vh gedeckelt + intern scrollend (Body flex-1
   min-h-0 overflow-y-auto) bei >2000px langem Test-Inhalt.
   Fix: flex-basis zurueck auf `auto` (= Content-Groesse), NUR fuer Drawer (Sheet/Dialog behalten den
   Original-Fix, den sie fuer ihre definite Hoehe weiterhin brauchen). grow:1/shrink:1 bleiben, damit
   ueberlanger Inhalt weiterhin korrekt an max-h-[96vh] gedeckelt wird statt den Drawer zu sprengen.
   shell.css laedt nach lumeo.css -> gleiche Selektor-Spezifitaet, spaetere Regel gewinnt per
   Kaskaden-Reihenfolge (kein !important noetig). Entfernen, sobald Lumeo das nativ fixt. */
[role="dialog"][id^="drawer-"] > form {
    flex: 1 1 auto;
}

/* Mike-Fund 2026-07-22 (Portal-Sidebar H-Scrollbar beim Expanden): Lumeos SidebarContent hat
   overflow-auto auf beiden Achsen. Wird die Nav-Liste hoeher als der Platz (seit den Gruppen-Labels
   moeglich), erscheint die V-Scrollleiste, nimmt Breite weg und die w-full-Eintraege erzeugen einen
   H-Overflow von exakt Leistenbreite. Fix: horizontal hart abschneiden.
   Mike-Fund 2026-07-23 (Icon-Rail schneidet Icons ab, Variant=Icon/eingeklappt): der erste Fix
   reservierte per `scrollbar-gutter: stable` dauerhaft eine Rinne fuer die V-Leiste - in der schmalen
   Icon-Rail (kein Platz fuer Gruppen-Labels-Overflow im Normalfall, aber bei hohem Viewport-Inhalt
   trotzdem V-Overflow moeglich) frisst diese Rinne plus die ggf. sichtbare V-Leiste selbst Breite von
   der Rail und schneidet die Icons rechts ab. Robusterer Fix: keine Rinne reservieren, sondern die
   V-Leiste selbst unsichtbar machen (Inhalt bleibt per Mausrad/Touch scrollbar) - dann kann in keinem
   der beiden Sidebar-Zustaende (expandiert/Icon) Breite verloren gehen. Laedt NACH tailwind.css
   (Link-Reihenfolge beider index.html) -> gewinnt bei gleicher Spezifitaet. */
.adepto-sidebar-content {
    overflow-x: hidden;
    scrollbar-width: none;
}
.adepto-sidebar-content::-webkit-scrollbar {
    display: none;
}

/* Mike-Fund 2026-08-25 (Portal, Dialog "Neue Rabatt-Aktion"): das rechte der beiden Datumsfelder
   ragte ueber den Dialogrand hinaus. GEMESSEN im laufenden Portal: die Grid-Spalte ist 221px breit,
   der DatePicker darin 234px - er sitzt in einem `inline-block`-Wurzelelement mit einem
   `inline-flex`-Ausloeser, beide sizen also auf ihre INHALTSBREITE und ignorieren die Spalte. Die
   Inhaltsbreite kommt vom eingebetteten `<input type=text>` (Browser-Standard ~192px) plus
   Innenabstand und Kalender-Symbol. Lumeo 5.0.0 hat den Ausloeser auf eine eigene Flex-Zeile
   umgestellt ('group flex h-8 w-full items-center rounded-md border ...', in 4.3.3 nicht vorhanden) -
   das `w-full` darin zeigt, dass der Ausloeser die Spalte FUELLEN soll; nur die beiden
   content-sizenden Huellen darueber lassen das nicht zu.
   Die Kunden-App hat dafuer laengst eine Loesung (Adepto.UI/wwwroot/css/app.css, Klasse `adepto-dp`,
   dort fuer Zertifikats-/Team-Formulare). Sie steht hier NOCH EINMAL, weil sie ins geteilte shell.css
   gehoert: das Portal laedt app.css der Kunden-App nicht. Die dortige Kopie bleibt vorerst
   unveraendert stehen (identische Deklarationen, daher wirkungsgleich) - sie zu entfernen waere eine
   Aenderung an der Kunden-App, die zu diesem Fund nicht gehoert.
   WICHTIG (aus dem dortigen Kommentar uebernommen und hier nachgeprueft): Lumeo legt die
   DatePicker-`Class` auf den AUSLOESER, nicht auf die Wurzel - also KEIN `display` setzen (der
   Ausloeser muss flex bleiben, sonst stapeln sich Eingabefeld und Symbol untereinander), nur
   schrumpfbar machen. Die beiden content-sizenden Huellen per :has() auf volle Spaltenbreite ziehen. */
.adepto-dp {
    min-width: 0;
}

.adepto-dp input {
    min-width: 0;
}

.inline-flex:has(> .adepto-dp) {
    display: flex;
    width: 100%;
    min-width: 0;
}

.inline-block:has(> .inline-flex > .adepto-dp) {
    display: block;
    width: 100%;
}

/* Mike-Fund 2026-08-25 (Portal, /bewerbungen/{id}): "der Title Text pro card ist zu nah am card top".
   GEMESSEN im laufenden Portal: die Karte selbst hat KEINEN Innenabstand (padding 0), ihr
   Inhaltsbereich (Lumeos CardContent) traegt `p-6 pt-0` - also 24px links/rechts/unten, aber 0 oben.
   Das ist ABSICHT der Bibliothek und in BEIDEN Versionen gleich (CardContent-Doku 4.3.3 und 5.0.0
   wortgleich: "rendered below the header ... but no top padding (it abuts CardHeader's bottom
   spacing)"). Es ist also KEIN 5.0.0-Rueckschritt: CardContent setzt voraus, dass eine CardHeader
   darueber steht und den oberen Abstand liefert. Zur Gegenprobe an einer Karte MIT CardHeader
   gemessen (/finanzen): dort hat die Kopfzeile 'flex flex-col space-y-1.5 p-6' und oben korrekte 24px.
   Betroffen sind genau die Karten, die - wie ApplicationDetailPage und weitere Portalseiten - ohne
   CardHeader gebaut sind und ihre Ueberschrift direkt in den Inhaltsbereich legen: deren erste Zeile
   klebt dann an der Kartenkante.
   Zentraler Fix statt Karte-fuer-Karte: nur wenn der Inhaltsbereich das ERSTE Kind der Karte ist
   (:first-child = keine CardHeader davor), bekommt er seinen oberen Abstand zurueck - passend zu dem
   Wert, den er seitlich ohnehin schon hat. Karten MIT CardHeader treffen die Regel nicht und bleiben
   unveraendert (kein doppelter Abstand). Alle drei Dichtestufen abgedeckt, die Lumeo fuer
   CardContent kennt (p-4/p-6/p-8). shell.css laedt nach lumeo.css - die zusaetzliche Klasse und
   :first-child machen die Regel ohnehin spezifischer als Lumeos einzelnes `.pt-0`.
   Sauberere Alternative fuer spaeter (bewusst NICHT in diesem Durchgang): die betroffenen Seiten auf
   <CardHeader><CardTitle> umstellen - das waere die von der Bibliothek vorgesehene Struktur, betrifft
   aber viele Dateien und mehr als den gemeldeten Fund. */
.rounded-xl.bg-card > .p-4.pt-0:first-child { padding-top: 1rem; }
.rounded-xl.bg-card > .p-6.pt-0:first-child { padding-top: 1.5rem; }
.rounded-xl.bg-card > .p-8.pt-0:first-child { padding-top: 2rem; }