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
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
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
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
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