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
2026-08-31 20:51:19 +02:00
1 parent e998231fed
commit 6a0b36ddcc
@@ -10,15 +10,15 @@ Einbau nur die Datenquelle getauscht werden muss.

 | Prototyp | HiveGrid-Entity | Verfügbar | Anmerkung |
 |---|---|---|---|
-| `Rechnung` | **`Rechnung`** (Sub-Entity am Projekt) | v1 | Status dort `entwurf/gestellt/bezahlt/storniert` — **kein `ueberfaellig`**. Überfälligkeit wird aus `faellig_am` gegen heute abgeleitet, nicht als Status geführt |
+| `Rechnung` | **`Rechnung`** (Sub-Entity am Projekt) | v1 | Status dort `entwurf/gestellt/bezahlt/storniert`: **kein `ueberfaellig`**. Überfälligkeit wird aus `faellig_am` gegen heute abgeleitet, nicht als Status geführt |
 | `Auftrag` | **`Projekt`** in einer Pipeline mit `typ_hint = auftrag` | v1 | „Auftrag" ist nach **AD-20 keine eigene Entität**, sondern eine Pipeline-View auf den Projekt-Kern. Wert = `auftragsvolumen`, Status = `stage_id` und damit **pipeline-intern** |
 | `Kunde` | **`Kontakt`** mit `kontakt_status = kunde` | v1 | „Kunde" ist ein **Status am Kontakt**, keine Entität. Kontakt ist der Oberbegriff (Privatperson/Organisation); die Verknüpfung zum Projekt läuft über `ProjektKontakt` mit Rolle `auftraggeber` |
 | `Mitarbeiter` | `TenantUser` + `User` | v1 | |
-| `Zeiteintrag` | — | **v2** | **Zeiterfassung steht im v2-Backlog.** Damit hat die gesamte Team-Seite in v1 keine Datenquelle — siehe unten |
+| `Zeiteintrag` |: | **v2** | **Zeiterfassung steht im v2-Backlog.** Damit hat die gesamte Team-Seite in v1 keine Datenquelle: siehe unten |

 > **Die Begriffe des Prototyps sind SHK-Fachsprache, nicht das Datenmodell der
 > Software.** „Auftrag" und „Kunde" existieren dort nicht als Entitäten. Das ist
-> kein Fehler des Prototyps — der Betrieb spricht so, und die Oberfläche soll so
+> kein Fehler des Prototyps, der Betrieb spricht so, und die Oberfläche soll so
 > sprechen. Beim Einbau ist es aber eine Übersetzungsleistung und keine
 > Eins-zu-eins-Zuordnung.

@@ -30,8 +30,8 @@ Auslastung, Produktivquote, erfasste Stunden und Abwesenheiten beruhen alle auf

 1. Team-Seite als v2 einplanen und in v1 nicht ausliefern;
 2. Stunden aus einem Drittsystem anbinden (der Betrieb erfasst sie ohnehin
-   irgendwo) — dann ist es eine Integrationsfrage, keine Modellfrage;
-3. Zeiterfassung nach v1 ziehen — die größte Entscheidung von den dreien.
+   irgendwo): dann ist es eine Integrationsfrage, keine Modellfrage;
+3. Zeiterfassung nach v1 ziehen, die größte Entscheidung von den dreien.

 Das ist eine Produktentscheidung, keine Gestaltungsfrage. Sie gehört vor den
 Einbau geklärt, weil sie eine von fünf Seiten betrifft.
@@ -60,7 +60,7 @@ hat. Ohne dieses Feld müsste der Trichter raten und würde die oberen Stufen
 systematisch zu klein zeigen.

 `ueberAngebot` trennt das Angebotsgeschäft (ab etwa 6.000 €) von Aufträgen, die
-direkt beauftragt werden — Wartung, Notdienst, E-Check. Trichter und
+direkt beauftragt werden: Wartung, Notdienst, E-Check. Trichter und
 Abschlussquote beziehen sich ausschließlich auf das Angebotsgeschäft.

 **Rechnung:** `entwurf` · `gestellt` · `bezahlt` · `ueberfaellig`.
@@ -84,7 +84,7 @@ Lüftungsanlage.

 ## Der Demo-Datensatz

-Erzeugt mit festem Seed (`mulberry32`, Seed `20260730`) — die Zahlen bleiben
+Erzeugt mit festem Seed (`mulberry32`, Seed `20260730`): die Zahlen bleiben
 über Reloads und Screenshots identisch. Bezugsdatum ist der **30.07.2026**
 (`HEUTE` in `utils/dateUtils.ts`).

@@ -104,15 +104,15 @@ Fiktiver Betrieb: **Meister Krause GmbH**, Raum Rhein-Main, 24 Beschäftigte

 **Eingebaute Effekte**, damit die Charts nicht künstlich flach aussehen:

- **Saisonalität** — Heizung und Lüftung ziehen von September bis Februar an,
+- **Saisonalität**: Heizung und Lüftung ziehen von September bis Februar an,
  der Hochsommer ist schwächer (`SAISON_INDEX`)
- **Wachstum** — rund 12 % gegenüber dem Vorjahr
- **Größenabhängige Abschlussquote** — Wartung und Notdienst werden fast immer
+- **Wachstum**, rund 12 % gegenüber dem Vorjahr
+- **Größenabhängige Abschlussquote**: Wartung und Notdienst werden fast immer
  ausgeführt, große Anlagen dagegen verglichen und häufiger verloren
- **Zahlungsverhalten** — die Mehrheit zahlt nahe am Zahlungsziel (21 Tage),
+- **Zahlungsverhalten**, die Mehrheit zahlt nahe am Zahlungsziel (21 Tage),
  ein kleiner Rest wird zum Mahnfall; Forderungen älter als sieben Monate sind
  eingebracht oder ausgebucht und stehen nicht mehr in der offenen Liste
- **Förderanträge** — nur bei Vorgängen der letzten rund 100 Tage offen; ein
+- **Förderanträge**, nur bei Vorgängen der letzten rund 100 Tage offen; ein
  Bescheid dauert Wochen, nicht Jahre

 Diese Effekte sind fachlich begründet, nicht kosmetisch: Ein gleichverteilter
@@ -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
@@ -19,7 +19,7 @@ absichtliche Korrektur.
 | **IBM Carbon Data Visualization** | Chart-Regeln, Farbpalette, Achsen, Tooltips, Kategorien-Obergrenze | laufend |

 Die ersten beiden liegen als lokale Ordner außerhalb dieses Repos und sind
-**nicht Teil der Übergabe** — alles fachlich Relevante daraus ist in `docs/`
+**nicht Teil der Übergabe**: alles fachlich Relevante daraus ist in `docs/`
 überführt. Die Zuordnung unten ist die Brücke zurück, falls jemand die
 Originale doch braucht.

@@ -32,7 +32,7 @@ sind hier eingeflossen:

 | Teil der Planung | Wirkung in diesem Repo |
 |---|---|
-| `01_CRM-Analytics-Clickdummy/` — React/Vite-Click-Dummy | Seitenschnitt, Komponentenzuschnitt, Filterarchitektur |
+| `01_CRM-Analytics-Clickdummy/`: React/Vite-Click-Dummy | Seitenschnitt, Komponentenzuschnitt, Filterarchitektur |
 | `UI_UX_GUIDELINES.md` | 8-px-Raster, Regel „innen ≤ außen", Zahlenformate, KPI-Karten-Aufbau |
 | `03_Planung-und-Konzept/Analytics/REQUIREMENTS-analytics.md` | Anforderungs-IDs (INFRA, DASH, FIN, ORD, CUST, COMP, FILT) |

@@ -45,11 +45,11 @@ Die Anforderungs-IDs stehen an mehreren Stellen als Kommentar im Code
 - **Fünf Analyse-Seiten** in derselben Reihenfolge: Übersicht, Finanzen,
  Aufträge, Kunden, Team
 - **Komponentenzuschnitt**: KPICard, ChartCard, AlertList, DataTable,
-  Filterleiste, Mehrfachauswahl mit Suche — dieselbe Aufteilung, neu geschrieben
+  Filterleiste, Mehrfachauswahl mit Suche: dieselbe Aufteilung, neu geschrieben
 - **Filterarchitektur**: globaler Filter-State über alle Seiten, in
  `localStorage` persistiert, aktive Einschränkungen als entfernbare Chips
 - **Seitenabhängige Filterrelevanz** (FILT-05) als Konzept
- **Recharts** als Chart-Bibliothek — dieselbe Wahl wie im Click-Dummy
+- **Recharts** als Chart-Bibliothek: dieselbe Wahl wie im Click-Dummy
 - **8-px-Raster und deutsche Zahlenformate** aus `UI_UX_GUIDELINES.md`,
  siehe [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) Abschnitt 5 und 7

@@ -63,7 +63,7 @@ Die Anforderungs-IDs stehen an mehreren Stellen als Kommentar im Code
 | **Chart-Elemente** | Drop-Shadow statt Rahmen | flach, Trennung über Weißraum und Segmentabstand | Schatten auf Datenflächen erzeugen eine Tiefe, die keine Bedeutung trägt |
 | **Fachlichkeit** | generisches CRM: Abteilungen, Bewertungen, Kundenkontakte | SHK-Handwerk: Gewerke, Förderung, Auslastung, Angebotsgeschäft | Auftrag dieses Prototyps |
 | **Bezeichner** | englisch (`revenue`, `orders`) | deutsch (`umsatz`, `auftraege`) | Die Oberfläche ist deutsch. Ein Bruch in der Mitte erzwingt beim Einbau ständiges Übersetzen |
-| **Datensatz** | 25 Mitarbeiter, 200 Kunden, 800 Aufträge, gleichverteilt | 24, 420, 1.900 — mit Saisonalität, Wachstum, Zahlungsverhalten | An einem gleichverteilten Datensatz lässt sich keine Gestaltung prüfen, siehe [DATENMODELL.md](DATENMODELL.md) |
+| **Datensatz** | 25 Mitarbeiter, 200 Kunden, 800 Aufträge, gleichverteilt | 24, 420, 1.900: mit Saisonalität, Wachstum, Zahlungsverhalten | An einem gleichverteilten Datensatz lässt sich keine Gestaltung prüfen, siehe [DATENMODELL.md](DATENMODELL.md) |

 ### Anforderungen, die hier nicht umgesetzt sind

@@ -75,7 +75,7 @@ fehlen vier davon bewusst:
 | INFRA-03 | Filter-Presets speichern und laden | Bedienkomfort ohne Gestaltungsfrage. Gehört in die echte Software ans Benutzerprofil, nicht in die Vorlage |
 | INFRA-04 (teilweise) | Zeitraum mit benutzerdefiniertem Bereich | Die sechs Presets decken die Abstimmung ab; ein Datumsbereichs-Picker ist eine Umsetzungs-, keine Gestaltungsfrage |
 | FILT-02 / FILT-04 | Filter für Rechnungsstatus und Betragsbereich | Rechnungsstatus ist auf der Finanzseite bereits als Chart-Dimension sichtbar; ein Betragsfilter verzerrt Summen-KPIs, ohne dass es an der Karte steht |
-| CUST-03 | KPI „Kontakte gesamt" | Der Prototyp führt keine Kontakt-Entität. In HiveGrid existiert sie — die Karte lässt sich beim Einbau ergänzen |
+| CUST-03 | KPI „Kontakte gesamt" | Der Prototyp führt keine Kontakt-Entität. In HiveGrid existiert sie, die Karte lässt sich beim Einbau ergänzen |

 Umgekehrt ist **Team** enthalten, obwohl die Planung es unter v2 führt
 (TEAM-01 bis TEAM-03): Auslastung ist im Handwerk die Kennzahl, nach der
@@ -90,10 +90,10 @@ gesamte Oberfläche außerhalb der Diagramme.

 | Übernommen | Wo |
 |---|---|
-| Komponentenbibliothek — 86 Komponenten, 4 Layouts | `ui/components/`, `ui/layouts/` |
+| Komponentenbibliothek: 86 Komponenten, 4 Layouts | `ui/components/`, `ui/layouts/` |
 | Design-Tokens (Farben, Radien, Schatten, Typo-Skala) | `ui/theme.css`, eingebunden in `app/globals.css` |
 | Icon-Set (Feather über `@subframe/core`) | überall, aufgelöst in `components/layout/FeatherIcon.tsx` |
-| Stack | Next.js 16 · React 19 · Tailwind v4 — gleiche Versionen |
+| Stack | Next.js 16 · React 19 · Tailwind v4: gleiche Versionen |

 `ui/` ist **byteidentisch** mit dem Stand im Pitch-Repo und wurde nicht
 angefasst. Die Bibliothek wird dort über die Subframe-CLI aus dem Projekt
@@ -104,7 +104,7 @@ npx @subframe/cli@latest sync --all
 ```

 Wer die Bibliothek aktualisiert, sollte das im Pitch-Repo tun und den Ordner
-hierher kopieren — sonst laufen die beiden Stände auseinander.
+hierher kopieren, sonst laufen die beiden Stände auseinander.

 ### Was aus der Bibliothek nicht verwendet wird

@@ -115,7 +115,7 @@ Carbon-Regeln umzusetzen. Die Diagramme unter
 `features/dashboard/components/charts/` setzen deshalb direkt auf Recharts auf.

 Das ist die einzige Stelle, an der dieser Prototyp von der Pitch-Bibliothek
-abweicht — überall sonst gilt sie.
+abweicht: überall sonst gilt sie.

 ---

@@ -126,7 +126,7 @@ Grundlage aller Diagramm-Entscheidungen. Ausformuliert in
 `features/dashboard/utils/chartTheme.ts`.

 Die Farb- und Linienwerte sind aus dem ausgelieferten Stylesheet von
-`@carbon/charts` (`dist/styles.css`, Light Theme) übernommen — nicht aus der
+`@carbon/charts` (`dist/styles.css`, Light Theme) übernommen, nicht aus der
 Dokumentation abgeschrieben. Das Paket selbst ist **keine Abhängigkeit** dieses
 Repos; gezogen wurden nur die Werte.

@@ -5,8 +5,8 @@ Alle Funktionen liegen in `features/dashboard/data/calculations.ts`.

 **Zwei Zeitbezüge sind zu unterscheiden:**

- **zeitraumbezogen** — reagiert auf die Zeitraum-Umschaltung (Umsatz, neue Kunden)
- **stichtagsbezogen** — gilt zum heutigen Tag, unabhängig vom Zeitraum
+- **zeitraumbezogen**: reagiert auf die Zeitraum-Umschaltung (Umsatz, neue Kunden)
+- **stichtagsbezogen**: gilt zum heutigen Tag, unabhängig vom Zeitraum
  (offene Forderungen, aktive Aufträge, Auslastung des Bestands)

 Das ist Absicht: „Offene Forderungen der letzten 7 Tage" wäre keine sinnvolle
@@ -14,7 +14,7 @@ Zahl.

 In der Oberfläche steht der Zeitbezug in der **Fußzeile jeder KPI-Karte**
 („im gewählten Zeitraum" / „zum Stichtag" / „über alle Zeiträume"). Karten mit
-Vorperiodenvergleich zeigen dort stattdessen den Trend — die Anatomie bleibt
+Vorperiodenvergleich zeigen dort stattdessen den Trend, die Anatomie bleibt
 gleich, damit die Reihe eine gemeinsame Grundlinie hat. Diagrammkarten, die
 den Zeitraumfilter ignorieren, sagen es im Untertitel.

@@ -35,7 +35,7 @@ den Zeitraumfilter ignorieren, sagen es im Untertitel.

 **Umsatzentwicklung** (`umsatzVerlauf()`) bildet zusätzlich den
 Vorjahreszeitraum ab: Jede Zahlung wird um zwölf Monate verschoben in denselben
-Zeitraster einsortiert. Die Auflösung wechselt automatisch — bis 30 Tage
+Zeitraster einsortiert. Die Auflösung wechselt automatisch, bis 30 Tage
 tageweise, darüber monatsweise.

 ---
@@ -73,7 +73,7 @@ grün nach rot eingefärbt.
 | Vertriebstrichter | Vorgänge je erreichter Stufe | Stichtag | `vertriebsTrichter()` |
 | Förderquote BAFA/KfW | Anteil **förderfähiger** Aufträge mit beantragter oder bewilligter Förderung | Stichtag | `foerderQuote()` |

-**Zum Trichter:** Er zeigt ausschließlich das **Angebotsgeschäft** — Vorhaben
+**Zum Trichter:** Er zeigt ausschließlich das **Angebotsgeschäft**: Vorhaben
 ab etwa 6.000 €, für die schriftlich angeboten wird (Feld `ueberAngebot`).
 Wartung, Notdienst und E-Check gehen ohne Angebot direkt in die Ausführung;
 zählte man sie mit, würde der Trichter unten breiter als oben.
@@ -83,12 +83,12 @@ Verlorene Vorgänge zählen bis zu der Stufe, auf der sie abgesprungen sind
 systematisch zu klein und die Übergangsquoten wertlos.

 **Zur Abschlussquote:** gleiche Bezugsgröße wie der Trichter. Sie entspricht
-deshalb exakt der Übergangsquote von „Angebot" auf „Beauftragt" — im
+deshalb exakt der Übergangsquote von „Angebot" auf „Beauftragt": im
 Demo-Datensatz rund 38 %.

 **Zur Förderquote:** Bezugsgröße sind nur förderfähige Leistungen (Wärmepumpe,
 PV-Anlage, Batteriespeicher, Lüftungsanlage). Über alle Aufträge gerechnet läge
-sie im einstelligen Bereich und wäre wertlos — eine Badsanierung war nie
+sie im einstelligen Bereich und wäre wertlos, eine Badsanierung war nie
 förderfähig.

 ---
@@ -97,7 +97,7 @@ förderfähig.

 | KPI | Definition | Bezug | Funktion |
 |---|---|---|---|
-| Kunden gesamt | Alle Kundendatensätze | Stichtag | — |
+| Kunden gesamt | Alle Kundendatensätze | Stichtag |: |
 | Neue Kunden | Anlagedatum im Zeitraum | Zeitraum | `neueKunden()` |
 | Wiederkehrende Kunden | Anteil mit mehr als einem Auftrag | Stichtag | `wiederkehrquote()` |
 | Ø Kundenwert | Bezahlter Umsatz je Kunde mit mindestens einem Auftrag | gesamt | abgeleitet |
@@ -106,7 +106,7 @@ förderfähig.
 | Auffällige Zahlungsmoral | Ø Zahlungsdauer über 30 Tage | Stichtag | `zahlungsauffaellig()` |

 Empfehlung und Bestandskunden zusammen zeigen, wie stark der Betrieb ohne
-Werbebudget wächst — im Handwerk die aussagekräftigste Quellenkennzahl.
+Werbebudget wächst, im Handwerk die aussagekräftigste Quellenkennzahl.

 ---

@@ -114,7 +114,7 @@ Werbebudget wächst — im Handwerk die aussagekräftigste Quellenkennzahl.

 | KPI | Definition | Bezug | Funktion |
 |---|---|---|---|
-| Im Einsatz | Gewerblich Beschäftigte mit Status „aktiv" | Stichtag | — |
+| Im Einsatz | Gewerblich Beschäftigte mit Status „aktiv" | Stichtag |: |
 | Ø Auslastung | Produktive Stunden / verfügbare Stunden (aus Wochenstunden hochgerechnet) | Zeitraum | `teamKennzahlen()` |
 | Produktivquote | Auftragsbezogene Stunden / erfasste Stunden | Zeitraum | abgeleitet |
 | Erfasste Stunden | Summe aller Zeiteinträge | Zeitraum | abgeleitet |
@@ -126,9 +126,9 @@ Werbebudget wächst — im Handwerk die aussagekräftigste Quellenkennzahl.

 | Bereich | Bedeutung |
 |---|---|
-| < 70 % | Luft frei — Kapazität ungenutzt |
+| < 70 % | Luft frei: Kapazität ungenutzt |
 | 70–95 % | Zielkorridor |
-| > 95 % | Ausgebucht — Terminrisiko |
+| > 95 % | Ausgebucht: Terminrisiko |

 Der Auftragswert je Mitarbeiter ist ausdrücklich **kein Leistungsvergleich**:
 Ein Wärmepumpen-Auftrag ist um ein Vielfaches größer als eine Wartung. Der
@@ -1,12 +1,12 @@
 # Leitplanken aus HiveGrid Cloud

-Welche Bereiche der Zielanwendung bereits Davids finale Subframe-Screens tragen
-und welche noch auf Interim-UI laufen — und was daraus für dieses Dashboard
+Welche Bereiche der Zielanwendung bereits Davids finale Subframe-Screens tragen,
+welche noch auf Interim-UI laufen, und was daraus für dieses Dashboard
 verbindlich ist.

 Warum die Unterscheidung zählt: Ein nachgezogener Screen ist eine
 **Design-Entscheidung**, an der man sich ausrichten kann. Eine Interim-UI ist
-eine **Notlösung des Devs** — sie kopieren hieße, einen Platzhalter zum Standard
+eine **Notlösung des Devs**, sie kopieren hieße, einen Platzhalter zum Standard
 zu erklären.

 Stand der Auswertung: 2026-08-29 gegen den lokalen Repo-Stand.
@@ -20,62 +20,62 @@ Der Repo pflegt dafür bewusste Marker. In absteigender Verlässlichkeit:
 | Muster | Bedeutung |
 |---|---|
 | `Interim-UI (AD-28)` im Kopfkommentar | Optik ist ausdrücklich vorläufig |
-| `design-nachzug` | offener Punkt — steht auch in sonst fertigen Screens für einzelne Reste |
+| `design-nachzug` | offener Punkt: steht auch in sonst fertigen Screens für einzelne Reste |
 | Kopfkommentar mit Subframe-Screen-ID (`WF-P8 S03`, `S02/S02L/S03/S05`), Page-UUID oder „gegen Davids Export vom …" | nachgezogen, Optik ist abgestimmt |
 | `@subframe/sync-disable` in `apps/web/app/ui/**` | lokal geänderte Komponente, die der Sync nicht überschreiben darf |

 Ein typischer Interim-Kopf (`projects/PipelineKanbanPage.tsx`):

-> `// R-P8b (P8 configurable Kanban) Interim-UI (AD-28) — pipeline board screen`
+> `// R-P8b (P8 configurable Kanban) Interim-UI (AD-28): pipeline board screen`
 > `// (D-KANBAN), composed from ~/ui …`

 Ein typischer nachgezogener Kopf (`projects/ProjektListPage.tsx`):

-> `// WF-P8 S03 "Projekt-Liste" — rebuilt against Davids Subframe export of`
+> `// WF-P8 S03 "Projekt-Liste": rebuilt against Davids Subframe export of`
 > `// 2026-07-28 (page 5c5bdb0a-995e-4c22-aa8b-e48333c60297) …`

 **Autoritativ ist aber die Liste, nicht der Kommentar:**
 `.planning/SUBFRAME-FLOW-INVENTAR.md` trackt jeden Subframe-Flow mit Seitenzahl,
 Owner und Stand. Der dortige Hinweis ist wichtig: Der Subframe-Sync pflegt nur
-Components, Layouts und Theme — **Pages werden nie automatisch integriert**,
+Components, Layouts und Theme: **Pages werden nie automatisch integriert**,
 jeder Screen wird einzeln hinter der Loader/Action-Grenze verdrahtet.

 **Grenze der Methode:** Ein fehlender Marker sagt nichts. Von 214
 `*Page.tsx`-Dateien tragen 92 einen Interim-Marker, 36 einen Subframe-Bezug und
-**86 gar keinen** — überwiegend Plattform-Admin (31) und Integrationen (13),
+**86 gar keinen**: überwiegend Plattform-Admin (31) und Integrationen (13),
 also interne Flächen mit niedrigem Politur-Druck.

 ---

 ## 2. Die Abgrenzung

-### Nachgezogen — als Leitplanke brauchbar
+### Nachgezogen, als Leitplanke brauchbar

 | Bereich | Stand laut Inventar | Im Code |
 |---|---|---|
-| **Team-Chat** | 🟢 24 von 24 Screens integriert (Handoff 2026-08-08) | `screens/chat/` — kein einziger Interim-Marker |
-| **Form-Builder** | ✅ integriert (PR #71) | `screens/forms/` — Kopf nennt „WF-P16, screens S02/S02L/S03/S05" |
-| **Automation / Workflow-Editor** | 🟡 voller Delta-Nachzug (Davids „V1 Vollbild minimal") | `screens/automation/` — 6 Screens mit Subframe-Bezug, keiner interim |
-| **Projekt-Pipelines** | 🟡 Kernstrecke S01–S07 integriert | `screens/projects/` — 7 nachgezogen, 4 noch interim (darunter das Kanban selbst) |
-| **Aufgaben** | 🟡 Stufen 0–6 fertig | `screens/tasks/` — 2 nachgezogen, 1 interim |
-| **Lead-Liste** | 🟡 Kernstrecke (`/leads` = S01, `/leads/inbox` = S02) | `screens/leads/` — 2 nachgezogen, 6 noch interim |
+| **Team-Chat** | 🟢 24 von 24 Screens integriert (Handoff 2026-08-08) | `screens/chat/`, kein einziger Interim-Marker |
+| **Form-Builder** | ✅ integriert (PR #71) | `screens/forms/`: Kopf nennt „WF-P16, screens S02/S02L/S03/S05" |
+| **Automation / Workflow-Editor** | 🟡 voller Delta-Nachzug (Davids „V1 Vollbild minimal") | `screens/automation/`: 6 Screens mit Subframe-Bezug, keiner interim |
+| **Projekt-Pipelines** | 🟡 Kernstrecke S01–S07 integriert | `screens/projects/`: 7 nachgezogen, 4 noch interim (darunter das Kanban selbst) |
+| **Aufgaben** | 🟡 Stufen 0–6 fertig | `screens/tasks/`: 2 nachgezogen, 1 interim |
+| **Lead-Liste** | 🟡 Kernstrecke (`/leads` = S01, `/leads/inbox` = S02) | `screens/leads/`: 2 nachgezogen, 6 noch interim |

-### Vollständig Interim — nicht als Vorbild nehmen
+### Vollständig Interim, nicht als Vorbild nehmen

 Kein einziger nachgezogener Screen: **HR** (21 Seiten), **Mobile-PWA** (19),
 **CRM** (6), **Booking** (5), **DSGVO/Privacy** (5), **E-Mail-Postfach** (4),
-**Files** (3), **Kalender** (2), **Audit** (2), Signatur, Plugins, Auth —
+**Files** (3), **Kalender** (2), **Audit** (2), Signatur, Plugins, Auth,
 **und das Dashboard** (1).

 ### Noch gar nicht entworfen

 Die zehn Auth-Flows (Login/2FA, Passwort-Reset, Set-Password, Admin-RBAC,
 Signup, Konto löschen, 2FA verwalten, Passwort ändern, Workspace-Auswahl,
-Profil & Sicherheit) stehen im Inventar auf ❌ offen — zusammen 44 Seiten.
+Profil & Sicherheit) stehen im Inventar auf ❌ offen: zusammen 44 Seiten.

 Ergänzend: Die 30 Designer-Briefs unter `.planning/designer-briefs/` haben ihren
 Block „Davids Delta" durchgehend **leer**. Die tatsächlichen Handoffs werden
-über das Flow-Inventar und die Ticket-Docs geführt, nicht über die Briefs —
+über das Flow-Inventar und die Ticket-Docs geführt, nicht über die Briefs,
 102 Ticket-Docs führen einen offenen `design-nachzug`.

 ---
@@ -100,7 +100,7 @@ Die API ist knapp:

 Unsere `KPICard` kann mehr: Sparkline, Akzentfarbe, `richtungGut` (steigender
 Wert ist je nach Kennzahl gut oder schlecht), Trendlabel, ⋯-Menü zum Ausblenden.
-Das ist fachlich begründet — **aber es ist eine Abweichung vom gesetzten
+Das ist fachlich begründet: **aber es ist eine Abweichung vom gesetzten
 Baustein.** Beim Einbau gibt es genau zwei saubere Wege:

 1. `StatsCard` erweitern und die Datei mit `@subframe/sync-disable` schützen
@@ -118,7 +118,7 @@ mobile:grid-cols-1 grid w-full grid-cols-4 gap-4
 ```

 `gap-4` = 16 px = unser Kartenabstand ✓. Das `mobile:`-Präfix ist der
-hauseigene Breakpoint und in 44 Stellen belegt — unser Prototyp hat kein
+hauseigene Breakpoint und in 44 Stellen belegt: unser Prototyp hat kein
 Mobil-Verhalten und muss es beim Einbau ergänzen.

 ### 3.3 Filterleiste: `FilterBar` statt Eigenbau
@@ -126,11 +126,11 @@ Mobil-Verhalten und muss es beim Einbau ergänzen.
 `ProjektListPage`, `AutomationListPage`, `AutomationExecutionsPage`,
 `FormsAdminPage` und die Betriebsmittel-Übersicht nutzen alle
 `~/ui/components/FilterBar`. Unsere `AnalyticsToolbar` ist handgebautes
-Tailwind — funktional gleichwertig, aber am gesetzten Baustein vorbei. Das ist
+Tailwind: funktional gleichwertig, aber am gesetzten Baustein vorbei. Das ist
 die auffälligste Stelle, an der der Prototyp beim Einbau umgestellt gehört.

 Bemerkenswert: Die Betriebsmittel-Übersicht wurde 2026-08-19 genau in diese
-Richtung überarbeitet — „auf kompakte Kennzahlen plus echte `FilterBar`
+Richtung überarbeitet: „auf kompakte Kennzahlen plus echte `FilterBar`
 umgestellt". Kennzahlenreihe über Filterleiste über Liste ist dort also bereits
 das etablierte Muster. Unser Seitenaufbau folgt derselben Logik.

@@ -139,7 +139,7 @@ das etablierte Muster. Unser Seitenaufbau folgt derselben Logik.
 - Seitenkopf über `PageShell` / `PageHeader` / `PageBody`, nie eigenes Chrome
 - i18n mit Namespace: `t("billing:subscriptionOverview.summary.plan")`
 - Screen-Komponente ist rein: `({ vm, actions })`, kein `useLoaderData`,
-  kein `useFetcher` — Navigation und Schreibpfade sind Callbacks
+  kein `useFetcher`: Navigation und Schreibpfade sind Callbacks
 - Tabellen über `~/ui/components/Table`, Dichte über die Komponente wählen

 ---
@@ -148,7 +148,7 @@ das etablierte Muster. Unser Seitenaufbau folgt derselben Logik.

 Recharts kommt im gesamten Repo an **drei** Stellen vor: die beiden
 Dashboard-Diagramme und `leads/LeadAnalyticsPage.tsx`. Es gibt keine geteilte
-Palette, kein Chart-Theme, keine Kategorienregel — die vorhandenen Diagramme
+Palette, kein Chart-Theme, keine Kategorienregel, die vorhandenen Diagramme
 setzen ihre Farben direkt im JSX.

 Auch Davids Standards decken das nicht ab:
@@ -157,12 +157,12 @@ Dialoggrößen und Zustände sehr genau, **Datenvisualisierung gar nicht**.

 Für dieses Dashboard heißt das beides:

- Für Kacheln, Filter, Tabellen und Seitenaufbau **gibt es** einen Standard —
+- Für Kacheln, Filter, Tabellen und Seitenaufbau **gibt es** einen Standard,
  daran halten wir uns, statt ihn neu zu erfinden.
 - Für Diagramme gibt es keinen. Was wir in
  [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) und `chartTheme.ts` festlegen, füllt eine
  echte Lücke und wird im Zweifel zur Referenz für alle späteren Charts. Das ist
-  der wertvollste, aber auch der begründungspflichtigste Teil der Übergabe —
+  der wertvollste, aber auch der begründungspflichtigste Teil der Übergabe,
  deshalb steht zu jeder Regel dort, warum sie so ist.

 ---
@@ -183,7 +183,7 @@ cat .planning/SUBFRAME-FLOW-INVENTAR.md
 ```

 Die Zahlen in diesem Dokument sind eine Momentaufnahme. Das Flow-Inventar wird
-fortgeschrieben (Stand dort: 2026-08-25, 12. Update) — vor einer Entscheidung
+fortgeschrieben (Stand dort: 2026-08-25, 12. Update). Vor einer Entscheidung
 lieber neu zählen.

 ---
@@ -192,7 +192,7 @@ lieber neu zählen.

 > Vorab, damit die folgende Tabelle nicht falsch gelesen wird: **Eine bewusste
 > Abweichung ist eine Bitte um eine Entscheidung, kein Freibrief.** Bei
-> globalen Regeln — Schrift, Größen, Abstände, Farben, Control-Höhen — gilt
+> globalen Regeln (Schrift, Größen, Abstände, Farben, Control-Höhen) gilt
 > ohne Diskussion HiveGrid. Die Punkte unten betreffen ausschließlich den
 > Analytics-Bereich und sind begründet, damit sie beim Einbau nicht
 > versehentlich „korrigiert" werden. Rangfolge: [ZIELSYSTEM.md](ZIELSYSTEM.md)
@@ -205,7 +205,7 @@ als **Entscheidung** erkennbar sind und nicht als Versehen wegkorrigiert werden.
 | Thema | Cloud | Hier | Begründung |
 |---|---|---|---|
 | **Zahlen in Tabellen** | linksbündig; `align-right` nur für die Aktionsspalte | rechtsbündig mit `tabular-nums` | IBM Carbon und die eigene Planung (`UI_UX_GUIDELINES.md` §2) verlangen es: Nur rechtsbündig stehen Tausenderstellen untereinander, und genau darum geht es in einem Analytics-Dashboard. Die Cloud-Tabellen zeigen überwiegend Text, nicht Beträge |
-| **Filterleiste** | `~/ui` `FilterBar` mit Facetten-Slots | eigene `AnalyticsToolbar` | Der Prototyp braucht ein Zeitraum-Segment-Control, das die FilterBar nicht kennt. Beim Einbau ist das der erste Umbau — die Logik passt fast 1:1 auf `FacetFilterBar` |
+| **Filterleiste** | `~/ui` `FilterBar` mit Facetten-Slots | eigene `AnalyticsToolbar` | Der Prototyp braucht ein Zeitraum-Segment-Control, das die FilterBar nicht kennt. Beim Einbau ist das der erste Umbau, die Logik passt fast 1:1 auf `FacetFilterBar` |
 | **Formatierung** | `locale/format.ts`, Prozent erwartet 0–1 | eigene `formatters.ts`, Prozent erwartet 0–100 | Der Prototyp hat keine i18n-Schicht. Beim Einbau ersetzen, aber die **Achsenformatierung** (`achsenFormat`, `nettesRaster`) hat dort kein Gegenstück und sollte mitkommen |

 Umgekehrt übernommen wurden: keine Versalien in Spaltenköpfen, Raster mit 16 px
@@ -215,7 +215,7 @@ Visualisierung.
 **Bereits umgesetzt:** Die Seiten sind reine `({ vm })`-Komponenten mit dem
 wortgleich gespiegelten `VMState`-Vertrag, die Berechnung liegt in reinen
 Buildern unter `view-models/`, und die fünf Seitenzustände sind ausgestaltet.
-Store-Zugriff gibt es ausschließlich in `routes/` — genau der Schicht, die beim
+Store-Zugriff gibt es ausschließlich in `routes/`, genau der Schicht, die beim
 Einbau durch den Loader ersetzt wird.

 **Offen für den Einbau** (Portierungsarbeit, keine Gestaltung): Texte über
@@ -4,12 +4,12 @@

 Die Seitenleiste zeigt **nur unsere beiden Features**. Kontakte, Leads,
 Pipelines, Postfach, Termine und Einstellungen stehen bereits in der
-Seitenleiste der Software und werden hier nicht verdoppelt — der Prototyp zeigt,
+Seitenleiste der Software und werden hier nicht verdoppelt, der Prototyp zeigt,
 was dazukommt, nicht was schon da ist.

 ```
 HIVEGRID
-├── Dashboard          Begrüßungsbildschirm — Widget-Fläche   /dashboard
+├── Dashboard          Begrüßungsbildschirm: Widget-Fläche   /dashboard
 └── Analytics          ◄── der Prototyp lebt hier   /analytics
 ├─────────────────────
 └── Komponenten        Bausteingalerie des Prototyps   /komponenten
@@ -19,12 +19,12 @@ Gerendert wird mit derselben Komponente wie in der Software
 (`ui/components/SidebarWithSections`, aus der Cloud-Fassung portiert) und
 derselben Schrift (Instrument Sans, selbst gehostet aus denselben Dateien).

-> **Für den Einbau:** Verbindlich ist an dieser Seitenleiste die **Struktur** —
+> **Für den Einbau:** Verbindlich ist an dieser Seitenleiste die **Struktur**,
 > zwei Einträge, Analytics mit innerer Leiste. Nicht verbindlich ist ihre
 > Umsetzung hier. In der Software werden die zwei Einträge in die bestehende
 > `AppSidebar` eingehängt und die innere Leiste über das dortige
 > `SidebarIconsLayout` gebaut; unser Nachbau wird nicht mitportiert. Globale
-> Regeln — Schrift, Größen, Abstände, Farben — kommen ausschließlich aus
+> Regeln (Schrift, Größen, Abstände, Farben) kommen ausschließlich aus
 > HiveGrid und werden von hier aus **nicht** überschrieben. Siehe
 > [ZIELSYSTEM.md](ZIELSYSTEM.md) Abschnitt 0.

@@ -39,8 +39,8 @@ Analyse-Seiten sind darin über eine **innere Leiste** erreichbar:
 /analytics/team       Team
 ```

-Zwei Navigationsebenen für dieselbe Sache — Unterpunkte in der Seitenleiste
-*und* eine innere Leiste — würden nur konkurrieren.
+Zwei Navigationsebenen für dieselbe Sache: Unterpunkte in der Seitenleiste
+*und* eine innere Leiste: würden nur konkurrieren.

 ### Warum innere Leiste und nicht Reiter

@@ -49,9 +49,9 @@ Beides gibt es im Zielsystem, aber für verschiedene Aufgaben:
 | | innere Leiste (`SidebarIconsLayout`) | Reiter (`Tabs`) |
 |---|---|---|
 | Wofür | Arbeitsbereich mit **Geschwisterseiten** | Abschnitte **innerhalb einer Seite** |
-| Beispiele | Leads, Termine, HR, Einstellungen — 17 Aufrufstellen | Formular-Editor, Chat-Dateien, Projekt-Teilbereiche, Übergabe-Dialog |
+| Beispiele | Leads, Termine, HR, Einstellungen: 17 Aufrufstellen | Formular-Editor, Chat-Dateien, Projekt-Teilbereiche, Übergabe-Dialog |

-Analytics mit fünf Analyse-Seiten ist der erste Fall — strukturell dasselbe wie
+Analytics mit fünf Analyse-Seiten ist der erste Fall: strukturell dasselbe wie
 Leads mit seinen acht. Drei Gründe geben den Ausschlag:

 1. **Kohärenz.** Wer in der Software von Leads nach Analytics wechselt, findet
@@ -59,7 +59,7 @@ Leads mit seinen acht. Drei Gründe geben den Ausschlag:
 2. **Der Platzeinwand trägt nicht.** Die Leiste ist standardmäßig eine 32 px
   schmale Icon-Spalte und klappt erst bei Zeigerkontakt oder Tastaturfokus auf
   Beschriftungen aus (verzögert, damit sie beim Überstreichen nicht
-   aufspringt). Sie kostet also kaum Breite — und die brauchen die
+   aufspringt). Sie kostet also kaum Breite, und die brauchen die
   Analyse-Seiten mit ihren fünfspaltigen Kennzahlenreihen und breiten Tabellen.
 3. **Reiter sind dort der Rückfall, nicht die Wahl.** `SidebarIconsLayout`
   zeigt unterhalb `sm` selbst eine Reiterleiste. Auf dem Schreibtisch Reiter zu
@@ -67,23 +67,23 @@ Leads mit seinen acht. Drei Gründe geben den Ausschlag:
   übernimmt diesen Rückfall mit.

 Ein weiterer Vorteil: Die Leiste wächst. Käme eine sechste Analyse-Seite dazu,
-ist das eine Zeile mehr — ein Reiterband würde eng.
+ist das eine Zeile mehr, ein Reiterband würde eng.

 „Dashboard" führt auf den **Begrüßungsbildschirm** unter `/dashboard`. Er hat
 bewusst **keine innere Leiste und keine Filterleiste**: Er ist eine einzelne
 Seite aus Kacheln, und jede Kachel trägt ihren eigenen Zeitraum. Das ist der
-sichtbarste Unterschied zwischen den beiden Menüpunkten — Analytics ist ein
+sichtbarste Unterschied zwischen den beiden Menüpunkten: Analytics ist ein
 Bereich, das Dashboard eine Seite. Siehe
 [SCOPE-ANALYTICS-DASHBOARD.md](SCOPE-ANALYTICS-DASHBOARD.md).

 ### Schmale Fenster

-Unterhalb **768 px** — derselbe Breakpoint, den die Software als `MOBILE_BREAKPOINT`
-führt — fährt die Seitenleiste als Schublade über den Inhalt, statt ihn zu
+Unterhalb **768 px**: derselbe Breakpoint, den die Software als `MOBILE_BREAKPOINT`
+führt: fährt die Seitenleiste als Schublade über den Inhalt, statt ihn zu
 verdrängen. Geöffnet wird sie über einen Hamburger links in der Kopfzeile.

 Das ist **nicht erfunden, sondern abgeglichen**: `SubframeAppShell` im
-Zielsystem rendert an derselben Stelle denselben Knopf — `FeatherMenu`, 32 × 32,
+Zielsystem rendert an derselben Stelle denselben Knopf: `FeatherMenu`, 32 × 32,
 `md:hidden`, links vor dem Breadcrumb. Übernommen wurden auch das Verhalten der
 Schublade (Abdeckung dahinter, Escape schließt, Fokus wandert beim Öffnen auf
 den ersten Eintrag und kehrt beim Schließen zum Auslöser zurück) und die
@@ -128,14 +128,14 @@ es sich entwickelt? → Woran liegt es?**
 Auf der **Übersicht** steht der Handlungsbedarf direkt unter der KPI-Reihe und
 über die volle Breite. Sie ist die Seite der Geschäftsführung; dort ist „was ist
 zu tun" die zweite Frage, nicht die letzte. Jede Zeile trägt Betrag und Handlung
-(„Mahnlauf starten", „Nachfassen") — eine Liste ohne Verb ist ein Bericht.
+(„Mahnlauf starten", „Nachfassen"): eine Liste ohne Verb ist ein Bericht.

 Auf den vier Detailseiten bleibt die Arbeitsliste unten: Dort ist sie die
 Konsequenz aus dem, was darüber steht.

 **Gleiche Kartenhöhe nur bei gleicher Struktur.** Die KPI-Reihe wird gestreckt,
 damit die fünf Karten als ein Objekt lesbar sind. Gemischte Reihen (Diagramm
-mit fester Höhe neben Tabelle) stehen auf `items-start` — Strecken erzeugt dort
+mit fester Höhe neben Tabelle) stehen auf `items-start`: Strecken erzeugt dort
 nur Weißraum.

 ---
@@ -173,5 +173,5 @@ Definiert in `features/dashboard/data/filtering.ts`:
 | Team | ✓ | ✓ | | | | ✓ |

 Ein Filter, der sichtbar ist aber nichts bewirkt, kostet Vertrauen in die
-Zahlen. Deshalb werden irrelevante Filter gar nicht erst angeboten — die
+Zahlen. Deshalb werden irrelevante Filter gar nicht erst angeboten, die
 Auswahl bleibt aber im Hintergrund erhalten und wirkt beim Seitenwechsel wieder.
@@ -1,7 +1,7 @@
 # Prüffragen für die Gestaltungsabnahme

 Für Reviews ohne Designerauge. Die Fragen sind so gestellt, dass man sie am
-Bildschirm beantworten kann — jede hat ein nachprüfbares Ja oder Nein, keine
+Bildschirm beantworten kann, jede hat ein nachprüfbares Ja oder Nein, keine
 Geschmacksfrage.

 Reihenfolge nach Wirkung: Wer nur zehn Minuten hat, nimmt Abschnitt 1.
@@ -33,7 +33,7 @@ Handlungsliste braucht je Zeile einen Betrag und ein Verb.

 | Frage | Wenn nein |
 |---|---|
-| Beginnt jede Balkenachse bei null? | Balken kodieren über Länge — abgeschnitten lügen sie. Bei engen Wertebändern Punktdiagramm statt Balken |
+| Beginnt jede Balkenachse bei null? | Balken kodieren über Länge: abgeschnitten lügen sie. Bei engen Wertebändern Punktdiagramm statt Balken |
 | Hat jede Achse runde Werte (0/50/100, nicht 0/55/110)? | Der Leser rechnet bei jedem Blick mit |
 | Trägt eine Achse genau eine Einheit? | „0 €" neben „10 T€" ist ein Einheitenwechsel mitten in der Skala |
 | Belegt in einem Ring kein Segment mehr als etwa 80 %? | Dann ist die Bezugsgröße falsch gewählt, nicht der Diagrammtyp |
@@ -58,7 +58,7 @@ Handlungsliste braucht je Zeile einen Betrag und ein Verb.
 ## 4. Layout, Raster und Zustände

 **Vor jedem Review `npm run verify:layout` laufen lassen.** Der Prüfer findet
-kollidierenden und überlaufenden Text über sieben Fensterbreiten — das ist die
+kollidierenden und überlaufenden Text über sieben Fensterbreiten, das ist die
 eine Fehlerklasse, die man mit dem Auge zuverlässig übersieht, weil sie nur in
 bestimmten Breiten auftritt.

@@ -81,11 +81,11 @@ Ringlegenden, Achsenbeschriftungen und Tabellenköpfe achten.

 Kurz und ergiebig, in dieser Reihenfolge:

-1. **FT Visual Vocabulary** — ein Poster, das Diagrammtypen nach Aussageabsicht
+1. **FT Visual Vocabulary**, ein Poster, das Diagrammtypen nach Aussageabsicht
   ordnet (Vergleich, Verteilung, Anteil, Veränderung …).
   Das beste Verhältnis von Aufwand zu Ertrag überhaupt.
   `github.com/Financial-Times/chart-doctor` → `visual-vocabulary`
-2. **IBCS — International Business Communication Standards**, die SUCCESS-Regeln.
+2. **IBCS: International Business Communication Standards**, die SUCCESS-Regeln.
   Das ist der ausgearbeitete Standard für *Geschäfts*grafik, den Carbon nicht
   ersetzt: einheitliche Notation, Ist/Plan/Vorjahr, Informationsdichte.
   Frei unter CC BY-SA auf `ibcs.com`.
@@ -95,14 +95,14 @@ Kurz und ergiebig, in dieser Reihenfolge:
   warum Ringe schwach und Punktdiagramme stark sind.
 4. **Stephen Few, „Information Dashboard Design"**. Das Standardwerk zur
   Dashboard-Kritik; die ersten beiden Kapitel reichen für ein geschultes Auge.
-5. **Datawrapper Academy** (`academy.datawrapper.de`) — kurze, gut belegte
+5. **Datawrapper Academy** (`academy.datawrapper.de`): kurze, gut belegte
   Artikel zu einzelnen Fragen („Wann Balken, wann Linien", „Warum keine zwei
   Y-Achsen").

 Zum Zielsystem passend:

 6. **Carbon Data Visualization** (`carbondesignsystem.com/data-visualization/`)
-   für Farben, Achsen und Diagrammtypen — mit der Einschränkung aus
+   für Farben, Achsen und Diagrammtypen, mit der Einschränkung aus
   [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) Abschnitt 0: Abstände regelt Carbon nicht.
 7. **Carbon Spacing und 2x-Grid** (`carbondesignsystem.com/elements/spacing/`)
   für genau diese Abstände.
@@ -114,4 +114,4 @@ Zum Zielsystem passend:
 Layout und Anordnung sind im Zielsystem **Entscheidung des Designers**
 (siehe [LEITPLANKEN.md](LEITPLANKEN.md)). Verbindlich zu übergeben sind
 Kennzahl-Definitionen, Diagrammregeln und Verhalten. Wer diese Liste im Review
-benutzt, prüft die Substanz — nicht, ob eine Karte 40 px weiter links sitzt.
+benutzt, prüft die Substanz, nicht, ob eine Karte 40 px weiter links sitzt.
@@ -2,14 +2,14 @@

 **Stand: 31.08.2026.** Entschieden und gebaut sind die Navigation (5.5) und
 der erste Aufschlag des Dashboards (Abschnitt 3a). Offen und mit den Kollegen
-zu klären bleiben 5.1, 5.3 und 5.6 — sie betreffen eine **Doppelung, die
+zu klären bleiben 5.1, 5.3 und 5.6: sie betreffen eine **Doppelung, die
 gerade absichtlich im Repo steht** und in Abschnitt 3a benannt ist.

 ---

 ## 1. Die Unterscheidung

-Bisher wurde dieser Prototyp als „das Dashboard" bezeichnet. Das ist ungenau —
+Bisher wurde dieser Prototyp als „das Dashboard" bezeichnet. Das ist ungenau,
 es sind zwei Features mit unterschiedlichem Zweck:

 | | **Analytics** | **Dashboard** |
@@ -23,7 +23,7 @@ es sind zwei Features mit unterschiedlichem Zweck:

 **Der entscheidende Unterschied:** Das Dashboard zeigt die wichtigsten Charts
 aus Analytics, ist aber **nicht darauf beschränkt**. Es ist der Ort für alles,
-was beim Anmelden zählt — auch für Dinge, die keine Auswertung sind:
+was beim Anmelden zählt, auch für Dinge, die keine Auswertung sind:
 „2 neue Anträge", offene Dokumente, Termine heute, zugewiesene Aufgaben.

 Analytics liefert also Bausteine an das Dashboard, deckt es aber nicht ab.
@@ -32,7 +32,7 @@ Analytics liefert also Bausteine an das Dashboard, deckt es aber nicht ab.

 ## 2. Was die Software dafür bereits vorsieht

-Das ist kein neuer Scope für HiveGrid Cloud — die Architektur ist darauf
+Das ist kein neuer Scope für HiveGrid Cloud, die Architektur ist darauf
 ausgelegt. Belegt in `packages/view-models/src/dashboard/dashboard-page.vm.ts`:

 ```ts
@@ -43,7 +43,7 @@ type DashboardWidgetKind   = "hero" | "kpi" | "list" | "trend" | "chart";
 ```

 Die Domäne **`hr`** und die Art **`list`** existieren bereits. „2 neue Anträge"
-ist damit ein `hr`/`kpi`- oder `hr`/`list`-Widget im Katalog — kein Sonderfall,
+ist damit ein `hr`/`kpi`- oder `hr`/`list`-Widget im Katalog, kein Sonderfall,
 sondern der vorgesehene Weg.

 Der Designer-Brief P11 nennt die drei Rollen-Layouts sogar konkret:
@@ -61,7 +61,7 @@ dokumentiert; was fehlt, ist die Verbindung zu unserer Analytics-Arbeit.
 ## 3. Was das für diesen Prototyp bedeutet

 **Die fünf Analyse-Seiten sind das Analytics-Feature.** Daran ändert sich
-nichts — Finanzen, Aufträge, Kunden, Team und die Diagrammbausteine bleiben,
+nichts: Finanzen, Aufträge, Kunden, Team und die Diagrammbausteine bleiben,
 wie sie sind.

 **Drei Stellen bekommen einen anderen Zuschnitt:**
@@ -74,13 +74,13 @@ wie sie sind.
 2. **Der Handlungsbedarf ist eigentlich ein Dashboard-Element.**
   „Was ist zu tun" ist die Frage des Begrüßungsbildschirms, nicht der Analyse.
   Ich habe ihn in der letzten Runde bewusst nach oben auf die Übersicht
-   gezogen, weil dort die Handlungsebene fehlte — unter der neuen Trennung
+   gezogen, weil dort die Handlungsebene fehlte: unter der neuen Trennung
   gehört er wahrscheinlich ins Dashboard.

 3. **Charts müssen als Widgets einzeln funktionieren.**
   Gute Nachricht: Sie tun es bereits. Die Diagrammkomponenten unter
   `components/charts/` sind reine Komponenten, die ihre Daten als Prop
-   bekommen — sie hängen an keiner Seite. Was **nicht** mitwandert, ist die
+   bekommen, sie hängen an keiner Seite. Was **nicht** mitwandert, ist die
   Kartenhülle `ChartCard`: Ihr ⋯-Menü und das Ausblenden sind Analytics-Logik;
   im Dashboard macht das die Widget-Registry.

@@ -88,14 +88,14 @@ wie sie sind.
   Filterleiste auf alle Karten gleichzeitig. Im Dashboard trägt jedes Widget
   seinen eigenen Zeitraum (P11: „Edit = nur Widget-Filter/Zeitraum"). Ein
   Chart, das aus Analytics ins Dashboard gehoben wird, verliert den globalen
-   Filter und braucht einen eigenen — sonst zeigt es stillschweigend einen
+   Filter und braucht einen eigenen, sonst zeigt es stillschweigend einen
   anderen Zeitraum als die Nachbarkachel.

 ---

 ## 3a. Was am 31.08.2026 gebaut wurde

-Das Dashboard existiert unter `/dashboard` — als **erster Aufschlag mit
+Das Dashboard existiert unter `/dashboard`, als **erster Aufschlag mit
 Analytics-Inhalten**, aber als Widget-Fläche gebaut, nicht als Analytics-Seite
 mit anderem Titel.

@@ -129,11 +129,11 @@ bearbeitbar.
 *Eine Zeile fehlt der Software dafür:* `dashboardWidgetGridClass` kennt keinen
 Fall `position.x === 9`, weil bisher keine Rolle vier Kacheln nebeneinander
 stellt. Unsere Kennzahlenreihe tut das. Ohne die Zeile fließt die vierte
-Kachel dank `grid-flow-row-dense` trotzdem an die richtige Stelle — nur ohne
+Kachel dank `grid-flow-row-dense` trotzdem an die richtige Stelle, nur ohne
 festen Anfang. Vermerkt in `components/dashboard/WidgetRaster.tsx`.

 **Die späteren Bereiche stehen nicht auf dem Dashboard.** Ein
-Begrüßungsbildschirm ist kein Ort für Ankündigungen — wer sich morgens
+Begrüßungsbildschirm ist kein Ort für Ankündigungen, wer sich morgens
 anmeldet, will seine Lage sehen und nicht lesen, was später einmal kommt.

 ### Wo die späteren Bereiche stehen
@@ -141,13 +141,13 @@ anmeldet, will seine Lage sehen und nicht lesen, was später einmal kommt.
 Meine Aufgaben, Termine heute und HR-Anträge sind an drei Stellen festgehalten,
 alle drei für den Einbau gedacht und keine davon auf dem Begrüßungsbildschirm:

-1. **`RESERVIERTE_BEREICHE`** in `view-models/dashboard.vm.ts` — die Kacheln als
+1. **`RESERVIERTE_BEREICHE`** in `view-models/dashboard.vm.ts`, die Kacheln als
   Datensatz, mit Titel, Beschreibung, Widget-Domäne und Quell-Feature.
 2. **Ein markierter Kommentarblock in `pages/DashboardSeite.tsx`** an genau der
-   Stelle im Raster, an die sie gehören — mit den konkreten Werten
+   Stelle im Raster, an die sie gehören, mit den konkreten Werten
   (`<Widget breite={4}>` mit `start={0}`, `{4}`, `{8}`).
 3. **Die Bausteingalerie unter `/komponenten`**, Abschnitt „Reservierte
-   Kacheln" — dort sind sie gestaltet zu sehen.
+   Kacheln": dort sind sie gestaltet zu sehen.

 Alle drei sind im Designer-Brief P11 benannt und haben in HiveGrid bereits ihre
 Widget-Domäne (`tasks`, `schedule`, `hr`). Sie brauchen kein neues Raster, nur
@@ -163,9 +163,9 @@ irgendwann fragt jemand, warum die Zahl nie hochzählt.
 weiterhin auf der Analytics-Übersicht. Das ist Absicht und vorläufig.

 Nach Abschnitt 3.2 gehört er ins Dashboard. Ihn gleichzeitig aus der Übersicht
-zu entfernen, hätte aber 5.1 mitentschieden — die Frage, ob es die
-Übersichtsseite überhaupt weiter gibt —, und das ist keine Entscheidung, die
-beim Bauen nebenbei fällt. Solange 5.1 offen ist, steht er doppelt.
+zu entfernen, hätte aber 5.1 mitentschieden: die Frage, ob es die
+Übersichtsseite überhaupt weiter gibt. Das ist keine Entscheidung, die beim
+Bauen nebenbei fällt. Solange 5.1 offen ist, steht er doppelt.

 **Beim Einbau ist das zu bereinigen, nicht zu übernehmen.** Zwei
 Einstiegsseiten mit derselben Arbeitsliste sind kein Entwurf, sondern ein
@@ -175,7 +175,7 @@ Versehen, das sich als Entwurf tarnt.

 - **Keine Rollenumschaltung.** Gestaltet ist die Sicht der Geschäftsführung.
  Büro und Monteur entstehen aus denselben Kacheln in anderer Zusammenstellung
-  (P11) — das ist eine Produktentscheidung, keine Gestaltungsfrage.
+  (P11): das ist eine Produktentscheidung, keine Gestaltungsfrage.
 - **Keinen Bearbeitungsmodus.** Die Software hat ihn (`DashboardEditPanel`,
  Widget-Katalog, gespeichertes Layout). Der Prototyp bildet ihn nicht nach;
  er zeigt das Ergebnis, nicht das Werkzeug.
@@ -200,7 +200,7 @@ Analytics (ein Menüpunkt, Reiter innen)      Dashboard (eigener Menüpunkt)
 Die Kennzahl-Definitionen aus [KPI-KATALOG.md](KPI-KATALOG.md) und die
 Diagrammregeln aus [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) gelten für **beide**
 Features. Ein Umsatzchart im Dashboard rechnet und aussieht wie dasselbe Chart
-in Analytics — sonst widersprechen sich zwei Seiten derselben Anwendung.
+in Analytics, sonst widersprechen sich zwei Seiten derselben Anwendung.

 ---

@@ -214,13 +214,13 @@ Nicht entschieden. Reihenfolge nach Tragweite:
  Begrüßungscharakter und wird zur reinen Kennzahlen-Zusammenfassung.
 - *C:* Sie entfällt; Analytics besteht aus vier fachlichen Seiten.

-**5.2 Welche Analytics-Charts werden Dashboard-Widgets? — Vorschlag steht.**
+**5.2 Welche Analytics-Charts werden Dashboard-Widgets?: Vorschlag steht.**
 Gebaut sind vier: Zahlungseingang, Umsatz nach Gewerk, Vertriebstrichter,
 Auslastung. Der Trichter war der Zweifelsfall (er lebt von der Übergangsquote
 und wird klein unlesbar); er steht deshalb auf sechs von zwölf Spalten und
 nicht auf vier. Die Auswahl ist ein Vorschlag zur Abnahme, keine Festlegung.

-**5.3 Wo lebt der Handlungsbedarf? — jetzt an beiden Orten.**
+**5.3 Wo lebt der Handlungsbedarf?, jetzt an beiden Orten.**
 Er steht seit dem 31.08. auf dem Dashboard und weiterhin auf der
 Analytics-Übersicht, weil das Entfernen 5.1 mitentschieden hätte. Siehe
 Abschnitt 3a. Das ist der dringlichste der offenen Punkte, weil er als
@@ -230,7 +230,7 @@ einziger sichtbar doppelt im Repo steht.
 Globaler Filter wie in Analytics oder pro Widget wie in P11? Die Software hat
 sich für „pro Widget" entschieden; das ist beim Übertragen zu beachten.

-**5.5 Navigation — entschieden am 29.08.2026.**
+**5.5 Navigation: entschieden am 29.08.2026.**
 Analytics ist **ein einzelner Menüpunkt** in der Seitenleiste, gleichrangig
 neben Dashboard. Die fünf Analyse-Seiten sind darin über Reiter erreichbar,
 nicht als Unterpunkte in der Navigation. Das Dashboard bleibt als eigener
@@ -240,7 +240,7 @@ Offen bleibt daran nur 5.1: Wenn die Übersichtsseite zum Dashboard wird,
 verliert der Analytics-Bereich seinen ersten Reiter.

 **5.6 Team-Seite.**
-Unabhängig davon offen, weil Zeiterfassung im v2-Backlog steht — siehe
+Unabhängig davon offen, weil Zeiterfassung im v2-Backlog steht: siehe
 [DATENMODELL.md](DATENMODELL.md).

 ---
@@ -248,12 +248,12 @@ Unabhängig davon offen, weil Zeiterfassung im v2-Backlog steht — siehe
 ## 6. Bis zur Klärung

 Die Diagrammbausteine, Kennzahl-Definitionen und Regeln gelten unabhängig
-davon, wie die beiden Features später geschnitten werden — sie sind von der
+davon, wie die beiden Features später geschnitten werden, sie sind von der
 Frage nicht betroffen.

 Betroffen ist genau eine Stelle: die Übersichtsseite. Fällt 5.1 auf „sie wird
-das Dashboard", dann ist die Arbeit größtenteils getan — der Handlungsbedarf
-steht schon dort, die Kennzahlen auch —, und die Übersichtsseite entfällt.
+das Dashboard", dann ist die Arbeit größtenteils getan. Der Handlungsbedarf
+steht schon dort, die Kennzahlen auch, und die Übersichtsseite entfällt.
 Fällt sie anders, verliert das Dashboard nichts; die Übersicht behält den
 Handlungsbedarf und das Dashboard gibt ihn ab.

@@ -11,10 +11,10 @@ Größenordnung: 678 Route-Dateien, davon 575 im Core-Manifest.

 ---

-## 0. Rangfolge beim Einbau — HiveGrid gewinnt
+## 0. Rangfolge beim Einbau: HiveGrid gewinnt

 **Dieser Prototyp ist nachrangig.** Wo er von HiveGrid Cloud abweicht, gilt
-HiveGrid — ohne Rückfrage, ohne Ausnahme. Das betrifft alles Globale:
+HiveGrid, ohne Rückfrage, ohne Ausnahme. Das betrifft alles Globale:

 | | Wer bestimmt |
 |---|---|
@@ -29,25 +29,25 @@ Dass dieser Prototyp dieselbe Schrift, dieselbe Seitenleisten-Komponente und
 dieselben Token benutzt, hat **einen einzigen Zweck**: Er soll neben der
 Software lesbar sein und nicht wie ein Fremdkörper wirken. Es ist **keine
 Vorlage, an der sich die Software auszurichten hätte.** Fällt beim Einbau auf,
-dass hier ein Wert von HiveGrid abweicht, ist der Wert hier falsch — nicht dort.
+dass hier ein Wert von HiveGrid abweicht, ist der Wert hier falsch, nicht dort.

 ### Was aus diesem Repo verbindlich ist

 Nur das Fachliche und das Analytics-Eigene:

-1. **Die Navigationsstruktur als Verabredung** — zwei Einträge in der
+1. **Die Navigationsstruktur als Verabredung**: zwei Einträge in der
   Seitenleiste (`Dashboard`, `Analytics`), und Analytics trägt eine **innere
   Leiste** mit den fünf Analyse-Seiten. Verbindlich ist die *Struktur*, nicht
   ihre Umsetzung hier: In der Software werden diese zwei Einträge in die
   bestehende `AppSidebar` eingehängt und die innere Leiste über das dortige
   `SidebarIconsLayout` gebaut. Unser Nachbau ist die Beschreibung, nicht das
   Bauteil.
-2. **Kennzahl-Definitionen** ([KPI-KATALOG.md](KPI-KATALOG.md)) —
+2. **Kennzahl-Definitionen** ([KPI-KATALOG.md](KPI-KATALOG.md)),
   was gerechnet wird, mit welchem Zeitbezug.
-3. **Diagrammregeln** ([DESIGN-SYSTEM.md](DESIGN-SYSTEM.md)) — Palette,
+3. **Diagrammregeln** ([DESIGN-SYSTEM.md](DESIGN-SYSTEM.md)): Palette,
   Achsen, Diagrammwahl, Leerzustände. Das ist die Lücke, die HiveGrid heute
   nicht füllt (siehe [LEITPLANKEN.md](LEITPLANKEN.md) Abschnitt 4).
-4. **Verhalten** — Filterlogik, Zeitbezüge, Widget-Sichtbarkeit,
+4. **Verhalten**: Filterlogik, Zeitbezüge, Widget-Sichtbarkeit,
   Sortier- und Blätterverhalten.

 ### Was aus diesem Repo Gerüst ist und wegfällt
@@ -60,7 +60,7 @@ Prototyp alleine lauffähig und beurteilbar ist. Beim Einbau übernehmen
 der Software.

 Das **Kachelraster des Dashboards** ist die Ausnahme in dieser Liste: Es ist
-kein Gerüst, sondern aus `DashboardPage.tsx` der Software übernommen —
+kein Gerüst, sondern aus `DashboardPage.tsx` der Software übernommen,
 dieselben Klassen, dieselbe Ableitung aus `size.w` und `position.x`. Es fällt
 nicht weg, es trifft dort auf sein Original.

@@ -88,7 +88,7 @@ Fachlich ist das die Phase **P11** (Modul M20): drei feste Rollen-Layouts
 Komfort-Delta aus **P30** (Edit-Modus, Drilldown, CSV-/Report-Export,
 Realtime-Opt-out).

-**Wichtig:** Dieser Stand ist ausdrücklich **Interim-UI nach AD-28** — der Dev
+**Wichtig:** Dieser Stand ist ausdrücklich **Interim-UI nach AD-28**, der Dev
 baut aus `~/ui` gegen ein stabiles View-Model, damit das Ticket nicht auf den
 finalen Screen wartet. Der Kommentarkopf von `DashboardPage.tsx` sagt es
 wörtlich: *„Final Subframe optics = tracked design-nachzug (D-DASH / VD-P30)."*
@@ -98,14 +98,14 @@ kein Umbau gegen den Strom.

 ---

-## 2. Gemeinsame Basis — und wo sie auseinanderläuft
+## 2. Gemeinsame Basis, und wo sie auseinanderläuft

 | | Prototyp | HiveGrid Cloud |
 |---|---|---|
-| Subframe-Projekt | `f023064a5ca0` | `f023064a5ca0` — **dasselbe** |
+| Subframe-Projekt | `f023064a5ca0` | `f023064a5ca0`: **dasselbe** |
 | Bibliothek | `ui/`, 86 Komponenten | `apps/web/app/ui/`, Alias `~/ui/*`, 92 Komponenten |
 | Überschneidung | 82 Komponenten gleich benannt | dieselben 82 |
-| Diagramme | Recharts ^2.15.4 | Recharts ^2.15.3 — **dieselbe Bibliothek** |
+| Diagramme | Recharts ^2.15.4 | Recharts ^2.15.3: **dieselbe Bibliothek** |
 | Framework | Next.js 16 | React Router 7 |

 Die vier Namensunterschiede: `DialogFullscreen` → `FullscreenDialog`,
@@ -120,7 +120,7 @@ Grund, warum der Einbau realistisch ein Port ist und keine Neuimplementierung.

 ## 3. Was beim Einbau konkret anders wird

-### 3.1 Daten kommen als View-Model-Prop — bereits umgesetzt
+### 3.1 Daten kommen als View-Model-Prop: bereits umgesetzt

 **Das ist im Prototyp schon so gebaut.** Jede Analyse-Seite ist eine reine
 Komponente:
@@ -177,13 +177,13 @@ Fünf Zustände statt einem. Der Prototyp kennt nur „Daten da"; `loading`,
 Was der Builder noch **nicht** kennt: `DashboardPageData` führt in der Cloud
 zusätzlich `activeRole`, `layout`, `generatedAt`, `streamUrl`, `canCustomize`,
 `liveUpdatesEnabled`, `layoutSource` und `catalog`. Das Dashboard ist dort
-rollen- und berechtigungsabhängig — diese Felder kommen beim Einbau dazu.
+rollen- und berechtigungsabhängig, diese Felder kommen beim Einbau dazu.

 ### 3.1a Warum der Prototyp auf Next.js bleibt

 Die Frage liegt nahe, weil die Software auf React Router 7 läuft. Ein Umbau
 brächte aber nichts: Im gesamten Prototyp gibt es **vier** Next-spezifische
-Importe, alle in zwei Dateien —
+Importe, alle in zwei Dateien,

 | Datei | Import | Schicksal beim Einbau |
 |---|---|---|
@@ -191,19 +191,19 @@ Importe, alle in zwei Dateien —
 | `app/layout.tsx` | `next`, `next/font/google` | entfällt, Root-Layout gehört der Cloud |

 Portiert wird nicht die Anwendung, sondern der Ordner
-`features/dashboard/{pages,components,view-models,utils}` — und der enthält
+`features/dashboard/{pages,components,view-models,utils}`, und der enthält
 keine Framework-Bindung. React 19, Tailwind v4 und Recharts sind in beiden
 Repos dieselben. Ein Framework-Wechsel im Prototyp wäre Aufwand ohne Ertrag und
 würde die Gestaltungsarbeit nur verzögern.

-### 3.1b Wo die Analyse in der Navigation landet — offen
+### 3.1b Wo die Analyse in der Navigation landet: offen

 **Die Seitenleiste des Prototyps ist Gerüst, kein Vorschlag.** Sie existiert nur,
 damit die Seiten einzeln aufrufbar sind, und entfällt beim Einbau (siehe 3.2).
 Wohin die fünf Analyse-Seiten in der echten Navigation gehören, ist **noch nicht
 entschieden**.

-Der Stand in der Software: Die Seitenleiste hat sechs Gruppen —
+Der Stand in der Software: Die Seitenleiste hat sechs Gruppen,
 Start (Dashboard, Aufgaben) · Kunden · Projekte · Kommunikation · Organisation ·
 Automatisierung. **Eine Analyse-Gruppe gibt es nicht.** Es gibt aber bereits
 zwei konkurrierende Muster:
@@ -211,7 +211,7 @@ zwei konkurrierende Muster:
 | Muster | Beispiel | Charakter |
 |---|---|---|
 | Rollen-Dashboard als Startseite | `/dashboard` (P11/P30) | Widgets, drei Rollen-Layouts, „wie ist meine Lage" |
-| Analyse **innerhalb** der Fachdomäne | `leads/analytics` — existiert bereits | vertieft genau eine Domäne |
+| Analyse **innerhalb** der Fachdomäne | `leads/analytics`: existiert bereits | vertieft genau eine Domäne |

 Dieser Prototyp schlägt implizit ein drittes Muster vor: einen
 **domänenübergreifenden Analysebereich** mit gemeinsamem Zeitraum- und
@@ -225,7 +225,7 @@ Dimensionsfilter.
   (Übersicht → Detail). Finanzen greift über Projekte, Rechnungen und Kontakte
   hinweg und passt in keine einzelne Domäne.
   *Dagegen:* eine siebte Gruppe in einer schon langen Seitenleiste.
-2. **Verteilt in die Domänen** — Finanzen unter Projekte, Kunden-Analyse unter
+2. **Verteilt in die Domänen**: Finanzen unter Projekte, Kunden-Analyse unter
   Kunden, analog zu `leads/analytics`.
   *Dafür:* folgt dem bestehenden Muster, keine neue Gruppe.
   *Dagegen:* Der gemeinsame Zeitraumfilter zerfällt, die Übersichtsseite hat
@@ -235,12 +235,12 @@ Dimensionsfilter.
   Analyse „warum ist das so". Beides in eine Seite zu legen, macht aus dem
   Einstieg eine Halde.

-**Entschieden am 29.08.2026: Option 1**, mit dem Namen **„Analytics"** — der
+**Entschieden am 29.08.2026: Option 1**, mit dem Namen **„Analytics"**, der
 Prototyp setzt das um. Die Seitenleiste spiegelt jetzt die der Software
 (dieselbe Komponente, dieselben Gruppen); „Analytics" ist ein einzelner
 Menüpunkt neben „Dashboard", die fünf Seiten sind darin über Reiter erreichbar.

-*Ursprüngliche Empfehlung war der Name* **„Statistiken"** — so heißt der
+*Ursprüngliche Empfehlung war der Name* **„Statistiken"**: so heißt der
 Breadcrumb im Prototyp bereits, und „Analyse" ist im Haus durch
 `leads/analytics` belegt. Das bestehende `/dashboard` bleibt Startseite; unsere
 Seite „Übersicht" braucht dann einen anderen Namen, sonst konkurrieren zwei
@@ -251,14 +251,14 @@ Einstiegsseiten um dieselbe Rolle.
 | Prototyp | In der Software |
 |---|---|
 | „Übersicht" | kollidiert mit der Startseite „Dashboard" |
-| „Aufträge" | keine Entität — eine Pipeline-View auf den Projekt-Kern (AD-20) |
-| „Kunden" | keine Entität — ein Status am `Kontakt` |
+| „Aufträge" | keine Entität, eine Pipeline-View auf den Projekt-Kern (AD-20) |
+| „Kunden" | keine Entität, ein Status am `Kontakt` |
 | „Team" | thematisch unter Organisation/HR; Datenquelle erst in v2 |

 Das ist eine Produkt- und Designentscheidung, keine Umsetzungsfrage. Sie gehört
 in die Runde mit dem Head of Design, nicht in den Einbau.

-**Nachtrag 29.08.2026:** Die Frage hängt an einer größeren — „Analytics" und
+**Nachtrag 29.08.2026:** Die Frage hängt an einer größeren: „Analytics" und
 „Dashboard" sind zwei Features. Siehe
 [SCOPE-ANALYTICS-DASHBOARD.md](SCOPE-ANALYTICS-DASHBOARD.md).

@@ -267,7 +267,7 @@ in die Runde mit dem Head of Design, nicht in den Einbau.
 `AppShell.tsx` aus diesem Prototyp fällt beim Einbau **weg**. Die Cloud-Routen
 laufen bereits in der echten App-Shell mit Sidebar, Tenant-Layout und
 Breadcrumb (`SubframeAppShell.tsx`, `AppSidebar.tsx`). Screen-Komponenten
-dürfen dort ausdrücklich **kein** `~/ui/layouts/DefaultPageLayout` rendern —
+dürfen dort ausdrücklich **kein** `~/ui/layouts/DefaultPageLayout` rendern,
 das bringt eine eigene Beispiel-Sidebar mit und erzeugt eine doppelte
 Navigation. Stattdessen gilt `PageShell` / `PageHeader` / `PageBody` aus
 `components/screens/shared/PageShell.tsx`.
@@ -278,7 +278,7 @@ Unsere Seitenköpfe und die Filterleiste bleiben, die Rahmen-Navigation nicht.

 Alle statischen Texte laufen über `react-i18next` (`t("app.dashboard.…")`).
 Dieser Prototyp hat deutsche Strings fest im JSX. Das ist beim Einbau
-mechanische Arbeit, aber flächendeckend — es betrifft jede Karte, jede
+mechanische Arbeit, aber flächendeckend, es betrifft jede Karte, jede
 Achsenbeschriftung und jeden Leerzustand.

 Die deutschen **Bezeichner im Code** (`umsatz`, `auftraege`) bleiben davon
@@ -289,7 +289,7 @@ in P30).

 In der Cloud sind Charts konsequent `aria-hidden="true"`, und die umgebende
 Karte liefert eine Textzusammenfassung plus Datentabelle für Screenreader.
-Dieser Prototyp hat das **nicht**. Beim Einbau ist es Pflicht — das Repo fährt
+Dieser Prototyp hat das **nicht**. Beim Einbau ist es Pflicht, das Repo fährt
 ein a11y-Lint-Baseline-Gate und axe-Tests je Primitive.

 ### 3.5 Stabile Oberflächen-IDs
@@ -304,7 +304,7 @@ müssen aber auf das dortige Namensschema umgestellt werden.
 `.planning/INTERIM-UI-DESIGN-STANDARDS.md` schreibt fest: Page-Padding **24**,
 Card **16**, Grid-Gap **16**, Section-Gap **24**, Field-Gap **16**,
 Control-Höhe Medium **36**, Input-Radius **4**. Das deckt sich mit dem
-8-px-System in [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) Abschnitt 5 — hier ist
+8-px-System in [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) Abschnitt 5: hier ist
 nichts anzupassen.

 ---
@@ -318,7 +318,7 @@ Farben direkt im JSX (`fill="#334155"`, `fill="#cbd5e1"`), jedes mit eigenem
 Gitter (`strokeDasharray="3 3"`), eigener Achsenbreite und eigenem
 Balkenradius. Es gibt keine geteilte Palette, keine Kategorien-Obergrenze und
 keine feste Farbzuordnung. `features/dashboard/utils/chartTheme.ts` ist genau
-das, was dort fehlt — und der Teil, der sich am ehesten unabhängig vom Rest
+das, was dort fehlt, und der Teil, der sich am ehesten unabhängig vom Rest
 übernehmen lässt.

 **Ausformulierte Diagramm-Regeln.** [DESIGN-SYSTEM.md](DESIGN-SYSTEM.md) hat in
@@ -332,20 +332,20 @@ Definition.

 ---

-## 5. Wer entwirft was — der Rest ist noch nicht fertig designt
+## 5. Wer entwirft was, der Rest ist noch nicht fertig designt

 HiveGrid Cloud ist nach dem **Designer-First-Prinzip** organisiert
 (`.planning/DESIGNER-FIRST-PLAYBOOK.md`). Der Ablauf ist verbindlich:

-1. Dev/Planung stellt je Phase einen **Designer-Brief** bereit —
+1. Dev/Planung stellt je Phase einen **Designer-Brief** bereit,
   *was* das Modul tut und *welche UI-Elemente* vorkommen müssen, **kein Layout**.
 2. Der Designer entwirft die Screens in Subframe und darf Spec und UI/UX
-   **überschreiben** — Anordnung und Layout sind eine Design-Entscheidung.
+   **überschreiben**: Anordnung und Layout sind eine Design-Entscheidung.
 3. Das **Delta** (geänderte Spec-Punkte, neue UX-Entscheidungen, Subframe-Link)
   wird in den Brief eingetragen.
 4. Der Dev setzt um und zieht Spec und Doku nach.

-Es gibt 31 solcher Briefs (`.planning/designer-briefs/P01…P34.md`) — Auth, CRM,
+Es gibt 31 solcher Briefs (`.planning/designer-briefs/P01…P34.md`): Auth, CRM,
 Lead-Inbox, Projekt-Pipelines, Automation-Flow-Editor, Form-Builder, Plantafel,
 Kalender, Telefonie, HR, Billing, Customer-Portal, Help-Center. Für einen
 großen Teil davon steht der Delta-Block **noch leer**: Der finale Screen ist
@@ -357,7 +357,7 @@ noch nicht entworfen, die Route läuft bis dahin auf Interim-UI.
  Anwendung. Es fügt sich in eine App-Shell und ein Design-System ein, die
  bereits stehen.
 - Was hier an Anordnung und Raster festgelegt ist, ist ein **Vorschlag**. Die
-  Layout-Hoheit liegt beim Designer — der Brief zu P11 sagt ausdrücklich
+  Layout-Hoheit liegt beim Designer, der Brief zu P11 sagt ausdrücklich
  „Anordnung = Davids freie Hand". Verbindlich zu übergeben sind die
  **Kennzahl-Definitionen, die Chart-Regeln und das Verhalten**, nicht die
  Pixelanordnung.
@@ -378,7 +378,7 @@ pnpm dev:local
 ```

 Tenant-App auf `http://app.localhost:3000`. Die lokalen Demo-Zugänge (Tenant
-„HiveGrid Demo SHK") stehen im README von HiveGrid Cloud unter „App starten" —
+„HiveGrid Demo SHK") stehen im README von HiveGrid Cloud unter „App starten",
 sie werden hier bewusst nicht wiederholt. Die Demo-Daten sind zunächst
 ausgeblendet und erscheinen über **„Demo-Daten anzeigen"** oder `?demo=show`.