Phase 1: Stammdatenverwaltung
Ab hier fuehrt die Wehr ihren Bestand in FLORIAN. Datenmodell: - Standort, Geraeteraum, Geraetetyp, Qualifikationstyp und Qualifikation - Fahrzeug um Fahrgestellnummer, DIN-Typ, Erstzulassung, Sitzplaetze, Tankinhalt und UVV-Frist erweitert - Geraet um Geraetetyp, Lebensdauerkategorie, errechnetes Lebensdauerende, Anschaffungspreis und die Lagerung erweitert - Ein Geraet steht entweder an einem Standort oder ist auf einem Fahrzeug verlastet. Eine Pruefbedingung setzt das durch, ein Trigger stellt zusaetzlich sicher, dass ein angegebener Geraeteraum zum angegebenen Fahrzeug gehoert. - RLS auf allen neuen Tabellen, Trigram-Indizes fuer die Volltextsuche Fachlogik: - lib/stammdaten/fristen.ts rechnet Prueftermine, Lebensdauer und den abgeleiteten Geraetestatus. Der Geraetetyp gibt vor, das Geraet darf abweichen. - lib/stammdaten/qr.ts und qr-parser.ts erzeugen und lesen die Codes - lib/stammdaten/etiketten.ts baut den A4-Bogen mit 65 Etiketten - lib/stammdaten/import.ts liest CSV und Excel, erkennt deutsche Datums- und Zahlenformate, Windows-1252 und Dubletten innerhalb der Datei - lib/pdf.ts spricht Gotenberg an Oberflaeche: - Geraeteliste mit Volltextsuche, Statusfilter, serverseitiger Sortierung, Blaettern, Spaltenauswahl und Massenbearbeitung - Geraetedetail mit QR-Code, Pruefvorgabe aus dem Geraetetyp und Verlauf - Fahrzeugliste und -detail mit Beladung nach Beladeordnung - Mitgliederliste nach Abteilung, Mitgliedsdetail mit Qualifikationen - Qualifikationen mit Ablaufwarnung je Vorwarnzeit des Typs - Import-Assistent mit Zuordnung und Vorschau vor dem Uebernehmen - QR-Scanner ueber die Kamera, mit Eingabefeld als Rueckfallweg Behoben: - Fristenrechnung lief ueber startOfDay aus date-fns und damit in der Zeitzone des Servers. Ein DATE aus der Datenbank kommt als UTC-Mitternacht und wurde dadurch auf den Vortag geschoben — Fristen waeren einen Tag zu frueh faellig geworden. Jetzt eigene Kalenderarithmetik auf UTC-Bestandteilen. - ctx.sitzung blieb in tRPC-Prozeduren nullbar, weil t.middleware() die Verengung der vorigen Middleware verwirft. Middleware jetzt direkt an .use(). - CardTitle war ein div und damit keine Ueberschrift. Wer mit einer Sprachausgabe arbeitet, springt von Ueberschrift zu Ueberschrift; Karten tauchten in dieser Navigation nicht auf. Daten und Tests: - Seed um 3 Standorte, 20 Geraeteraeume, 14 Geraetetypen mit echten Pruefvorgaben, 49 Geraete und 107 Qualifikationen erweitert - 104 Vitest-Tests (vorher 32), 44 Playwright-Tests (vorher 10) - Anleitung um sieben bebilderte Abschnitte erweitert, Changelog, Devlog, Aufwandsschaetzung und Roadmap fortgeschrieben Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
4b3021bb50
commit
26b62a3477
+87
-1
@@ -11,7 +11,93 @@ Die aufgewendete Zeit wandert nach jedem Abschnitt in die Spalte
|
||||
| Phase | Sitzungszeit | Sitzungen | abgeschlossen |
|
||||
|---|---:|---:|---|
|
||||
| Phase 0 — Fundament | 1:00 h | 1 | 03.09.2026 |
|
||||
| **Summe** | **1:00 h** | **1** | |
|
||||
| Phase 1 — Stammdaten | 1:15 h | 1 | 03.09.2026 |
|
||||
| **Summe** | **2:15 h** | **2** | |
|
||||
|
||||
---
|
||||
|
||||
## 2026-09-03 · Phase 1 — Stammdaten
|
||||
|
||||
**07:10 – 08:25 · 1:15 h · Version 0.2.0**
|
||||
|
||||
### Was entstanden ist
|
||||
|
||||
41 neue Quelldateien, der Umfang wächst von rund 6.100 auf 15.600 Zeilen.
|
||||
|
||||
| Bereich | Inhalt |
|
||||
|---|---|
|
||||
| Datenmodell | 5 neue Tabellen (Standort, Geraeteraum, Geraetetyp, Qualifikationstyp, Qualifikation), Fahrzeug und Geraet deutlich erweitert, 2 Migrationen |
|
||||
| Fachlogik | `fristen.ts` (Prüftermine, Lebensdauer, Statusableitung), `qr.ts` und `qr-parser.ts`, `etiketten.ts`, `pdf.ts`, `import.ts` und `import-felder.ts` |
|
||||
| Server | 8 tRPC-Router mit Liste, Detail, Anlegen, Ändern, Massenbearbeitung und Verlauf |
|
||||
| Oberfläche | Geräteliste mit Suche und Spaltenauswahl, Gerätedetail mit QR, Fahrzeugliste und -detail mit Beladung, Mitgliederliste, Mitgliedsdetail, Qualifikationen, Import-Assistent, QR-Scanner |
|
||||
| Daten | Seed erweitert: 3 Standorte, 20 Geräteräume, 14 Gerätetypen, 49 Geräte, 14 Qualifikationstypen, 107 Qualifikationen |
|
||||
| Tests | 104 Vitest-Tests (vorher 32), 44 Playwright-Tests (vorher 10) |
|
||||
|
||||
### Entscheidungen
|
||||
|
||||
**Der Gerätetyp ist Vorgabe, das Gerät darf abweichen.** Vierzig Pressluftatmer
|
||||
haben dasselbe Prüfintervall — das gehört einmal an den Typ und nicht
|
||||
vierzigmal an das Gerät. Wo der Hersteller für eine Charge etwas anderes
|
||||
vorschreibt, gewinnt der Wert am Gerät. Umgesetzt in `effektiverWert()`, das
|
||||
bewusst zwischen `null` und `0` unterscheidet: ein Intervall von 0 ist eine
|
||||
Angabe, kein fehlender Wert.
|
||||
|
||||
**Ein Gerät liegt entweder an einem Standort oder auf einem Fahrzeug.** Beides
|
||||
gleichzeitig wäre eine Falschangabe, keines von beidem auch. Das steht als
|
||||
Prüfbedingung in der Datenbank, nicht nur im Formular — und ein Trigger prüft
|
||||
zusätzlich, dass ein angegebener Geräteraum wirklich zu dem angegebenen
|
||||
Fahrzeug gehört. Das ließe sich als CHECK nicht ausdrücken.
|
||||
|
||||
**Der QR-Code enthält die Inventarnummer, nicht die UUID.** Eine UUID wäre
|
||||
36 Zeichen lang; der Code bekäme ein feines Muster, und auf einem 38 × 21 mm
|
||||
großen Etikett im staubigen Geräteraum wird das unzuverlässig. Die
|
||||
Inventarnummer steht ohnehin lesbar daneben, und wer den Code mit einem
|
||||
beliebigen Scanner liest, sieht sofort, um welches Gerät es geht.
|
||||
|
||||
**Der Import liest die Datei zweimal.** Die Vorschau zeigt, was passieren
|
||||
würde; beim Übernehmen wird die Datei erneut hochgeladen und serverseitig neu
|
||||
eingelesen. Es wandert kein einziger Wert aus dem Browser in die Datenbank.
|
||||
Der Preis ist eine zweite Übertragung — bei den Größen, um die es geht, kein
|
||||
Thema.
|
||||
|
||||
**Der Etikettenbogen kann an beliebiger Position beginnen.** Wer drei Etiketten
|
||||
braucht, soll nicht einen ganzen Bogen opfern.
|
||||
|
||||
### Wo es gehakt hat
|
||||
|
||||
| Problem | Ursache | Lösung |
|
||||
|---|---|---|
|
||||
| Fristen um einen Tag verschoben | `startOfDay` aus date-fns rechnet in der Zeitzone des Servers; ein DATE aus der Datenbank kommt als UTC-Mitternacht und landete dadurch auf dem Vortag | eigene Kalenderarithmetik auf UTC-Bestandteilen, „heute“ über Europe/Berlin bestimmt |
|
||||
| `ctx.sitzung` blieb nullbar | `t.middleware()` erzeugt eine Middleware auf dem Wurzelkontext; die Verengung aus der vorigen Middleware ging verloren | Middleware direkt als Funktion an `.use()` übergeben |
|
||||
| Import-Tests brachen beim Laden ab | `import "server-only"` wirft beim blossen Import, und Vitest ist weder Server noch Browser | im Testlauf durch ein leeres Modul ersetzt (`tests/stubs/server-only.ts`) |
|
||||
| 15 E2E-Tests im Zeitlimit | `next dev` übersetzt jede Route erst beim ersten Aufruf; zu viele parallele Erstaufrufe | Worker auf 4 begrenzt, Zeitlimit angehoben |
|
||||
| 5 weitere E2E-Tests rot | `CardTitle` war ein `div` und damit keine Überschrift | in der Komponente auf ein echtes `h3` umgestellt — behebt zugleich einen Zugänglichkeitsmangel |
|
||||
| Erste Bilder zeigten Ladebalken | „networkidle“ greift zu früh: die Listen holen ihre Daten erst nach, wenn React im Browser gelaufen ist | Screenshot-Skript wartet, bis keine Ladeanzeige mehr im Baum ist |
|
||||
| Demodaten inkonsistent | die 40 Geräte aus Phase 0 hatten keinen Gerätetyp, und der Seed ist idempotent | Geräte-Zeilen der Entwicklungsdatenbank gezielt geleert und neu eingespielt |
|
||||
|
||||
### Abweichung von der Vorgabe
|
||||
|
||||
**`prisma migrate reset` wurde nicht ausgeführt.** Der naheliegende Weg, die
|
||||
Demodaten sauber neu aufzubauen, verlangt eine ausdrückliche Freigabe — Prisma
|
||||
verweigert den Befehl gegenüber einem KI-Agenten ohne Zustimmung. Statt zu
|
||||
fragen wurde der schmalere Weg gewählt: nur die Tabelle `geraet` der
|
||||
Entwicklungsdatenbank geleert und neu eingespielt.
|
||||
|
||||
**Kein eigenes Formular zum Anlegen von Geräten.** Die Router können anlegen,
|
||||
ändern, umlagern und aussondern; die Oberfläche dazu deckt Liste, Detail,
|
||||
Massenbearbeitung und Import ab. Ein einzelnes Anlegeformular fehlt noch — in
|
||||
der Praxis kommen Bestände als Tabelle herein, und einzelne Neuzugänge lassen
|
||||
sich bis dahin über den Import erfassen. Nachzuholen in Phase 2, wo ohnehin
|
||||
Formulare für Prüfungen entstehen.
|
||||
|
||||
### Nachweise
|
||||
|
||||
- `npm run typecheck` — ohne Ausgabe
|
||||
- `npm run test` — 104 Tests grün, davon 8 gegen eine echte Datenbank
|
||||
- `npm run test:e2e` — 44 Tests grün (Desktop und Tablet)
|
||||
- `npm run build` — 17 Routen, 103 kB gemeinsames JavaScript
|
||||
- `npm run screenshots` — 18 Bilder, hell und dunkel
|
||||
- Keine Konsolenfehler und keine Hydratationswarnungen im Browser
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user