Case-Lebenszyklus

Status: Entwurf · Quelle: projektmike/output/gettingtoyes/zielarchitektur.md

Acht Stationen, alle Pflicht, jeder Schritt auditiert.

1. Anlage          — Case-Typ, Modellauswahl, Beteiligte
2. Datensammlung   — Stammdaten-Referenzen, Inputs, Dokumente
3. Analyse         — UI-geführte Bearbeitung, Szenarien, Optimierungen
4. Entscheidung    — Vorgeschlagenes Ergebnis, Begründung
5. Freigabe        — Review + Approval durch berechtigte Rolle
6. Umsetzung       — operative Umsetzung nach Freigabe
7. Aktiv           — Case ist produktiv / wirksam, Monitoring läuft
8. Archiv          — unveränderlich, auditierbar

Status-Übergänge

von	nach	Auslöser	Berechtigung
—	`draft`	Case-Anlage	`analyst` (oder höher)
`draft`	`daten`	Pflichtfelder ausgefüllt	Owner
`daten`	`analyse`	Stammdaten-Referenzen vollständig	Owner
`analyse`	`entscheidung`	mind. 1 Szenario tragend markiert	Owner
`entscheidung`	`freigabe`	Begründung dokumentiert	Owner
`freigabe`	`aktiv`	Approval durch `management`	Approver
`freigabe`	`analyse`	Reject mit Begründung	Approver
`aktiv`	`archiv`	Ende der Gültigkeit	Steward / automatisch
jeder	`cancelled`	Storno	Owner + Begründung

Snapshots bei Freigabe

Beim Übergang freigabe → aktiv werden eingefroren:

Modell-Version
alle referenzierten Stammdaten (Eigentümer + Liegenschaft + Gebäude + Verträge + Provider + Material + Tarife zum Zeitpunkt)
gewählte Modul-Konfiguration (case_selects_module-Snapshot)
alle Szenarien mit Ergebnissen
alle Annahmen
generierter PDF-Report (Eigentümer-Angebot + Holding-Dossier — bei Mandats-Cases beides)

Zugriff auf den eingefrorenen Stand bleibt langfristig möglich (entity_version der Spec).

Folge-Cases (Modul nachbuchen / kündigen)

Eigentümer kann nach Mandats-Start zusätzliche Module hinzubuchen oder einzelne kündigen. Datenmodell:

Neuer Case (case_type=liegenschafts_bewertung) auf demselben Eigentümer + derselben Liegenschaft.
Der neue Case referenziert den vorherigen über parent_case_id (in case-Attributen) — der Datenbestand kennt damit die Entscheidungshistorie pro Mandat.
Bei Freigabe des Folge-Cases werden die property_booked_module-Beziehungen aktualisiert: neue Module aktiviert (seit-Datum), gekündigte Module mit bis-Datum versehen.
Originaler Case bleibt unverändert im Status archiv — Audit-Trail vollständig.

Der Workflow oben gilt für jeden dieser Cases gleich; die Verkettung passiert ausschließlich über die parent_case_id-Beziehung, nicht über zusätzliche Status-Phasen.

Parallele Bearbeitung

Mehrere User können parallel an einem Case arbeiten (Owner + Mitwirkende). Konflikte werden optimistisch gelöst (Versions-Token im Datensatz). Kommentare und Aufgaben sind kollaborativ.

Verbindung zur Aggregation

Wenn ein unit_case in aktiv geht, wird ggf. ein holding_case erst angelegt oder neu berechnet (siehe UC-02). Die Aggregation ist keine eigene Status-Stufe, sondern ein nachgelagerter Vorgang.

Audit

Jeder Status-Übergang erzeugt eine audit_log-Zeile (Spec) mit:

actor_principal_id
from_status / to_status
reason (bei Reject oder Cancel pflicht)
payload_diff (was wurde gleichzeitig verändert)