feat(seed): sieben Vorlagen, Beispielbestand und Demo-Kunden (#33)
Prüfung / pruefung (push) Canceled after 0s
Prüfung / e2e (push) Canceled after 0s

This commit was merged in pull request #33.
This commit is contained in:
2026-09-26 03:26:58 +00:00
parent ae290345b7
commit 9bd198a531
33 changed files with 3400 additions and 119 deletions
+35
View File
@@ -331,6 +331,41 @@ hinter einem Reverse Proxy kommen sich sonst in die Quere. Der Zeitplan nimmt
ausdruecklich **keine** eigene Sperre — sie traege einen anderen Schluessel und
liefe an der des Dienstes vorbei.
## 5h. Der Seed: einrichten, nicht aufraeumen
Die sieben Vorlagen stehen als **JSON im Austauschformat** unter
`prisma/seed-daten/vorlagen/` und nicht als TypeScript-Literale. Damit prueft sie
dasselbe Zod-Schema, das auch Import, Export und Editor benutzen: eine
Seed-Vorlage ist genau das, was ein Redakteur einspielen koennte, und ein Fehler
faellt beim Einrichten auf statt im ersten Lauf.
Angelegt werden sie **nicht** ueber `vorlageImportieren`. Der Import erzeugt
absichtlich einen Entwurf und schreibt einen Protokolleintrag mit dem handelnden
Menschen; der Seed hat keinen Menschen und braucht veroeffentlichte Versionen,
weil sich sonst kein Lauf starten liesse. Er geht trotzdem denselben Weg wie ein
Redakteur — **erst Entwurf, dann veroeffentlichen**: die Trigger aus #010
verbieten jedes Schreiben an Abschnitten, Variablen und Schritten einer
veroeffentlichten Version. Eine Version gleich als `VEROEFFENTLICHT` anzulegen und
danach zu fuellen scheitert an der Datenbank, und das ist richtig so.
**Der Seed richtet ein, er raeumt nicht auf.** Jede Zeile hat einen sprechenden
Schluessel — die Vorlage ihren Namen, die Abteilung `(kundeId, name)`, die Person
ihren UPN, das Geraet seinen `tagCode` —, und was es schon gibt, bleibt
unberuehrt. Kein `upsert` mit gefuelltem `update`: eine im Betrieb geaenderte
Ziel-OU, eine bearbeitete Vorlage und ein umgeschalteter Betriebsmodus ueberstehen
jeden weiteren Lauf. Zweimal hintereinander aufgerufen aendert der zweite Lauf
nichts, und `tests/seed.test.ts` haelt das fest.
Im Modus DIENSTLEISTUNG haengt der Beispielbestand an der **Musterfirma** und nicht
an der eigenen Organisation: der Auftrag verlangt, dass `LZ-7K3F9Q` dort auf
`MUS-PC-001` fuehrt. Ein Tag-Code gehoert genau einem Geraet, beides zugleich
ginge also ohnehin nicht — „erzeugt **stattdessen**“.
Die Tag-Codes der Beispielgeraete sind **fest** und nicht gezogen. Ein Seed, der
jedes Mal fuenf neue Codes zieht, waere nicht idempotent: beim dritten Lauf laegen
fuenfzehn Aufkleber im Stapel. Weil ein `tagCode` global eindeutig ist und nie
wiederverwendet wird, bekommt jeder Demo-Kunde seinen eigenen Satz.
## 6. Betrieb: zwei Wege, eine Regel
Die Datenbank ist auf beiden Wegen von außen nicht erreichbar: