3b57ca4594
All checks were successful
Build and Push Docker Image / build-and-push (push) Successful in 13m43s
274 lines
12 KiB
Markdown
274 lines
12 KiB
Markdown
# Roadmap — Feedback Fabian (Mai 2026)
|
||
|
||
> **Quelle**: User-Feedback von Fabian, Führungsoffizier / Übungsleiter Feuerwehr.
|
||
> **Erhalten**: 20.05.2026
|
||
> **Status**: Geplant, noch nicht umgesetzt.
|
||
|
||
Dieses Dokument ist die strukturierte Roadmap aus Fabians Feedback. Jede KI / jeder Entwickler der an Lageplan arbeitet, soll diese Datei vor Beginn lesen, um Kontext und Priorisierung zu kennen.
|
||
|
||
---
|
||
|
||
## Originalfeedback (Zusammenfassung)
|
||
|
||
Fabian sucht eine Lösung um **Einsätze und Übungen einfach zu skizzieren und zu krokieren**. Lobt die App, gibt aber konkrete Verbesserungsvorschläge aus Anwendersicht:
|
||
|
||
1. **Einsatz vs. Übung unterscheiden** — bei Übungen kein Journal nötig, dafür Übungsziele/Auswertung
|
||
2. **Symbol-Bibliothek erweitern** — Warteraum, Rettungsachse, taktische Zeichen
|
||
3. **Symbol-Schönheitsfehler** — Treppe/Eingang mit Umriss, Absperrung
|
||
4. **Stockwerke/Geschosse** — eigene Werte eintragen
|
||
5. **Symbol-Kategorien aufräumen** — Motorspritze unter Organisation statt Geräte; Hydrant/Leitern uneinheitlich
|
||
6. **Linien mit Typ** — nach Zeichnen wählen: Rettungsachse (gestrichelt + R), Leitung (blau), Schlauch, etc.
|
||
7. **Multi-User Live** — eine Person zeichnet Karte, andere schreibt Journal gleichzeitig
|
||
8. **Rapport-/Lageansicht** — separate Sicht mit Pendenzen, aktueller Stand, wichtige Punkte für Führungsunterstützung (FU), darstellbar auf grossem Bildschirm; nicht alle Journaleinträge sichtbar für alle
|
||
|
||
---
|
||
|
||
## Phasen-Plan
|
||
|
||
### Phase 1 — Symbol-Architektur Redesign (3-4 Wochen) ⭐⭐
|
||
|
||
**Strategischer Umbau** statt nur Kategorien aufräumen. Begründung:
|
||
- Fabians Feedback zeigt, dass die aktuelle Kategorisierung uneinheitlich ist
|
||
- Symbol-Bibliothek ist zu starr — andere Anwender (THW, Sanität, ausländische Wehren) brauchen andere Symbole
|
||
- Mandantenfähigkeit ist zentrales Versprechen → muss auch für Symbole konsequent durchgezogen werden
|
||
|
||
#### 1.1 Neue Symbol-Architektur: Template-Import + 100% mandantenspezifisch
|
||
|
||
**Konzept**: Mandant startet mit leerer Bibliothek, importiert beim Onboarding (oder jederzeit) **kuratierte Vorlagen-Pakete** (Feuerwehr CH, THW, Sanität…). Importierte Symbole werden vollständig eigene Mandanten-Daten — umbenennbar, löschbar, kategorisierbar, ergänzbar.
|
||
|
||
**Datenmodell**:
|
||
```
|
||
TenantCategory (per-tenant, frei definierbar)
|
||
- id, tenantId, name, sortOrder, icon
|
||
|
||
TenantSymbol (per-tenant, ehemals "Meine Symbole")
|
||
- id, tenantId, categoryId → TenantCategory
|
||
- name, svgPath, sortOrder, customName
|
||
|
||
SymbolTemplate (global, read-only)
|
||
- id, packageId ("feuerwehr-ch", "thw", "sanitaet")
|
||
- categoryName, name, svgPath, tags
|
||
```
|
||
|
||
**Tasks**:
|
||
- [x] Schema-Migration: `TenantCategory` neu, `TenantSymbol.categoryId` ergänzen, `SymbolTemplate` erstellen
|
||
- [x] Migration SQL + idempotente Raw-SQL-Migration (`prisma/migrate.js`)
|
||
- [x] Seed-Skript: `public/signaturen/*.svg` → `SymbolTemplate`
|
||
- [x] Migration bestehender Tenants: `TenantSymbol.name`, `svgPath`, `categoryId` befüllen
|
||
- [ ] **Auto-Import des `feuerwehr-ch` Pakets beim ersten Login** (oder bei leerer Bibliothek)
|
||
- [ ] API: CRUD für `TenantCategory` (`GET/POST/PATCH/DELETE /api/tenant/categories`)
|
||
- [ ] API: `GET /api/templates` — listet verfügbare Pakete
|
||
- [ ] API: `POST /api/templates/import` — importiert ausgewählte Symbole als TenantSymbols
|
||
- [ ] API: `TenantSymbol` erweitern — Upload-Endpoint, Kategorie-Zuordnung, gruppierte Liste
|
||
- **Files**: `prisma/schema.prisma`, `src/app/api/tenant/categories/`, `src/app/api/tenant/symbols/`, `src/app/api/templates/`
|
||
|
||
#### 1.2 UX: Symbol-Manager im Admin
|
||
|
||
**Sidebar / Symbol-Verwaltung**:
|
||
```
|
||
┌─ Meine Symbole ─────────────┐
|
||
│ ┌ Fahrzeuge ─────────┐ │
|
||
│ │ 🚒 TLF │ │
|
||
│ │ 🚒 RW │ │
|
||
│ │ + Symbol │ │
|
||
│ └────────────────────┘ │
|
||
│ ┌ Wasser ────────────┐ │
|
||
│ │ 🟦 Hydrant │ │
|
||
│ └────────────────────┘ │
|
||
│ [+ Kategorie] │
|
||
│ [📦 Vorlagen importieren] │
|
||
└─────────────────────────────┘
|
||
```
|
||
|
||
**Tasks**:
|
||
- [ ] Admin-Tab: Kategorien anlegen/umbenennen/sortieren (Drag & Drop)
|
||
- [ ] Symbole pro Kategorie verwalten (Drag & Drop zwischen Kategorien)
|
||
- [ ] Eigene SVG-Uploads direkt einer Kategorie zuordnen
|
||
- [ ] Import-Dialog: Pakete-Auswahl mit Vorschau, granulare Symbol-Auswahl
|
||
- [ ] Mehrfach-Import desselben Symbols erlaubt (z.B. "TLF rot" + "TLF blau" auf gleicher SVG-Basis)
|
||
- **Files**: `src/components/admin/icons-tab.tsx` (umbauen), neuer `import-templates-dialog.tsx`
|
||
|
||
#### 1.3 Vorlagen-Pakete kuratieren
|
||
|
||
Aus dem aktuellen Symbol-Bestand werden die ersten Pakete:
|
||
|
||
- [ ] 📦 **Feuerwehr Schweiz** — taktische Zeichen CH (aktueller Bestand, sauber kategorisiert)
|
||
- [ ] 📦 **Sanität / Rettungsdienst** — falls Symbole vorhanden, sonst Phase 2
|
||
- [ ] 📦 **Polizei / Verkehr** — als Stub für später
|
||
- [ ] Innerhalb der Pakete: **fehlende taktische Zeichen ergänzen**:
|
||
- Warteraum
|
||
- Rettungsachse
|
||
- Sammelplatz
|
||
- Verletztennest / Eingang Verletzter
|
||
- Einsatzleitung (EL) / Kommandoposten
|
||
- Bereitstellungsraum
|
||
- [ ] **Symbol-Schönheitsfehler im Paket** beheben:
|
||
- Treppe — Umriss entfernen
|
||
- Eingang — Umriss entfernen
|
||
- Absperrung — Seitenlinien aufräumen
|
||
- **Files**: `prisma/seed/symbol-templates.ts`, `public/icons/`
|
||
|
||
#### 1.4 Stockwerke/Geschosse editierbar
|
||
|
||
- [ ] Symbol-Property: `instanceLabel` (Freitext, pro Symbol-Instanz auf der Karte)
|
||
- [ ] Bei Gebäude-Symbolen: optionales Textfeld für Geschosszahl (z.B. "EG+3")
|
||
- [ ] Anzeige als Badge auf dem Symbol
|
||
- [ ] Editierbar via Doppelklick oder Sidebar
|
||
- **Files**: `src/types/`, `map-view.tsx` Symbol-Renderer, ggf. DrawFeature.properties erweitern
|
||
|
||
---
|
||
|
||
### Phase 1.5 — Quick Polish (parallel oder danach, 1 Woche) 🔥
|
||
|
||
Kleinkram der nicht in den Architektur-Umbau passt aber wichtig ist.
|
||
|
||
- [ ] Default-Linientyp / -farbe pro Mandant konfigurierbar
|
||
- [ ] Symbol-Suche im Sidebar (Volltext über Name, Tags, Kategorie)
|
||
- [ ] Häufig-benutzte Symbole oben anzeigen (Recent / Favoriten)
|
||
|
||
---
|
||
|
||
### Phase 2 — Übungsmodus (2-3 Wochen) ⭐
|
||
|
||
Neuer Projekt-Typ, eigene Logik.
|
||
|
||
#### 2.1 Projekt-Typ Auswahl
|
||
- [ ] Bei "Neues Projekt": Auswahl `Einsatz | Übung`
|
||
- [ ] DB-Schema: `Project.type: 'einsatz' | 'uebung'`
|
||
- [ ] UI-Anpassung in `app/page.tsx`
|
||
|
||
#### 2.2 Übungs-Metadaten
|
||
- [ ] Felder: Übungstitel, Datum, **Übungsziele (Liste)**
|
||
- [ ] Übungsleiter, Teilnehmer (optional)
|
||
- [ ] Eigene Sidebar-Sektion für Übungsdaten
|
||
|
||
#### 2.3 Journal ausblenden bei Übung
|
||
- [ ] Bei `type === 'uebung'`: Journal-Tab → "Übungsauswertung"
|
||
- [ ] Karte bleibt voll funktionsfähig
|
||
- [ ] Krokierung kann **im Voraus** erstellt und mit Übungsleitern geteilt werden (bestehender Share-Link)
|
||
|
||
#### 2.4 Übungsauswertung
|
||
- [ ] Checkliste **Übungsziele** mit Status: `erreicht | teilweise | nicht erreicht`
|
||
- [ ] Notizen / Erkenntnisse pro Ziel
|
||
- [ ] Gesamtbewertung / Erkenntnisse
|
||
- [ ] **PDF-Export** für Debriefing (analog Rapport)
|
||
- **Files**: neue Komponente `uebungsauswertung-tab.tsx`, neuer PDF-Renderer
|
||
|
||
---
|
||
|
||
### Phase 3 — Linien mit Typ (1 Woche) ⭐
|
||
|
||
Smart Lines mit vordefinierten Stilen.
|
||
|
||
#### 3.1 Linientypen definieren
|
||
- [ ] **Schlauch** (default, aktuelle Linie)
|
||
- [ ] **Rettungsachse** — gestrichelt, Label "R"
|
||
- [ ] **Leitung** — blau
|
||
- [ ] **Absperrung** — rot gestrichelt
|
||
- [ ] **Frei** — Standard ohne Vorlage
|
||
|
||
#### 3.2 UX
|
||
- [ ] Nach Zeichnen einer Linie: kleines Popup "Was ist das?"
|
||
- [ ] Auswahl per Klick → Linie wird automatisch gestylt
|
||
- [ ] In Sidebar pro Linie nachträglich änderbar (Dropdown)
|
||
- [ ] Tastatur-Shortcut für Typ-Wechsel?
|
||
|
||
#### 3.3 Daten-Modell
|
||
- [ ] `DrawFeature` erweitern: `lineCategory: 'hose' | 'rescue' | 'pipe' | 'barrier' | 'free'`
|
||
- [ ] Default-Stile als Konstante (Farbe, Strich, Label)
|
||
- **Files**: `src/types/`, `tool-store.ts`, `map-view.tsx`
|
||
|
||
---
|
||
|
||
### Phase 4 — Rapport-/Lageansicht (Führungsunterstützung) (2-3 Wochen) ⭐
|
||
|
||
Eigenes Modul, hoher Mehrwert für FU.
|
||
|
||
#### 4.1 Sichtbarkeits-Stufen pro Journaleintrag
|
||
- [ ] DB: `JournalEntry.visibility: 'intern' | 'rapport' | 'public'`
|
||
- [ ] UI: Dropdown beim Erstellen / Editieren
|
||
- [ ] Migration: bestehende Einträge → `intern` (sicher)
|
||
|
||
#### 4.2 Rapport-Modus (Display)
|
||
- [ ] Neuer Tab/Modus: **Rapport-Ansicht**
|
||
- [ ] Sektionen:
|
||
- **Aktuelle Lage** (Freitext, prominentes Feld)
|
||
- **Pendenzen** (Liste mit Status: offen/erledigt)
|
||
- **Wichtige Punkte / Befehle**
|
||
- **Mittel / Personal** (aktueller Stand)
|
||
- [ ] Grosse Schrift, kontrastreich (Beamer-tauglich)
|
||
- [ ] Auto-Refresh via Socket.IO
|
||
|
||
#### 4.3 Display-Sharing
|
||
- [ ] Read-only Token-Link (wie bestehende Rapport-URL)
|
||
- [ ] Vollbild-Modus
|
||
- [ ] Optional: Auswahl welche Sektionen sichtbar
|
||
|
||
#### 4.4 Berechtigungen
|
||
- [ ] Rolle "Rapport-Viewer" — sieht nur Rapport, nicht Karte / Journal
|
||
- [ ] Berechtigung pro Projekt vergebbar
|
||
|
||
---
|
||
|
||
### Phase 5 — Multi-User Live-Editing polish (optional, später)
|
||
|
||
Realtime-Sync läuft schon via Socket.IO — hier nur Verbesserungen.
|
||
|
||
- [ ] **Live-Cursor** anderer User auf Karte (mit Name)
|
||
- [ ] **Presence-Anzeige** ("Fabian schreibt im Journal", "Pepe zeichnet")
|
||
- [ ] **Soft-Locks** während Symbol bewegt wird
|
||
- [ ] **Conflict Resolution** bei gleichzeitigem Edit testen
|
||
|
||
---
|
||
|
||
## Priorisierungs-Matrix
|
||
|
||
| Phase | Aufwand | Impact | Priorität | Empfohlene Reihenfolge |
|
||
|-------|---------|--------|-----------|------------------------|
|
||
| 1 — Symbol-Architektur Redesign | L (3-4 W) | Sehr Hoch | ⭐⭐ Höchste | **1.** |
|
||
| 1.5 — Quick Polish | S | Mittel | 🔥 Hoch | parallel zu 1 |
|
||
| 3 — Linien-Typen | M | Hoch | ⭐ Hoch | **2.** |
|
||
| 4 — Rapport-Ansicht | L | Sehr Hoch (FU) | ⭐ Sehr Hoch | **3.** |
|
||
| 2 — Übungsmodus | L | Sehr Hoch | ⭐ Sehr Hoch | **4.** |
|
||
| 5 — Multi-User polish | M | Mittel | 📅 Mittel | später |
|
||
|
||
**Begründung der Reihenfolge**:
|
||
1. **Phase 1 zuerst** — Architektur-Umbau, weil alles andere darauf aufbaut. Sobald TenantSymbols + Kategorien sauber strukturiert sind, sind 1.3 (fehlende Symbole) und 1.4 (Stockwerke) trivial. Auch Phase 2 (Übungsmodus) profitiert: Übungs-Pakete als eigene Templates möglich.
|
||
2. **Phase 3 (Linien-Typen)** — kleine Erweiterung, hoher UX-Gewinn, unabhängig von Phase 1.
|
||
3. **Phase 4 (Rapport-Ansicht)** — USP gegenüber anderen Krokier-Tools, FU-Funktion fehlt überall sonst.
|
||
4. **Phase 2 (Übungsmodus)** — grosses Update; baut konzeptuell auf Phase 4 auf (Übungsauswertung ≈ Rapport).
|
||
5. **Phase 5** — Polish, kein User wartet darauf.
|
||
|
||
**Risiko-Hinweis Phase 1**:
|
||
- Schema-Migration von `Icon` (global) zu `SymbolTemplate` + Auto-Import muss **wasserdicht** sein, damit existierende Mandanten ihre Symbole nicht verlieren
|
||
- Vor Deploy: vollständiges DB-Backup (PostgreSQL) und MinIO-Backup (Icon-Files)
|
||
- Auf Staging testen falls möglich, sonst kleinen Test-Tenant zuerst migrieren
|
||
|
||
---
|
||
|
||
## Hinweise für Entwickler / KIs
|
||
|
||
- **Stack**: Next.js 15, React 19, MapLibre GL JS, Prisma, PostgreSQL, MinIO, Socket.IO, Zustand
|
||
- **Sprache**: Schweizerdeutsch / Hochdeutsch (Code englisch, UI deutsch)
|
||
- **Bei Symbol-Änderungen**: SVGs in `public/icons/` + Symbol-Definitionen + ggf. DB-Migration
|
||
- **Bei Schema-Änderungen**: Prisma Migration erstellen + DB-Backup vor Deploy
|
||
- **Vor Deploy**: Build testen (`npx next build`), commit + push, Portainer baut automatisch via Webhook
|
||
- **Realtime**: bei DB-Änderungen, die alle User sehen müssen, Socket-Event triggern
|
||
|
||
---
|
||
|
||
## Status-Tracking
|
||
|
||
> Status pro Aufgabe oben in Checkboxen. Hier kurzer Überblick:
|
||
|
||
- [-] **Phase 1** — Sprint A erledigt (Schema, Migration, Seed). Sprint B–D offen.
|
||
- [ ] **Phase 2** — nicht gestartet
|
||
- [ ] **Phase 3** — nicht gestartet
|
||
- [ ] **Phase 4** — nicht gestartet
|
||
- [ ] **Phase 5** — nicht gestartet
|
||
|
||
---
|
||
|
||
**Letztes Update**: 2026-05-20
|
||
**Verantwortlich**: Pepe (adminpepe)
|