/* ============================================================
   Ausgleich zum Element-Reset des Design Systems (378 S2, Nachbesserung N1).

   WARUM DIESE DATEI EXISTIERT
   `vendor/wd-apps-design-system/styles.css` (Zeilen 14-33) bringt einen
   Element-Reset mit — `body`, `button`, `a`, `a:hover`, `:focus-visible` — und
   laedt NACH dem App-CSS (Ende des <body>, siehe index.html). Bei gleicher
   Spezifitaet gewinnt damit das DS gegen den Tailwind-Preflight:
     · `button { border: none }` (0,0,1) schlaegt `* { border-style: solid }`
       (0,0,0) — jeder <button> mit Tailwind-`border` verlor die Kante
       (Knoepfe als Outline, Radix-Checkbox, Select-Trigger, Radio, Switch);
     · `a { color: var(--brand-text) }` und `a:hover { underline }` faerbten und
       unterstrichen jeden Link, der keine eigene Farbe traegt;
     · `body { font-size: 14px; font-weight: 500 }` verschob die ganze App.
   S2 soll an der App nichts aendern. Diese Datei stellt den Stand VOR dem
   Einbau wieder her — der Element-Teil mit Element-Selektoren derselben
   Spezifitaet wie der DS-Reset, geladen direkt nach `styles.css`; deshalb
   gewinnt er (gleiche Spezifitaet, spaeter). Ein zweiter Abschnitt (Speicher-
   anzeige des Rahmens, 378 S3 B1) ist mit 2.2.2 entfallen — siehe LEBENSDAUER.

   WAS BEWUSST NICHT HIER STEHT
   · `body` Farbe und Hintergrund: bleiben DS (die Tokens gelten, das ist der
     Zweck von S2).
   · `:focus-visible` (378 S2 P3): bleibt DS, bewusst. Das DS setzt dort DREI
     Eigenschaften — `outline: none; box-shadow: var(--ring-focus);
     border-color: var(--ring)` (0,1,0, laedt spaeter). Sichtbare Folge:
     fokussierte Felder und Knoepfe mit eigener `border-*`-Klasse bekommen beim
     TASTATURFOKUS den Rahmen in `--ring`; Bauteile mit eigener
     `focus-visible:ring-*`/`outline-*`-Klasse (0,2,0) behalten ihre. Die
     Rahmenfarbe je Bauteil laesst sich nicht allgemein wiederherstellen, und
     der Fokus bleibt sichtbar — das ist die einzige benannte Ausnahme vom
     Leitsatz „S2 aendert am Aussehen nur, was die Tokens aendern". Der Test
     pinnt die Eigenschaftsmenge; setzt eine DS-Version dort mehr, wird er rot.

   WERTE: aus Tailwind-Preflight und dem eigenen index.css abgelesen, nicht
   geraten; `ds-ausgleich.test.ts` liest sie aus denselben Quellen und wird rot,
   wenn Preflight, Tailwind-Config oder DS-Reset sich aendern.

   LEBENSDAUER (Stand 378 S7, 2.2.2): die Datei BLEIBT — aber nur noch als
   Element-Reset-Ausgleich.
   · Element-Teil: bis in 378 S6 je Regel entschieden ist, ob sie entfaellt oder
     bleibt. Der AppShell uebernimmt den Grundstil des DS NICHT fuer die
     shadcn-Knoepfe der Seiten (F7: `button { border:none }` nahme ihnen die
     Kante). Wer die Datei vorher loescht, bekommt Knoepfe ohne Rand und blau
     unterstrichene Links in jeder Tabelle.
   · Der Abschnitt „Speicheranzeige des Rahmens" ist ENTFALLEN (378 S7.2,
     Q-009 = a): 2.2.2 zeigt ohne `saveState` keine Speicheranzeige mehr, und
     das DMS setzt keinen. Er versteckte per `display:none !important` einen
     Knoten, den es nicht mehr gibt. Dreht jemand das zurueck, versteckt die
     Regel nichts — aber ein kuenftiges `saveState` auf einer Seite, die
     wirklich speichert, bliebe unsichtbar. Der Test dazu steht in
     `rahmen-378.test.tsx` (gerenderter Rahmen, nicht CSS) und prueft, dass die
     Datei keine `.wd-shell__msave`/`.wd-shell__foot`-Regel mehr hat.
   ============================================================ */

/* body: das DS setzt zusaetzlich zu Schrift/Farbe/Grund auch das Schriftbild
   (378 S2 P2). Vor 378 setzte das DMS davon NICHTS: weder Preflight noch
   index.css noch eine `antialiased`-Klasse — also Browser-Ausgangswerte
   (`auto`/`auto`) und, fuer die Feature-Settings, den Wert des Preflight-`html`
   (`normal`, weil `fontFamily.sans` keine Feature-Settings traegt) per Vererbung.
   Das DS-`cv05` (einstoeckiges „g") und `optimizeLegibility` aendern die
   Glyphen und die Metrik des ganzen Textes — das gehoert zu S3, nicht zu S2. */
body {
  font-size: inherit;
  font-weight: inherit;
  line-height: inherit;
  -webkit-font-smoothing: auto;
  text-rendering: auto;
  font-feature-settings: inherit;
}

button {
  background-color: transparent;
  background-image: none;
  border-width: 0;
  border-style: solid;
  border-color: #e5e7eb;
}

a {
  color: inherit;
  text-decoration: inherit;
}

/* a:hover (378 S2 P1): das DS setzt hier NUR `text-decoration: underline`
   (0,1,1) — keine Farbe. Der Ausgleich darf deshalb nur die Unterstreichung
   zuruecknehmen, und nur bei Links, deren Klassen die Unterstreichung nicht
   selbst regeln. Ausgenommen sind `underline` und jedes Token, das auf
   `:underline` endet oder es enthaelt — also auch `md:underline`,
   `focus:underline` und `hover:underline-offset-*`. Bei Letzteren waere beim
   Hover die DS-Unterstreichung sichtbar; im Bestand gibt es keinen solchen
   Fall, der Scan (Test) meldet jeden neuen. Ohne das schluege diese Regel
   (0,1,1) die Tailwind-Klasse (0,1,0 bzw. 0,2,0 fuer hover:) und der Link
   verlore beim Hover die Unterstreichung, die seine eigene Klasse verlangt.
   Die hoehere Spezifitaet (0,3,1) trifft damit Links, deren Klassen die
   Unterstreichung nicht regeln — fuer die stellt sie den Stand vor 378 her
   (`text-decoration: inherit`, wie `a`). NICHT erfasst sind DS-Klassen, die
   selbst unterstreichen (`a.wd-ref`, `styles.css:305`): das `:not()` kennt sie
   nicht; sie sind bis S3 nicht in Benutzung. Der Bestand an Klassen mit
   Unterstreichung steht im Test (Bestandsscan); eine neue ist dort rot. */
a:hover:not([class~="underline"]):not([class*=":underline"]) {
  text-decoration: inherit;
}