docs(issues): Phase 3 schneiden, und Verweise zeigen wieder richtig

Vier Meilensteine fuer v0.3.0, 34 h geschaetzt: bedingte Schritte und
Abschnitte (M23), Vier-Augen-Freigabe (M24), PDF-Uebergabeprotokoll (M25),
weitere Schritt-Typen (M26). Die Reihenfolge ist begruendet: M23 zuerst, weil
es als einziges am Datenmodell und an der Abschlussregel arbeitet; M26 zuletzt,
weil UNTERSCHRIFT erst im PDF einen Zweck hat.

Jedes Issue nennt die Entscheidungen, die zu treffen sind, mit Empfehlung und
Begruendung. Bei M23 ist die entscheidende: eine Bedingung auf einer Variable
liesse sich beim Start festschreiben wie bei #031, eine auf einem
Schrittergebnis nicht — die Antwort entsteht erst waehrend der Arbeit.

Beim Nummernvergeben einen Fund: vier Codestellen, sechs Changelog-Zeilen und
der Doku-Pruefer nannten dreistellig die Tracker-Nummern 39 und 40 — gemeint
waren die Issue-Dateien 025 und 026. Solange es diese Dateien nicht gab, fiel es
niemandem auf; mit Phase 3 waere es eine falsche Spur geworden, und zwar in
Kommentaren, die eine Codestelle begruenden.

Behoben, und pruefe:doku prueft es ab jetzt: jeder dreistellige Verweis muss auf
eine Issue-Datei zeigen. Gegenprobe mit einer erfundenen Nummer schlaegt an.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/issues/039-bedingte-schritte.md

@@ -0,0 +1,95 @@
+# #039 M23 – Bedingte Schritte und Abschnitte
+
+**Status:** offen
+**Im Tracker:** –
+**Meilenstein:** v0.3.0
+**Labels:** phase-3, backend, frontend
+**Geschätzt:** 12 h   **Tatsächlich:** –
+
+## Ziel
+
+Eine Checkliste enthält heute **alles**, und was nicht zutrifft, wird von Hand auf
+`NICHT_ZUTREFFEND` gesetzt. Der echte Fall steht im Seed: „Mitarbeiter-Onboarding“ trägt **beide**
+Konto-Abschnitte — „Konto anlegen (Active Directory)“ mit 5 Schritten und „Konto anlegen (Entra
+ID)“ mit 4 —, obwohl in jedem einzelnen Lauf nur einer gilt. Die Variable `konto_typ` sagt es
+bereits; niemand wertet sie aus.
+
+Neun Schritte, die ein Techniker bei jedem Onboarding wegklickt. Die Abschnitts-Aktion aus #013
+macht es erträglich, aber sie ist ein Pflaster: der Fortschrittsbalken zählt die Schritte mit, und
+im Archiv steht später eine Checkliste mit einem Abschnitt, den niemand je gebraucht hat.
+
+Setzt [#031](031-abteilungsabschnitte.md) voraus: `geltendeAbschnitte` und `nurGeltende` sind die
+Stelle, an der das sitzt.
+
+## Zu entscheiden
+
+- [ ] **Wann wird ausgewertet?** Das ist die Entscheidung, an der alles hängt.
+
+      Für Abteilungen (#031) wird beim **Start festgeschrieben** — die Abteilung des Laufs steht
+      dann fest, und ein archivierter Lauf muss genau die Schritte zeigen, die damals galten.
+
+      Für Bedingungen reicht das **nicht**: eine Bedingung auf einer Variable (`konto_typ`) ließe
+      sich beim Start auswerten, eine Bedingung auf einem **Schrittergebnis** („wenn Schritt 3 =
+      nein, dann Abschnitt B“) nicht — die Antwort entsteht erst während der Arbeit.
+
+      Empfehlung: **laufend auswerten, Ergebnis mitschreiben.** Die Auswertung läuft bei jeder
+      Änderung an einem Schrittergebnis; was dabei herauskommt, wird in den Lauf geschrieben (wie
+      `geltendeAbschnitte`). Damit gilt für das Archiv weiter „der Lauf weiß, was galt“, und der
+      Ereignisstrom aus #033 trägt die Änderung ohnehin schon zur zweiten Sitzung.
+- [ ] **Woran darf eine Bedingung hängen?** Empfehlung: an einer **Variable** des Laufs und an
+      einem **Schrittergebnis** derselben Version. Nicht an Gerätetyp, Abteilung oder Rolle — für
+      Abteilungen gibt es #031, und je mehr Quellen, desto schwerer zu erklären, warum ein Schritt
+      fehlt.
+- [ ] **Wie wird sie gespeichert?** Empfehlung: ein Json-Feld `bedingung` an `VorlagenAbschnitt`
+      und `VorlagenSchritt`, mit einem engen Schema — `{ art: "variable", schluessel, operator,
+      wert }` oder `{ art: "schritt", schrittId, zustand }`. Json, weil `konfig` es schon so macht
+      und ein neuer Operator dann keine Migration braucht.
+      **Eine Bedingung, kein Ausdrucksbaum.** Kein `und`/`oder`, keine Verschachtelung: das wäre
+      eine kleine Sprache, die niemand im Editor pflegen kann, und ein Abschnitt, der aus
+      unerklärlichen Gründen fehlt, ist schlimmer als einer zu viel.
+- [ ] **Was passiert mit einem Schrittergebnis, das schon Daten trägt**, wenn die Bedingung
+      umschlägt? Empfehlung: die Zeile **bleibt** und wird nur ausgeblendet. Löschen hieße, eine
+      Notiz zu verlieren, die jemand geschrieben hat; und schlägt die Bedingung zurück, ist sie
+      wieder da.
+
+## Aufgaben
+
+- [ ] Migration: `bedingung Json?` an `VorlagenAbschnitt` und `VorlagenSchritt`, dazu ein CHECK, der
+      sicherstellt, dass eine Bedingung auf einen Schritt **derselben Version** zeigt (sonst zeigt
+      sie nach dem Veröffentlichen ins Leere)
+- [ ] `src/lib/bedingungen.ts`, framework-frei: Schema, Auswertung, und die Liste der Schritte und
+      Abschnitte, die gelten. **Dieselbe Stelle für alle drei Schichten**, wie
+      `src/lib/geltende-abschnitte.ts`
+- [ ] Auswertung bei jedem Schreiben an einem `Schrittergebnis`; das Ergebnis in den Lauf
+- [ ] Abschlussregel: ein ausgeblendeter Pflichtschritt hält den Abschluss **nicht** auf (dieselbe
+      Regel wie bei #031, dieselbe Funktion)
+- [ ] Fortschrittsbalken und Zählwerte rechnen nur mit dem, was gilt
+- [ ] Editor: Bedingung an Abschnitt und Schritt setzen, mit Auswahl der Variable bzw. des Schritts
+      **aus derselben Version**; eine Vorschau, die sagt „gilt, wenn …“
+- [ ] Warnung im Editor bei einer Bedingung auf einen Schritt, der **nach** dem bedingten steht —
+      sie wäre beim Abarbeiten noch offen, und der Abschnitt erschiene erst rückwirkend
+- [ ] Abarbeitung: ausgeblendete Abschnitte verschwinden, ohne die Nummerierung zu verschieben
+      (`01 · Vorbereitung` kommt aus der Position und wird nie gespeichert)
+- [ ] Druckansicht und Archiv zeigen, was galt
+- [ ] Export/Import: die Bedingung wandert mit, und ein Verweis auf einen Schritt wird dabei auf die
+      **neue** Kennung umgeschrieben — sonst zeigt sie in der zweiten Installation ins Leere
+- [ ] Seed: „Mitarbeiter-Onboarding“ bekommt die Bedingung auf `konto_typ`, die beiden
+      Konto-Abschnitte bleiben drin und schließen sich gegenseitig aus. Das ist die Gegenprobe am
+      echten Fall.
+- [ ] Anleitung Kapitel 04 (Vorlagen): wann eine Bedingung das richtige Mittel ist und wann eine
+      zweite Vorlage
+
+## Akzeptanzkriterien
+
+- [ ] Test: ein Lauf mit `konto_typ = AD` hat die 5 AD-Schritte und **keinen** der 4 Entra-Schritte
+- [ ] Test: dasselbe umgekehrt, und bei nicht gesetzter Variable gelten **beide** — eine Bedingung,
+      die nicht entschieden werden kann, blendet nichts aus
+- [ ] Test: eine Bedingung auf einem Schrittergebnis schlägt um, **während** der Lauf läuft, und der
+      Abschnitt erscheint
+- [ ] Test: ein ausgeblendeter Pflichtschritt hält den Abschluss nicht auf
+- [ ] Test: ein Schrittergebnis mit Notiz bleibt stehen, wenn seine Bedingung umschlägt, und ist
+      danach wieder da
+- [ ] Test: Export und Import einer Vorlage mit Bedingungen ergeben dieselbe Struktur, und der
+      Schritt-Verweis zeigt auf den richtigen Schritt der **neuen** Version
+- [ ] Test: ein archivierter Lauf zeigt genau die Schritte, die bei seinem Abschluss galten
+- [ ] Am Handy kein horizontales Scrollen