Memo 2026081701: Kapitalverwendung mit waehlbarem Tilgungsziel, AHV automatisch, Farb- und Textkorrekturen

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

SPEZIFIKATION.md

@@ -4,10 +4,10 @@
 | | |
 |---|---|
 | **Dokument** | Funktionale und Technische Spezifikation FPT |
-| **Version** | 0.40.1 |
+| **Version** | 0.41 |
 | **Datum** | 2026-07-25 |
 | **Status** | Lebendes Dokument |
-| **Codestand** | Arbeitsstand nach `ce987b9` inkl. «ein Wert, ein Ort» (Branch `main`) |
+| **Codestand** | Arbeitsstand nach `f9d7ca0` inkl. Memo 2026081701 (Branch `main`) |
 | **Ersetzt** | `FDD_TDD_FPT.docx` (v1–v5) im Ordner `Info Dateien` – diese sind ab Version 0.1 dieses Dokuments obsolet |
 | **Geltungsbereich** | Gesamter Code im Verzeichnis `FPT` |
 
@@ -17,6 +17,7 @@
 
 | Version | Datum | Autor | Änderung |
 |---|---|---|---|
+| 0.41 | 2026-08-17 | Claude (Opus 5) | **Memo 2026081701** – zehn Punkte aus einer Testrunde, mehrheitlich Feinschliff, zwei davon inhaltlich. (1) **Die Kapitalverwendung heisst neu Schuldentilgung · Investition · Cash, und die Tilgung hat ein wählbares Ziel** (`capitalUseDebtTargetElementId`): eine Immobilie **oder** eine sonstige Schuld. Bisher floss die Quote stur in die erstbeste Immobilie – wer neben einer Hypothek zu 1,5 % einen Konsumkredit zu 6 % trägt, konnte den Kredit gar nicht zuerst tilgen. Ohne Wahl bleibt es beim alten Verhalten, damit bestehende Pläne unverändert rechnen. **Cash ist neu eine gleichrangige Zeile** statt einer blassen Fussnote: «ich lasse es liegen» ist ein legitimer Entscheid. Rechnerisch bleibt es der Rest – alle drei frei eintippbar zu machen hiesse, dass beim Tippen still eine andere Zahl wandert. (2) **Die Maske gibt es neu auch bei der Säule 3a.** Dort stellt sich die Frage sogar zwingender als bei der PK: Ein 3a-Konto wird IMMER vollständig bezogen, es fliesst also in jedem Fall ein grosser Betrag – der bis 0.40 stumm auf dem Cash landete. (3) **Je Person entsteht beim Abschluss der Bestandsaufnahme automatisch ein AHV-Element**, idempotent (wer die Bestandsaufnahme später korrigiert, bekommt kein zweites). Die AHV ist die einzige Kategorie ohne Bestand – ein Plus-Knopf mit leerer Karte wäre sinnlos, das Element wegzulassen aber auch: Ohne es rechnet der Plan ab der Pensionierung mit einer AHV-Rente von 0. Die Karte in der Bestandsaufnahme sagt neu, warum dort nichts zu erfassen ist. (4) **Farben folgen der Bedeutung, nicht dem Zustand.** Ein einmaliger Cash-Zufluss am Übergang trug die Akzentfarbe – im warmen Schema ein Orangerot, das eine Erbschaft wie einen Fehler aussehen liess; neu ist er grün, ein Abfluss neutral. Die Knöpfe «Kapital verteilen» und «Sparquote verteilen» sind **grün mit Haken, sobald erledigt** – vorher sah man einer vollständig verteilten Phase nicht an, dass sie fertig war. (5) **Sechs Stellen mit unlesbarer Schrift behoben:** `text-attention-fg` ist **weiss** und für vollflächigen Attention-Grund gedacht; auf hellem oder 10-%-Grund war der Text im warmen und im hellen Schema praktisch unsichtbar (PK-Einkaufswarnung, 3a-Kollision, fehlendes Anlageziel, zwei Stellen in der Kachel «Offene Punkte»). (6) **Der Kapitalanteil-Regler hatte keine sichtbare Schiene**: `appearance-none` schaltet die native Darstellung ab, womit auch `accent-color` nicht mehr greift – übrig blieb der blosse Knopf. (7) **Der Umwandlungssatz verschwindet bei 100 % Kapital**, spiegelbildlich zur Kapitalbezugssteuer bei 0 %. Bei vollem Kapitalbezug wird nichts verrentet. (8) **Der Dialog «Neue Lebensphase» erklärt die Dauer-Kappung** – welches Ereignis sie setzt und warum (die Rechnung leitet Erwerbsstatus und Bezüge am Phasen**beginn** ab). Vorher stand dort nur «max. N». (9) **Zustand statt Regel nach der Pensionierung:** Die Zellen von PK und 3a beschrieben in der Pensionsphase die Regel im Futur («wird berechnet», «wird bezogen»), obwohl der Bezug längst geschehen war. Neu steht dort der gerechnete Stand – bei der PK die Rente in Franken oder «Vollständig bezogen», bei der 3a «Vollständig bezogen». (10) **Eine Vokabel für einen Gedanken:** Die Bestätigung der Pensionsentscheide heisst neu «angeschaut» wie die der Phasenzellen, und der Erklärtext sagt ausdrücklich, dass der Haken **keine Zahl ändert**. Zwei Wörter für dieselbe Sache hatten mehr verwirrt als geholfen. Die Fixpunkt-Kappung um AHV-, PK- und 3a-Bezugsalter zu erweitern wurde **bewusst zurückgestellt** – im Basisszenario ist das Pensionsalter fest 65, das Thema gehört zur Szenario-Art «Frühpensionierung» (Roadmap Nr. 48). 3 Tests ergänzt (334 → 337). |
 | 0.40.1 | 2026-08-16 | Claude (Opus 5) | **Zwei Fehler aus der Testrunde.** (1) **«Ein Wert, ein Ort» gilt jetzt im Rechenkern, nicht nur in der Oberfläche.** Eine Immobilie zeigte in der ersten Lebensphase Startwert 0 statt Kaufpreis minus Hypothek. Ursache: Der Rechenkern legte die Phasenwerte über die Stammdaten (`{...baseData, ...phaseValues}`) – eine in 0.39 versehentlich gespeicherte 0 gewann damit gegen die Bestandsaufnahme. Seit 0.40 ist das Feld read-only, wodurch dieser Altwert **unerreichbar** war und den Kaufpreis dauerhaft verdeckt hätte. Neu gewinnen bei den fünf Bestandsfeldern (`amount`, `currentValue`, `startValue`, `purchasePrice`, `mortgage`) **immer die Stammdaten**, wo sie einen Wert tragen (`firstPhaseValues`); der Rückfall auf den Phasenwert bleibt nur, solange die Stammdaten leer sind – sonst fielen Pläne aus der Zeit vor 0.36 schlagartig auf 0. Die Annahmen (Rendite, Zins, Wertsteigerung, Teuerung) bleiben in Phase 1 überschreibbar: Sie gelten für einen Zeitraum, nicht für den Anfangsbestand. Damit heilen bestehende Daten von selbst. (2) **«Alle bestätigen» war zu grob.** Der Knopf in der Annahmen-Maske schrieb `confirmed: true` auf jede Zeile – man konnte ihn drücken, ohne je gescrollt zu haben, also genau das Durchwinken, das der Mechanismus verhindern soll. Neu trägt **jede Zeile ein Häkchen «Angeschaut»**, anfangs leer; wer ein Feld ändert, hakt es automatisch an (bearbeiten IST anschauen); oben markiert ein Klick alle auf einmal, aber als sichtbarer Akt. Gespeichert werden die Werte aller Zeilen, bestätigt nur die angehakten – der Knopf nennt die Zahl. 4 Tests ergänzt (330 → 334). |
 | 0.40 | 2026-08-16 | Claude (Opus 5) | **Ein Wert, ein Ort** (neues Kap. 3.14.3, aus einer Testrunde des Nutzers). Der rote Faden aller acht Punkte: Für dieselbe Zahl gab es an mehreren Stellen ein Eingabefeld, und der Rechenkern entschied still, welches gewinnt. (1) **Startwerte sind in der ersten Lebensphase read-only.** Sie standen dort als Eingabefeld, das `phaseValues[phase1]` schrieb – der Rechenkern legt die Phase über die Stammdaten (`{...baseData, ...phaseValues}`), also überschattete jede Eingabe still die Bestandsaufnahme. Neu wird der Stammdatenwert angezeigt, mit Absprung in die Spalte «Start». Ab Phase 2 bleibt der Betrag bei Einkommen und Ausgaben **änderbar** – Teilzeit, Beförderung, Jobwechsel sind echte Entscheide dieser Phase; die Bestände sind dort ohnehin schon fortgeschrieben und read-only. (2) **Jährliche Raten entstehen nur noch im Verteil-Dialog**, einmalige Kapitalverwendungen nur noch im Kapital-Dialog. In der Zelle stehen sie weiterhin, aber read-only mit Absprung. Nur im Dialog sieht man, wie viel überhaupt zu verteilen ist und ob die Summe aufgeht. (3) **Der PK-Beitrag wandert in den Verteil-Dialog** – in einen **eigenen Block** «Aus dem Bruttolohn (ausserhalb der Quote)». Er ist bewusst nicht Teil der Quote ([4.6.3](#463-pension_fund)), aber der Dialog ist neu der einzige Ort für jährliche Beträge; ohne ihn wäre er unerreichbar und fiele still auf 0. (4) **Deckel und Schalter «grosse Säule 3a» stehen im Verteil-Dialog**, direkt über der Einzahlung, deren Obergrenze sie bestimmen – getrennt davon war der Schalter eine Einstellung ohne sichtbare Wirkung. (5) **Sonderamortisation und Sofort-Tilgung verlassen die Übergangszelle.** Sie zehren vom Kapital der FOLGEphase und werden dort entschieden; angezeigt werden sie in der Phasenzelle, wo auch die Zusatzeinlage steht. (6) **Der «Kapital verteilen»-Knopf ist immer sichtbar.** Er hing an `pot.total > 0` – wer alles verteilt hätte, käme an seine eigene Zuteilung nie mehr heran, sobald die Elementfelder read-only sind. (7) **Cash in der Bestandsaufnahme.** Es fehlte ganz: Die Summe «Vermögen heute» rechnete es bereits mit, erfassen konnte man es dort nirgends. Kein Plus-Knopf, sondern ein festes Feld – Cash ist kein Element, sondern `Scenario.initialCash`. (8) **Die Tour startet direkt nach dem Anlegen des Plans.** Sie hing an `phases.length > 0`, einem Überbleibsel der Spotlight-Tour, die echte DOM-Ziele brauchte; die Attrappe braucht nichts – und die Tour gehört genau dorthin, wo man noch nicht weiss, wie der Plan aufgebaut ist. (9) **Das Abzeichen im Phasenkopf öffnet eine Maske mit allen offenen Annahmen** (`PhaseReviewDialog`), analog zum Übergangs-Review. Bis 0.39 fragte es nur «N Annahmen bestätigen?» – eine Zustimmung zu etwas Ungesehenem, also genau die Bewegung, die der Mechanismus verhindern soll. (10) **Unbestätigte Zellen sind deutlicher markiert**: getönter Grund, kräftiger linker Balken, Warnzeichen. Der dünne Ring aus 0.39 ging in einer vollen Matrix unter. (11) **Cash-Zeile mit `ValuePair`**: der Realwert steht im Modus «Beide» darunter statt daneben, wie in jeder anderen Zeile. (12) Zwei Folgen daraus: Der Dialog **«Element anlegen» schreibt neu in die Stammdaten** statt in Phase 1 und **braucht keine Lebensphase mehr**; und `needsConfirmation` verlangt keine Bestätigung mehr für Zellen **ohne jede Annahme** – eine «Sonstige Schuld» trägt seit (2) nichts mehr in der Phasenzelle. 1 Test ergänzt (329 → 330). |
 | 0.39.1 | 2026-08-16 | Claude (Opus 5) | **Fehlerbehebung: Die Bestandsaufnahme schloss sich beim ersten Plus-Knopf.** `InventoryDialog` kannte nur einen Rückkanal nach oben (`onSaved`) und benutzte ihn für zwei verschiedene Ereignisse: «Element angelegt, bitte Plan neu laden» und «Dialog fertig». In `PlanView` hängt an `onSaved` aber das Schliessen -- ein Klick auf «Ausgaben» legte das Element korrekt an und beendete den Dialog sofort, womit sich genau der eine Bildschirm nicht bedienen liess, der alles erfassen soll. Neu trägt der Dialog beide Rückkanäle getrennt: `onChanged` lädt nur nach (der Entwurf im Dialog überlebt das, weil `loadDetail(id, true)` still nachlädt und die `PlanView` montiert bleibt), `onSaved` schliesst. Betraf auch das Löschen einer Position aus dem Dialog heraus. |
@@ -474,12 +475,28 @@ Neue Phasen werden **immer am Ende der Kette** angehängt (`sequenceNumber = Anz
 **Automatische Dauer-Kappung:** Die Dauer wird ans nächste Pensionsereignis gekappt. Formel
 (`maxPhaseDuration`): für jede Person, die zu Phasenbeginn noch erwerbstätig ist, gilt
 `retirementAge − (age + yearsBefore)`; das Minimum dieser Werte ist die Obergrenze. Ist keine
-Person mehr erwerbstätig, gibt es keine Obergrenze (`null`). Diese Kappung ist im Dialog
-sichtbar („max. N") **und** wird serverseitig erzwungen.
+Person mehr erwerbstätig, gibt es keine Obergrenze (`null`). Diese Kappung wird
+serverseitig erzwungen.
 
 Fachliche Begründung: Eine Phase darf keine Pensionierung überspannen, weil der Phasentyp
 und die AHV-/PK-Renten am Phasenbeginn ausgewertet werden.
 
+**Der Dialog nennt seit 0.41 den Grund, nicht nur die Zahl.** Vorher stand dort «max. 12» –
+eine Sperre ohne Erklärung wirkt willkürlich, und man vermutet einen Fehler. Neu steht im
+Klartext, welches Ereignis die Grenze setzt («Anna geht mit 65 in Pension»), warum das so ist
+(die Rechnung wertet Erwerbsstatus und Renten am Phasen**beginn** aus) und dass es weitergeht
+(«danach legst du einfach die nächste Phase an»). Sind alle Personen bereits pensioniert, sagt
+der Dialog stattdessen, dass die Dauer frei ist.
+
+> **Bekannte Lücke.** `maxPhaseDuration` kann zusätzliche Fixpunkte entgegennehmen (AHV-Beginn,
+> PK-Bezug, jedes 3a-Konto, siehe [3.14.5](#3145-fixpunkte-jeder-bezugsbeginn-erzwingt-eine-phasengrenze)),
+> aber weder der Dialog noch der Endpunkt übergeben sie – gekappt wird nur am Erwerbsende. Im
+> Basisszenario fällt das nicht ins Gewicht, weil das Pensionsalter dort fest **65** ist. Wer
+> im Übergangs-Dialog ein abweichendes 3a-Bezugsalter setzt, kann die Grenze jedoch
+> überspannen; der Bezug rutscht dann auf die nächste Phasengrenze. Bewusst zurückgestellt bis
+> zur Szenario-Art «Frühpensionierung» (Roadmap Nr. 48), wo abweichende Bezugsalter zum
+> eigentlichen Thema werden.
+
 **Default-Dauer:** die Kappung, sonst 10 Jahre.
 **Default-Name:** Phase 1 → „Erste Lebensphase"; sonst „Pensionsphase" wenn zu Phasenbeginn
 mindestens eine Person pensioniert ist, sonst „Erwerbsphase".
@@ -756,7 +773,7 @@ Seit 0.35 gibt es **drei** Zustände statt zwei. Der dritte ist der interessante
 |---|---|
 | **unbeantwortet** | Das System weiss nichts. Verkauf/Halten, Tilgung, Cash-Übergang. |
 | **auf Vorgabe** | Das System **hat** eine Antwort – nur nicht die des Benutzers. Gilt für die Pensionierungs-Entscheide (AHV/PK/3a), die seit 0.35 durchgängige Vorgaben haben. |
-| **bestätigt** | Der Benutzer hat hingeschaut (`retirementDecision.confirmed`), je Säule. |
+| **bestätigt** | Der Benutzer hat hingeschaut (`retirementDecision.confirmed`), je Säule. Seit 0.41 heisst das im UI durchgehend «angeschaut» – dieselbe Vokabel wie bei den Phasenzellen ([3.14.2](#3142-bestätigen-heisst-ich-habe-hingeschaut)), weil es derselbe Gedanke ist: dort auf den Werten der Vorphase, hier auf einer Vorgabe des Tools. Zwei Wörter für eine Sache hatten mehr verwirrt als geholfen. Der Erklärtext sagt neu ausdrücklich, dass der Haken **keine Zahl ändert**. |
 
 Warum der dritte Zustand nötig wurde: Die Vorgaben sind Absicht – ohne sie müsste man am
 Anfang Fragen beantworten, die man erst am Ende beantworten kann, und der Plan wäre bis dahin
@@ -1199,6 +1216,13 @@ Was nicht verteilt wird, **bleibt automatisch auf dem Cash** – dafür braucht
 ist das Verhalten des Modells. Wird mehr verteilt als vorhanden, startet die Folgephase mit
 negativem Cash; der Dialog weist das als Liquiditätslücke aus.
 
+**Der Knopf ist grün mit Haken, sobald etwas zugeteilt ist**, und trägt sonst die
+Attention-Farbe. Vorher sah man einer fertig verteilten Phase nicht an, dass sie fertig war –
+der Knopf sah immer gleich aus. «Erledigt» heisst hier: Es ist Kapital da und **etwas davon**
+ist zugeteilt; wer bewusst nur einen Teil verteilt und den Rest liegen lässt, hat entschieden.
+Anders als bei der Quote gibt es dafür kein gespeichertes Kennzeichen – das Kapital ist keine
+Frage, die man beantworten MUSS, sondern eine Gelegenheit.
+
 **Der Knopf ist immer sichtbar**, auch wenn der Topf leer ist. Bis 0.39 hing er an
 `pot.total > 0` – also am **Rest**. Wer alles verteilt hatte, sah ihn nicht mehr. Solange die
 Beträge im Element noch änderbar waren, ging das; seit 0.40 sind sie read-only, und der Knopf
@@ -1318,6 +1342,19 @@ Referenz: `src/lib/ratefields.ts`, `src/components/ElementDetail.tsx`.
 
 ### 3.7.2 Farbschemata
 
+> **Der Akzent ist keine Bedeutung** (Lehre aus 0.41). Im warmen Schema ist er ein Orangerot,
+> im dunklen ein Indigo. Wer ihn benutzt, um «erledigt» oder «hier ist Geld hereingekommen» zu
+> sagen, sagt im einen Schema etwas anderes als im anderen: Ein einmaliger Erbschafts-Zufluss
+> sah warm aus wie ein Fehler. Bedeutung trägt deshalb **Grün** (positiv, erledigt),
+> **Attention** (hier fehlt etwas) und **Danger** (hier ist etwas falsch) – der Akzent nur
+> «hier kannst du klicken».
+>
+> Ebenso hat jede Farbe **zwei** Vordergrund-Töne, und sie sind nicht austauschbar:
+> `--attention-fg` ist weiss und gehört auf **vollflächigen** Attention-Grund;
+> `--attention-soft-fg` ist dunkel und gehört auf den weichen. Verwechselt man sie, ist die
+> Schrift im warmen und im hellen Schema praktisch unsichtbar – in 0.41 an sechs Stellen
+> behoben.
+
 Drei Themes: **Hell**, **Dunkel**, **Warm** (cremefarben, Koralle-Akzent). Wahl im Profilmenü,
 persistiert in `localStorage` (`fpt-theme`), gesetzt als `data-theme` am `<html>`. Ohne
 gespeicherte Wahl folgt die Oberfläche `prefers-color-scheme`. Ein Inline-Script im `<head>`
@@ -1977,11 +2014,31 @@ gegen die Vererbung, bis man das Häkchen aktiv setzt.
 
 Am Pensions-Übergang kommt oft ein grosser Betrag auf einmal herein (PK-Kapital, Säule 3a).
 Ihn vollständig als Cash liegen zu lassen ist selten die Absicht. Beim **Bezugs-Entscheid des
-jeweiligen Guthabens** lässt sich deshalb erfassen, wie viel **in Prozent** in die Amortisation
-der Hypothek und in eine Anlage fliesst; der Rest bleibt Cash.
+jeweiligen Guthabens** lässt sich deshalb erfassen, wie viel **in Prozent** wohin fliesst – seit
+0.41 in drei gleichrangigen Zeilen:
+
+| Zeile | Ziel | wirkt als |
+|---|---|---|
+| **Schuldentilgung** | wählbar: eine Immobilie **oder** eine sonstige Schuld | Sonderamortisation bzw. Sofort-Tilgung |
+| **Investition** | wählbar: ein Element «Sonstiges Vermögen» | Zusatzeinlage in der Folgephase |
+| **Cash** | – | bleibt liegen |
+
+**Das Tilgungs-Ziel ist wählbar, seit es Schulden ausserhalb der Hypothek gibt.** Bis 0.40 floss
+die Quote stur in die erstbeste Immobilie; wer neben einer Hypothek zu 1,5 % einen Konsumkredit
+zu 6 % trägt, konnte den Kredit gar nicht zuerst tilgen. Ohne getroffene Wahl bleibt es beim
+alten Verhalten (Immobilien der Reihe nach) – ein Bestandsschutz, damit bestehende Pläne
+unverändert rechnen; ein Schuld-Element wird nur getilgt, wenn es **ausdrücklich** gewählt ist.
+
+**Cash ist eine Zeile, kein Rest.** Rechnerisch ist es beides – die Zahl ergibt sich aus
+100 % minus den beiden anderen und ist deshalb nicht eintippbar. Dargestellt wird sie trotzdem
+gleichrangig: «ich lasse es liegen und entscheide später» ist ein Entscheid, keine Unterlassung.
+Alle drei frei eintippbar zu machen hiesse, dass beim Tippen still eine der anderen Zahlen
+wandert.
 
 Die Frage steht seit 0.33 dort, wo der Bezug entschieden wird – bei der **Pensionskasse** (nur
-wenn Kapital bezogen wird) und bei der **Säule 3a**. Bis 0.32 hing sie am **Cash-Übergang**:
+wenn Kapital bezogen wird) und bei der **Säule 3a**. Bei der 3a fehlte sie bis 0.40 allerdings
+in der Oberfläche, obwohl sie sich dort **zwingender** stellt: Ein 3a-Konto lässt sich nur ganz
+auflösen, es fliesst also in jedem Fall ein grosser Betrag – und der landete stumm auf dem Cash. Bis 0.32 hing sie am **Cash-Übergang**:
 Das war der falsche Ort, weil sich mit zwei Guthaben nicht getrennt festlegen liess, welches
 wohin fliesst. Beide Dialoge führen deshalb neu in der Reihenfolge, in der man tatsächlich
 entscheidet: **Bezugsart → Betrag brutto → Steuersatz → Betrag netto → Verteilung**.
@@ -1990,8 +2047,7 @@ entscheidet: **Bezugsart → Betrag brutto → Steuersatz → Betrag netto → V
 Kapital. Ein Frankenbetrag müsste von Hand nachgezogen werden – und würde bis dahin still eine
 falsche Aufteilung rechnen. Eine Quote skaliert mit.
 
-Die Amortisations-Quote ist am Restsaldo der Hypothek gekappt; ist sie grösser, bleibt der Rest
-Cash. Die Anlage-Quote fliesst in ein wählbares Vermögens-Element (Vorgabe: das erste aktive).
+Die Tilgungs-Quote ist am Restsaldo gekappt; ist sie grösser, bleibt der Rest Cash. Die Anlage-Quote fliesst in ein wählbares Vermögens-Element (Vorgabe: das erste aktive).
 Beide sind mechanisch nichts Neues – die eine wirkt wie eine Sonderamortisation, die andere wie
 eine Zusatzeinlage, und beide laufen dadurch korrekt durch die zwei Wasserfall-Brücken.
 
@@ -2192,6 +2248,15 @@ Der **PK-Beitrag** steht bewusst bei den Annahmen und nicht in der Sparquoten-Ve
 stammt aus dem Bruttolohn und belastet das Cash-Konto nicht
 ([4.6.3](#463-pension_fund)) -- aus der Quote liesse er sich gar nicht verteilen.
 
+**Beim Abschliessen entsteht je Person ein AHV-Element** (seit 0.41), idempotent – wer die
+Bestandsaufnahme später korrigiert und erneut abschliesst, bekommt kein zweites. Die AHV ist
+die einzige Kategorie **ohne Bestand**: Es gibt kein Guthaben zum Nachschlagen, nur eine
+Beitragskarriere, die FPT aus den Einkommen dieses Plans ableitet. Ein Plus-Knopf mit einer
+leeren Karte darunter wäre deshalb sinnlos gewesen – sie wegzulassen aber auch: In der Schweiz
+hat jede Person eine AHV, und ohne das Element rechnet der Plan ab der Pensionierung mit einer
+Rente von 0. Erscheint die Karte später in der Liste, sagt sie, warum dort nichts zu erfassen
+ist. Wer die Bestandsaufnahme nie öffnet, legt das Element selbst an.
+
 **Die Bestandsaufnahme bleibt als eigener Dialog** (`InventoryDialog`): als grosser Knopf im
 leeren Plan und dauerhaft unter den Schnellaktionen. Sie ist der einzige Sammel-Dialog, der
 geblieben ist, weil sie als einzige etwas leistet, das die Matrix nicht kann -- sieben
@@ -4064,9 +4129,10 @@ den Wert der Vorphase. Alle übrigen Felder bedeuten «nicht gesetzt = 0» wie b
 | `extraAmortization` | REAL_ESTATE (Sonderamortisation) | ≥ 0 |
 | `saleTaxRate` | REAL_ESTATE | 0–100 |
 | `immediateRepayment` | OTHER_DEBT | ≥ 0 |
-| `capitalUseAmortizationPct` | PENSION_FUND (Kapitalbezug), PILLAR_3A – Anteil des bezogenen Kapitals in die Amortisation | 0–100 |
-| `capitalUseInvestPct` | dito – Anteil in eine Anlage | 0–100 |
-| `capitalUseTargetElementId` | Ziel der Anlage-Quote; ohne Angabe das erste aktive Sonstige Vermögen | ≤ 60 Zeichen |
+| `capitalUseAmortizationPct` | PENSION_FUND (Kapitalbezug), PILLAR_3A – Anteil des bezogenen Kapitals in die **Schuldentilgung** | 0–100 |
+| `capitalUseDebtTargetElementId` | Ziel der Tilgungs-Quote: eine Immobilie **oder** eine sonstige Schuld. Ohne Angabe die Immobilien der Reihe nach (Bestandsschutz); ein Schuld-Element wird nur getilgt, wenn es ausdrücklich gewählt ist | ≤ 60 Zeichen |
+| `capitalUseInvestPct` | dito – Anteil in eine **Investition** | 0–100 |
+| `capitalUseTargetElementId` | Ziel der Investitions-Quote; ohne Angabe das erste aktive Sonstige Vermögen | ≤ 60 Zeichen |
 
 ### 5.4.5 JSON-Payload `CashTransitionData`
 
@@ -4494,7 +4560,7 @@ Include `src/**/*.test.ts`). Es gibt **keine** Komponenten-, API- oder E2E-Tests
 | `migrations.test.ts` | 3 | spielt alle Migrationen gegen echtes PostgreSQL (PGlite) ein; prüft zusätzlich die V7-**Datenübernahme** (Basisszenario gewinnt, Pensionsalter bleiben szenario-eigen) |
 | `rate-limit.test.ts` | 6 | Fixed-Window: erlaubt bis Limit, blockt danach, startet nach Fensterablauf neu, trennt je Schlüssel; Client-IP aus X-Forwarded-For / X-Real-IP |
 | `csv.test.ts` | 7 | BOM, alle vier Blöcke, jedes Element als Zeile, Beginn-/Ende-/Übergangsspalten, Entscheid im Klartext, ein Eintrag je Planjahr, Maskierung von `;` und `"` |
-| **Total** | **334** | |
+| **Total** | **337** | |
 
 ## 8.2 Testfälle