feat(bausteine): Abschnitte, die mehrere Vorlagen teilen #57

2026-10-04T17:07:10Z

florian.wilde commented

2026-10-04 17:07:10 +00:00

„Datensicherung prüfen" steht in vier der sieben mitgelieferten Vorlagen, wortgleich. Wer den Ablauf ändert, ändert ihn viermal — oder dreimal und vergisst den vierten.

Die Entscheidung, die das Issue offen gelassen hat

Gewählt wie vorgeschlagen: ein Entwurf verweist auf eine veröffentlichte Baustein-Fassung, und beim Veröffentlichen der Vorlage setzt der Dienst deren Schritte als tiefe Kopie ein.

Damit sieht ein Lauf weiterhin konkrete Schritte, und Schrittergebnis, Druckansicht und Archiv müssen nichts von Bausteinen wissen. Die Alternative — Läufe verweisen zur Laufzeit — hätte die Unveränderlichkeit an einer zweiten Stelle durchsetzen müssen, und jede Abfrage über Schritte hätte zwei Wege kennen müssen.

Eine neue Fassung ändert deshalb keine veröffentlichte Vorlagenversion und keinen laufenden Lauf. Sie wirkt in der nächsten veröffentlichten Version. Die Oberfläche sagt das an zwei Stellen, weil man sonst Durchschlag erwartet.

Vier Garantien in der Datenbank

Nicht nur im Dienst: höchstens ein Entwurf je Baustein (partieller Index), eine veröffentlichte Fassung ist unveränderlich (Trigger), der Weg zurück zum Entwurf ist versperrt (Trigger), und ein Abschnitt kann nur auf eine veröffentlichte Fassung verweisen (Trigger) — einen Entwurf einzusetzen hieße, beim Veröffentlichen etwas zu kopieren, das sich danach noch ändert.

Beim Aufräumen der Testdaten hat der zweite sofort zugeschlagen: DELETE auf einen Abschnitt einer veröffentlichten Version → abgewiesen. Gut so.

Zwei kleinere Entscheidungen

Ein Baustein ist genau ein Abschnitt, nicht eine Gruppe davon — so steht es im Auftrag, und es spart eine Verschachtelungsebene, die niemand gebraucht hätte.

Der Titel kommt aus dem Baustein, nicht aus dem Abschnitt der Vorlage. Sonst müsste er in jeder Vorlage einzeln gepflegt werden, und zwei Vorlagen zeigten denselben Baustein unter verschiedenen Namen.

Ein Fehler, den nur das Durchklicken gefunden hat

neuerBausteinAbschnitt legt Platzhalter-Schritte ohne Titel an, damit die Anzahl in der Karte stimmt. alsStruktur schickte sie mit, SchrittSchema wies den ganzen Entwurf ab — das Speichern scheiterte. Die Suite war grün, die Seite sah richtig aus.

Behoben, mit Test und Gegenprobe. Danach den ganzen Weg am gebauten Stand nachgemessen: Baustein anlegen → Titel und zwei Schritte → veröffentlichen (Fassung 01, Entwurf verschwindet) → in eine Vorlage einsetzen (als Einheit, ohne Titelfeld und ohne „Schritt hinzufügen") → Vorlage veröffentlichen. In der Datenbank stehen danach die zwei echten Schritte in richtiger Reihenfolge, mit Herkunft (Baustein + Fassung 1) und einem Protokolleintrag bausteine: [{name, version}].

Zweimal habe ich dabei mein eigenes Prüfskript für den Fehler gehalten — ein zu weiter role=status-Selektor und eine Prüfung nach dem Neuladen. Die Datenbank hat beides geklärt.

Tests

27 neue (1209 statt 1182): alle fünf Akzeptanzkriterien des Issues, beide Trigger an der Service-Schicht vorbei, der Rundlauf durch Export und Import, und drei für die Umwandlung im Editor. Gegenprobe gefahren: ohne die tiefe Kopie werden sieben Tests rot, ohne den Editor-Fix einer.

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

Closes #50

🤖 Generated with Claude Code

„Datensicherung prüfen" steht in vier der sieben mitgelieferten Vorlagen, wortgleich. Wer den Ablauf ändert, ändert ihn viermal — oder dreimal und vergisst den vierten. ## Die Entscheidung, die das Issue offen gelassen hat Gewählt wie vorgeschlagen: ein **Entwurf verweist** auf eine veröffentlichte Baustein-Fassung, und beim **Veröffentlichen der Vorlage** setzt der Dienst deren Schritte als **tiefe Kopie** ein. Damit sieht ein Lauf weiterhin konkrete Schritte, und `Schrittergebnis`, Druckansicht und Archiv müssen nichts von Bausteinen wissen. Die Alternative — Läufe verweisen zur Laufzeit — hätte die Unveränderlichkeit an einer zweiten Stelle durchsetzen müssen, und jede Abfrage über Schritte hätte zwei Wege kennen müssen. **Eine neue Fassung ändert deshalb keine veröffentlichte Vorlagenversion und keinen laufenden Lauf.** Sie wirkt in der nächsten veröffentlichten Version. Die Oberfläche sagt das an zwei Stellen, weil man sonst Durchschlag erwartet. ## Vier Garantien in der Datenbank Nicht nur im Dienst: höchstens ein Entwurf je Baustein (partieller Index), eine veröffentlichte Fassung ist unveränderlich (Trigger), der Weg zurück zum Entwurf ist versperrt (Trigger), und ein Abschnitt kann nur auf eine **veröffentlichte** Fassung verweisen (Trigger) — einen Entwurf einzusetzen hieße, beim Veröffentlichen etwas zu kopieren, das sich danach noch ändert. Beim Aufräumen der Testdaten hat der zweite sofort zugeschlagen: `DELETE` auf einen Abschnitt einer veröffentlichten Version → abgewiesen. Gut so. ## Zwei kleinere Entscheidungen **Ein Baustein ist genau ein Abschnitt**, nicht eine Gruppe davon — so steht es im Auftrag, und es spart eine Verschachtelungsebene, die niemand gebraucht hätte. **Der Titel kommt aus dem Baustein**, nicht aus dem Abschnitt der Vorlage. Sonst müsste er in jeder Vorlage einzeln gepflegt werden, und zwei Vorlagen zeigten denselben Baustein unter verschiedenen Namen. ## Ein Fehler, den nur das Durchklicken gefunden hat `neuerBausteinAbschnitt` legt Platzhalter-Schritte **ohne Titel** an, damit die Anzahl in der Karte stimmt. `alsStruktur` schickte sie mit, `SchrittSchema` wies den ganzen Entwurf ab — **das Speichern scheiterte.** Die Suite war grün, die Seite sah richtig aus. Behoben, mit Test und Gegenprobe. Danach den ganzen Weg am gebauten Stand nachgemessen: Baustein anlegen → Titel und zwei Schritte → veröffentlichen (Fassung 01, Entwurf verschwindet) → in eine Vorlage einsetzen (als Einheit, ohne Titelfeld und ohne „Schritt hinzufügen") → Vorlage veröffentlichen. In der Datenbank stehen danach die zwei echten Schritte in richtiger Reihenfolge, mit Herkunft (Baustein + Fassung 1) und einem Protokolleintrag `bausteine: [{name, version}]`. Zweimal habe ich dabei **mein eigenes Prüfskript** für den Fehler gehalten — ein zu weiter `role=status`-Selektor und eine Prüfung nach dem Neuladen. Die Datenbank hat beides geklärt. ## Tests 27 neue (1209 statt 1182): alle fünf Akzeptanzkriterien des Issues, beide Trigger an der Service-Schicht vorbei, der Rundlauf durch Export und Import, und drei für die Umwandlung im Editor. **Gegenprobe gefahren:** ohne die tiefe Kopie werden sieben Tests rot, ohne den Editor-Fix einer. Alle Tore grün: `lint`, `typecheck`, `format:pruefen`, `pruefe:doku`, **1209 Vitest-Tests** in 55 Dateien. Closes #50 🤖 Generated with [Claude Code](https://claude.com/claude-code)

florian.wilde added 1 commit 2026-10-04 17:07:11 +00:00

feat(bausteine): Abschnitte, die mehrere Vorlagen teilen

Prüfung / pruefung (pull_request) Canceled after 0s

Details

Prüfung / pruefung (push) Canceled after 0s

Details

Prüfung / e2e (pull_request) Canceled after 0s

Details

Prüfung / e2e (push) Canceled after 0s

Details

0b5138d8bb

"Datensicherung pruefen" steht in vier der sieben mitgelieferten Vorlagen,
wortgleich. Wer den Ablauf aendert, aendert ihn viermal -- oder dreimal und
vergisst den vierten.

Entschieden wie im Issue vorgeschlagen: ein Entwurf **verweist** auf eine
veroeffentlichte Baustein-Fassung, und beim Veroeffentlichen der Vorlage setzt
der Dienst deren Schritte als tiefe Kopie ein. Danach sieht ein Lauf weiterhin
konkrete Schritte, und Schrittergebnis, Druckansicht und Archiv muessen nichts
von Bausteinen wissen. Die Alternative -- Laeufe verweisen zur Laufzeit --
haette die Unveraenderlichkeit an einer zweiten Stelle durchsetzen muessen.

Eine neue Fassung aendert damit keine veroeffentlichte Vorlagenversion und
keinen laufenden Lauf. Sie wirkt in der naechsten veroeffentlichten Version;
die Oberflaeche sagt das an zwei Stellen, weil man sonst Durchschlag erwartet.

Vier Garantien liegen in der Datenbank, nicht nur im Dienst: hoechstens ein
Entwurf je Baustein, eine veroeffentlichte Fassung ist unveraenderlich, der Weg
zurueck zum Entwurf ist versperrt, und ein Abschnitt kann nur auf eine
veroeffentlichte Fassung verweisen.

Der Titel kommt aus dem Baustein, nicht aus dem Abschnitt der Vorlage: sonst
muesste er in jeder Vorlage einzeln gepflegt werden, und zwei Vorlagen zeigten
denselben Baustein unter verschiedenen Namen.

Ein Export traegt die aufgeloesten Schritte, keinen Verweis -- eine Kennung aus
dieser Installation bedeutet in einer anderen nichts.

Das Durchklicken des gebauten Stands fand einen Fehler, den die Suite nicht
gesehen haette: die Platzhalter-Schritte eines Baustein-Abschnitts haben keinen
Titel, wurden aber mitgeschickt, und SchrittSchema wies den ganzen Entwurf ab.
Behoben, mit Test und Gegenprobe. Der ganze Weg danach am gebauten Stand
nachgemessen: Baustein anlegen, veroeffentlichen, einsetzen, Vorlage
veroeffentlichen -- die Schritte stehen drin, mit Herkunft und
Protokolleintrag.

Closes #50

florian.wilde merged commit 80870133b8 into main

2026-10-04 17:07:12 +00:00

florian.wilde deleted branch feat/50-bausteine

2026-10-04 17:07:13 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/Laufzettel#57