Files

T

florian.wildeandClaude Opus 5.5 b3787f514c docs(devlog): Sitzung 7 mit #033 und #034 (#034 )

Zeiten und Entscheidungen festhalten, bevor die Abnahme beginnt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-12 20:11:39 +02:00

1.6 KiB

Raw Blame History

#033 Erneut rotieren nach abgebrochener Rotation

Status: erledigt Meilenstein: v1.0.0 Labels: backend, datenbank Geschätzt: 1 h Tatsächlich: 0 h 20 min

Ziel

Nach einer abgebrochenen Rotation (#032) lässt sich derselbe Schlüssel erneut rotieren, statt dass ein neuer Schlüssel angelegt, zugewiesen und der alte widerrufen werden muss.

Aufgaben

vorgaengerId nicht mehr eindeutig; stattdessen partieller Index: je Vorgänger höchstens ein Nachfolger, der weder widerrufen ist noch gerade widerrufen wird
Relation 1:n (nachfolgerListe); maßgeblich ist der jüngste Nachfolger (JUENGSTER, mitNachfolger)
Neue Rotation erst, wenn der Abbruch abgeschlossen ist (Nachfolger WIDERRUFEN)
Schlüsselseite: „Rotieren“ wieder anbieten, Hinweistext angepasst

Akzeptanzkriterien

DB-Test: Abbruch → während des Abbruchs keine neue Rotation → danach zweiter Nachfolger, Kette zeigt ihn
DB-Test: die Datenbank lehnt einen zweiten offenen Nachfolger ab
E2E: nach dem Abbruch führt „Rotieren“ wieder zu Schritt 1

Abhängigkeiten

#023, #032

Notizen / Entscheidungen

Abgebrochene Nachfolger bleiben mit vorgaengerId in der Historie; die Rotationskette folgt dem jüngsten Nachfolger.
Kein neuer Rotations-Zustand: Ist der jüngste Nachfolger vollständig widerrufen und der alte nicht ROTIERT, steht die Rotation wieder bei Schritt 0.
Prisma kennt partielle Indizes nicht; migrate diff bleibt trotzdem leer, weil der Index nur in der Migration steht (wie beim Instanz-Standard).

1.6 KiB Raw Blame History