feat(seed): mitgelieferte Vorlagen am Schluessel erkennen #42

Merged

florian.wilde merged 1 commits from feat/32-stabiler-schluessel into main 2026-10-04 14:49:01 +00:00

Conversation 0 Commits 1 Files Changed 20

+316 -36

florian.wilde commented 2026-10-04 14:48:59 +00:00

Owner

Copy Link

Copy Source

Der Seed erkannte seine sieben Vorlagen am Namen. Wer eine umbenannte, bekam beim nächsten Lauf eine zweite — und der Schnellstart stand auf der Geräteseite doppelt.

Was jetzt gilt

Vorlage.seedSchluessel trägt die Kennung, eindeutig wo gesetzt: der Index ist partiell, weil eigene Vorlagen keinen Schlüssel tragen und ein gewöhnlicher Index an der zweiten davon scheitern würde.

Das Austauschformat kennt das Feld als seedSchluessel — nicht als schluessel, wie das Issue plante. So heißt dort schon das Feld einer Variablen, und zwei Dinge gleichen Namens in derselben Datei wären eine Lesefalle.

Der Umstiegspfad

Der Rückfall auf den Namen bleibt. Eine Installation von vor diesem Feld hat noch keinen Schlüssel; ohne den Rückfall bekäme sie beim ersten Lauf danach genau die Dubletten, die das Feld verhindern soll. Wird eine Vorlage so gefunden, trägt der Seed den Schlüssel nach — und nur bei einer Zeile ohne Schlüssel, damit eine fremde Vorlage, die zufällig so heißt, nicht den Platz des Originals einnimmt.

An der Entwicklungsdatenbank gefahren, nicht nur getestet: sieben Schlüssel nachgetragen, 7 vorhanden, davon 0 neu angelegt.

Was der Schlüssel nicht tut

Er macht eine Vorlage nicht unveränderlich, und er erlaubt dem Seed nicht, eine bearbeitete Vorlage zu überschreiben. Steht die Vorlage, bleibt sie unangetastet — auch umbenannt, auch umgebaut, auch archiviert. Das steht ausdrücklich in docs/vorlagen-format.md, weil ein Feld namens „Schlüssel" sonst mehr zu versprechen scheint, als es hält.

Der Import setzt ihn nicht, auch nicht wenn das Dokument ihn mitbringt — dafür gibt es einen eigenen Test, der ihn hineinschreibt und prüft, dass er verfällt. Der Export schreibt ihn ebenfalls nicht: ein Feld, das beim Einlesen verfällt, verwirrt in der Datei nur.

Tests

Sieben neue (1143 statt 1136), darunter die drei Kriterien des Issues und zwei für die Datenbankregel selbst — doppelter Schlüssel wird abgewiesen, beliebig viele ohne sind erlaubt. Gegenprobe gefahren: ohne die Suche am Schlüssel werden vier Tests rot.

Alle Tore grün: lint, typecheck, format:pruefen, pruefe:doku, 1143 Vitest-Tests in 52 Dateien.

Nebenbefund

In der Entwicklungsdatenbank standen 105 Vorlagen ZZ E2E Editor … — die Ende-zu-Ende-Abläufe räumen ihre Vorlagen nicht weg. Als #027 aufgenommen, nicht hier behoben.

Closes #32

🤖 Generated with Claude Code

Der Seed erkannte seine sieben Vorlagen am **Namen**. Wer eine umbenannte, bekam beim nächsten Lauf eine zweite — und der Schnellstart stand auf der Geräteseite doppelt. ## Was jetzt gilt `Vorlage.seedSchluessel` trägt die Kennung, eindeutig **wo gesetzt**: der Index ist partiell, weil eigene Vorlagen keinen Schlüssel tragen und ein gewöhnlicher Index an der zweiten davon scheitern würde. Das Austauschformat kennt das Feld als **`seedSchluessel`** — nicht als `schluessel`, wie das Issue plante. So heißt dort schon das Feld einer Variablen, und zwei Dinge gleichen Namens in derselben Datei wären eine Lesefalle. ## Der Umstiegspfad Der Rückfall auf den Namen bleibt. Eine Installation von vor diesem Feld hat noch keinen Schlüssel; ohne den Rückfall bekäme sie beim ersten Lauf danach genau die Dubletten, die das Feld verhindern soll. Wird eine Vorlage so gefunden, trägt der Seed den Schlüssel nach — und nur bei einer Zeile **ohne** Schlüssel, damit eine fremde Vorlage, die zufällig so heißt, nicht den Platz des Originals einnimmt. **An der Entwicklungsdatenbank gefahren**, nicht nur getestet: sieben Schlüssel nachgetragen, `7 vorhanden, davon 0 neu angelegt`. ## Was der Schlüssel nicht tut Er macht eine Vorlage nicht unveränderlich, und er erlaubt dem Seed nicht, eine bearbeitete Vorlage zu überschreiben. Steht die Vorlage, bleibt sie unangetastet — auch umbenannt, auch umgebaut, auch archiviert. Das steht ausdrücklich in `docs/vorlagen-format.md`, weil ein Feld namens „Schlüssel" sonst mehr zu versprechen scheint, als es hält. **Der Import setzt ihn nicht**, auch nicht wenn das Dokument ihn mitbringt — dafür gibt es einen eigenen Test, der ihn hineinschreibt und prüft, dass er verfällt. Der Export schreibt ihn ebenfalls nicht: ein Feld, das beim Einlesen verfällt, verwirrt in der Datei nur. ## Tests Sieben neue (1143 statt 1136), darunter die drei Kriterien des Issues und zwei für die Datenbankregel selbst — doppelter Schlüssel wird abgewiesen, beliebig viele ohne sind erlaubt. **Gegenprobe gefahren:** ohne die Suche am Schlüssel werden vier Tests rot. Alle Tore grün: `lint`, `typecheck`, `format:pruefen`, `pruefe:doku`, **1143 Vitest-Tests** in 52 Dateien. ## Nebenbefund In der Entwicklungsdatenbank standen **105** Vorlagen `ZZ E2E Editor …` — die Ende-zu-Ende-Abläufe räumen ihre Vorlagen nicht weg. Als #027 aufgenommen, nicht hier behoben. Closes #32 🤖 Generated with [Claude Code](https://claude.com/claude-code)

florian.wilde added 1 commit 2026-10-04 14:49:00 +00:00

feat(seed): mitgelieferte Vorlagen am Schluessel erkennen ... 7eb81bd191

Der Seed erkannte seine sieben Vorlagen am Namen. Wer eine umbenannte, bekam
beim naechsten Lauf eine zweite -- und der Schnellstart stand auf der
Geraeteseite doppelt.

Vorlage.seedSchluessel traegt die Kennung, eindeutig wo gesetzt (partieller
Index, weil eigene Vorlagen keinen tragen). Das Austauschformat kennt das Feld
als seedSchluessel; nicht als schluessel, wie das Issue plante, denn so heisst
dort schon das Feld einer Variablen.

Der Rueckfall auf den Namen bleibt, sonst bekaeme eine Installation von vor
diesem Feld beim ersten Lauf danach genau die Dubletten, die es verhindern
soll. Wird sie so gefunden, traegt der Seed den Schluessel nach -- an der
Entwicklungsdatenbank gefahren: sieben nachgetragen, nichts neu angelegt.

Der Import setzt den Schluessel nicht, auch nicht wenn das Dokument ihn
mitbringt, und der Export schreibt ihn nicht: eine eingespielte Kopie soll
nicht den Platz des Originals einnehmen.

Gegenprobe gefahren: ohne die Suche am Schluessel werden vier Tests rot.

Closes #32

florian.wilde merged commit 0fa41b9e08 into main 2026-10-04 14:49:01 +00:00

florian.wilde deleted branch feat/32-stabiler-schluessel 2026-10-04 14:49:01 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

backend

Datenmodell, Services, Queries

bug

Fehler

docs

README, Anleitung, Devlog, Changelog

frontend

Oberflaeche, Komponenten, Design

infra

Docker, Compose, Proxmox, CI, Release

phase-1

Phase 1 – MVP

phase-2

Phase 2 – SCIM, Graph, Bausteine, Anhaenge

phase-3

Phase 3 – PDF-Protokoll, bedingte Schritte, Freigabe

phase-4

Phase 4 – Aktionen, Connectors, REST-API

security

Rechte, Geheimnisse, Datenschutz

test

Vitest, Playwright, Testdaten

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

florian.wilde (Florian Wilde)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/Laufzettel#42