dejanandClaude Opus 5
1896d2772b
Die Uebergabe geht an einen Dev, der den Einbau mit einem Coding-Agenten macht. Dafuer reicht "hier ist das Repo" nicht. Vier neue Artefakte, alle gegen das Zielsystem geprueft, nicht aus dem Gedaechtnis geschrieben. **EINBAU.md** ist der Einstieg. Der wichtigste Satz darin steht ganz oben: Das Dashboard in HiveGrid ist kein leeres Blatt. Route, Widget-Registry, Rollen-Layouts, Drilldown, Export, Live-Updates und Layout-Speicherung sind gebaut. Wer dort eine neue Seite anlegt, wirft funktionierende Software weg. Das ist nicht meine Einschaetzung: Der Brief P30 im Zielsystem sagt woertlich "Delta-Phase, kein Neubau ... Dashboard/Widget-Registry voll gebaut". Analytics dagegen gibt es noch nicht und wird nach dem Muster von leads.analytics.tsx neu gebaut. Dazu eine Tabelle, welche Datei wohin wandert, und eine zweite, was ausdruecklich nicht mitwandert und warum. **docs/port/TICKET-ANALYTICS.md und TICKET-DASHBOARD.md** sind im Format von .planning/ticket-docs/ geschrieben, mit Header-Tabelle, Abhaengigkeiten, Definition of Done, Technischen Bausteinen, Quellen und Dev-Nachzug. Sie koennen dorthin kopiert werden; dann greift der bestehende Ablauf, statt dass wir einen zweiten danebenstellen. **docs/port/i18n-*.json plus TEXTE.md.** pnpm run verify:i18n ist in HiveGrid ein Gate: keine hartkodierten Strings. Dieser Prototyp ist zu 100 % hartkodiertes Deutsch. 185 Texte mit Schluesselvorschlag und Fundstelle, dazu derselbe Inhalt als einfuegbarer Baum. Erzeugt von scripts/i18n-inventar.py (npm run i18n:inventar), damit das Inventar nicht auseinanderlaeuft, wenn sich am Prototyp noch etwas aendert. Dabei gefunden: app.dashboard.widgets.* enthaelt bereits 17 Widgets, darunter genau fuenf, die dieser Prototyp gestaltet (receivables, orderIntake, daysToPayment, winRate, stageDistribution) und genau die drei, die er als reserviert markiert (myTasks, scheduleToday, hrRequests). Neue Schluessel dafuer waeren Dubletten; die acht sind in TEXTE.md einzeln aufgefuehrt. Die Anrede stimmt ebenfalls schon ueberein, HiveGrid duzt. **CLAUDE.md** als Einstiegspunkt, den Claude Code beim Oeffnen des Repos von selbst liest: was dieses Repo ist, die drei Dinge, an denen ein Einbau sonst scheitert, und wo was steht. Jeder in den Dokumenten genannte Pfad wurde in beiden Repos nachgeprueft. Ein Fehler dabei gefunden und behoben: der Designer-Brief heisst P11-suche-dashboard.md, nicht P11.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
89 lines
4.5 KiB
Markdown
89 lines
4.5 KiB
Markdown
# ANA-2 · Dashboard-Gestaltung aus dem Prototyp übernehmen
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Typ** | Dev (UI, bestehenden Screen erweitern) |
|
|
| **Owner** | *(offen)* |
|
|
| **Phase** | *(offen)* |
|
|
| **Cycle/Fenster** | *(offen)* |
|
|
| **Status** | geplant |
|
|
|
|
> **Achtung, zuerst lesen:** Das Dashboard existiert bereits vollständig:
|
|
> Route, Widget-Registry, Rollen-Layouts, Drilldown, Export, Live-Updates,
|
|
> Layout-Speicherung, Berechtigungen. Dieses Ticket **gestaltet**, es baut
|
|
> nicht neu. Wer hier eine neue Seite anlegt, wirft funktionierende Software weg.
|
|
|
|
## Abhängigkeiten & Parallelität
|
|
- **Blocked by:** `ANA-1`, vier der Kacheln zeigen Diagramme aus Analytics.
|
|
- **Blocks:** nichts.
|
|
- **Läuft parallel zu:** allem. Berührt `DashboardPage.tsx` und die
|
|
Widget-Definitionen, sonst nichts.
|
|
|
|
## Was wir bauen
|
|
Die Kacheln des Begrüßungsbildschirms bekommen die Gestaltung aus dem
|
|
Prototyp: Begrüßung, vier Kennzahlen mit Absprung in die Analyse,
|
|
Handlungsbedarf über die volle Breite, vier Diagramme.
|
|
|
|
Das 12-Spalten-Raster bleibt unangetastet. Der Prototyp hat es aus
|
|
`DashboardPage.tsx` übernommen; die Kachelbreiten dort (`breite`/`start`)
|
|
sind eins zu eins `widget.size.w` und `widget.position.x`.
|
|
|
|
## Benötigte Screens
|
|
Keine neuen Designs. Der Prototyp zeigt den fertigen Stand unter `/dashboard`.
|
|
|
|
## Definition of Done
|
|
- [ ] Kachelrahmen entspricht dem Prototyp: Titel, Beschreibung, Domänen-Icon,
|
|
**Zeitraum im Kopf**, Absprung als Fußzeile
|
|
- [ ] Die vier Kennzahlen sind Links in die zugehörige Analyse-Seite
|
|
(`widget.href`, wie es die `StatsCard` heute schon kann)
|
|
- [ ] Handlungsbedarf-Liste als Widget über die volle Breite
|
|
- [ ] Vier Diagramme aus `ANA-1` als Widgets eingehängt
|
|
- [ ] Kein seitenweiter Filter. Jede Kachel nennt ihren Zeitraum selbst
|
|
(P11: „Edit = nur Widget-Filter/Zeitraum")
|
|
- [ ] Bestehende Funktionen unverändert lauffähig: Rollenwechsel,
|
|
Bearbeitungsmodus, Drilldown, Export, Live-Updates, Gating
|
|
- [ ] `pnpm run verify:i18n`, `lint`, `test`, `verify:push` grün
|
|
|
|
## Technische Bausteine
|
|
| Baustein | Quelle im Prototyp | Ziel |
|
|
|---|---|---|
|
|
| Kachelrahmen | `components/dashboard/WidgetKachel.tsx` | Widget-Renderer in `DashboardPage.tsx` |
|
|
| Begrüßung (`hero`) | `components/dashboard/Begruessung.tsx` | `hero`-Zweig in `DashboardPage.tsx` |
|
|
| Kachelraster | `components/dashboard/WidgetRaster.tsx` | **vorhanden**, nur abgleichen |
|
|
| Kennzahl-Kachel | `components/cards/KPICard.tsx` | `StatsCard` bzw. deren Gestaltung |
|
|
| Handlungsbedarf | `components/cards/AlertList.tsx` | neues `list`-Widget |
|
|
|
|
**Eine Zeile fehlt im Raster.** `dashboardWidgetGridClass` kennt keinen Fall
|
|
`position.x === 9`, weil bisher keine Rolle vier Kacheln nebeneinander stellt.
|
|
Die Kennzahlenreihe tut das. Ohne die Zeile fließt die vierte Kachel dank
|
|
`grid-flow-row-dense` trotzdem richtig, nur ohne festen Anfang. Vermerkt in
|
|
`components/dashboard/WidgetRaster.tsx` des Prototyps.
|
|
|
|
**Übersetzungen: erst suchen, dann anlegen.** `app.dashboard.widgets.*` enthält
|
|
bereits `receivables`, `orderIntake`, `daysToPayment`, `winRate` und
|
|
`stageDistribution`. Das sind genau die Kacheln aus diesem Ticket. Neue
|
|
Schlüssel dafür wären Dubletten.
|
|
|
|
## Quellen (granular)
|
|
- `toolctrl-labs/Dashboard` → `EINBAU.md`, `docs/SCOPE-ANALYTICS-DASHBOARD.md`
|
|
(Abschnitt 3a: was gebaut wurde und warum), `docs/DESIGN-SYSTEM.md`
|
|
- `.planning/designer-briefs/P11-suche-dashboard.md` → Rollen-Layouts GF / Büro / Monteur
|
|
- `.planning/designer-briefs/P30-dashboard-deluxe-querschnitt.md` → bestätigt die
|
|
Ausgangslage wörtlich: „Delta-Phase, kein Neubau … Dashboard/Widget-Registry
|
|
voll gebaut"
|
|
- Bestehender Code: `apps/web/app/components/screens/dashboard/DashboardPage.tsx`,
|
|
`services/dashboard/dashboard.server.ts`, `services/dashboard-registry/registry.server.ts`
|
|
|
|
## Dev-Nachzug
|
|
- **Handlungsbedarf steht doppelt.** Im Prototyp absichtlich: auf dem Dashboard
|
|
und auf der Analytics-Übersicht. Das Entfernen hätte eine offene Produktfrage
|
|
mitentschieden. **Vor dem Port auflösen, nicht übernehmen.** Siehe
|
|
`docs/SCOPE-ANALYTICS-DASHBOARD.md` Abschnitt 3a.
|
|
- **Drei Bereiche kommen später:** eigene Aufgaben, Termine des Tages,
|
|
HR-Anträge. Alle drei haben in HiveGrid schon Widget-Domäne **und**
|
|
Übersetzungsschlüssel (`myTasks`, `scheduleToday`, `hrRequests`). Im
|
|
Prototyp sind sie gestaltet unter `/komponenten`; die Stelle im Raster ist in
|
|
`pages/DashboardSeite.tsx` als Kommentarblock markiert.
|
|
- **Rollen Büro und Monteur** sind nicht gestaltet. Sie entstehen aus denselben
|
|
Kacheln in anderer Zusammenstellung; das ist eine Produktentscheidung.
|