main
14
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  dejanandClaude Opus 5
|
bada5db344 |
Menue nicht mehr abschneiden, Zeile teilt sich nach dem Ausblenden neu auf
Zwei Fehler aus dem Sparring, beide an der Diagrammkarte. **Das Optionsmenue war abgeschnitten.** Die Karte trug `overflow-hidden`, das Menue klappt aus dem Kopf heraus, und der zweite Eintrag war nur zur Haelfte zu sehen. Das Beschneiden ist entfallen; die runden Ecken brauchen es nicht, weil Kopf und Koerper 16 px Innenabstand haben und nichts an der Kante anliegt. **Nach dem Ausblenden blieb eine Luecke.** Die Zeilen waren ein Raster mit festen Spalten. Blendet man eine Karte aus, gibt ChartCard `null` zurueck, die Spalte bleibt aber stehen und die Nachbarkarte behaelt ihre zwei Drittel. Neu ist `ChartReihe` in PageContainer.tsx: eine Flexzeile statt eines Rasters. Die verbliebenen Karten verteilen den Platz unter sich neu, ohne dass jemand mitzaehlen muesste, wie viele gerade sichtbar sind. Nachgemessen auf /analytics: Der Zahlungsverlauf geht von 574 px auf 1164 px, sobald die Nachbarkachel verschwindet. Zehn Zeilen auf allen fuenf Analyse-Seiten umgestellt. `gleichHoch` haelt die Unterscheidung aus dem letzten Sparring fest: gestreckt nur, wo die Karten dieselbe Bauart haben. Beim Umbau eine Regression gebaut und durch Nachmessen gefunden: Aus 885/443 wurde 664/664. `[&>*]:flex-1` erzeugt den Selektor `.zeile > *`, und der ist spezifischer als eine Klasse am Kind, also verlor `xl:flex-[2]`. Jetzt `xl:flex-[2]!`, mit dem Grund als Kommentar an der Komponente. Nachgemessen nach der Aenderung, alle Zeilen: 885/443 wo zwei zu eins gewollt ist, 389/389 und 409/409 und 595/595 wo gleiche Hoehe gewollt ist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX |
||
|
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
|
||
|
dejanandClaude Opus 5
|
7bbbd00ed2 |
Fokusring nur noch bei Tastaturbedienung zeigen
Nach dem Oeffnen der Schublade lag ein blauer Rahmen um "Dashboard", nach dem Schliessen um den Hamburger — bis man woanders hinklickte. Der Ring hat einen praktischen Grund, aber nur fuer die Tastatur: Er zeigt, wo man gerade steht. Nach einem Mausklick weiss man das ohnehin. Ursache war unser eigener Fokus-Sprung, nicht die CSS-Regel. Die benutzt laengst :focus-visible. Setzt aber ein Skript den Fokus — Fokusfalle beim Oeffnen, Rueckgabe an den Ausloeser beim Schliessen —, wertet Chrome das wie Tastaturbedienung und zeigt den Ring trotzdem. Drei Aenderungen: - Beim Oeffnen bekommt der Dialograhmen den Fokus statt des ersten Links. Das ist ohnehin das uebliche Vorgehen fuer einen Dialog; die Sprachausgabe liest den Dialog an, der erste Tabulatorschritt landet auf dem ersten Link. - Elemente mit tabindex="-1" bekommen keinen Ring mehr. Sie sind aus der Tabulatorreihenfolge heraus und werden nur per Skript fokussiert — ein Ring um den ganzen Schubladenrahmen waere dort Laerm. - AppShell schreibt die zuletzt benutzte Eingabeart als data-eingabe an das Wurzelelement. Solange sie "zeiger" ist, entfaellt der Ring an Knoepfen und Links. Eingabefelder sind ausgenommen, dort gehoert er zum Zustand "hier wird gerade geschrieben". Der erste Tastendruck schaltet ihn ueberall zurueck. Dabei ist eine Luecke in der Fokusfalle aufgefallen und behoben: Mit dem Fokus auf dem Rahmen lief Umschalt+Tab aus dem Dialog heraus, weil die Falle nur den ersten Link als Umkehrpunkt kannte. Der Rahmen steht im Dokument vor seinen Kindern und gehoert dazu — sonst waere die Zusage von aria-modal gebrochen. Nachgemessen statt begutachtet, alle Faelle: Maus offen → Rahmen, kein Ring Maus zu → Hamburger, kein Ring Tastatur offen → Rahmen, kein Ring Tastatur erstes → "Dashboard", RING Tastatur rueckwaerts → "Komponenten", RING (Falle haelt) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX |
||
|
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 |
||
|
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 |
||
|
dejanandClaude Opus 5
|
4cb0b5c799 |
feat(responsive): Breakpoints für 375–1920 px
Der Prototyp war auf Schreibtischbreiten gebaut. Bei 375 px lief die Seite um 306 px seitlich über, und dem Inhalt blieben 135 px, weil die Seitenleiste ihre vollen 240 px behielt. Seitenleiste (an HiveGrid abgeglichen, nicht erfunden): - Unterhalb 768 px faehrt sie als Schublade ueber den Inhalt. Derselbe Breakpoint, den die Software als MOBILE_BREAKPOINT fuehrt. - Hamburger links in der Kopfzeile, FeatherMenu, 32x32, md:hidden, vor dem Breadcrumb — wie SubframeAppShell ihn rendert. - Abdeckung dahinter, Escape schliesst, Fokus wandert beim Oeffnen auf den ersten Eintrag und kehrt beim Schliessen zum Ausloeser zurueck. - Fokusfalle mit Tab und Umschalt+Tab: Der Rahmen traegt role=dialog und aria-modal, ohne Falle waere das gegenueber einem Screenreader unwahr. - Der Einklapp-Knopf ist unterhalb md ausgeblendet. Er ragt bauartbedingt 17 px nach rechts heraus und blieb sonst als angeschnittener, wirkungsloser Rest bei x = -16 am Bildrand stehen — der gemeldete Fehler. Inhalte: Raster einspaltig ab 375 px, Seitenkopf mit Aktionen unter dem Titel und Icon-only, Zeitraum-Segment und Reiterstreifen waagerecht scrollend statt umbrechend (ein Segment ueber zwei Zeilen liest sich als zwei Steuerelemente), Filter-Panel auf volle Zeilenbreite, Tabellen mit eigenem Scrollbereich. Zwei abgeschnittene Fehler mitbehoben, die der Prueferer nicht sieht: - KPI-Label lief bei 1280 px um 5 px aus seinem Kasten; bricht jetzt um. Die Karte wird dadurch eine Zeile hoeher — der Preis fuer eine vollstaendig lesbare Beschriftung. - Randmarken der Auslastungsachse ragten je rund 10 px ueber die Spur. In sehr schmalen Karten entfaellt die Achse ganz; dort bleibt nur rund 40 px Spur, auf der selbst zwei Marken aneinanderstossen. verify-layout deckt jetzt 375-1920 px ab (vorher ab 1024) und meldet zusaetzlich Seitenueberlauf: ein waagerechter Scrollbalken auf Dokumentebene ist immer ein Fehler, nie ein Kompromiss. 7 Seiten x 9 Breiten gruen. Ab 1024 px ist der abgenommene Stand unveraendert — numerisch geprueft ueber die Bounding-Boxen aller Karten, Raster, Tabellen und Kopfelemente. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX |
||
|
dejanandClaude Opus 5
|
b3d71c1f19 |
docs: Rangfolge beim Einbau festhalten — HiveGrid gewinnt
Klarstellung, damit beim Port keine globalen Regeln aus diesem Repo in die Software wandern. Verbindlich ist aus diesem Repo nur das Analytics-Eigene und das Fachliche: Kennzahl-Definitionen, Diagrammregeln, Verhalten — und die Navigationsstruktur als Verabredung (zwei Einträge in der Seitenleiste, Analytics mit innerer Leiste). Nicht verbindlich ist alles Globale: Schrift, Schriftgrößen, Abstände, Farben, Radien, Control-Höhen, App-Shell, Kopfzeile, i18n, Formatierung. Das kommt ausschließlich aus HiveGrid. Dass dieser Prototyp dieselbe Schrift, dieselbe Seitenleisten-Komponente und dieselben Token benutzt, dient allein der Lesbarkeit neben der Software — es ist keine Vorlage, an der sich die Software auszurichten hätte. Weicht ein Wert hier von HiveGrid ab, ist der Wert hier falsch. Ebenso festgehalten, was Gerüst ist und wegfällt: AppShell, unsere Kopie der Seitenleiste, PageHeader, die Kopfzeile, die Routen unter app/ und die Dashboard-Platzhalterseite. Der Nachbau der inneren Leiste wird nicht portiert; in HiveGrid entsteht sie über das dortige SidebarIconsLayout. Vermerkt in ZIELSYSTEM.md (neuer Abschnitt 0 mit Zuständigkeitstabelle), im Kopf von HANDOVER.md und README.md, bei der Struktur in NAVIGATION.md, als Vorbemerkung zu den bewussten Abweichungen in LEITPLANKEN.md — und als Kommentarblock in AppShell.tsx und AnalyticsInnerNav.tsx, weil beim Port oft zuerst der Code gelesen wird. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX |
||
|
dejanandClaude Opus 5
|
9eec855f57 |
fix(shell): Einklapp-Knopf wurde von der Inhaltsspalte überdeckt
Der Knopf ragt bauartbedingt 17 px aus der Seitenleiste in die Inhaltsfläche hinein. Dort wurde seine rechte Hälfte verdeckt — er sah abgeschnitten aus und war auf diesem Teil nicht anklickbar. Nicht abgeschnitten, sondern überdeckt: Gemessen war overflow überall visible, aber das oberste Element an der Knopfmitte war die Inhaltsspalte. Ursache ist ein Stapelkontext — 'position: sticky' erzeugt einen eigenen, wodurch das z-index:40 des Knopfes darin gefangen bleibt. Der Rahmen selbst hatte z-index:auto, also malte die später im Dokument stehende Inhaltsspalte darüber. Behoben mit z-50 am Sidebar-Rahmen; die Software setzt an derselben Stelle ebenfalls z-50. Nachgemessen: Am rechten Rand ist jetzt der Knopf selbst das oberste Element, und ein Klick genau dort schaltet um. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX |
||
|
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 |
||
|
dejanandClaude Opus 5
|
466c079644 |
feat(nav): innere Leiste statt Reiter im Analytics-Bereich
Abwägung an der Quelle statt nach Gefühl. Das Zielsystem nutzt beide Muster, aber für verschiedene Aufgaben: - Innere Leiste (SidebarIconsLayout, 17 Aufrufstellen): Arbeitsbereiche mit Geschwisterseiten — Leads, Termine, HR, Einstellungen. - Reiter (Tabs): Abschnitte innerhalb EINER Seite — Formular-Editor, Chat-Dateien, Projekt-Teilbereiche, Übergabe-Dialog. Analytics mit fünf Analyse-Seiten ist der erste Fall, strukturell dasselbe wie Leads mit acht. Drei Gründe: 1. Kohärenz: dieselbe Bedienung an derselben Stelle wie in Leads. 2. Der Platzeinwand trägt nicht. Die Leiste ist eine 32 px schmale Icon-Spalte und klappt erst bei Zeigerkontakt oder Tastaturfokus auf 191 px aus, verzögert (300 ms auf, 350 ms zu), damit sie beim Überstreichen nicht aufspringt. Die Breite brauchen die Analyse-Seiten mit ihren fünfspaltigen Kennzahlenreihen. 3. Reiter sind dort der Rückfall, nicht die Wahl: SidebarIconsLayout zeigt unterhalb sm selbst eine Reiterleiste. Auf dem Schreibtisch Reiter zu nehmen hieße, die Handy-Notlösung zur Hauptform zu machen. Der Nachbau übernimmt diesen Rückfall mit. Nachgemessen: 32 px eingeklappt, 191 px bei Zeigerkontakt, aktiver Eintrag hervorgehoben, aria-current gesetzt. verify-layout weiterhin grün. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX |
||
|
dejanandClaude Opus 5
|
aa86dfe44d |
fix(nav,schrift): nur eigene Features in der Leiste, Instrument Sans laden
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 |
||
|
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 |
||
|
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
|
||
|
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 |