/* ============================================================
   WD-ERP — Ausgleich fuer den Element-Reset des Design Systems (378 S2-N1)

   WARUM ES DIESE DATEI GIBT
   styles.css des DS (public/vendor/wd-apps-design-system/styles.css:14-33)
   bringt einen Element-Reset mit: body 14px/500/1.45, `button { background:
   none; border: none }`, `a { color: var(--brand-text) }`, `a:hover
   { underline }`. styles.css laedt NACH dem App-CSS (index.html, Ende des
   <body>, damit es hinter dem Tailwind-Preflight steht — siehe dort). Bei
   gleicher Spezifitaet gewinnt die spaetere Regel; die DS-Elementregeln
   schlagen deshalb den Preflight, und `button { border: none }` (0,0,1)
   schlaegt `* { border-style: solid }` (0,0,0). Folge ohne diese Datei, ohne
   Fehlermeldung: jeder <button> mit Tailwind-`border` verliert die Kante
   (Knoepfe als Outline, Radix-Checkbox, Select-Trigger, Radio, Switch),
   Links werden petrol und unterstrichen beim Hover, der Fliesstext 14px/500.

   WAS DIESE DATEI TUT
   Sie steht direkt NACH styles.css und stellt mit Element-Selektoren
   GLEICHER Spezifitaet den Stand vor 378 wieder her — also den des
   Tailwind-Preflight (node_modules/tailwindcss/lib/css/preflight.css) und des
   eigenen src/index.css. S2 soll am Aussehen der App nichts aendern; die
   Umstellung auf den Grundstil des DS ist Sache von S3/S6. Der Test
   `ds-ausgleich.test.ts` liest die Werte aus Preflight und App-Konfiguration
   und haelt fest, dass jede Element-Regel des DS-Resets hier ein Gegenstueck
   hat — eine neue DS-Version mit weiterem Reset wird dort rot.

   WAS BEWUSST BEIM DS BLEIBT
   · `:focus-visible` — die EINZIGE Ausnahme vom Leitsatz „S2 aendert am
     Aussehen nur, was die Tokens aendern". Das DS setzt dort DREI
     Eigenschaften: `outline: none; box-shadow: var(--ring-focus);
     border-color: var(--ring)` (Spezifitaet 0,1,0, laedt spaeter). Sichtbare
     Folge: ein fokussiertes Feld mit eigener `border-*`-Klasse bekommt beim
     TASTATURfokus den Rahmen in `--ring`; Bauteile mit eigener
     `focus-visible:ring-*`/`outline-*`-Klasse (0,2,0) behalten ihre. Warum
     nicht ausgeglichen: die Rahmenfarbe je Bauteil laesst sich nicht
     allgemein wiederherstellen, und der Fokus bleibt sichtbar. Der Test
     pinnt die Eigenschaftsmenge — setzt eine neue DS-Version dort mehr, wird
     er rot.
   · `body` Farbe, Hintergrund und Schriftfamilie: die DS-Tokens gelten (S2).
     Smoothing/text-rendering setzt das DS gleich wie index.css (siehe unten,
     vom Test belegt), also nichts auszugleichen.

   ⛔ BLEIBT (378 S3 hat den Ausgleich bewusst NICHT entfernt, F7: die DS-Regel
   `button { border: none }` naehme den shadcn-Knoepfen die Kante). Der
   Element-Teil bleibt bis zur Entscheidung je Regel in 378 S6 (`Q-015`: body/a
   nach der Live-Gegenprobe, `button` bleibt).

   ENTFALLEN (378 S7.2): der Abschnitt „Speicheranzeige des Rahmens", der
   „Gespeichert" per `display:none !important` versteckte. Das DS 2.2.2 zeichnet
   die Anzeige nur noch MIT `saveState`; das ERP setzt keinen. Wer die Regel
   zurueckholt, versteckt kuenftig eine echte Anzeige (Seite mit Formular) ohne
   Fehlermeldung. Der Test `rahmen-speicheranzeige378.test.tsx` rendert den
   Rahmen und haelt fest, dass ohne `saveState` kein „Gespeichert" steht.
   ============================================================ */

/* Preflight: `html { line-height: 1.5 }`, `body { line-height: inherit }`;
   Schriftgroesse und -gewicht setzt weder Preflight noch index.css — sie
   kommen vom Browser-Standard (16px/400). `inherit` ist genau dieser Stand. */
/* `font-feature-settings`: das DS setzt am body `"cv05" 1` (einstoeckiges g).
   Vor 378 kam der Wert vom Preflight an `html` (`theme('fontFamily.sans[1].
   fontFeatureSettings', normal)`); die App-Schrift ist ein flaches Array ohne
   Optionsobjekt, also `normal`, und body erbt. `inherit` stellt das her.
   `-webkit-font-smoothing` und `text-rendering` brauchen keinen Ausgleich:
   index.css setzt am body `antialiased` und `optimizeLegibility` — dieselben
   Werte wie das DS. */
body {
  font-size: inherit;
  font-weight: inherit;
  line-height: inherit;
  font-feature-settings: inherit;
}

/* Preflight: `button { background-color: transparent; background-image: none }`
   und `* { border-width: 0; border-style: solid }`; die Farbe der Kante ist
   die von `* { @apply border-border }` in index.css (`hsl(var(--shadcn-border))`,
   tailwind.config.js `border`). */
button {
  background-color: transparent;
  background-image: none;
  border-width: 0;
  border-style: solid;
  border-color: hsl(var(--shadcn-border));
}

/* Preflight: `a { color: inherit; text-decoration: inherit }`. */
a {
  color: inherit;
  text-decoration: inherit;
}
/* Das DS setzt bei `a:hover` NUR `text-decoration: underline`, keine Farbe.
   Deshalb hier auch keine `color`: eine Farbregel in `a:hover` (0,1,1) wuerde
   jede Tailwind-Klasse (`text-primary`, 0,1,0) beim Hover uebersteuern.
   `:not(...)`: ausgenommen sind Links mit dem Token `underline` und mit jedem
   Token, das `:underline` enthaelt oder darauf endet (`hover:underline`,
   `group-hover:underline`, aber auch `md:underline`, `focus:underline` und
   `hover:underline-offset-*` — bei den letzten beiden waere beim Hover die
   DS-Unterstreichung sichtbar; im Bestand gibt es keinen solchen Fall, der
   Scan in `ds-ausgleich.test.ts` meldet jeden neuen). Das ist der Stand vor
   378. Ohne `:not` wuerde die Regel (0,1,1) deren `hover:underline` (0,2,0)
   schlagen. Die Liste der Ausschluesse leitet der Test aus dem Bestand ab; ein
   neues Token (z. B. `no-underline`, `line-through`) verlangt dort eine
   Entscheidung. NICHT bekannt ist dem `:not()` jede DS-Klasse, die selbst
   unterstreicht (`a.wd-ref`, `styles.css:305`): bis S3 nicht benutzt. */
a:hover:not([class~="underline"]):not([class*=":underline"]) {
  text-decoration: inherit;
}