davidandClaude Fable 5
e48a5a46e8
- 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>
7.4 KiB
kind, project, area, topic, status, stand
| kind | project | area | topic | status | stand |
|---|---|---|---|---|---|
| decisions | HiveGrid Screen Project | HiveGrid Map | Infrastruktur & Navigation | in Arbeit | 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
- KI-Punkt → wird „MCP" (v1 gesperrter Platzhalter) — entschieden 2026-07-08
- Plantafel + HR in die Sidebar — entschieden: beide rein
- Labels „Pipelines" und „Leads" — bleiben wie gebaut
- „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