Das Auswahlfeld enthielt nur die gerade erreichbaren Zustaende. Damit sah
man weder, wo die Akte steht, noch welche Zustaende es ueberhaupt gibt - und
nach jedem Wechsel standen andere Eintraege darin. Eine Auswahl, die ihre
Eintraege tauscht, ist keine Orientierung.
Jetzt stehen immer alle sieben da, in der Reihenfolge des Lebenszyklus:
Entwurf, Offen, In Pruefung, Abgeschlossen, Archiviert als eine Linie,
darunter Ruhend und Versiegelt als Nebenwege. Der jetzige Zustand ist
markiert, erreichbare sind Knoepfe, gesperrte bleiben blass stehen statt zu
verschwinden - mit dem Grund als Titel daran.
Der Grund ist dabei nicht dasselbe wie die Sperre: "von hier fuehrt kein
Weg dorthin" laesst sich durch kein Recht beheben, "dir fehlt case.close"
schon. Wer das verwechselt, sucht an der falschen Stelle.
Was ein Wechsel verlangt, steht jetzt vorher da statt als Absage danach:
die Pflichtbegruendung beim Wiedereroeffnen und beim Versiegeln, und dass
vor dem Abschluss die noetigen Abschnitte gefuellt sein muessen. Bei
Pflichtbegruendung bleibt der Knopf gesperrt, bis sie dasteht.
Die Rechtepruefung rechnet der Server, mit derselben Funktion, die der
Dienst beim Wechsel anwendet - vorher zeigte die Liste auch Ziele, die
danach abgelehnt wurden. Zwei Pruefungen halten das fest, und zwar in beide
Richtungen: nichts angeboten, was scheitern wuerde, und nichts verschwiegen,
was ginge. Die zweite ist die wichtigere, weil ihr Fehlen nicht auffaellt.
Fachlogik in lib/cases/service.ts, Zugriffsprüfung in lib/access/. Jede
Funktion prüft selbst und schreibt ihren Protokolleintrag in derselben
Transaktion wie die Änderung - die Server Actions daneben sind dünn.
Schreibgrenzen nach docs/03: niemand legt eine Akte über der eigenen Stufe an,
niemand stuft über die eigene Stufe hoch, archiviert und versiegelt sind
schreibgeschützt auch für Admins. Eine Herabstufung verlangt eine Begründung
und landet als sichtbarer Systemeintrag im Verlauf, nicht nur im Protokoll.
Aktenzeichen über CaseCounter mit INSERT ... ON CONFLICT DO UPDATE, geprüft mit
acht gleichzeitigen Anlagen ohne Doppelung. Wer eine Akte anlegt, wird ihr
Ermittler, sonst verliert er sie aus dem Blick, sobald jemand hochstuft.
Fallliste cursorbasiert auf (updatedAt, id), Sichtbarkeit und Trefferzahl in
derselben Abfrage. Aktenansicht mit Kopfdaten sofort und Verlauf in eigener
Suspense-Grenze. Vermerke optimistisch mit clientseitiger UUIDv7, die zugleich
Idempotenzschlüssel ist - zweimal gesendet bleibt ein Eintrag.
Lesezugriffe ab Stufe 3 werden protokolliert, gepuffert und alle zwei Sekunden
gebündelt geschrieben, damit das Protokoll die Antwort nicht ausbremst.
Die vier Startvorlagen stehen jetzt im Seed statt in Phase 3: ohne Vorlage
lässt sich keine Akte anlegen.
Harlekin