Zwei Korrekturen aus dem Review.
1. Die Seitenleiste zeigte die komplette Software-Navigation nach. Falsch:
Kontakte, Leads, Pipelines, Postfach, Termine und Einstellungen stehen dort
bereits, der Prototyp verdoppelt sie nur. Jetzt stehen in der Leiste
ausschließlich unsere beiden Features — Dashboard (eigenes Feature, hier
nicht enthalten) und Analytics — plus die Bausteingalerie im sekundären
Bereich, die zum Prototyp und nicht zum Produkt gehört.
2. Die Schrift stimmte nicht. Die Software nutzt Instrument Sans, selbst
gehostet als variable Schrift. Der Prototyp lud Inter über next/font,
während ui/theme.css für sämtliche Subframe-Typo-Token bereits
'Instrument Sans' verlangte — die Schrift war aber nie geladen und fiel auf
die Systemschrift zurück. Ergebnis waren zwei verschiedene Schriften auf
einer Seite, keine davon die der Software.
Jetzt liegen dieselben woff2-Dateien unter public/fonts/, mit denselben
@font-face-Regeln und derselben Alias-Zuordnung für Komponenten, die noch
direkt auf Inter verweisen. next/font entfällt.
Der Layout-Prüfer lief nach dem Schriftwechsel erneut durch: andere Metrik,
andere Textbreiten — weiterhin keine Kollisionen über 6 Seiten × 7 Breiten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
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
Klarstellung aus der Abstimmung: Der Prototyp wurde bisher als 'das Dashboard'
bezeichnet, tatsächlich sind es zwei Features mit unterschiedlichem Zweck.
Analytics beantwortet 'warum ist das so' — mehrerer Seiten, seitenübergreifender
Zeitraum- und Dimensionsfilter, fachlich geschnitten. Das Dashboard beantwortet
'wie ist meine Lage' — Begrüßungsbildschirm, rollenbezogen, Widgets. Es zeigt die
wichtigsten Charts aus Analytics, ist aber nicht darauf beschränkt: HR-Anträge
('2 neue Anträge'), Aufgaben und Termine gehören ebenfalls dorthin.
Die Software sieht das bereits vor. DashboardWidgetDomain kennt 'hr',
DashboardWidgetKind kennt 'list', und der Designer-Brief P11 nennt HR-Anträge
wörtlich im Büro-Dashboard. Neu ist nicht der Scope der Software, sondern das
Verhältnis zu diesem Prototyp.
Drei Stellen bekommen dadurch einen anderen Zuschnitt: die Seite 'Übersicht'
überschneidet sich mit dem Dashboard, der Handlungsbedarf ist eher ein
Dashboard-Element, und Charts brauchen als Widgets einen eigenen Zeitraum, weil
das Dashboard keinen globalen Filter hat.
Sechs offene Punkte sind in docs/SCOPE-ANALYTICS-DASHBOARD.md Abschnitt 5
festgehalten. Nichts davon ist entschieden, am Code ist nichts geändert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
Drei Fehler in der Übergabedoku gefunden und behoben. Die Zuordnung in
DATENMODELL.md nannte HiveGrid-Entities, die es nach AD-20 nicht gibt:
- 'Auftrag' → 'order': Auftrag ist eine Pipeline-View auf den Projekt-Kern,
keine eigene Entität. Status ist pipeline-intern (stage_id).
- 'Kunde' → 'company': Kunde ist ein Status am Kontakt (kontakt_status),
keine Entität. Kontakt ist der Oberbegriff.
- 'Rechnung' → 'invoice': heißt Rechnung und ist Sub-Entity am Projekt; ihr
Status kennt kein 'ueberfaellig' — Überfälligkeit wird aus faellig_am
abgeleitet.
Dazu ein Befund mit Konsequenz: Zeiterfassung steht im ENTITY-MODEL im
v2-Backlog. Damit hat die gesamte Team-Seite in v1 keine Datenquelle. Drei
Wege sind in DATENMODELL.md festgehalten; die Entscheidung gehört vor den
Einbau.
Neu in ZIELSYSTEM.md 3.1b: wohin die Analyse-Seiten in der Navigation gehören.
Die Software hat heute keine Analyse-Gruppe, aber bereits zwei konkurrierende
Muster (Rollen-Dashboard unter /dashboard, Domänen-Analyse unter
leads/analytics). Drei Optionen mit Konsequenzen und eine Empfehlung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
Gemeldeter Fehler: In der Ringlegende klebten Bezeichnung und Wert aneinander
("Gestellt189,1 T€"). Ursache war eine eigene Regression — beim Beheben der
abgeschnittenen Legendennamen war das truncate entfallen, ohne Ersatz. Damit
schrumpft die Namensspalte durch min-w-0 + grow auf null Breite, und der Text
läuft sichtbar über seinen Kasten hinaus:
1280 px Kastenbreite 0 px, Text 43 px darüber hinaus
1440 px Kastenbreite 25 px, Text 18 px darüber hinaus
1600 px unauffällig
Genau deshalb war es auf den Screenshots nicht zu sehen: Der Fehler tritt nur in
bestimmten Fensterbreiten auf.
Neu: scripts/verify-layout.mjs + npm run verify:layout. Lädt alle sechs Seiten in
sieben Breiten (1024–1920) und misst jede Textzeile über Range.getClientRects.
Gemessen wird auf Textzeilen, nicht auf Elementkästen — sonst melden benachbarte
Tabellenzellen mit Innenabstand falsch positiv. Mindestabstand 8 px = Carbon
$spacing-03. Der Lauf fand 110 Fehler; alle behoben:
- Ringlegende: Container-Query statt fester Zweispaltigkeit. Legende sitzt rechts
vom Ring, wenn Platz ist, sonst darunter — Carbon: "positioned to the right of
the chart when space is plentiful". Namen brechen um statt überzulaufen.
- Auslastungs-Achse: Beschriftungsdichte staffelt sich über drei Container-Stufen,
vorher überlappten die Zahlen in schmalen Karten um bis zu 16 px.
- Handlungsbedarf und Kennzahl-Labels: break-words statt Überlauf.
- Kartentitel und -untertitel: break-words, weil Dateipfade keine Leerzeichen
zum Umbrechen haben.
Dokumentiert als DESIGN-SYSTEM.md §9 mit Begründung, warum das ein gemessener
Prüfer sein muss und keine Sichtprüfung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
Recherche an der Quelle statt an der Dokumentation. Zwei Ergebnisse:
1. Carbon regelt Datenvisualisierung nur teilweise. Farben, Gitter, Achsen,
Tooltip und Tickanzahl sind verbindlich festgelegt — Paddings, Margins und
Dashboard-Raster dagegen NICHT. Die Carbon-Seiten zu Chart-Anatomie und
Dashboards tragen ausdrücklich den Hinweis "this guidance is a work in
progress" und enthalten keine Zahlenwerte. Unsere Abstandswerte stammen
deshalb aus der Carbon-Spacing-Skala und der Planung mit dem Branchenpartner,
nicht aus der Data-Viz-Norm. Das steht jetzt so in DESIGN-SYSTEM.md §0.
2. Eine echte Abweichung gefunden: Der Tooltip ist seit Carbon v11 hell
(--cds-layer-02 #ffffff auf --cds-text-primary #161616, abgesetzt allein
durch den Schatten). Unser Theme führte den dunklen v10-Stand (#393939) und
berief sich dabei auf das ausgelieferte Stylesheet — die Angabe war veraltet.
Korrigiert.
Neu:
- docs/carbon-referenz.json — kanonische Werte mit Quelle, Version und
Prüfdatum, gezogen aus @carbon/charts 1.23.0 styles.min.css und
configuration.ts. Bewusste Abweichungen (Balkenbreite 48 statt 16, feste
Kategoriefarben statt n-Serien-Paletten) sind dort begründet.
- scripts/verify-carbon.mjs + npm run verify:carbon — gleicht chartTheme.ts
gegen die Referenz ab und bricht bei Drift ab.
- docs/PRUEFFRAGEN.md — Prüffragen für die Gestaltungsabnahme mit
nachprüfbarem Ja/Nein, plus Leseliste (FT Visual Vocabulary, IBCS,
Cleveland & McGill, Few, Datawrapper Academy).
Die 14er-Palette wurde gegen die CSS-Variablen --cds-charts-14-1-* geprüft und
stimmt exakt; ebenso Gitter #e0e0e0, Achse #8d8d8d und Achsentext #525252.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
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
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
dejanandClaude Opus 5