/* ==========================================================================
   TelRadKo Intranet — Bridge

   Bildet die im Bestand verwendeten Tailwind-Utilities auf Design-Tokens
   ab. Dadurch erben alle 190 Templates die Theme-Farben, ohne dass eine
   einzige Utility-Klasse aus einem Template entfernt werden muss.

   Nachfolger von dark.css. Der Unterschied: die Regeln gelten fuer BEIDE
   Themes. Im hellen Theme liefert --panel Weiss, die Regel ist dort also
   wirkungslos; im dunklen liefert sie #161b22.

   Warum !important:
   Das Tailwind-CDN erzeugt seine Regeln zur Laufzeit im Browser und fuegt
   sie in ein <style>-Element ein. Die Reihenfolge gegenueber diesem
   Stylesheet ist nicht garantiert. Bei gleicher Spezifitaet entschiede
   sonst der Zufall. Das ist Notwendigkeit, nicht Bequemlichkeit.

   Achtung Deckkraft-Varianten:
   Tailwind erzeugt fuer bg-gray-50/50 die Klasse .bg-gray-50\/50 — einen
   ANDEREN Klassennamen als .bg-gray-50. Jede Variante muss einzeln
   aufgefuehrt werden. tests/test_theme_bridge.py prueft das (Scan ueber
   alle Templates + Abgleich gegen diese Datei).

   Farblogik fuer die semantischen Familien:
   grün/emerald/lime            -> --ok     (+ --ok-soft, --ok-fill)
   gelb/amber/orange            -> --warn   (+ --warn-soft, --warn-fill)
   rot/rose/pink                -> --err    (+ --err-soft, --err-fill)
   blau/purple/indigo/sky/      -> --accent (+ --accent-soft, --accent-fill)
   violet/cyan/teal
   "Blau" & Co. waren nie eine bewusste Markenfarbe, sondern
   Tailwind-Standard; sie werden auf den Petrol-Akzent der Marke
   vereinheitlicht.

   Stufenlogik (Fix-Runde 1, Befund 6 — gilt jetzt fuer bg UND border
   gleichermassen):
     Stufen 50/100/200  -> *-soft   (helle Flaeche / blasser Rahmen)
     Stufen 300 aufwaerts -> Basis-Token (Text, Rahmen ab 300)
     Gesaettigte Flaechen (Buttons/Badges mit weissem Text, ca. ab 400) ->
       *-fill-Token (Befund 3) statt Basis-Token, weil die Basisfarben im
       dunklen Theme als HELLE Vordergrundfarben definiert sind und als
       Flaeche unter weissem Text den Kontrast nicht schaffen.
   Hover/Active auf gesaettigten Flaechen liegt auf eigenen *-fill-hover-
   Tokens (Fix-Runde 2, Schaden 1), NICHT auf einem filter:brightness:
   ein Bildfilter faerbt den weissen Beschriftungstext im Button mit ein
   und unterlaeuft dadurch selbst den geforderten Kontrast (im hellen
   Theme gemessen 4.66:1 statt der berechneten 5.85:1 — schlechter als der
   Ruhezustand). Siehe Abschnitt "Gesaettigte Flaechen" unten.

   Fix-Runde 2, Schaden 2: die dunklen *-fill-Werte muessen zusaetzlich
   zum Text-Kontrast (>=4.5:1) auch >=3:1 gegen die umgebende --panel-
   Flaeche erreichen (WCAG 1.4.11) — dieselben Flaechen dienen auch als
   Fortschrittsbalken, Diagrammbalken und Ampelpunkte OHNE Text. Die
   genaue Rechnung (Leuchtdichte-Fenster 0.132-0.183) steht in tokens.css
   bei den dunklen *-fill-Werten.
   ========================================================================== */

/* ── Flaechen: Neutral ──────────────────────────────────────────────────── */
.bg-white                        { background-color: var(--panel)    !important; }
.bg-gray-50,
.bg-gray-100,
.bg-gray-50\/40,
.bg-gray-50\/50,
.bg-gray-50\/60                  { background-color: var(--panel-2)  !important; }
.bg-gray-200                     { background-color: var(--panel-2)  !important; }
.bg-gray-300                     { background-color: var(--line-strong) !important; }

/* Immer-dunkle Flaechen (Buttons/Tooltip/Viewer): funktionieren bereits
   heute in beiden Themes unveraendert richtig (dunkler Knopf auf hellem
   ODER dunklem Panel ist ausreichend Kontrast). Hier bewusst auf den
   Original-Tailwind-Wert FIXIERT statt auf ein Token gelegt — anders als
   bg-black (AUSNAHMEN) brauchen wir hier trotzdem eine echte Regel, weil
   der Abdeckungstest die Klasse verlangt. */
.bg-gray-700                     { background-color: #374151 !important; }
.bg-gray-800                     { background-color: #1f2937 !important; }
.bg-gray-900                     { background-color: #111827 !important; }

/* ── Text: Neutral ──────────────────────────────────────────────────────── */
.text-gray-900,
.text-gray-800,
.text-gray-700                   { color: var(--ink)   !important; }
.text-gray-600,
.text-gray-500                   { color: var(--ink-2) !important; }
.text-gray-400,
.text-gray-300                   { color: var(--ink-3) !important; }

/* ── Rahmen und Trenner: Neutral ────────────────────────────────────────── */
.border-gray-50,
.border-gray-100,
.border-gray-200,
.border-gray-300                 { border-color: var(--line) !important; }
.border-gray-400,
.border-gray-700                 { border-color: var(--line-strong) !important; }
.divide-gray-100 > :not([hidden]) ~ :not([hidden]),
.divide-gray-200 > :not([hidden]) ~ :not([hidden]) { border-color: var(--line) !important; }

/* Aktiver Tab-Indikator in der (immer dunkelblauen) Marken-Nav: bleibt
   fixiert weiss, analog zu text-white in AUSNAHMEN — dieselbe Rolle
   (Text/Rahmen auf farbiger Flaeche), nur als border- statt als
   text-Utility. Bewusst NICHT in AUSNAHMEN aufgenommen (Auftrag: Liste
   nicht erweitern), sondern als echte, wertgleiche Regel formuliert. */
.border-white                    { border-color: #ffffff !important; }

/* ── Hover/Focus: Neutral ───────────────────────────────────────────────── */
.hover\:bg-gray-50:hover,
.hover\:bg-gray-50\/60:hover,
.hover\:bg-gray-100:hover,
.hover\:bg-gray-200:hover,
.hover\:bg-white:hover,
.focus\:bg-white:focus           { background-color: var(--panel-2) !important; }
.hover\:bg-gray-300:hover        { background-color: var(--line-strong) !important; }

/* hover:bg-white steht im Bestand ausnahmslos zusammen mit focus:bg-white
   auf denselben Elementen: den randlosen Inline-Eingabefeldern in Tarif-
   und Klinik-Tabellen (bg-transparent hover:bg-white hover:border
   focus:bg-white focus:border-gray-300). Beide markieren "dieses Feld ist
   editierbar", indem sich das Feld aus der Zeile heraushebt. Deshalb
   dieselbe Zuordnung wie focus:bg-white — NICHT --panel wie die nackte
   Klasse .bg-white: die Zeile liegt bereits auf einer --panel-Karte, ein
   Wechsel auf --panel waere im hellen Theme voellig unsichtbar. */

/* ── Deaktivierte Zustaende ─────────────────────────────────────────────
   Fix-Runde 2, Schaden 3: die Variante disabled: (20 Vorkommen) hat der
   alte Abdeckungstest ueberhaupt nie gesehen — er schnitt Varianten ab.
   Dadurch blieben deaktivierte Felder und Knoepfe im dunklen Theme in
   Tailwind-Grau stehen, also hell leuchtend auf dunklem Grund.
   Jeweils dieselbe Zuordnung wie der nackte Klassenname weiter oben.

   Fuer disabled:bg-gray-300 gilt das auch dann, wenn der Knopf weissen
   Text traegt (3 Fundstellen, u.a. "Monat abschliessen"): --line-strong
   ergibt im hellen Theme nur 1.5:1 gegen weiss — das ist so gewollt und
   war schon mit dem Tailwind-Original so. WCAG 1.4.3 nimmt inaktive
   Bedienelemente ausdruecklich vom Kontrastziel aus; "nicht anklickbar"
   IST hier die Botschaft. */
.disabled\:bg-gray-50:disabled,
.disabled\:bg-gray-100:disabled  { background-color: var(--panel-2) !important; }
.disabled\:bg-gray-300:disabled  { background-color: var(--line-strong) !important; }
.disabled\:text-gray-500:disabled { color: var(--ink-2) !important; }
.disabled\:text-gray-400:disabled { color: var(--ink-3) !important; }
.hover\:bg-gray-800:hover        { background-color: #1f2937 !important; }
.hover\:border-gray-300:hover,
.focus\:border-gray-300:focus    { border-color: var(--line) !important; }
.hover\:border-gray-400:hover    { border-color: var(--line-strong) !important; }
.hover\:text-gray-600:hover      { color: var(--ink-2) !important; }
.hover\:text-gray-700:hover      { color: var(--ink)   !important; }

/* ── Semantische Tints: helle Flaechen (Badges, Banner, Callouts) ────────
   Acht dieser Klassen (bg-yellow-50/40, bg-red-50/40, bg-green-50/30,
   bg-blue-50/30, bg-amber-50/40, bg-emerald-50/40, bg-gray-50/40 [oben])
   behandelte dark.css bisher gar nicht — im dunklen Theme standen sie als
   grelle helle Flecken. Hier vollstaendig geschlossen, inkl. aller
   uebrigen im Bestand verwendeten Deckkraft- und Stufen-Varianten. */
.bg-green-50,
.bg-green-50\/30,
.bg-green-50\/40,
.bg-green-100,
.bg-green-200,
.bg-emerald-50,
.bg-emerald-50\/40,
.bg-emerald-100                  { background-color: var(--ok-soft)   !important; }

.bg-yellow-50,
.bg-yellow-50\/30,
.bg-yellow-50\/40,
.bg-yellow-100,
.bg-yellow-200,
.bg-yellow-400,
.bg-amber-50,
.bg-amber-50\/40,
.bg-amber-100,
.bg-amber-200,
.bg-orange-50,
.bg-orange-100                   { background-color: var(--warn-soft) !important; }
/* Hover einer bernsteinfarbenen Zeile in der Uebergabe-Liste. Wird in
   index.html aus JavaScript zusammengesetzt und stand deshalb bis
   Fix-Runde 2 ausserhalb des Blickfelds. Die Zeile traegt im Ruhezustand
   schon bg-amber-100; der Hover war im Bestand dieselbe Farbe und bleibt
   es — hier wird nichts an der Gestaltung entschieden, nur die vorhandene
   Farbe auf ihr Token gelegt. */
.hover\:bg-amber-100:hover       { background-color: var(--warn-soft) !important; }
/* bg-yellow-400 gehoert inhaltlich zur "-500"-Stufe (saettigter), steht
   im Bestand aber ausschliesslich als Badge-Hintergrund neben
   text-yellow-900 (Nav-Macro "inaktiv"). Nur im --warn-soft/--warn-Paar
   ergibt sich in BEIDEN Themes ausreichend Kontrast — mit --warn waere
   Hintergrund- und Textfarbe identisch (siehe Bericht Task 3). */

.bg-red-50,
.bg-red-50\/40,
.bg-red-100,
.bg-red-200,
.bg-rose-50,
.bg-rose-100,
.bg-rose-200                     { background-color: var(--err-soft)  !important; }

.bg-blue-50,
.bg-blue-50\/30,
.bg-blue-50\/50,
.bg-blue-100,
.bg-blue-200,
.bg-purple-50,
.bg-purple-100,
.bg-indigo-50,
.bg-indigo-100,
.bg-violet-50,
.bg-cyan-50,
.bg-sky-50                       { background-color: var(--accent-soft) !important; }

.hover\:bg-green-50:hover,
.hover\:bg-green-100:hover,
.hover\:bg-green-200:hover       { background-color: var(--ok-soft)   !important; }
.hover\:bg-yellow-50:hover,
.hover\:bg-yellow-50\/40:hover,
.hover\:bg-yellow-100:hover,
.hover\:bg-yellow-200:hover,
.hover\:bg-amber-50:hover,
.hover\:bg-amber-200:hover,
.hover\:bg-orange-50:hover       { background-color: var(--warn-soft) !important; }
.hover\:bg-red-50:hover,
.hover\:bg-red-100:hover,
.hover\:bg-red-200:hover,
.hover\:bg-rose-50:hover,
.hover\:bg-rose-200:hover        { background-color: var(--err-soft)  !important; }
.hover\:bg-blue-50:hover,
.hover\:bg-blue-100:hover,
.hover\:bg-blue-200:hover        { background-color: var(--accent-soft) !important; }

/* ── Semantische Flaechen: gesaettigt (Buttons, Legenden-Punkte) ─────────
   Auf *-fill statt Basis-Token (Befund 3): --ok/--warn/--err/--accent
   sind im dunklen Theme helle Vordergrundfarben (fuer Text/Icons gedacht)
   und erreichen als Flaeche unter weissem Text keinen ausreichenden
   Kontrast (gemessen 2.14 - 3.62:1, siehe Bericht). Die *-fill-Tokens
   sind eigens fuer diese Rolle in tokens.css angelegt. */
.bg-green-500,
.bg-green-600,
.bg-green-700,
.bg-green-800,
.bg-emerald-500,
.bg-emerald-600,
.bg-emerald-700                  { background-color: var(--ok-fill)    !important; }
.bg-amber-400,
.bg-amber-500                    { background-color: var(--warn-fill)  !important; }
.bg-orange-500,
.bg-orange-600                   { background-color: var(--warn-fill)  !important; }
.bg-red-500,
.bg-red-600,
.bg-red-700                      { background-color: var(--err-fill)   !important; }
.bg-rose-600                     { background-color: var(--err-fill)   !important; }
.bg-blue-500,
.bg-blue-600,
.bg-blue-700,
.bg-blue-800,
.bg-sky-500                      { background-color: var(--accent-fill) !important; }

/* Hover/Active auf denselben Flaechen (Fix-Runde 2, Schaden 1): eigene
   *-fill-hover-Tokens statt filter:brightness. Ohne Korrektur waeren
   z.B. bg-red-600 + hover:bg-red-700 (13x im Bestand, ueberwiegend an
   destruktiven Aktionen wie Loeschen/Ablehnen) im Ruhezustand und im
   Hover exakt identisch eingefaerbt — die Rueckmeldung "ich bin auf dem
   richtigen Ziel" fehlte komplett. Ein Bildfilter haette das behoben,
   faerbt aber nachweislich auch den weissen Beschriftungstext mit ein
   (im hellen Theme gemessen 4.66:1 statt 5.85:1, siehe Bericht) und legt
   auf jedem gefilterten Element einen neuen Stacking-/Containing-Block
   an. Echte Tokens vermeiden beides.
   NICHT betroffen: hover:bg-gray-50 auf bg-white (128 Vorkommen, das
   haeufigste Hover-Muster im Bestand) — das ist bereits ein echter
   Farbwechsel (--panel -> --panel-2) und bleibt unangetastet. */
.hover\:bg-green-700:hover,
.hover\:bg-green-800:hover,
.hover\:bg-emerald-700:hover     { background-color: var(--ok-fill-hover)    !important; }
.hover\:bg-red-700:hover         { background-color: var(--err-fill-hover)   !important; }
.hover\:bg-orange-600:hover      { background-color: var(--warn-fill-hover)  !important; }
.hover\:bg-blue-700:hover        { background-color: var(--accent-fill-hover) !important; }
.active\:bg-blue-800:active      { background-color: var(--accent-fill-hover) !important; }

/* ── Semantischer Text ────────────────────────────────────────────────── */
.text-green-600,
.text-green-700,
.text-green-800,
.text-green-900,
.text-emerald-500,
.text-emerald-600,
.text-emerald-700,
.text-emerald-800,
.text-emerald-900                { color: var(--ok)     !important; }
/* Hover der beiden "erledigt"-Haken in der Uebergabe-Liste, ebenfalls aus
   JavaScript zusammengesetzt. Gleiche Zuordnung wie .text-green-700. */
.hover\:text-green-700:hover     { color: var(--ok)     !important; }
.text-yellow-600,
.text-yellow-700,
.text-yellow-800,
.text-yellow-900,
.text-amber-500,
.text-amber-600,
.text-amber-700,
.text-amber-800,
.text-amber-900,
.text-orange-600,
.text-orange-700,
.text-orange-800                 { color: var(--warn)   !important; }
.text-red-500,
.text-red-600,
.text-red-700,
.text-red-800,
.text-red-900,
.text-rose-600,
.text-rose-700,
.text-rose-800                   { color: var(--err)    !important; }
.text-blue-600,
.text-blue-700,
.text-blue-800,
.text-blue-900,
.text-purple-600,
.text-purple-700,
.text-indigo-600,
.text-indigo-700,
.text-violet-700,
.text-cyan-800,
.text-sky-800                    { color: var(--accent) !important; }

.hover\:text-green-800:hover     { color: var(--ok)    !important; }
.hover\:text-yellow-800:hover    { color: var(--warn)  !important; }
.hover\:text-red-600:hover,
.hover\:text-red-700:hover       { color: var(--err)   !important; }

/* ── Semantische Rahmen (Callout-Boxen, Badge-/Button-Umrandung) ──────────
   Stufenlogik wie bei den Flaechen (Befund 6): 100/200 sind im
   Original-Tailwind blasse Haarstriche, keine Signalfarbe — die gehoeren
   auf --line (neutral, dezent), nicht auf die gesaettigte Basisfarbe.
   Erst ab 300 wird der Rahmen selbst zum Signal (Basis-Token). */
.border-red-200,
.border-amber-200,
.border-yellow-200,
.border-green-200,
.border-blue-100,
.border-blue-200,
.border-rose-200,
.border-sky-200                  { border-color: var(--line) !important; }

.border-green-300,
.border-green-400,
.border-green-500,
.border-emerald-300              { border-color: var(--ok)    !important; }
.border-amber-300,
.border-amber-400,
.border-amber-500,
.border-yellow-300,
.border-yellow-400,
.border-orange-400               { border-color: var(--warn)  !important; }
.border-red-300,
.border-red-400,
.border-rose-300,
.border-rose-600                 { border-color: var(--err)   !important; }
.border-blue-300,
.border-blue-800                 { border-color: var(--accent) !important; }

.hover\:border-green-500:hover    { border-color: var(--ok)   !important; }
.hover\:border-amber-500:hover    { border-color: var(--warn) !important; }
.hover\:border-red-400:hover      { border-color: var(--err)  !important; }

/* ── Marken-Nav: entfallen (Aufgabe 10) ──────────────────────────────────
   Hier stand ein Block fixer Blautoene fuer die "immer dunkelblaue
   Kopfleiste": .text-blue-100/200/300, .text-blue-300\/70,
   .border-blue-900\/40, .hover\:text-blue-300, .hover\:bg-blue-900\/40 und
   .hover\:border-blue-300. Sie waren Kontrastfarben AUF einem festen
   Marine (#003261), das nav.html und kundenportal/_layout.html per
   Inline-style setzten.

   Beide Flaechen gibt es nicht mehr: nav.html ist in Aufgabe 5 in die
   Sidebar aufgegangen, und die Kundenportal-Leiste steht seit Aufgabe 10
   auf --accent. Damit hatte keine dieser Regeln noch eine Fundstelle.

   Auf der neuen Petrol-Leiste waeren sie sogar schaedlich gewesen:
   text-blue-200 faellt dort von 9.07:1 auf 3.48:1, text-blue-300 von
   7.15:1 auf 2.74:1. Die Leiste traegt jetzt weissen Text (4.95:1).

   Bemerkt hat das der Abdeckungstest erst, nachdem er Kommentare aus den
   Vorlagen ausblendet -- vorher hielt der erklaerende Kommentar in
   _layout.html genau die Regeln am Leben, die er fuer tot erklaerte. */

/* bg-primary hover:bg-blue-900 (OHNE Deckkraft-Suffix) ist ein anderer
   Fall: das kommt ausschliesslich auf den sechs Auth-Seiten vor (Login,
   Aktivierung, Passwort-Erst-Setzen/-Reset/-Vergessen, TOTP-Verifizieren)
   als Hover-Zustand des primaeren Buttons (weisser Text) — ein Relikt aus
   der Zeit vor der Petrol-Marke, keine Nav-Farbe. Fix-Runde 1, Befund 1:
   diese Regel war zuvor faelschlich in der Nav-Gruppe (fixe navyblaue
   rgba) versteckt, obwohl gar keine Nav-Flaeche betroffen ist. Es gibt im
   Bestand keine Verwendung von bg-blue-900 OHNE hover:-Praefix — eine
   zusaetzliche Regel fuer den nackten Klassennamen waere daher tote Deko
   und wurde entfernt.
   Bewusste Abweichung von der im Review vorgeschlagenen Loesung
   `var(--accent-hover)`: im Browser nachgemessen ergibt --accent-hover im
   dunklen Theme (#63c6cf, eine helle Vordergrundfarbe wie --accent selbst)
   nur Kontrast 2.0:1 zu weissem Text — derselbe Fehler wie in Befund 3,
   nur an einer weiteren Stelle.
   Fix-Runde 2, Schaden 1: `var(--accent-fill)` (Fix-Runde 1) war zwar
   kontraststark, aber IDENTISCH mit der Ruhefarbe von .bg-primary (Zeile
   siehe unten) — Hover und Ruhezustand des Login-Buttons sahen dadurch
   auf allen sechs Auth-Seiten exakt gleich aus, keine Rueckmeldung beim
   Hover. Jetzt auf --accent-fill-hover, eine eigens dafuer angelegte,
   erkennbar andere Farbe (siehe tokens.css). */
.hover\:bg-blue-900:hover          { background-color: var(--accent-fill-hover) !important; }

/* ── Primary-Button (bg-primary) ──────────────────────────────────────────
   Fix-Runde 1, Nachtrag: bg-primary ist keine Tailwind-Palette-Utility
   (deshalb nie von TAILWIND_MUSTER erfasst und bisher komplett
   unbehandelt geblieben — bridge.css hat sie schlicht nicht angefasst),
   sondern eine eigene Tailwind-Farbe aus der Config in base.html
   (`primary: 'rgb(var(--accent-rgb) / <alpha-value>)'`). Trotzdem gilt
   dieselbe Mechanik wie bei jeder anderen Utility: die Bridge ueberschreibt
   sie nach Tailwind, mit !important. Mit 221 bg-primary + 71
   bg-primary/90 die mit Abstand haeufigste farbige Flaeche im Bestand —
   ausnahmslos Buttons mit weissem Text, deshalb *-fill statt --accent
   (dieselbe Kontrast-Begruendung wie bei Befund 3: --accent ist im
   dunklen Theme eine helle Vordergrundfarbe, als Flaeche unter weissem
   Text nicht lesbar). --accent-fill-rgb ist die Kanalform von
   --accent-fill, damit auch die Deckkraft-Variante bg-primary/90
   funktioniert (exakt das Muster, das --accent-rgb fuer bg-primary/90
   selbst schon loesen musste, siehe tokens.css). */
.bg-primary                        { background-color: rgb(var(--accent-fill-rgb)) !important; }
.hover\:bg-primary:hover           { background-color: rgb(var(--accent-fill-rgb)) !important; }
/* file: ist Tailwinds Variante fuer den ::file-selector-button eines
   <input type=file>. Einziger Fundort: rechnung_einstellungen.html. Nicht
   von TAILWIND_MUSTER erfasst (wie bg-primary generell), aber dieselbe
   Flaeche mit weissem Text — der Vollstaendigkeit halber mitgezogen. */
.file\:bg-primary::file-selector-button { background-color: rgb(var(--accent-fill-rgb)) !important; }

/* bg-primary/90 (72x + 1x file:, ausnahmslos als hover: auf einem
   bg-primary-Button — nackt kommt die Klasse im Bestand nicht vor) NICHT
   wortgetreu als 90%-Deckkraft umgesetzt: 90% --accent-fill-rgb ueber
   einer hellen --panel-Flaeche komponiert im hellen Theme auf nur noch
   4.13:1 Kontrast zu weissem Text — knapp UNTER dem Zielwert 4.5:1, weil
   die Deckkraft den Farbton in Richtung des hellen Untergrunds aufhellt.

   Fix-Runde 2, Schaden 4: die erste Antwort darauf war volle Deckkraft
   plus filter:brightness. Das war derselbe Fehler, den Schaden 1 zwoelf
   Zeilen weiter oben schon einmal behoben hat, nur an der haeufigsten
   Stelle des Bestands: ein Bildfilter faerbt den weissen Beschriftungstext
   mit ein (im hellen Theme gemessen 4.66:1 statt der gerechneten 5.85:1,
   also SCHLECHTER als der ungefilterte Ruhezustand mit 4.95:1) und legt
   auf jedem Button einen neuen Stacking-/Containing-Block an.

   Jetzt auf --accent-fill-hover, genau wie alle anderen Hover-Partner
   gesaettigter Flaechen. Das passt hier besonders gut: bg-primary steht
   auf --accent-fill, und bg-primary/90 ist nichts anderes als dessen
   Hover-Zustand. Ohne Deckkraft wird auch keine Kanalform gebraucht.
   Kontrast zu weissem Text: hell #0a5a61 -> 8.02:1, dunkel #308087 ->
   4.60:1 (Wert aus tokens.css, dort im Leuchtdichte-Fenster begruendet). */
.bg-primary\/90,
.hover\:bg-primary\/90:hover,
.hover\:file\:bg-primary\/90:hover::file-selector-button {
    background-color: var(--accent-fill-hover) !important;
}

/* bg-primary/5 und bg-primary/10 sind ein ANDERER Fall: beide Fundstellen
   sind zarte Hover-Toenungen von Outline-Buttons/Tabellenzeilen, bei
   denen der Text NICHT weiss ist (border-primary text-primary
   hover:bg-primary/5|/10, bzw. eine anklickbare Tabellenzeile mit
   normalem Fliesstext). Hier auf --accent-rgb (nicht --accent-fill-rgb)
   gelegt: die begleitende Schrift-/Rahmenfarbe bleibt bewusst --accent
   (Auftrag: text-primary/ring-primary nicht anfassen) — bei nur 5-10%
   Deckkraft ist der Farbunterschied zwischen --accent und --accent-fill
   ohnehin kaum wahrnehmbar, aber die Konsistenz mit dem unveraendert auf
   --accent stehenden Rahmen/Text desselben Buttons ist so hoeher. */
.hover\:bg-primary\/5:hover        { background-color: rgb(var(--accent-rgb) / .05) !important; }
.hover\:bg-primary\/10:hover       { background-color: rgb(var(--accent-rgb) / .1)  !important; }

/* ── Formularelemente ───────────────────────────────────────────────────── */
input:not([type=checkbox]):not([type=radio]):not([type=range]),
select,
textarea {
    background-color: var(--panel-3);
    color: var(--ink);
    border-color: var(--line-strong);
}
input::placeholder,
textarea::placeholder { color: var(--ink-3); }

/* ══ Form ═══════════════════════════════════════════════════════════════
   Bis hierher steuert die Bridge nur FARBE. Rundung und Schatten sind
   ebenfalls Einzeleigenschaften mit kleinem Wertevorrat und lassen sich
   deshalb genauso auf Tokens legen -- anders als Abstand oder Groesse, wo
   der konkrete Wert die Aussage IST und eine globale Ueberschreibung
   Layouts zerlegen wuerde. Dort bleibt die Angabe im Template.

   Betroffen sind rund 2.100 Stellen. Das ist eine Gestaltungsentscheidung
   und keine Fehlerbehebung: die App sieht damit anders aus. Beide
   Varianten wurden am 2026-08-05 nebeneinander betrachtet und diese
   gewaehlt -- der Gewinn ist, dass Eckradius und Schattentiefe der ganzen
   Anwendung ab jetzt vier Zahlen in tokens.css sind.
   ══════════════════════════════════════════════════════════════════════ */

/* ── Eckradius ──────────────────────────────────────────────────────────
   Der Bestand mischt drei Radien ohne erkennbares System: rounded (661x,
   4px), rounded-lg (444x, 8px) und rounded-xl (470x, 12px) stehen an
   vergleichbaren Elementen -- Karten, Knoepfen, Feldern -- nebeneinander.
   Die Spezifikation hat das als Befund notiert. Hier fallen sie auf die
   eine Kartenrundung --radius zusammen.

   rounded-md (39x) und rounded-sm (7x) sind die kleine Stufe und gehen
   auf --radius-sm.

   NICHT angefasst: rounded-full (18x, Punkte und Pillen -- die sollen
   rund bleiben, nicht kartenrund) und die seitenbezogenen Formen
   rounded-t (5x) und rounded-b-xl (3x), die eine Kante bewusst offen
   lassen. rounded-2xl (14x) faellt mit auf --radius: die Klasse steht im
   Bestand an denselben Karten wie rounded-xl, nur groesser gewaehlt. */
.rounded,
.rounded-lg,
.rounded-xl,
.rounded-2xl                     { border-radius: var(--radius)    !important; }
.rounded-md,
.rounded-sm                      { border-radius: var(--radius-sm) !important; }

/* ── Schatten ───────────────────────────────────────────────────────────
   Bisher standen die dunklen Werte hier fest verdrahtet, waehrend
   tokens.css fuer Dunkel `--shadow: none` fuehrte. Zwei Antworten auf
   dieselbe Frage: eine .card aus components.css haette im Dunkelmodus
   keinen Schatten geworfen, ein `bg-white shadow`-Div daneben schon.
   Jetzt entscheidet das Token, und zwar fuer beide.

   Zwei Stufen: --shadow fuer Flaechen, die NEBEN anderen liegen (Karten,
   Zeilen; auf Dunkel none, dort trennt Helligkeit), --shadow-lg fuer
   Flaechen, die UEBER anderen liegen (Modale, Dropdowns) -- die brauchen
   die Trennung in beiden Themes. */
.shadow,
.shadow-sm,
.shadow-md                       { box-shadow: var(--shadow)    !important; }
.shadow-lg,
.shadow-xl                       { box-shadow: var(--shadow-lg) !important; }
/* Hover-Varianten: im Bestand 65x hover:shadow-lg und 4x hover:shadow-md,
   ueberwiegend an anklickbaren Karten. Bisher von der Bridge gar nicht
   erfasst -- im Dunkelmodus lief dort weiter Tailwinds Standardschatten. */
.hover\:shadow-md:hover          { box-shadow: var(--shadow)    !important; }
.hover\:shadow-lg:hover          { box-shadow: var(--shadow-lg) !important; }

/* ── Ausnahmen ──────────────────────────────────────────────────────────
   Dokumente bleiben hell: ein PDF ist ein Dokument, kein Oberflaechen-
   element. Uebernommen aus dark.css. */
[data-theme="dark"] iframe { background: #fff; }

@media print {
    :root { --bg: #fff; --panel: #fff; --ink: #000; --ink-2: #222; }
    .bg-white, .bg-gray-50, .bg-gray-100 { background: #fff !important; }
}