Geviertstriche aus Text, Kommentaren und Doku entfernen

467 Stellen. Nicht durch einen anderen Strich ersetzt, sondern durch das
Satzzeichen, das an der jeweiligen Stelle richtig ist: Doppelpunkt, wo eine
Erlaeuterung folgt; Komma, wo der Satz weiterlaeuft; Punkt, wo zwei
Hauptsaetze aneinanderstiessen. Ein Halbgeviertstrich waere nur derselbe
Griff mit kuerzerem Strich gewesen.

Regelbasiert ersetzt und danach nachgeprueft, weil eine Regel allein nicht
reicht. Gefunden und einzeln korrigiert:

- Eingeschobene Saetze mit Strichpaar. Nur der oeffnende Strich passte ins
  Muster, der schliessende blieb als "—," stehen. Drei Stellen, jetzt mit
  Klammern oder als eigener Satz.

- Doppelte Doppelpunkte, wo beide Striche eines Paars zu Doppelpunkten wurden
  ("Globale Regeln: Schrift, Groessen, Abstaende: kommen aus HiveGrid").
  Sieben Stellen in Doku und Oberflaeche, jetzt in Klammern.

- Pfade, denen ein Komma statt eines Doppelpunkts folgte.

- Ausgerichtete Kommentartabellen, in denen der Strich eine Spalte war.

Nicht angefasst: drei Geviertstriche, die keine Prosa sind, sondern
Tabellenplatzhalter fuer "kein Wert" (Trichter, Auftraege, Kunden). Dort ist
der Strich die Angabe selbst; ihn zu entfernen liesse leere Zellen zurueck.

tsc, lint, build, verify:carbon und verify:layout laufen sauber.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX

docs/DESIGN-SYSTEM.md

@@ -4,11 +4,11 @@ Grundlage ist **IBM Carbon Data Visualization**, ergänzt um die Spacing- und
 Zahlenregeln aus der eigenen Planung (`UI_UX_GUIDELINES.md`, Januar 2026).
 
 Die konkreten Farb- und Linienwerte sind aus dem ausgelieferten Stylesheet von
-`@carbon/charts` (Light Theme) übernommen — nicht aus der Dokumentation
+`@carbon/charts` (Light Theme) übernommen, nicht aus der Dokumentation
 abgeschrieben. Alles Folgende ist in
 `features/dashboard/utils/chartTheme.ts` als Code hinterlegt.
 
-## 0. Was Carbon regelt — und was nicht
+## 0. Was Carbon regelt, und was nicht
 
 Wichtig für jeden, der hier etwas anzweifelt: **Carbon regelt Datenvisualisierung
 nur teilweise.** Die Grenze verläuft so:
@@ -26,14 +26,14 @@ nur teilweise.** Die Grenze verläuft so:
 Die Carbon-Seiten zu Chart-Anatomie und Dashboards tragen ausdrücklich den
 Hinweis „this guidance is a work in progress" und enthalten **keine Zahlenwerte**
 für Abstände. Wer dort nach Paddings sucht, findet Prinzipien („create a clear
-visual hierarchy", „limit the number of metrics") — richtig, aber nicht
+visual hierarchy", „limit the number of metrics"): richtig, aber nicht
 nachprüfbar.
 
 **Die Abstandswerte in diesem Dokument stammen deshalb nicht von Carbon**,
 sondern aus zwei anderen Quellen:
 
 1. der **Carbon-Spacing-Skala und dem 2x-Grid** des allgemeinen Design-Systems
-   (4/8/12/16/24/32/48…) — dieselbe Skala, aus der auch Davids
+   (4/8/12/16/24/32/48…): dieselbe Skala, aus der auch Davids
    `INTERIM-UI-DESIGN-STANDARDS.md` im Zielsystem schöpft;
 2. der eigenen Planung mit dem Branchenpartner (`UI_UX_GUIDELINES.md`).
 
@@ -41,7 +41,7 @@ Beides ist konsistent zueinander. Es ist aber ehrlicher zu sagen: Bei Farben und
 Achsen folgen wir einer Norm, bei Abständen einer begründeten Hauskonvention.
 
 **Nachprüfbar gemacht:** `npm run verify:carbon` gleicht `chartTheme.ts` gegen
-`docs/carbon-referenz.json` ab — Palette, neutrale Werte, Tooltip, Achsenraster.
+`docs/carbon-referenz.json` ab: Palette, neutrale Werte, Tooltip, Achsenraster.
 Die Referenzdatei nennt Quelle, Version und Prüfdatum. Bewusste Abweichungen
 (Balkenbreite, feste Kategoriefarben) sind dort begründet hinterlegt und werden
 als Hinweis ausgegeben, nicht als Fehler.
@@ -58,7 +58,7 @@ als Hinweis ausgegeben, nicht als Fehler.
 11 #009d9a  12  #012749  13  #8a3800  14  #a56eff
 ```
 
-Die Reihenfolge ist auf Unterscheidbarkeit optimiert — auch bei
+Die Reihenfolge ist auf Unterscheidbarkeit optimiert, auch bei
 Farbfehlsichtigkeit und in Graustufen. Farben deshalb **immer von vorne
 vergeben**, nie nach Geschmack auswählen und nie umsortieren.
 
@@ -76,7 +76,7 @@ keine Information mehr, sondern Dekoration.
 | neutral | `#8d8d8d` |
 | Information | `#1192e8` |
 
-Kategorie- und Statusfarben nie im selben Chart mischen — eine grüne Kategorie
+Kategorie- und Statusfarben nie im selben Chart mischen, eine grüne Kategorie
 neben einem grünen Positiv-Status ist nicht mehr eindeutig lesbar.
 
 **Rangfolgen einfarbig.** Top-Kunden oder Aufträge je Mitarbeiter sind keine
@@ -106,7 +106,7 @@ Aussage der Grafik verwässern.
 
 Altersklassen, Risikostufen und Ähnliches sind **keine Kategorien**, sondern eine
 Reihenfolge mit wachsendem Risiko. Dafür gilt die vierstufige Risikorampe
-(`RISIKO_RAMPE` in `chartTheme.ts`) — durchgehend Statusfarben, keine
+(`RISIKO_RAMPE` in `chartTheme.ts`): durchgehend Statusfarben, keine
 Palettenfarbe dazwischen:
 
 | Stufe | Wert | Bedeutung |
@@ -138,7 +138,7 @@ Die Vergleichsreihe ist bewusst neutral: Sie soll einordnen, nicht konkurrieren.
 | Y-Achsen-Breite | 58 px | Platz für „245 T€" ohne Umbruch |
 
 Bei mehr als 12 Datenpunkten wird nur jede n-te Beschriftung gezeigt, sonst
-überlappen sie (`MAX_ACHSENLABELS` in `chartTheme.ts` — eine Konstante für
+überlappen sie (`MAX_ACHSENLABELS` in `chartTheme.ts`, eine Konstante für
 alle Diagrammtypen).
 
 **Achsenwerte sind rund.** Recharts leitet Ticks aus `max/(n-1)` ab und rundet
@@ -158,7 +158,7 @@ Einheitlich für alle Charts (`components/charts/ChartTooltip.tsx`), Werte aus
 `.cds--cc--tooltip` im ausgelieferten Stylesheet:
 
 - Fläche `#ffffff` (`--cds-layer-02`), Text `#161616` (`--cds-text-primary`)
-- abgesetzt allein durch den Schatten `0 1px 6px 0 rgba(0,0,0,.2)` — **kein Rahmen**
+- abgesetzt allein durch den Schatten `0 1px 6px 0 rgba(0,0,0,.2)`: **kein Rahmen**
 - Label und Reihenname 12 px in `#525252`, Wert fett in Tabellenziffern
 - kein Doppelpunkt zwischen Name und Wert, maximal 270 px breit
 - Farbmarker je Reihe, 10 × 10 px
@@ -179,10 +179,10 @@ Ein gemeinsamer Tooltip verhindert, dass jedes Chart eigene Regeln entwickelt.
 | Balkenabstand | mindestens halbe Balkenbreite (`barCategoryGap: 28 %`) |
 | Balkenecken | 2 px, nur an der Werteseite |
 | Linienstärke Fläche | 2 px, Verlaufsfüllung 24 % → 2 % |
-| Interpolation | **linear** — eine Monotone-Kurve erfindet Zwischenwerte zwischen zwei Messpunkten |
+| Interpolation | **linear**, eine Monotone-Kurve erfindet Zwischenwerte zwischen zwei Messpunkten |
 | Punkte | nur beim Hovern, Radius 4, weißer Rand |
 | Ring innen/außen | 62 % / 88 %, 2° Segmentabstand |
-| Ringmitte | Gesamtwert — sonst muss man die Segmente addieren |
+| Ringmitte | Gesamtwert, sonst muss man die Segmente addieren |
 | Ringlegende | rechts, einzeilig, mit Wert und Prozentanteil |
 
 Ringsegmente starten oben (12 Uhr) mit dem größten Wert und laufen im
@@ -190,7 +190,7 @@ Uhrzeigersinn absteigend. Auch „Sonstige" wird nach Größe einsortiert, nicht
 ans Ende gehängt.
 
 **Ein Ring braucht ein echtes Ganzes.** Beträgt ein Segment über 80 %, trägt die
-Grafik nichts mehr bei — dann ist die Bezugsgröße falsch gewählt. Beispiel: Der
+Grafik nichts mehr bei, dann ist die Bezugsgröße falsch gewählt. Beispiel: Der
 Rechnungsbestand aus zwei Jahren gegen den heutigen Forderungsstand ergibt
 92 % „Bezahlt". Richtig ist der offene Bestand allein; dann zeigt der Ring, wie
 viel davon bereits überfällig ist.
@@ -198,13 +198,13 @@ viel davon bereits überfällig ist.
 ### Werte in einem engen Band: Punkt statt Balken
 
 Auslastung liegt betrieblich zwischen etwa 70 und 100 %. Ein Balken **muss** bei
-Null beginnen, sonst verzerrt seine Länge — und dann sind 74 % und 96 % optisch
+Null beginnen, sonst verzerrt seine Länge, und dann sind 74 % und 96 % optisch
 fast gleich lang. Ein Punkt kodiert über die **Position**, nicht über die Länge,
 und darf deshalb einen ausgeschnittenen Bereich zeigen.
 
 Der Zielkorridor liegt als graues Band hinter den Punkten, die 100-%-Marke als
 beschriftete Linie, darunter eine Achse. Damit erklärt sich die Grafik ohne
-Ampel-Legende — und tote Legendeneinträge („Luft frei", wenn niemand darunter
+Ampel-Legende, und tote Legendeneinträge („Luft frei", wenn niemand darunter
 liegt) entfallen.
 
 ---
@@ -239,7 +239,7 @@ zwischen den Karten, zerfällt das Raster optisch.
 Eine Schriftfamilie: **Instrument Sans**, selbst gehostet aus denselben
 Schriftdateien wie die Software (`public/fonts/`, variabel 400–700). Vorher lief
 der Prototyp auf Inter, während `ui/theme.css` für alle Subframe-Typo-Token
-bereits „Instrument Sans" verlangte — zwei Schriften auf einer Seite, keine
+bereits „Instrument Sans" verlangte: zwei Schriften auf einer Seite, keine
 davon die der Software. Zahlen immer in Tabellenziffern
 (`font-variant-numeric: tabular-nums`, global gesetzt), damit Spalten
 untereinander stehen.
@@ -257,20 +257,20 @@ untereinander stehen.
 | Datum | `30.07.2026`, kurz `30.07.`, Monat `Jul 26` |
 
 Punkt als Tausendertrenner, Komma als Dezimaltrenner. Innerhalb einer Ansicht
-immer dasselbe Format — nicht in einer Zeile `245.000 €` und in der nächsten
+immer dasselbe Format, nicht in einer Zeile `245.000 €` und in der nächsten
 `245 T€`.
 
 ---
 
 ## 8. Zustände
 
-Jedes Chart braucht einen **Leerzustand** — Filter können jede Ansicht leer
+Jedes Chart braucht einen **Leerzustand**: Filter können jede Ansicht leer
 laufen lassen. `ChartLeer` zeigt dann eine gestrichelte Fläche mit Hinweistext
 statt eines leeren Rechtecks.
 
 Hover-Zustände: Karten erhalten einen stärkeren Schatten, Balken und
 Ringsegmente werden hervorgehoben (die übrigen auf 35–45 % Deckkraft).
-Tabellenzeilen bekommen **keinen** Hover, solange sie nicht anklickbar sind —
+Tabellenzeilen bekommen **keinen** Hover, solange sie nicht anklickbar sind,
 ein Hover ohne Ziel verspricht eine Interaktion, die es nicht gibt.
 
 ## 9. Textabstände und Umbruch
@@ -287,7 +287,7 @@ zusammengehörig, bei 0 px kleben Beschriftung und Wert aneinander.
 schrumpft auf null, der Text bleibt stehen und läuft in das Nachbarelement.
 Deshalb trägt jedes Textfeld, das schrumpfen kann, entweder `truncate` (wenn
 Kürzen vertretbar ist) oder `break-words` (wenn nicht). Dateipfade und lange
-Einzelwörter brauchen zwingend `break-words` — sie haben keine Leerzeichen zum
+Einzelwörter brauchen zwingend `break-words`, sie haben keine Leerzeichen zum
 Umbrechen.
 
 **Legenden weichen nach unten aus.** Carbon sagt, die Legende gehört rechts
@@ -295,7 +295,7 @@ neben das Diagramm, „when space is plentiful". Ist der Platz nicht reichlich,
 rutscht sie unter das Diagramm, statt Namen und Werte ineinanderlaufen zu
 lassen. Gesteuert über **Container-Queries** (`@container` / `@md:`), nicht über
 den Viewport: Dieselbe Karte nimmt mal ein Drittel und mal die halbe
-Seitenbreite ein — der Viewport weiß davon nichts.
+Seitenbreite ein, der Viewport weiß davon nichts.
 
 **Nachprüfbar gemacht:** `npm run verify:layout` lädt alle sechs Seiten in
 sieben Fensterbreiten (1024–1920) und misst jede Textzeile. Kollisionen unter
@@ -303,7 +303,7 @@ sieben Fensterbreiten (1024–1920) und misst jede Textzeile. Kollisionen unter
 
 Warum das ein eigener Prüfer sein muss: Diese Fehler treten **nur in bestimmten
 Breiten** auf. Die Ringlegende auf der Finanzseite kollidierte bei 1280 und
-1440 px und war bei 1600 px unauffällig — auf einem Screenshot also unsichtbar.
+1440 px und war bei 1600 px unauffällig: auf einem Screenshot also unsichtbar.
 Auge und Einzelbild reichen dafür nicht.
 
 ## 10. Fokus und Kontrast
@@ -324,7 +324,7 @@ Dropdown, Karten-Menü) schließen mit **Escape** und geben den Fokus an den
 auslösenden Knopf zurück.
 
 **Kontrast:** `--color-text-neutral-tertiary` liegt auf `neutral-700`
-(5,15:1 auf Weiß), nicht auf `neutral-600` (3,68:1 — unter WCAG AA). Das
+(5,15:1 auf Weiß), nicht auf `neutral-600` (3,68:1, unter WCAG AA). Das
 entspricht dem a11y-Override im Zielsystem. `text-neutral-subtle` ist ein
 Placeholder-Token und für lesbaren Text nicht geeignet.
 
@@ -333,7 +333,7 @@ Placeholder-Token und für lesbaren Text nicht geeignet.
 ## Kartenhöhen in einer Zeile
 
 **Gestreckt wird nur, wenn die Karten einer Zeile dieselbe Bauart haben.**
-Zwei Listen, zwei Zeitverläufe, zwei Tabellen — da gibt die eine Karte eine
+Zwei Listen, zwei Zeitverläufe, zwei Tabellen: da gibt die eine Karte eine
 Höhe vor, die die andere ohnehin fast erreicht, und der Rest verteilt sich
 oben und unten je zur Hälfte (`justify-center` im Kartenkörper).
 
@@ -352,7 +352,7 @@ bei 1680 px:
 | Vorgänge nach Status ∣ nach Gewerk (Diagramm ∣ Liste) | 190 px | **358 px** |
 
 Der Grund steckt in der Liste: Eine Balkenliste hat keine Mindesthöhe. Fünf
-Kategorien ergeben 280 px, eine einzige 112 px — daneben liegt ein
+Kategorien ergeben 280 px, eine einzige 112 px: daneben liegt ein
 Zeitverlauf unverändert bei 427 px, weil seine Diagrammfläche fest ist.
 
 Diese Zeilen zu strecken hieße, eine Karte mit einem Balken auf 427 px
@@ -368,12 +368,12 @@ nach unten.
 **Auf dem Dashboard ist die Zeile aus Zeitverlauf und Balkenliste trotzdem
 gestreckt.** Das ist kein Widerspruch, sondern derselbe Maßstab: Der
 Unterschied entsteht dort gar nicht erst groß, weil das Dashboard keinen
-Filter hat — jede Kachel zeigt ihren festen Zeitraum, die Balkenliste hat
+Filter hat, jede Kachel zeigt ihren festen Zeitraum, die Balkenliste hat
 immer ihre fünf Gewerke, und es bleiben rund 90 px, die sich oben und unten
 verteilen. In Analytics kann derselbe Unterschied durch einen Filter auf
 315 px wachsen. Der Filter ist der Unterschied, nicht die Kachel.
 
-Die Karten sind in allen Fällen dynamisch — nirgends steht eine feste Höhe.
+Die Karten sind in allen Fällen dynamisch: nirgends steht eine feste Höhe.
 Kommt mehr Inhalt hinein, wächst die Karte.
 
 ---
@@ -381,13 +381,13 @@ Kommt mehr Inhalt hinein, wächst die Karte.
 ## Ansprache
 
 **Die Anwendung duzt.** „2 Punkte brauchen heute deine Aufmerksamkeit", nicht
-„Ihre". Das gilt für jeden Text, der den Benutzer anspricht — Begrüßung,
+„Ihre". Das gilt für jeden Text, der den Benutzer anspricht: Begrüßung,
 Leerzustände, Hinweise, Fehlermeldungen.
 
 Halb geduzt liest sich schlechter als durchgehend gesiezt: Sobald zwei Sätze
 auf derselben Seite unterschiedlich ansprechen, klingt die Anwendung wie von
 zwei Leuten geschrieben. Beim Einbau gilt im Zweifel die Ansprache von
-HiveGrid — sie hat nach [ZIELSYSTEM.md](ZIELSYSTEM.md) Abschnitt 0 den Vorrang.
+HiveGrid, sie hat nach [ZIELSYSTEM.md](ZIELSYSTEM.md) Abschnitt 0 den Vorrang.
 
 **Namen im Prototyp stehen in eckigen Klammern.** Die Begrüßung zeigt
 „Guten Tag, [Vorname]" und nicht einen erfundenen Namen. Ein fester Name sieht