Frontend-MVP – aktueller Implementierungsstand¶
Status: informativ
Dokumenttyp: aktuell implementierter Frontend-Stand
Spezifikationsversion: 1.3.0
Modellbezug: 0.6.2
Implementierungsbezug: frontend-mvp-0.2.5
Stand: 2026-07-06
1. Zweck¶
Diese Datei beschreibt den sichtbaren und technisch aktiven Frontend-MVP. Sie ist keine zusätzliche fachliche Wahrheit. Formeln, Datenverträge und Schnittstellen stehen in den jeweils führenden Spezifikationen.
2. Hauptnavigation¶
Einzelanalyse
Batch-Analyse
Meine Objekte
Dokumentation
Separater Adminbereich:
Admin / Marktmiet-Daten
3. Einzelanalyse¶
Aktiv:
Quick Mode
Kaufpreis
Wohnfläche
Objektprofil
Baujahr
Zustand
Investitionsbedarf nach Kauf
Eigenkapitalbeitrag
monatliche Nettokaltmiete
Erwerbsnebenkosten
Initialzins
Anfangstilgung
Betrachtungszeitraum
optionaler Inseratslink als reine Quellenreferenz
optionale eigene Szenario-Slider
Ein einziger aktiver Controller erzeugt PropertyInput, ScenarioInputs und AnalysisResult.
4. Aktive Rechenkette¶
Formular einschließlich Sliderwerte
-> PropertyInput 0.5.1
-> JSON-Schema-, Semantik- und Berechenbarkeitsprüfung
-> ScenarioInput[]
-> Single-Property-Engine
-> ScenarioResult[] mit ScenarioRating
-> AnalysisResult 0.1.1 mit Investment Rating
Ein formales AnalysisResult entsteht nur mit einem vollständig gebundenen PropertyInput-Snapshot.
5. Initialzustand und Herkunft¶
Die im HTML sichtbaren Startwerte sind Beispiele und werden nicht automatisch bewertet.
Seite laden
-> Status Noch nicht berechnet
-> kein vertrauenswürdiges AnalysisResult
-> bewusste Nutzeraktion Analyse berechnen erforderlich
Herkunftsregel:
unveränderter Beispielwert -> origin default
bewusst geänderter Formularwert -> origin manual
Die AnalysisDataQualityAssessment wird nach der finalen Herkunfts- und Snapshot-Auflösung erneut berechnet.
6. Runtime-Validierung¶
Vor jedem bewussten Rechenlauf werden mindestens geprüft:
PropertyInput gegen Schema 0.5.1
ValueWithOrigin-Semantik
Szenarioregeln
CAPEX-Methodenkonsistenz
Miet- und Zinsbasis
Kaufpreis > 0
Wohnfläche > 0
Betrachtungszeitraum als positive ganze Zahl
Bei einem Fehler wird kein AnalysisResult erzeugt und die UI zeigt eine Validierungsmeldung.
7. Szenario-Slider¶
Die Slider werden vor dem Rechenlauf gelesen und im PropertyInput gespeichert:
PropertyInput.scenarios.control_mode = custom_sliders
PropertyInput.scenarios.controls
Der Szenarioresolver liest kein DOM. Base bleibt unverändert. Best und Stress werden aus dem gespeicherten PropertyInput erzeugt.
8. Ergebnisbereiche¶
Dashboard
Finanzierung
Cashflow
ETF & Vermögen
Reports
Das Dashboard zeigt zentrale KPIs, Case Ratings, Szenariovergleich, Plausibilitätschecks, Annahmenherkunft, Datenqualität und Modellgrenzen.
Kanonische KPI-Assessments werden direkt aus dem Engine-Ergebnis dargestellt. Die UI leitet keine eigenen Schwellen ab.
9. Case Ratings und Investment Rating¶
Der Szenariovergleich liest für jeden Case ausschließlich:
ScenarioResult.scenario_rating.scenario_rating
ScenarioResult.scenario_rating.reason
Das gilt identisch für Best, Base und Stress. Base verwendet nicht das übergeordnete Investment Rating als Case Rating.
Das Investment Rating wird ausschließlich aus AnalysisResult.investment_rating gelesen.
10. Restschuld-Chart¶
Der Finanzierungsbereich rendert den Restschuldverlauf ausschließlich aus dem Base-Projection-Snapshot.
Angezeigt werden:
Restschuld je Jahr
lesbare Y-Achse in EUR
horizontale Rasterlinien
Jahresmarken
beschriftete Punkte
Zinsreset als eigene Markierung
Hinweis auf den nach Reset neu angenäherten Kapitaldienst
Der Chart berechnet keine Finanzwerte neu.
11. Datenqualität¶
Die Quick-Analyse erzeugt ein deterministisches AnalysisDataQualityAssessment nach Methodenversion analysis-dq-0.2.0.
Score >= 75: good
50 bis < 75: borderline
< 50: insufficient und UNRATED
Die Bewertung verwendet die Herkunft des final berechneten PropertyInput. Unveränderte Beispielwerte erhalten keinen manuellen Herkunftsbonus.
12. Meine Objekte¶
Aktiv:
lokale PropertyRecord-0.1.1-Speicherung
bewusstes Speichern
Snapshot-Laden ohne automatische Neuberechnung
Entfernen mit Bestätigung
Filter
Sortierung
Pagination
Statusbearbeitung
KPI- und Segmentauswertung
Mehrfachauswahl
Zwei-Objekt-Vergleich
CSV-Export
Versionsmetadaten
Technische URL: /objects.html.
13. Aktuelle und Legacy-Records¶
Beim Lesen werden Records klassifiziert:
current:
PropertyRecord 0.1.1
PropertyInput 0.5.1
AnalysisResult 0.1.1
legacy_read_only:
anderer oder unvollständiger Vertragsstand mit gültiger object_id
invalid:
nicht als PropertyRecord lesbar
Legacy-Records bleiben sichtbar und auswertbar, werden aber als Legacy · read-only markiert. Laden zur Neuberechnung und erneutes Speichern sind ohne explizite Migration gesperrt. Speicherfehler werden sichtbar gemeldet und nicht still als leere Objektliste interpretiert.
14. Snapshot-Laden¶
aktuellen PropertyRecord öffnen
-> gespeichertes AnalysisResult anzeigen
-> Eingaben ohne Rechenlauf ins Formular laden
-> Formularänderungen als unberechnet markieren
-> Neuberechnung nur über Analyse berechnen
Das aktuelle Formular ist keine Report- oder Speicherquelle, solange es nicht neu berechnet wurde.
15. Inseratslink¶
Aktiver Umfang:
optional URL erfassen
als source_reference und listing_import_reference speichern
keine automatische Portalabfrage
keine automatische Feldübernahme
16. Marktmiet-Daten¶
Aktiver lokaler Prototyp:
CSV-Import
Normalisierung
Marktart, Einheit und Möblierung trennen
Dubletten und Ausreißer
P25, Median und P75
numerische Confidence und confidence_level
Dataset-Lifecycle draft, published, archived
Dataset-Scope
pro Scope genau eine published Version
RentEstimate nur aus published Dataset innerhalb seines Scope
kanonische RentEstimateReference
17. Batch-Analyse¶
Aktuell nur als Architektur- und UI-Platzhalter vorhanden. Die spätere Vollanalyse verwendet dieselbe Single-Property-Engine.
18. Reports¶
Aktuell vorhanden:
Dashboard
One-Pager-Vorschau
Investment-Report-Vorschau
Bank-Report-Vorschau
Browser-Druck
Print-to-PDF über den Browser
CSV-Export gespeicherter Objekte
Die Vorschauen verwenden den aktuellen AnalysisResult-Snapshot. Die bekannte DOM-basierte Reporting-Abweichung wird separat in ARCH-2026-002 behandelt.
19. Speicher¶
Meine Objekte: immohai.propertyRecords.v1
Marktmiet-Daten: immohai.marketRentDatabase.v1
Keine Serverdatenbank und keine Gerätesynchronisation.
20. Aktuelle Versionen¶
model_version = 0.6.2
calculation_engine_version = frontend-mvp-0.2.5
property_input_schema_version = 0.5.1
analysis_result_schema_version = 0.1.1
property_record_schema_version = 0.1.1
rent_estimate_schema_version = 0.1.0
market_rent_schema_version = 0.3.0
analysis_data_quality_method_version = analysis-dq-0.2.0
Manifest:
frontend/assets/config/model-manifest.json
21. Nicht im aktuellen MVP¶
vollständiger Expert Mode
funktionale Batch-Analyse
Backend und Serverdatenbank
Login und Rollen
Gerätesynchronisation
vollständige automatische Legacy-Migration
Monte Carlo
steuerliches Detailmodul
automatisches Scraping
automatische Portal-API
serverseitige PDF-Erzeugung
22. Tests vor Deployment¶
node scripts/check-active-frontend-syntax.mjs
./scripts/check-frontend-config-sync.sh
node scripts/check-engine-version-sync.mjs
node scripts/validate-property-input.mjs
node scripts/check-baseline.mjs
node scripts/check-analysis-contract.mjs
node scripts/check-property-record-store.mjs
node scripts/check-property-record-adapter.mjs
node scripts/check-single-analysis-controller.mjs
node scripts/check-market-rent-aggregation.mjs
node scripts/check-specification-consistency.mjs
node scripts/check-browser-acceptance-readiness.mjs
./scripts/check-frontend-baseline.sh
docker compose config --quiet
mkdocs build --strict
23. Browserabnahme¶
Die interaktive Abnahme erfolgt nach Deployment gemäß:
docs/operations/browser-acceptance.md
Ein erfolgreicher Readiness-Check ist Voraussetzung, aber kein Ersatz für die reale Browserabnahme.
24. Nächste technische Arbeiten¶
Pull Request #12 vollständig prüfen und mergen
Integrationscommit deployen
Browserabnahme durchführen und dokumentieren
anschließend Architektur-Proposals separat bewerten