Commit Graph
11 Commits
Author SHA1 Message Date
dejanandClaude Opus 5 6a0b36ddcc 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
dejanandClaude Opus 5 84ce322a19 Begruessung: Vorname als Platzhalter, Anwendung duzt
Zwei Aenderungen an der Ansprache.

"Guten Tag, [Vorname]" statt eines erfundenen Namens. Ein fester Name sieht in
einer Abnahme aus wie ein fest verdrahteter Wert, und irgendwann fragt jemand,
warum dort immer derselbe steht. Die Klammern sagen, was an der Stelle
eingesetzt wird; beim Einbau kommt der Wert aus der Sitzung.

Und die Anwendung duzt: "2 Punkte brauchen heute deine Aufmerksamkeit."

Vor der Aenderung geprueft, ob es weitere Siez-Formen gibt — es war genau
diese eine Stelle, einmal im View-Model und einmal in der Bausteingalerie.
Halb geduzt liest sich schlechter als durchgehend gesiezt, deshalb steht die
Ansprache jetzt als Regel in DESIGN-SYSTEM.md, zusammen mit dem Hinweis, dass
beim Einbau im Zweifel die Ansprache von HiveGrid Vorrang hat.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-31 20:04:14 +02:00
dejanandClaude Opus 5 b8d44f7f7d Reservierte Kacheln vom Dashboard in die Galerie verlegen
Der Begruessungsbildschirm hatte einen Abschnitt "Kommt noch" mit drei leeren
Kacheln. Das ist der falsche Ort: Wer sich morgens anmeldet, will seine Lage
sehen und nicht lesen, was spaeter einmal kommt. Ein Dashboard ist kein Ort
fuer Ankuendigungen.

Die Verabredung bleibt vollstaendig erhalten, nur an Stellen, wo sie hingehoert
— alle drei fuer den Einbau gedacht:

1. RESERVIERTE_BEREICHE in view-models/dashboard.vm.ts, jetzt exportiert: die
   Kacheln als Datensatz mit Titel, Widget-Domaene und Quell-Feature.

2. Ein markierter Kommentarblock in pages/DashboardSeite.tsx an genau der
   Stelle im Raster, an die sie gehoeren — mit den konkreten Werten
   (<Widget breite={4}> mit start 0, 4 und 8) und dem Hinweis, dass das Raster
   dafuer nicht angefasst werden muss.

3. Die Bausteingalerie unter /komponenten, neuer Abschnitt "Reservierte
   Kacheln" — dort sind alle drei gestaltet zu sehen, aus derselben Konstante
   gerendert statt abgeschrieben.

docs/SCOPE-ANALYTICS-DASHBOARD.md nennt die drei Stellen jetzt ausdruecklich
unter "Wo die spaeteren Bereiche stehen", damit beim Port niemand sucht.

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 19:39:35 +02:00
dejanandClaude Opus 5 885c7b9609 Komponentenseite auf ihren tatsaechlichen Zweck schaerfen
Sie war als "Referenz fuer den Einbau" ausgeschildert. Das trifft es nicht:
Wer den Prototyp einbaut, liest Code und Doku und kann sich keine gerenderte
Seite ansehen — die Datei-Pfade und DESIGN-SYSTEM.md tun diese Arbeit
ohnehin. Nuetzlich ist die Seite fuer die Abstimmung mit Menschen: Auf den
Analyse-Seiten sieht man von jedem Baustein immer nur den Zustand, den die
Daten gerade hergeben.

Neu ausgeschildert, und die fehlenden Zustaende ergaenzt:

- Seitenzustaende (laedt / leer / Fehler). In HiveGrid sind alle fuenf
  VMState-Zustaende Pflicht, im Prototyp ist keiner davon je zu sehen, weil
  die Demo-Daten immer liefern. Gestaltet werden muessen sie trotzdem —
  "laedt", "nichts gefunden" und "kaputt" sind drei verschiedene Aussagen.

- Dashboard-Kacheln: Begruessung, WidgetKachel, reservierte Kachel. Das
  Dashboard benutzt nicht ChartCard, sondern einen eigenen Rahmen; bisher war
  der in der Galerie gar nicht vertreten.

Zwei Fehler dabei gefunden und behoben:

- Die Regelliste nannte noch den dunklen Tooltip (#393939). Seit Carbon v11
  ist er hell (#ffffff auf #161616); im Code war das laengst umgestellt, auf
  dieser Seite nicht. Eine Referenzseite, die eine ueberholte Regel behauptet,
  ist schlimmer als keine.

- Die Abschnittstexte beginnen mit einem Dateipfad, und ein Pfad ist ein Wort
  ohne Trennstelle. Bei 375 px lief
  "features/dashboard/components/layout/SeitenZustand.tsx" neun Pixel ueber
  den Rand — von verify:layout gefunden.

Die Regel zu den Kartenhoehen aus dem letzten Commit steht jetzt auch hier.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-31 18:07:50 +02:00
dejanandClaude Opus 5 ffbe70aede Zeilen nur strecken, wenn die Karten dieselbe Bauart haben
Rueckbau des letzten Commits, soweit er zu weit ging. Er hat alle
Diagrammzeilen gestreckt; richtig ist das nur dort, wo die Karten von Natur
aus aehnlich hoch sind.

Gemessen bei 1680 px, Hoehenunterschied innerhalb einer Zeile:

  Trichter | Auslastung          (Liste | Liste)        0 px /   0 px
  Zahlungseingang | Bestand      (Chart | Chart)        0 px /   0 px
  Zahlungseingang | Gewerk       (Chart | Liste)      147 px / 315 px
  Vorgaenge Status | Gewerk      (Chart | Liste)      190 px / 358 px
                                            (volle Daten / duenne Daten)

Der Grund steckt in der Liste: Eine Balkenliste hat keine Mindesthoehe. Fuenf
Kategorien ergeben 280 px, eine einzige 112 px — daneben liegt ein
Zeitverlauf unveraendert bei 427 px, weil seine Diagrammflaeche fest ist.
Diese Zeile zu strecken heisst, eine Karte mit einem Balken auf 427 px
aufzublasen. Das ist schlimmer als die Luecke, die es vermeiden soll:
Weissraum auf der Seite liest sich als "hier ist gerade wenig", eine riesige
Karte mit einem Balken darin als Fehler.

items-start kehrt deshalb auf allen Zeilen zurueck, in denen ein Diagramm mit
fester Hoehe neben einer Liste steht. Gestreckt bleibt, wo beide Karten
dieselbe Bauart haben — Trichter neben Auslastung.

Das senkrechte Zentrieren im Kartenkoerper bleibt: Auf oben buendigen Zeilen
ist es wirkungslos, auf den gestreckten verteilt es den Ueberschuss oben und
unten statt ihn unten abzuladen. Das war die Verbesserung am Trichter.

Auf dem Dashboard bleibt die Zeile aus Zeitverlauf und Balkenliste gestreckt.
Derselbe Massstab, anderes Ergebnis: Dort gibt es keinen Filter, die Liste hat
immer ihre fuenf Gewerke, und es bleiben rund 90 px. Der Filter ist der
Unterschied, nicht die Kachel.

DESIGN-SYSTEM.md traegt jetzt die Regel mit den Messwerten statt der zu
weit gefassten Fassung von vorhin.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-31 17:48:05 +02:00
dejanandClaude Opus 5 ab79c711ad Karten einer Zeile gleich hoch, Ueberschuss mittig verteilen
Aus dem Sparring: Bei duenner Datenlage riss die oben buendige Ausrichtung
Loecher in die Seite. Nachgemessen auf /analytics mit Zeitraum "heute" und
Gewerk "Heizung": "Umsatz nach Gewerk" 112 px neben "Zahlungseingang im
Zeitverlauf" 427 px — 315 px Seitenhintergrund dazwischen. Das liest sich
nicht als "wenig Daten", sondern als "etwas ist kaputt".

Zwei Aenderungen, beide klein:

- Der Kartenkoerper zentriert seinen Inhalt senkrecht. Der Ueberschuss geht
  je zur Haelfte nach oben und unten, statt unten abgeladen zu werden. Eine
  Stelle in ChartCard und eine in WidgetKachel — nicht in fuenf Diagrammen.

- items-start faellt auf den Zeilen, die ausschliesslich Diagrammkarten
  tragen. Die Zeile mit den beiden Tabellen auf der Kundenseite bleibt oben
  buendig: Eine Tabelle hat ein natuerliches Ende und eine eigene
  Blaetterleiste, Strecken schiebt die nur nach unten.

Die Karten bleiben dynamisch — keine feste Hoehe, mehr Inhalt laesst die
Karte und mit ihr die Zeile weiter wachsen.

Die Leere verschwindet nicht, sie zieht aus dem Seitenhintergrund in die
Karte. Das ist der Unterschied zwischen einem Raster mit Luecken und einer
Karte, in der gerade wenig steht.

Nachgemessen nach der Aenderung: 427/427, 389/389 auf /analytics,
372/372 und 423/423 auf /dashboard. Dabei ist nebenbei die Leerflaeche unter
dem Vertriebstrichter verschwunden, die vorher auffiel.

In DESIGN-SYSTEM.md als Regel festgehalten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-31 17:38:57 +02:00
dejanandClaude Opus 5 831a6ec9ad Dashboard als Widget-Flaeche bauen, Platzhalter ersetzen
Das Dashboard ist ein eigenes Feature neben Analytics: der
Begruessungsbildschirm, nicht ein zweiter Analysebereich. Es zeigt heute nur
Auswertungen, ist aber so gebaut, dass die spaeteren Bereiche als weitere
Kacheln dazukommen und nicht als Umbau.

Aufbau: Begruessung, vier Kennzahlen (je ein Link in die Analyse),
Handlungsbedarf, vier Diagramme, drei reservierte Plaetze.

Drei Entscheidungen, die dabei getroffen wurden:

- Kein seitenweiter Filter. Jede Kachel traegt ihren eigenen Zeitraum und
  schreibt ihn in den Kopf. Das ist das Bedienmodell der Software (P11) und
  war die unbequemere Variante; eine Filterleiste haette beim Einbau alle
  Kacheln wieder auseinandergenommen.

- Das Raster ist aus DashboardPage.tsx der Software uebernommen, nicht
  erfunden: dieselben Klassen, dieselbe Ableitung aus size.w und position.x.
  Der Software fehlt dafuer eine Zeile (position.x === 9); vermerkt in
  WidgetRaster.tsx.

- Die reservierten Plaetze zeigen keine erfundenen Zahlen. "2 neue Antraege"
  aus dem Nichts liest sich in einer Abnahme wie eine fertige Funktion.

Absichtliche Doppelung: Der Handlungsbedarf steht jetzt auf dem Dashboard und
weiterhin auf der Analytics-Uebersicht. Ihn dort zu entfernen haette die
offene Frage 5.1 mitentschieden. Dokumentiert in Abschnitt 3a des
Scope-Papiers, aufzuloesen vor dem Port.

Nebenbei zwei Fehler behoben, die auch Analytics betrafen:

- Die Beschriftungen der Zeitachse liefen in schmalen Karten ineinander
  (fuenf Kalenderwochen brauchen 200px, eine halbe Kachel bei 768px hat 150).
  Recharts duennt sie jetzt selbst aus und haelt Anfang und Ende.

- Das Zeitraum-Etikett im Kachelkopf schaltete per Viewport-Breakpoint, die
  Kachelbreite haengt aber am Raster. Bei 1024px blieben dem Untertitel 77px,
  und er lief ins Diagramm. Jetzt Container-Query.

Die Wurzel leitet auf /dashboard statt /analytics — wie in der Software, wo
nach der Anmeldung der Begruessungsbildschirm steht.

tsc, lint, build, verify:carbon und verify:layout (7 Seiten x 9 Breiten)
laufen sauber.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-31 16:51:09 +02:00
dejanandClaude Opus 5 7183fad27a feat(dashboard): Platzhalterseite statt Hinweis-Toast
Der Menüpunkt 'Dashboard' löste bisher nur einen Toast aus. Ein
Navigationseintrag, der nirgendwohin führt, lässt den Leser im Unklaren, ob
etwas fehlt oder etwas kaputt ist.

Jetzt führt er auf /dashboard: ein Leerzustand nach dem Hausmuster
(ui/components/EmptyState), der benennt, warum hier nichts steht, was später
hinkommt (drei Rollen-Layouts, Widgets teils aus Analytics, teils nicht — offene
HR-Anträge, Aufgaben, Termine) und wo der Zuschnitt dokumentiert ist. Mit einem
Weg zurück nach Analytics.

Dabei:
- EmptyState aus der Cloud-Fassung nachgezogen; unsere Kopie hatte den
  action-Slot noch nicht.
- PageHeader bekommt 'standardAktionen': Auf einer leeren Seite gibt es nichts
  zu aktualisieren oder zu exportieren, also stehen dort auch keine
  Schaltflächen dafür.
- Die Variante 'software' in NavZiel entfällt — jeder Eintrag führt jetzt auf
  eine echte Seite, der Toast-Zweig in der AppShell war damit toter Code.
- verify-layout deckt /dashboard mit ab (jetzt 7 Seiten x 7 Breiten).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-29 20:56:35 +02:00
dejanandClaude Opus 5 e85ceb6f9d feat(nav): Seitenleiste der Software spiegeln, Analytics als ein Menüpunkt
Der Prototyp hatte eine eigene Seitenleiste mit den fünf Analyse-Seiten als
Menüpunkten. Die Software hat eine andere Navigation, in der Analytics noch gar
nicht vorkommt. Beides zusammen ergab kein Bild davon, wo die Analyse später
sitzt.

Jetzt:
- Die Seitenleiste spiegelt die von HiveGrid Cloud — dieselbe Komponente
  (SidebarWithSections aus der Cloud-Fassung portiert, inkl. der dortigen
  lokalen Fixes: Collapse-Breite, verdrahteter Toggle, Logo-Slot, Hover-Sweep),
  dieselben Gruppen, dieselbe Reihenfolge, dasselbe Logo.
- 'Analytics' ist ein einzelner Menüpunkt, gleichrangig neben 'Dashboard'.
- Die fünf Analyse-Seiten sind darin über Reiter erreichbar, nicht als
  Unterpunkte in der Navigation. Zwei Navigationsebenen für dieselbe Sache
  würden nur konkurrieren. Die Reiter folgen dem Hausmuster aus
  SettingsHubShell (Link um Tabs.Item), damit jeder Reiter eine echte Adresse
  hat und mittelklickbar bleibt.
- Routen: /analytics, /analytics/finanzen, /auftraege, /kunden, /team.
  '/' leitet auf /analytics; das Dashboard liegt in der Software unter '/'.
- Alle übrigen Einträge sind Kontext: Sie zeigen den Ort in der fertigen
  Anwendung und melden beim Klick, dass sie zur Software gehören.

Kopfzeile und Filterleiste sind aus den fünf Seiten in die Analytics-Hülle
gewandert — sie sind für alle gleich, und der Filterzustand gilt bereichsweit.

Nebenbei: @radix-ui/react-slot war eine Phantom-Dependency (nur transitiv über
@subframe/core vorhanden, vom portierten IconButton direkt importiert) und ist
jetzt deklariert. verify-layout prüfte noch die alten Routen und lief damit auf
404-Seiten, die naturgemäß keine Kollisionen haben — Routen korrigiert und eine
Absicherung ergänzt, die bei Statuscode >= 400 abbricht.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-29 20:25:04 +02:00
dejanandClaude Opus 5 99be627dad refactor(dashboard): Seiten von der Datenquelle entkoppeln
Die Seiten holten ihre Zahlen selbst aus einem globalen Store. HiveGrid Cloud
verlangt reine Screens nach dem Muster <XPage vm={} actions={} /> — jede Seite
hätte beim Einbau auseinandergenommen werden müssen.

Neue Schichtung:

  view-models/<seite>.vm.ts   baue<Seite>VM(daten, filter) → VMState<…>
                              reine Funktion, kein React, kein Store
  pages/<Seite>.tsx           ({ vm, optionen }) → JSX      wird portiert
  routes/<Seite>Route.tsx     Store + Builder + Seite       wird ersetzt

view-models/index.ts spiegelt VMState wortgleich aus @hivegrid/view-models;
beim Einbau ist es ein Import-Wechsel. Der Loader ruft denselben Builder mit
echten Daten, die Seiten bleiben unberührt.

Dabei abgefallen: die fünf Seitenzustände (idle · loading · ready · empty ·
error) über SeitenZustand — bisher lief der Prototyp nur im Zustand "Daten da",
in der Cloud sind alle fünf DoD-Pflicht. Die Filterleiste bekommt ihre
Auswahllisten jetzt als Prop (in der Software die Facetten aus dem Loader)
statt sie selbst aus dem Datensatz zu ziehen.

Store- und Rohdatenzugriff gibt es damit ausschließlich in routes/. Alle sechs
Seiten rendern pixelgleich; typecheck, lint und build sind grün.

Nicht geändert: Next.js bleibt. Im gesamten Projekt gibt es vier
Next-spezifische Importe, alle in AppShell und app/layout — beide Dateien
entfallen beim Einbau ohnehin, weil die Cloud Shell und Root-Layout mitbringt.
Ein Framework-Wechsel wäre Aufwand ohne Ertrag.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-29 17:39:41 +02:00
dejanandClaude Opus 5 b8bf987d0e feat(dashboard): Analytics-Dashboard als Gestaltungsvorlage zur Übergabe
UI/UX-Prototyp der Analytics-Dashboards in HiveGrid, fachlich auf einen
SHK-/Handwerksbetrieb zugeschnitten. Ziel ist die Übergabe an die Entwicklung,
nicht der Produktivbetrieb.

Inhalt: sechs Seiten (Übersicht, Finanzen, Aufträge, Kunden, Team, Komponenten),
26 KPIs, neun Chart-Bausteine, Filtersystem mit seitenabhängiger Relevanz und ein
deterministischer Demo-Datensatz (420 Kunden, 1.900 Aufträge, Stichtag 30.07.2026).

Drei Quellen sind zusammengeführt: die fachliche Planung mit dem Branchenpartner
(Januar 2026), die Subframe-Komponentenbibliothek aus dem HiveGrid-Pitch und
IBM Carbon Data Visualization für die Diagrammregeln. Herkunft und bewusste
Abweichungen stehen in docs/HERKUNFT.md.

Dokumentation: README, HANDOVER (was echte Logik braucht), docs/DESIGN-SYSTEM,
KPI-KATALOG, DATENMODELL, NAVIGATION, HERKUNFT, ZIELSYSTEM (Einbauort in
HiveGrid Cloud) und LEITPLANKEN (welche Cloud-Screens als Vorbild taugen).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-29 17:25:20 +02:00