Roadmap Nr. 9 (reduziert): Einkommen ist neu explizit als NETTOLOHN definiert
(Label + Hilfetext). Bisher stand nirgends, ob netto oder brutto gemeint ist -- fuer
den Cash-Fluss egal (beide Konventionen heben sich auf), aber seit der
einkommensabhaengigen AHV haengt eine Rente daran. Die AHV bemisst sich am
Bruttolohn, deshalb rechnet das Tool intern mit AHV_GROSS_FROM_NET_FACTOR = 1.12
hoch. Ohne das war die Rente um bis zu ~1'900/Jahr zu tief (Details: SPEZ 9.13).
Der Faktor ist hergeleitet und dokumentiert (AHV/IV/EO 5.3% + ALV 1.1% + NBU ~1% +
PK ~2-5% auf den koordinierten Lohn) -- fix vertretbar, weil das mdJE selbst ein
Karriere-Durchschnitt ist. Keine Aufschluesselung, kein sichtbares Feld (kommt mit
Roadmap Nr. 41 als erklaerte Konstante).
Roadmap Nr. 8: Immobilie neu mit Hypothekarzins (% der Restschuld, Zinsbetrag sinkt
mit der Amortisation, read-only "Beginn -> Ende") und Wertsteigerung.
WICHTIG: Die Wertsteigerung wirkt auf die LIEGENSCHAFT, nicht auf das Eigenkapital.
1% von 1 Mio sind 10'000/Jahr, also 10% eines Eigenkapitals von 100'000 -- das ist
der Hebel. Auf dem EK gerechnet waeren es 1'000 (Beispiel: 304'622 statt 210'462).
Kaufpreis und Verkehrswert laufen deshalb getrennt; die Grundstueckgewinnsteuer
bemisst sich weiterhin am urspruenglichen Kaufpreis.
Doppelzaehlung: Schalter interestHandling auf der Immobilie, Default INCLUDED --
bestehende Plaene haben die Zinsen in den Ausgaben und aendern sich nicht.
Keine Steuerschaetzung (Begruendung: SPEZ 9.14). Sechs Regressionstests (30 -> 36).
Spezifikation auf v0.5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Roadmap Nr. 3: Die AHV-Rente folgt neu der amtlichen Rentenformel (Skala 44) ueber
das massgebende durchschnittliche Jahreseinkommen statt pauschal der Maximalrente.
- Formel aus den amtlichen Randbedingungen hergeleitet und gegen die Tabelle
318.117.1 verifiziert: 51/51 Zeilen exakt. Schwellen sind Vielfache von R0=1'260
(12/36/72 x R0 = 15'120 / 45'360 / 90'720). Stuetzstellen als Golden Tests.
- Alles REAL gerechnet: die AHV wertet vergangene Einkommen auf UND indexiert die
Schwellen -- real hebt sich das auf. Nominal wuerde die Rente systematisch zu hoch
ausfallen (Beispiel: faelschlich Maximalrente, ~41'600 ueber 25 Rentenjahre).
- Pruefung der Beitragskarriere am Pensions-Uebergang; Zusatzfelder fuer die Jahre
vor Planbeginn nur, wenn der Plan nicht bis Alter 21 zurueckreicht.
- Sonderfall "bei Planbeginn bereits pensioniert": Felder in der Phasenzelle.
- Ohne Pruefung gilt der geplante Durchschnitt (nicht 0) -- sonst waere die Rente
still viel zu tief.
- 13. Altersrente: Jahresbetrag = Monatsrente x 13.
Roadmap Nr. 4: Warnhinweis in Phasenzellen und Phasen-Detail, wenn Folgephasen
existieren -- Werte schreiben sich fort und wirken bis ans Planende durch.
Verhaltensaenderung fuer bestehende Plaene: siehe SPEZIFIKATION 9.10.
Zwoelf Regressionstests (18 -> 30). Spezifikation auf v0.4.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Cash-Uebergang zwischen zwei Phasen ist neu ein eigener Entscheid:
1:1 uebernehmen / einmaliger Zufluss / einmalige Kosten / beides. Die Betraege
gehen direkt aufs Cash-Konto und bleiben aus der Spar-/Verzehrquote heraus.
- Zufluss NOMINAL erfasst, real angezeigt (wie Einkommen), optionaler Steuersatz
(Default 0 %). Kosten REAL erfasst, nominal angezeigt (wie Ausgaben).
Umrechnung ueber den Bestands-Deflator an der Phasengrenze.
- Entscheid startet unbeantwortet und zaehlt im "offen"-Badge mit; eine neue Phase
erzeugt damit automatisch einen offenen Cash-Entscheid am neuen Uebergang.
- Eigene Kopf-Kennzahlen statt Vermischung mit Kapitalzufluss/-investitionen:
eine Erbschaft ist kein Verkaufserloes, ein Poolbau keine Investition.
- Cash ist kein FinancialElement -> der Entscheid haengt als JSON an der Von-Phase
(neue Spalte Phase.cashTransition + Migration). Szenario-Kopie nimmt ihn mit.
Fuenf Regressionstests ergaenzt (13 -> 18). Spezifikation auf v0.3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Neue Funktionale/Technische Spezifikation (SPEZIFIKATION.md) mit
Aenderungshistorie; ersetzt die bisherigen FDD/TDD-Dokumente v1-v5.
In der App unter dem Menueintrag "SPEZIFIKATION" (Sidebar, unter den Plaenen)
lesbar: /api/spec liefert das Markdown, SpecView rendert es. Styling ueber die
bestehenden Farb-Tokens, folgt damit allen drei Schemata.
Die MD-Datei war ueber .dockerignore (*.md) vom Image ausgeschlossen -> Ausnahme
ergaenzt und Kopie in die Runner-Stage aufgenommen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Phase.inflationRate ersatzlos entfernt (inkl. Migration). Die Inflation liegt
seit V5 plan-weit; das Feld wurde von computePlan nie gelesen und war wirkungslos.
- Amortisation und Tilgung stoppen, sobald Hypothek bzw. Schuld abbezahlt sind:
Hypothek/Restschuld sind neu laufende Salden, die Rate ist pro Jahr am Restsaldo
gekappt. Belastet danach weder Cash noch Sparquote.
- Kapitalbezugssteuer greift neu auch bei PK-/3a-Vorbezuegen vor der Pensionierung.
Der Bezug wird brutto dem Kapital entnommen, netto ins Cash gebucht.
plannedSaveRate ist neu die Rate des ersten Phasenjahres. Drei Regressionstests
ergaenzt (10 -> 13).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Investitionen einer Phase (Zusatz-/Neuinvestitionen aus Cash) werden am Phasenanfang
abgezogen; der Cash-Startwert bildet das nun ab. Behebt zugleich eine Doppelzaehlung im
Startvermoegen (der investierte Betrag stand zuvor sowohl im Cash-Start als auch im
Vermoegen). Endwerte unveraendert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Sonstiges Vermoegen bekommt "Jaehrliche Bezugsrate (Entnahme)": mindert das Vermoegen
(gekappt am Bestand) und fliesst jaehrlich ins Cash.
- Phasenkopf neu strukturiert: Einkommen / Ausgaben / Quote, dann Geplante Sparrate
(3a + Vermoegen-Sparbeitrag + Amortisation + Tilgung) und Geplante Verzehrrate
(Bezugsraten), dann Kapitalzufluss (Verkaeufe + PK-/3a-Bezuege aus dem Uebergang) und
Kapitalinvestitionen (Zusatz-/Neuinvestitionen + sofortige Tilgungen), dann Vermoegen.
Die Cash-Zeile im Kopf entfaellt (die Cash-Zeile in der Matrix bleibt).
- Engine liefert plannedSaveRate/plannedWithdrawRate/capitalInflow/capitalInvest.
- Golden Tests: Bezugsrate ins Cash + Kapitalzufluss/-investitionen (10 gruen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
INCOME von PERSON_ONLY zu OWNER_OPTIONAL verschoben -> im Erstell-Dialog ist neben
Person A/B auch "Gemeinsam" waehlbar; die API erzwingt keine Personenzuordnung mehr.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Punkt 1: Beim Speichern eines Einkommens-/Ausgaben-Basiswerts, der dem fortgeschriebenen
Wert der Vorphase entspricht, wird KEIN Override gespeichert. Damit wirken sich Aenderungen
in frueheren Phasen automatisch auf Folgephasen aus (live vererbt); nur ein bewusst
abweichender Wert bleibt fix.
Punkt 2: Anzeige-Umschalter oben links (Nominal / Beide / Real), pro Geraet gespeichert.
Alle Betraege in Matrix, Cash-Zeile und Phasenkopf zeigen je nach Wahl den nominalen,
realen (kaufkraftbereinigten) oder beide Werte. Engine liefert dazu cumulativeInflationStart
(Deflator zu Phasenbeginn) zusaetzlich zum Phasenende.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das separate "Uebersteuern"-Feld (amountOverride) konnte 0 nicht von "nicht gesetzt"
unterscheiden und nahm faelschlich 0. Entfernt. Stattdessen ist der Basiswert (amount)
selbst editierbar: ab Phase 2 mit dem fortgeschriebenen Endwert der Vorphase vorbelegt,
aber bewusst aenderbar (Teilzeit/Beförderung/Jobwechsel). Solange nicht geaendert, wird
der Wert 1:1 aus der Vorphase fortgeschrieben (pd.amount ungesetzt -> carry.flowBasis).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Neues Feld Plan.initialCash (additiv, Default 0). computePlan startet die erste Phase
mit diesem Cash-Bestand statt 0. In der Matrix ist die Cash-Zelle der ersten Phase
klickbar und oeffnet ein Popup zum Setzen des Anfangswerts (PATCH /api/plans/{id}).
Szenario-Kopie uebernimmt den Wert. Golden-Test ergaenzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Klick auf eine Element-Zelle in einer Lebensphase oeffnet neu ein kleines Popup
(PhaseCellDialog mit ElementDetail) - analog zu den Uebergangszellen. Das untere
Detail-Panel dient nur noch der Phasen-Kopf-Bearbeitung. Popup ist per key stabil
(kein Uebertrag des Formularzustands zwischen Elementen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Behebt die Nominal/Real-Inkonsistenz (Bug #1): Einkommen/Ausgaben werden neu Jahr fuer
Jahr indexiert (eigenes Feld teuerungsausgleich je Element, Default = Phaseninflation;
Renten nominal fix = 0%). Vermoegen verzinst weiterhin nominal.
Cash: neues systemseitiges, immer sichtbares Element (0% Verzinsung, kein DB-Row -
synthetisch in computePlan). Ist der Ausgleichstopf = "verfuegbares Kapital fuer
Investments": cash_delta(t) = quote(t) - geplante flache Jahresraten (3a/Vermoegen/Amort./
Tilgung); Cash laeuft ueber Phasen fort, darf negativ werden (rot). Der Verteilzwang und
die harten Sparraten-Caps entfallen.
Ruin: Gesamtvermoegen (inkl. Cash) je Jahr; erstes Unterschreiten von 0 -> Ruin-Alter
(Person A), Anzeige als Banner + Zeitachsen-Marker.
Phasenkopf neu: Einkommen/Ausgaben Start->Ende, Quote Beginn/Ende, Cash Start->Ende,
Vermoegen inkl. Cash, Realwert. Inflation-Deflator neu pro Jahr (Math.pow ^Dauer).
Golden Tests (vitest) 1-4 + Renten-0% + Fortschreibung gruen (Test1 761'654/565'928,
Test2 Ruin Alter 94).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kapitalbezugssteuer, Grundstueckgewinnsteuer und PK-Umwandlungssatz wurden im UI nur
optisch vorbelegt (num(td.x, 8/20/6)), die Berechnung las aber num(td.x) mit Fallback 0.
Ein nicht angetupftes Feld fuehrte so zu 0% Steuer bzw. 0 Rente. Defaults sind jetzt
zentrale Konstanten (constants.ts) und werden in Berechnung UND UI als Fallback genutzt.
Betrifft: PK-Kapital/-Kombi/-Rente, 3a-Bezug, Immobilienverkauf.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Sparquote/Verzehr zeigt in Klammern den bereits verteilten/gedeckten Prozentsatz,
z. B. "Sparquote 10'000 (100% verteilt)".
- Statt einer Alterszeile je Phase nun pro Person "Name Startalter -> Endalter".
- Neue Zeile "Vermoegen Startvermoegen -> Endvermoegen" (nominal).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Balkendiagramm: je Phase zwei x-Kategorien (Beginn/Ende), gestapelt nach Asset-Element
(Schluessel = elementId, damit gleiche Namen nicht kollidieren). Zeigt die Umschichtung;
Ende Phase N liegt neben Beginn Phase N+1.
- Liniendiagramm: x-Achse ist neu das Alter (Referenz Person A) von Startalter bis Ende der
letzten Phase, mit Start- und Phasen-Endwerten (nominal + real), statt Phasenindex.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das untere Detail-Panel (ElementDetail/PhaseDetail) initialisiert seinen lokalen
Formular-Zustand nur beim Mounten. Ohne key wurde beim Wechsel der Zelle/Phase
dieselbe Instanz wiederverwendet -> Werte (z. B. Zusatzinvestition) blieben vom
zuvor geoeffneten Element haengen. Fix: key pro Auswahl (Zelle/Phase) erzwingt
Neuaufbau. Analog key am Uebergangs-Popup.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Person A/B erhalten ein optionales Namensfeld (Migration: Person.name nullable).
Fallback im UI bleibt "Person A"/"Person B". Angezeigt in Grundprofil-Box, Zeitachse,
Matrix-Elementzuordnung und Element-Erstelldialog; Szenario-Kopie uebernimmt den Namen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ist der Besitzer eines PK-/3a-Elements zu Beginn der Von-Phase bereits pensioniert,
wurde die Position bei der Pensionierung bereits bezogen oder verrentet -- in allen
weiteren Uebergaengen gibt es nichts mehr zu tun. Zentrale Hilfsfunktion
transitionInactive() (verkauft/getilgt ODER PK/3a post-Pension) steuert Zelle,
"?"-Status und Offen-Zaehler einheitlich.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
refreshCurrent laedt den Plan-Detail neu OHNE Loading-Umschaltung, damit die PlanView
montiert bleibt und die Scrollposition nicht auf 0/0 zurueckspringt. Der Spinner
erscheint weiterhin nur beim initialen Plan-Wechsel.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ist ein Element am jeweiligen Uebergang bereits verkauft/getilgt (status != ACTIVE),
zeigt die Zelle nur noch "–" (nicht interaktiv, kein "?"), analog zu AHV.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wenn openCount == 0, zeigt der Kopf statt "n offen" nun gruen hinterlegt einen
Haken (CheckCircle2) + "geprueft".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Ursache des "?"-Bugs: sichtbarer Default (Halten/Rente) wurde ohne aktive Auswahl
nicht in den Datensatz geschrieben -> beim Speichern blieb der Entscheid leer.
Fix: withTransitionDefaults belegt den Entscheid explizit vor (Popup + Review-Panel),
sodass ein blosses Speichern den Default persistiert.
- Uebergangszellen oeffnen neu ein kleines Popup (TransitionCellDialog) statt des
unteren Detail-Panels; offene Zellen sind kraeftig eingefaerbt.
- PK und 3a bekommen im normalen Uebergang einen echten Bezugs-Entscheid
(Kein Bezug / Bezug + Betrag) inkl. offenem "?"-Status bis entschieden.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Vorlauf berechnet das Quoten-Vorzeichen (Einkommen inkl. Renten minus Ausgaben)
vor der Element-Schleife; in Verzehrphasen (Quote < 0) wird die Jahresrate beim
sonstigen Vermoegen als Bezug (negativ) statt als Sparbeitrag verrechnet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
admGitAICDS