Meine Objekte: gespeicherte Analysen und Vergleich¶
Status: verbindlich
Spezifikationsversion: 1.1.1
Modellbezug: 0.6.2
Implementierungsbezug: frontend-mvp-0.2.5
PropertyRecord-Schema: 0.1.1
Stand: 2026-07-05
1. Zweck¶
Meine Objekte ist die persönliche Sammlung bewusst gespeicherter Immobilienanalysen.
Analyseergebnisse bewusst speichern
Snapshots anzeigen
Objekte verwalten, filtern und vergleichen
Objekte exportieren
Reports aus gespeicherten Ergebnissen erzeugen
Die Berechnungswahrheit steht in docs/calculations/model-specification.md. Der PropertyRecord-Vertrag steht in docs/specification/data-quality-and-validation/data-model.md.
2. Abgrenzung¶
Enthalten:
PropertyInput-Snapshots
ScenarioResults einschließlich Case Ratings
Base-KPIs
Investment Rating
Datenqualität
Plausibilitätsprüfungen und Warnungen
Status, Notizen und Tags
Nicht enthalten:
Marktmiet-Rohdaten
RentObservation
RentAreaStats
ungeprüfte Batch-Zeilen
reine Pre-Screening-Ergebnisse
Portfolio-Buchhaltung
3. Entstehung¶
PropertyInput
-> Single-Property-Engine
-> AnalysisResult
-> bewusste Nutzeraktion
-> PropertyRecord
Herkunft:
manual_analysis
batch_analysis
imported_analysis
Eine Berechnung speichert nichts automatisch. Beim Speichern wird ausschließlich der an das AnalysisResult gebundene PropertyInput-Snapshot übernommen. Das Formular wird nicht erneut als Recheninput gelesen.
4. Objektidentität und Snapshot¶
object_id:
identifiziert das gespeicherte Objekt
analysis_result_id:
identifiziert den gespeicherten Rechenlauf
property_input.meta.property_input_id:
identifiziert den berechneten Eingabesnapshot
object_id wird nicht nachträglich in den unveränderbaren PropertyInput-Snapshot geschrieben.
5. Batch und Marktmiete¶
BatchAnalysisResult != PropertyRecord
RentEstimate != RentObservation
Nur vollständig berechnete und bewusst ausgewählte Batch-Ergebnisse werden übernommen. Eine gespeicherte Mietschätzung wird nicht automatisch zu einer Marktbeobachtung.
6. Aktueller Speicher¶
localStorage
Storage Key: immohai.propertyRecords.v1
Der Key wird nur mit expliziter Migration geändert.
Nicht Teil des lokalen MVP:
Backend
Serverdatenbank
Login
Gerätesynchronisation
mehrere Nutzer
serverseitige Reportgenerierung
7. PropertyRecord 0.1.1¶
Der vollständige Feldvertrag steht ausschließlich in docs/specification/data-quality-and-validation/data-model.md.
Zusätzlich verbindlich:
object_id identifiziert das gespeicherte Objekt
analysis_result_id identifiziert den Rechenlauf
property_input stammt aus demselben Rechenlauf
scenario_results und summary_kpis stammen aus demselben Rechenlauf
rating und data_quality_assessment stammen aus demselben Rechenlauf
scenario_results enthalten die gespeicherten Case Ratings
rating enthält ausschließlich das Investment Rating
batch_run_id und batch_row_id werden bei Batch-Herkunft gespeichert
listing_import_reference ist nur eine Quellenreferenz
Kanonische Versionsfelder:
property_input_schema_version
analysis_result_schema_version
property_record_schema_version
market_rent_schema_version optional
rent_estimate_schema_version optional
analysis_data_quality_method_version
Neue PropertyRecords schreiben kein generisches top-level schema_version.
8. Snapshot-Prinzip¶
Nicht zulässig:
stille Neuberechnung beim Öffnen
stilles Überschreiben alter Ergebnisse
stille Aktualisierung auf neue Modellversion
stille Änderung gespeicherter Annahmen oder Datenqualität
Kombination eines älteren AnalysisResult mit neuem Formularzustand
stille Migration von Legacy-Feldern
9. Öffnen und Neuberechnen¶
1. PropertyRecord auswählen.
2. gespeicherten Snapshot anzeigen.
3. alle im Formular repräsentierbaren gespeicherten Eingaben ohne Rechenlauf laden.
4. Szenario-Steuerungsmodus und alle sieben Sliderwerte wiederherstellen.
5. nicht sichtbare gespeicherte Annahmen für eine bewusste Neuberechnung erhalten.
6. Versionsunterschiede sichtbar anzeigen.
7. Formularänderungen als unberechnet markieren.
8. Neuberechnung nur bewusst starten.
9. neues AnalysisResult erzeugen.
10. neuen Stand bewusst speichern.
Eine Neuberechnung verändert den alten Snapshot nicht automatisch. Ohne bewusste fachliche Eingabeänderung bleibt der vollständige PropertyInput-Inhalt erhalten; neu entstehen nur Identifikatoren, Zeitstempel und kompatible Patch-Schemaversionen.
10. Inseratslink als Quellenreferenz¶
Ein optionaler Inseratslink wird gespeichert als:
listing_import_reference
Aktueller Umfang:
Quellen-URL dokumentieren
Quelle und Erfassungszeitpunkt nachvollziehbar halten
keine automatische Datenübernahme
keine Rohdatenberechnung
listing_import_state ist ausschließlich ein Legacy-Lesealias.
11. Status¶
watchlist
in_review
rejected
archived
Statusänderungen verändern keine Rechenergebnisse.
12. Filter und Sortierung¶
MVP-Filter:
Freitext
Stadt
Stadtteil
Objektprofil oder Kategorie
Status
Investment Rating
Wohnfläche
Kaufpreis
Kaufpreis pro m²
Miete pro m²
Cashflow Jahr 1
DSCR
Anfangs-LTV
Net vs ETF nach Exit
Mindestens sortierbar nach Objektname, Zeitstempeln, Kaufpreis, Fläche, Cashflow, DSCR, Anfangs-LTV, Net vs ETF, Rating und Status.
13. Pagination und Auswahl¶
Seitengrößen:
10
25
50
Aktionen:
Vergleichen: exakt zwei Objekte
Exportieren: mindestens ein Objekt
Entfernen: mindestens ein Objekt und Bestätigung
14. Kennzahlen und Auswertung¶
Zulässig:
Anzahlen
Quoten
Medianwerte
Min/Max
Verteilungen
Top-/Bottom-Objekte
Segmentauswertungen
Nicht automatisch zulässig:
Summe Kaufpreise
Summe Darlehen
Summe Eigenkapital
Summe Gesamtinvestitionen
Diese Summen würden eine Portfoliosemantik erzeugen.
15. Zwei-Objekt-Vergleich¶
Mindestens:
Kaufpreis
Wohnfläche
Kaufpreis und Miete pro m²
Gesamtinvestition
Eigenkapital und Darlehen
Anfangs-LTV
gross_rent_y1
Cashflow und Minimum Cashflow
kumulativer Zuschussbedarf
DSCR
Net vs ETF nach Exit
Self-funding und ETF Break-even
Investment Rating
Case Ratings
Datenqualität
Der Vergleich verwendet ausschließlich gespeicherte Snapshots.
16. Export¶
Aktuell:
Excel-kompatible UTF-8-CSV
Semikolon-Trennung
nur ausgewählte PropertyRecords
nur gespeicherte Snapshot-Werte
17. Reports¶
One Pager
Investment Report
Bank Report
Reports verwenden PropertyRecord-Snapshots. Sie berechnen keine Fachwerte oder Ratings neu.
18. Datenqualität¶
Ein PropertyRecord speichert das vollständige AnalysisDataQualityAssessment einschließlich Methodenversion. UNRATED bleibt ein eigener Status.
19. Legacy-Kompatibilität¶
Zulässige Lesealiase stehen ausschließlich in docs/specification/data-quality-and-validation/data-model.md. Neue PropertyRecords schreiben nur kanonische Felder.
20. Aktueller Frontend-Stand¶
Vorhanden:
lokale Speicherung
bewusstes Speichern
Snapshot-Laden ohne automatische Neuberechnung
vollständige Wiederherstellung sichtbarer Eingaben und Szenario-Slider
Erhalt nicht sichtbarer Snapshot-Annahmen bei bewusster Neuberechnung
Suche und Filter
Sortierung
Pagination
Statusbearbeitung
KPI- und Segmentauswertung
Mehrfachauswahl
Zwei-Objekt-Vergleich
CSV-Export
Versionsmetadaten
Datenqualitäts-Snapshot
PropertyRecord 0.1.1 Serialisierung
Offen:
Top-/Bottom-Auswertung
Szenario- und Jahresverläufe
Notizen und Tags vollständig
Reportauswahl aus der Objektliste
explizite Legacy-Migration
bewusste Snapshot-Historie je Objekt
Serverpersistenz
21. Tests¶
Berechnen allein speichert nicht.
Speichern erzeugt einen vollständigen PropertyRecord 0.1.1.
AnalysisResult-ID und Versionen werden gespeichert.
Datenqualität und Methodenversion werden gespeichert.
PropertyInput-ID und Snapshot stimmen mit AnalysisResult überein.
object_id verändert den PropertyInput-Snapshot nicht.
Formularänderungen können nicht mit dem vorherigen Ergebnis gespeichert werden.
Öffnen zeigt den Snapshot und startet keinen Rechenlauf.
Alle sichtbaren Eingaben und Szenario-Slider werden beim Öffnen wiederhergestellt.
Nicht sichtbare Snapshot-Annahmen bleiben bei bewusster Neuberechnung erhalten.
Bewusste Neuberechnung verändert den alten Snapshot nicht.
CSV verwendet gespeicherte Werte.
UNRATED bleibt separat.
Case Ratings bleiben im Snapshot erhalten.
Batch-Herkunft speichert batch_run_id und batch_row_id.
Inseratslink wird nur als Quellenreferenz gespeichert.
Legacy-Aliase werden nicht neu geschrieben.