Szenario-Hierarchie: Plan als Behaelter, Diff-Markierung (V6)

Groesste Umstrukturierung bisher. Der PLAN ist neu ein schlanker Behaelter ohne
Finanzdaten; die berechenbare Einheit ist das SZENARIO.

Modell:
- Jeder Plan bekommt beim Anlegen automatisch ein Basisszenario (isBase).
- Das Grundprofil liegt am Szenario, nicht am Plan -- nur so sind Szenarien mit
  abweichendem PENSIONSALTER moeglich (Fruehpensionierung), das in Person steckt.
- Neue Szenarien sind vollstaendige Kopien eines BELIEBIGEN Szenarios und haengen
  als Baum darunter (parentScenarioId); die Seitenleiste rueckt sie ein.
- Kopierte Phasen/Elemente tragen Herkunfts-Verweise (sourcePhaseId,
  sourceElementId). Ueber den Namen zu matchen waere fragil gewesen.

Abweichungs-Markierung (Diff gegen das Eltern-Szenario, live):
- geaendert = gelb, neu = gruen + Badge, entfernt = graue Geisterzeile.
- Markiert: Phasen-/Uebergangszellen, Element-Zeilen, Phasenkoepfe, Cash-Anfangswert,
  Cash-Uebergaenge, Grundprofil. Zaehler ueber der Matrix.
- Eigene Theme-Tokens fuer Hell/Dunkel/Warm -- ein fester Gelbwert waere im
  Dunkelschema unbrauchbar.

Charts vergleichen neu die Geschwister-Szenarien statt fremder Plaene.

Datenmodell/Migration:
- Neue Tabelle Plan; bisheriger Plan -> Scenario (IDs erhalten, damit alle
  Kind-Fremdschluessel gueltig bleiben); planId -> scenarioId in Person/Phase/
  FinancialElement. Bestehende Szenarien werden per rekursivem CTE demselben
  Behaelter zugeordnet, auch mehrfach verschachtelte.
- Migration VOR dem Deploy gegen echtes PostgreSQL verifiziert (PGlite, in-process),
  inkl. verschachtelter Szenarien und Cascade. Der Test ist als
  migrations.test.ts committet und sichert kuenftige Migrationen ab.

API neu unter /api/scenarios/*. 10 neue Tests (48 -> 58). Spezifikation auf v0.8.

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

prisma/schema.prisma

@@ -1,13 +1,21 @@
 // FPT (Financial Planning Tool) — Datenmodell.
-// Kernkonzept (Rework 07/2026): finanzielle Elemente leben auf PLAN-Ebene und sind
-// ueber alle Lebensphasen hinweg dieselbe Entitaet. Pro Element existiert je Lebensphase
-// ein Werte-Datensatz (ElementPhaseValue) und je Uebergang ein Entscheid-Datensatz
+//
+// Kernkonzept: finanzielle Elemente leben auf SZENARIO-Ebene und sind ueber alle
+// Lebensphasen hinweg dieselbe Entitaet. Pro Element existiert je Lebensphase ein
+// Werte-Datensatz (ElementPhaseValue) und je Uebergang ein Entscheid-Datensatz
 // (ElementTransitionValue). Die kategorie-/kontextspezifischen Felder liegen als JSON,
 // validiert und typisiert in der Applikationsschicht (lib/elements.ts).
 //
-// Rework 07/2026 (V3): Das Grundprofil (Haushaltsform, Personen, Inflation) wurde vom
-// frueheren Household auf die PLAN-Ebene verschoben. Jeder Plan ist selbsttragend und
-// definiert seine eigenen Personen (Alter, Pensionsalter) und Inflationsannahme.
+// Rework 07/2026 (V6, Szenario-Hierarchie): Der PLAN ist neu ein schlanker Behaelter und
+// traegt selbst keine Finanzdaten. Die berechenbare Einheit ist das SZENARIO -- es traegt
+// das Grundprofil (Haushaltsform, Personen, Inflation, Cash-Anfangswert), die Phasenkette
+// und die Elemente. Jeder Plan hat genau ein Basisszenario (isBase) und beliebig viele
+// weitere Szenarien, die als Baum (parentScenarioId) darunter haengen. Kopierte Phasen und
+// Elemente tragen einen Herkunfts-Verweis (sourcePhaseId / sourceElementId) auf ihr
+// Gegenstueck im Eltern-Szenario -- darauf beruht die Abweichungs-Markierung im UI.
+//
+// Namens-Hinweis: In der Berechnungsschicht heisst die berechenbare Einheit weiterhin
+// `PlanInput` / `computePlan` (sie beschreibt eine Finanzplanung -- fachlich ein Szenario).
 
 generator client {
   provider = "prisma-client"
@@ -54,35 +62,52 @@ enum ElementCategory {
   OTHER_DEBT
 }
 
-// Einzelperson eines Plans. retirementAge ist das (plan-eigene) Pensionsalter.
+// Einzelperson eines Szenarios. retirementAge ist das (szenario-eigene) Pensionsalter --
+// dadurch sind Frueh-/Spaetpensionierungs-Szenarien moeglich.
 model Person {
   id            String     @id @default(cuid())
-  planId        String
-  plan          Plan       @relation(fields: [planId], references: [id], onDelete: Cascade)
+  scenarioId    String
+  scenario      Scenario   @relation(fields: [scenarioId], references: [id], onDelete: Cascade)
   role          PersonRole
   name          String?
   age           Int
   retirementAge Int
 
-  @@unique([planId, role])
+  @@unique([scenarioId, role])
 }
 
-// Eine vollstaendige Phasenkette; selbsttragend inkl. Grundprofil (Haushaltsform,
-// Personen, Inflationsannahme). Kann Szenario eines anderen Plans sein (Deep-Copy).
+// Behaelter einer Planung. Traegt selbst KEINE Finanzdaten, nur den Namen und die Szenarien.
 model Plan {
-  id                   String        @id @default(cuid())
-  userId               String
-  user                 User          @relation(fields: [userId], references: [id], onDelete: Cascade)
-  name                 String
+  id     String @id @default(cuid())
+  userId String
+  user   User   @relation(fields: [userId], references: [id], onDelete: Cascade)
+  name   String
+
+  createdAt DateTime @default(now())
+  updatedAt DateTime @updatedAt
+
+  scenarios Scenario[]
+}
+
+// Die berechenbare Einheit: Grundprofil + Phasenkette + Elemente. Genau ein Szenario je
+// Plan ist das Basisszenario (isBase); weitere haengen als Baum darunter (parentScenarioId).
+model Scenario {
+  id     String @id @default(cuid())
+  planId String
+  plan   Plan   @relation(fields: [planId], references: [id], onDelete: Cascade)
+  name   String
+  isBase Boolean @default(false)
+
+  // Szenario, aus dem dieses kopiert wurde. Zugleich die Vergleichsbasis fuer den Diff
+  // (Basisszenario: null). Beim Loeschen des Elternteils bleibt der Baum flach erhalten.
+  parentScenarioId String?
+  parentScenario   Scenario?  @relation("ScenarioTree", fields: [parentScenarioId], references: [id], onDelete: SetNull)
+  children         Scenario[] @relation("ScenarioTree")
+
   householdType        HouseholdType
   inflationRateDefault Float
   initialCash          Float         @default(0)
 
-  parentPlanId      String?
-  parentPlan        Plan?   @relation("PlanScenarios", fields: [parentPlanId], references: [id], onDelete: SetNull)
-  scenarios         Plan[]  @relation("PlanScenarios")
-  branchFromPhaseId String?
-
   createdAt DateTime @default(now())
   updatedAt DateTime @updatedAt
 
@@ -95,13 +120,16 @@ model Plan {
 // wird NICHT gespeichert, sondern aus Alter + Pensionsalter abgeleitet (lib/calculations).
 // Die Inflation liegt seit V5 plan-weit am Plan (inflationRateDefault), nicht mehr hier.
 model Phase {
-  id             String @id @default(cuid())
-  planId         String
-  plan           Plan   @relation(fields: [planId], references: [id], onDelete: Cascade)
+  id             String   @id @default(cuid())
+  scenarioId     String
+  scenario       Scenario @relation(fields: [scenarioId], references: [id], onDelete: Cascade)
   sequenceNumber Int
   name           String
   durationYears  Int
 
+  // Gegenstueck im Eltern-Szenario (lose Referenz, kein FK) -- Grundlage des Diffs.
+  sourcePhaseId String?
+
   // Entscheid fuer das Cash-Konto beim UEBERGANG NACH dieser Phase (JSON, validiert in
   // lib/elements.ts): 1:1 uebernehmen oder einmaliger Zufluss/einmalige Kosten. Liegt hier
   // und nicht in ElementTransitionValue, weil Cash kein FinancialElement ist.
@@ -113,20 +141,23 @@ model Phase {
   phaseValues      ElementPhaseValue[]
   transitionValues ElementTransitionValue[] @relation("TransitionFromPhase")
 
-  @@unique([planId, sequenceNumber])
+  @@unique([scenarioId, sequenceNumber])
 }
 
-// Ein finanzielles Element (plan-weit): Kategorie + optionale Personenzuordnung.
+// Ein finanzielles Element (szenario-weit): Kategorie + optionale Personenzuordnung.
 model FinancialElement {
   id         String          @id @default(cuid())
-  planId     String
-  plan       Plan            @relation(fields: [planId], references: [id], onDelete: Cascade)
+  scenarioId String
+  scenario   Scenario        @relation(fields: [scenarioId], references: [id], onDelete: Cascade)
   category   ElementCategory
   name       String
   ownerRole  OwnerRole?
   orderIndex Int             @default(0)
   createdAt  DateTime        @default(now())
 
+  // Gegenstueck im Eltern-Szenario (lose Referenz, kein FK) -- Grundlage des Diffs.
+  sourceElementId String?
+
   phaseValues      ElementPhaseValue[]
   transitionValues ElementTransitionValue[]
 }