## Ergebnis: **BLOCK**

### P0
- Keine P0-Funde.

### P1
1. **Bestätigungs-Race kann erfolgreiche Writes im UI verschweigen**  
   `PortfolioPerformancePanel.vue:185,191` invalidiert bei einer Eingabeänderung die Confirm-Generation und verwirft anschließend die Antwort. Der bereits gesendete Confirm wird serverseitig jedoch nicht abgebrochen: Der lokale Gegenprobe schrieb **1 Cashflow und 1 Audit-Eintrag**, während das UI laut Test bewusst keine Erfolgsmeldung zeigt (`PortfolioPerformancePanel.test.ts:94–109`).  
   **Risiko:** Nutzer sieht den produktiven Write nicht, arbeitet mit altem Setup weiter oder bestätigt überlappende Eingaben erneut. Während Confirm müssen Eingaben gesperrt oder der Abschluss des alten Requests wahrheitsgemäß angezeigt und der Zustand neu geladen werden.

2. **True-Wealth-View liefert mehrere widersprüchliche Werte pro Tag**  
   `truewealth_valuation.py:485–508` liefert sämtliche modellierten Snapshot-Versionen und zusätzlich offizielle Anker desselben Tages. `supersedes_snapshot_id` bzw. die offizielle Vorrangregel wird hier nicht berücksichtigt. Gegenprobe ergab für einen Tag gleichzeitig **110 bestätigt, 108 modelliert und 105 modelliert**. Das Frontend zeichnet alle Punkte.  
   **Risiko:** irreführender Performancechart und falsche Modell-/Ankerdarstellung. Pro Account/Tag muss genau die kanonische Version projiziert werden; ein offizieller Anker muss modellierte Kandidaten dieses Tages verdrängen.

### P2
1. **`max="9999-12-31"` nur teilweise umgesetzt**  
   Nur das Feld „Bis“ hat die Grenze (`PortfolioPerformancePanel.vue:63`). „Von“, Cashflow-Datum und die allgemeinen Periodenfelder besitzen sie nicht (`:28–29,63,68`). Fünfstellige Jahre können damit clientseitig bis zum Backend gelangen und dort als 400 enden.

2. **Attestierung bleibt nach inhaltlicher Änderung angehakt**  
   `resetTrueWealthPreview()` setzt `twAttested` nicht zurück (`PortfolioPerformancePanel.vue:185`). Nach Änderung von Zeitraum, Modus, CSV oder Cashflow-Zeilen gilt die Checkbox daher weiter für eine neu generierte Erklärung. Für eine explizite Vollständigkeits-/Nullflussbestätigung sollte sie bei relevanten Änderungen zurückgesetzt werden.

### Positiv verifiziert
- `PerformanceSetupResponse` und Diagnostics sind strikt geschlossen; keine Rohprovenienz bzw. internen IDs in der Setup-Projektion gefunden.
- Neue True-Wealth-Responsemodelle verwenden `extra="forbid"`.
- Read-only-Modus erlaubt Preview, blockiert Confirm/Activation.
- Touch-Ziele überwiegend mindestens 44 px; responsive Grids sind vorhanden.
- Confirm-/Load-Generationszähler verhindern stale UI-Responses, lösen aber den oben genannten Write-Receipt-Race nicht.

### Tests
- Vollständiges Verify erfolgreich: **973 Backendtests**, **232 Frontendtests**, Typecheck, Build und Git-Safety.
- `git diff --check`: erfolgreich.
- Keine Dateien erstellt oder verändert; nur temporäre In-Memory-Gegenproben.
- Erster `make PYTHON=.venv/bin/python verify`-Versuch fand `pytest` nicht im `PATH`; mit `.venv/bin` im `PATH` vollständig erfolgreich wiederholt.