Files
HiveGrid-Wireframes/05 HiveGrid Map/Infrastruktur und Navigation.md
T
davidandClaude Fable 5 e48a5a46e8 Plan Querschnitt-Pakete P3-P5 und Infrastruktur-Entscheidungen
- Feature Map: Regelwerk, Kanten-System, Paket-Canvas-Verknuepfungen, MD-Links
- Infrastruktur & Navigation: Sidebar-Abgleich, Einstellungen-Modell, Mobile, Gating
- WF-P3 Benachrichtigungen + Audit Log (validiert)
- WF-P4 Aufgaben (inkl. Topbar-Drawer-Delta) + Dateien (inkl. Teilen v1, CR an Dev)
- WF-P5 Integrationen (Sync-Verlauf als eigene Seiten)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-08 20:47:46 +02:00

117 lines
7.4 KiB
Markdown

---
kind: decisions
project: HiveGrid Screen Project
area: HiveGrid Map
topic: Infrastruktur & Navigation
status: in Arbeit
stand: 2026-07-08
---
# Infrastruktur & Navigation
High-Level-Entscheidungen: wo Tools in der UI sitzen, wie sie heißen, wie man zu Einstellungen kommt. Grundsatz: **Wir weichen nicht vom Repo ab** — welche Tools es gibt und was sie können, ist fix. Hier geht es nur um Platzierung, Benennung und Navigation. Echte Repo-Fehler werden markiert und gefixt.
## 1. Sidebar — Ist-Stand (von David gebaut, 2026-07-08)
| Gruppe | Punkte |
|---|---|
| 1 | Dashboard · Kontakte · Leads · Pipelines · Aufgaben |
| 2 | Kalender · Terminbuchung · Dateien · Formulare |
| 3 | Chat · Telefonie · Marketing |
| 4 | Automation · KI |
| 5 | Integrationen · Einstellungen |
Die Gruppierung mit Trennlinien ist validiert und bleibt.
## 2. Abgleich mit dem Repo — nötige Anpassungen
Alle Punkte am 2026-07-08 mit David entschieden:
| # | Punkt | Befund | Entscheidung |
|---|---|---|---|
| 1 | „Dashbord" | Tippfehler | ✅ → „Dashboard" (David fixt in Subframe) |
| 2 | „KI"-Punkt | Kein KI-Layer in v1 (AD-26); HiveGrid wird von außen per MCP angesteuert | ✅ Punkt wird zu **„MCP"** umbenannt (MCP-Server-Anbindung). Achtung: Feature selbst ist v2 (VR-MCP) — Punkt in v1 als gesperrter „bald"-Platzhalter behandeln |
| 3 | Plantafel fehlt | Kern-Werkzeug, eigene Route `/projects/plantafel` | ✅ rein — Gruppe 2 (Planung), neben Kalender |
| 4 | HR fehlt | Eigenes Modul `/hr` | ✅ rein — unterste Arbeits-Gruppe (Abo-Modul, ggf. mit Schloss) |
| 5 | „Pipelines" als Label | UI-Label ist Davids Freiheit | ✅ bleibt **„Pipelines"** |
| 6 | „Leads" als Label | UI-Label ist Davids Freiheit | ✅ bleibt **„Leads"** |
| 7 | „Automation" | Spec-Sidebar hatte Automationen vergessen — Davids Sidebar hat es richtig drin | ✅ bleibt |
| 8 | „Integrationen" als Top-Punkt | Repo-Route `/admin/integrations` | ✅ bleibt eigener Punkt — Default für Admin; Sichtbarkeit für andere später über Rollen/Rechte |
**Ziel-Sidebar v1** (Änderungen fett):
| Gruppe | Punkte |
|---|---|
| 1 | Dashboard · Kontakte · Leads · Pipelines · Aufgaben |
| 2 | Kalender · Terminbuchung · **Plantafel** · Dateien · Formulare |
| 3 | Chat · Telefonie · Marketing |
| 4 | Automation · **MCP** (v1 gesperrt) · **HR** |
| 5 | Integrationen · Einstellungen |
## 3. Einstellungen — ein Hub, kein separater Admin-Tab ✅ (Empfehlung, zu bestätigen)
Frage war: „Einstellungen" und zusätzlich ein eigener „Admin"-Tab? Entscheidung Vorschlag:
**EIN Punkt „Einstellungen"**, innen getrennt durch die Seitennavigation. Begründung:
- SHK-Betriebe sind klein — der Chef IST der Admin. Zwei Orte („wo war das nochmal — Einstellungen oder Admin?") erzeugen genau die Verwirrung, die wir vermeiden wollen.
- P2 hat das Muster schon validiert und gebaut: „Einstellungen → Mitarbeiter" mit Tabs. Mitarbeiter & Rollen gehören also in die Einstellungen. ✅
- Was man nicht darf, sieht man nicht (Permission-Gate blendet Workspace-Sektionen für Nicht-Admins aus) — die Trennung passiert über Rechte, nicht über zwei Menüpunkte.
Grobe Innen-Gliederung (Detail kommt beim jeweiligen Feature):
- **Persönlich:** Profil · Sicherheit · Benachrichtigungen
- **Team:** Mitarbeiter & Rollen *(gebaut, P2)*
- **Daten:** Eigene Felder · Tags · Duplikate
- **Verbindungen:** Integrationen · E-Mail-Domain · Telefonie · Kalender
- **Workspace:** Abo & Rechnungen · Aktivitäts-Protokoll · Datenschutz · Demo-Daten & Erste Schritte
## 4. Zentral vs. atomar — die Unterscheidungsregel ✅
Davids Anforderung: klare Trennung, damit niemand rätselt, wo eine Einstellung lebt.
**Faustregel:**
- **Im Tool (atomar):** alles, was verändert, wie DIESES Tool aussieht und arbeitet — oft pro Nutzer oder pro Board. Beispiele: Kanban — welche Felder auf der Karte sichtbar sind, wo sie sitzen, Feld-Verschieben; Listen-Spalten konfigurieren; Filter; Plantafel-Ansicht; Formular-Builder selbst; Buchungsseiten + Verfügbarkeit im Terminbuchungs-Tool.
- **In den Einstellungen (zentral):** alles, was Struktur, Menschen, Rechte, Geld, Daten oder Verbindungen betrifft und workspace-weit gilt. Beispiele: Mitarbeiter & Rollen, Pipeline-Struktur (welche Boards existieren, Spalten, Pflichtfelder, wer sie sieht), eigene Felder, Tags, Integrationen, Abo, Datenschutz.
- **Brücke:** Tools mit zentralen Einstellungen bekommen einen klar beschrifteten Einstieg im Tool-Header (z. B. „Board verwalten" im Kanban) — der springt in die Einstellungen (gleiche Seite, kein Duplikat). Beschriftet, nicht nur ein Zahnrad-Icon, damit klar ist: Das führt woanders hin.
Merksatz: **„Ansicht & Arbeitsweise = im Tool. Struktur & Rechte = in den Einstellungen."**
## 5. Mobile ✅
- v1 mobil = **responsive PWA-Version der Web-App** (kein eigenes App-Design), Monteur-Flächen (Plantafel „Heute", Abnahme, Chat) sind mobile-first designt.
- Bottom-Nav (Handy): **Heute (meine Termine) · Projekte · Aufgaben · Chat · Mehr** — Chat wird mitgeplant, auch wenn er zum Start evtl. noch nicht fertig ist.
- Monteur landet nach Login auf seinem Monteur-Dashboard (= genau diese „Heute"-Inhalte laut Spec).
## 6. Abo-Gating: Schloss statt unsichtbar ✅
Nicht gebuchte Module bleiben **sichtbar mit Schloss + „Freischalten"-Hinweis** — Luft nach oben soll offensichtlich sein. Der Admin kann sie zusätzlich aktiv ausblenden. (Repo unterstützt beides: „ausgeblendet/gesperrt".)
## 7. Rollen-Ansichten: erst am Ende ✅
Wir designen jetzt überall die **Maximalansicht (Admin sieht alles)**. Rollen-/Persona-Sichten (Chef/Büro/Monteur) werden ganz am Ende als eigener Durchgang geplant. Ausnahme: Monteur-Mobil-Flächen, die per Spec mobile-first sind (Plantafel, Abnahme), werden direkt mitgedacht.
## 8. Bearbeitungs-Reihenfolge: nach Abhängigkeiten ✅
Gemäß blocked-by der Tickets — erst Querschnitt (wird überall eingebettet), dann die Kern-Kette, dann Zubringer:
| # | Feature | Ticket | Warum an dieser Stelle |
|---|---|---|---|
| 1 | Benachrichtigungen + Aktivitäts-Protokoll | D-P3 | Querschnitt: Glocke + Verlaufs-Drawer stecken in jedem Feature |
| 2 | Aufgaben + Dateien | D-P4 | Querschnitt: Reiter in jeder Detailseite |
| 3 | Integrationen | D-P5 | Framework für alle Verbindungs-Karten (E-Mail, Telefonie, Kalender, Signatur) |
| 4 | Kontakte & Organisationen | D-CRM | Detailseite = Vorlage für ALLE Detailseiten |
| 5 | Lead-Eingang | D-P7 | Start der Kette |
| 6 | Kanban-Board & Pipelines | D-P8 + D-KANBAN | Kern der Kette |
| 7 | Projekt-Akte / Plantafel / Abnahme | D-P9, D-PLAN, D-ABN | Auftrags-Kette |
| 8 | danach | Zubringer + Rest | Formulare, Terminbuchung, Kalender, Chat, Telefonie, Marketing, Automationen, HR, Dashboard/Suche, Verwaltung |
Langläufer-Hinweis: Der **Automations-Baukasten (D-FLOW)** ist die schwerste UI und sollte parallel früh angerissen werden, sobald die Querschnitts-Runde durch ist.
## Offene Punkte aus dieser Runde
- [x] KI-Punkt → wird „MCP" (v1 gesperrter Platzhalter) — entschieden 2026-07-08
- [x] Plantafel + HR in die Sidebar — entschieden: beide rein
- [x] Labels „Pipelines" und „Leads" — bleiben wie gebaut
- [x] „Integrationen" — bleibt eigener Top-Punkt (Admin-Default, Sichtbarkeit via Rollen)
- [ ] David: Sidebar in Subframe nachziehen (Dashboard-Tippfehler, MCP-Label, + Plantafel, + HR)
- [ ] Einstellungen-Innen-Gliederung (Abschnitt 3) im Detail — wird beim jeweiligen Feature festgezurrt