Immohai Projektstruktur

Status: informativ
Spezifikationsversion: 1.0.2
Implementierungsbezug: frontend-mvp-0.2.5
Stand: 2026-07-05

1. Zweck

Diese Datei beschreibt die aktuelle Repository-Struktur und die technische Eigentümerschaft der wichtigsten Verzeichnisse.

Grundsatz:

Immohai-spezifische App-Inhalte gehören ins Immohai-Repository.
Allgemeine Infrastruktur- und Setup-Anleitungen gehören ins Developer Playbook.

2. Aktuelle Hauptstruktur

Immohai/
├── .github/
│   └── workflows/
├── docs/
├── frontend/
├── model/
├── scripts/
├── AGENTS.md
├── docker-compose.yml
├── mkdocs.yml
└── README.md

Die Verzeichnisse backend/, database/ und nginx/ sind im aktuellen Repository-Stand nicht als produktive Projektverzeichnisse vorhanden. Backend, Serverpersistenz und zusätzliche Deploymentkomponenten sind spätere Architekturentscheidungen und dürfen nicht als bereits vorhandene Struktur dargestellt werden.

3. Fachliche Dokumentation

docs/
├── calculations/
│   └── model-specification.md
├── specification/
│   ├── architecture/
│   │   ├── overview.md
│   │   └── project-structure.md
│   ├── data-quality-and-validation/
│   │   ├── data-model.md
│   │   ├── data-quality-assessment.md
│   │   ├── import-and-data-quality.md
│   │   ├── link-import.md
│   │   └── validation.md
│   ├── model-and-calculations/
│   │   ├── calculations.md
│   │   ├── calculation-interfaces.md
│   │   └── kpi-assessments.md
│   ├── product-domains-and-workflows/
│   │   ├── application-domains.md
│   │   ├── saved-objects.md
│   │   ├── batch-analysis.md
│   │   ├── market-rent-import.md
│   │   ├── rent-analysis.md
│   │   ├── renovation-and-condition.md
│   │   └── admin-data-management.md
│   └── user-interface-and-reporting/
│       ├── frontend-mvp.md
│       ├── app-shell-and-navigation.md
│       ├── reporting.md
│       └── report-types.md
├── governance/
│   ├── documentation-system.md
│   └── change-control.md
├── changes/
│   ├── proposals/
│   │   ├── architecture/
│   │   ├── roadmap/
│   │   └── specification/
│   ├── decisions/
│   └── changelog.md
├── roadmap/
│   ├── current-status.md
│   └── roadmap.md
├── operations/
│   └── deployment.md
└── legal/

Es existiert keine Datei docs/specification/README.md. Die Navigation und die fachliche Eigentümerschaft werden über mkdocs.yml und docs/governance/documentation-system.md beschrieben.

Die Auflistung zeigt die fachlich und technisch relevanten Bereiche. Einzelne weitere Hilfs- oder Indexdateien können innerhalb dieser Verzeichnisse vorhanden sein.

Eigentümerschaft:

model-specification.md:
  Formeln, Schwellen und Modellgrenzen

data-model.md:
  Datenobjekte, Feldverträge und Legacy-Aliase

calculation-interfaces.md:
  Übergänge zwischen Eingabe, Szenarioauflösung, Engine, Speicherung und Reporting

kpi-assessments.md:
  Darstellung und Serialisierung von KPI-, Case- und Investment-Bewertungen

reporting.md:
  Reportquellen und reine Ergebnisdarstellung

validation.md:
  Test- und Abnahmestrategie

4. Frontend

frontend/
├── index.html
├── objects.html
├── batch.html
├── admin.html
├── admin-data-import.html
└── assets/
    ├── config/
    ├── css/
    └── js/

4.1 Aktiver Einzelanalysepfad

frontend/index.html
-> frontend/assets/js/single-analysis-controller.js
-> PropertyInput-Adapter
-> Szenarioauflösung
-> Single-Property-Engine
-> AnalysisResult
-> reine Ergebnisdarstellung

Der alte frontend/assets/js/app.js ist kein aktiver Einzelanalyse-Controller mehr.

4.2 Zentrale aktive JavaScript-Module

single-analysis-controller.js
  orchestriert Formular, PropertyInput, Szenarien und AnalysisResult

property-input-adapter.js
property-input-adapter-v2.js
property-input-snapshot-adapter.js
  erzeugen und normalisieren PropertyInput
  erhalten nicht sichtbare Snapshot-Annahmen bei bewusster Neuberechnung

scenarios.js
  löst Base, Best und Stress ohne DOM-Zugriff auf

calculations.js
calculations-core.js
  berechnen Projektionen, KPIs, Assessments und Ratings

analysis-result.js
  erzeugt den formalen AnalysisResult-Snapshot

result-compatibility.js
  stellt nicht serialisierte Legacy-Lesealiase für Laufzeit und Snapshots bereit

property-record-adapter.js
property-record-adapter-v2.js
property-record-store.js
property-record-ui.js
  speichern und öffnen PropertyRecord-Snapshots
  stellen sichtbare Eingaben und Szenario-Slider wieder her

reports.js
reports-entry.js
  bauen Reportansichten aus AnalysisResult oder PropertyRecord

kpi-assessment-ui.js
  rendert Engine-Assessments ohne eigene Schwellen

result-visualization-ui.js
  rendert kanonische Case Ratings und den Restschuld-Chart aus gespeicherten Ergebniswerten

data-quality.js
  erzeugt AnalysisDataQualityAssessment

market-rent-*.js
rent-market-reference.js
  verwalten lokale Marktmiet-Datasets und RentEstimate-Übernahme

4.3 UI-Regeln

Die UI enthält keine eigene Finanzformel.
Die UI verwendet gespeicherte ScenarioRatings und leitet sie nicht neu ab.
Das Investment Rating wird nur auf AnalysisResult-Ebene dargestellt.
Charts verwenden vorhandene Projektionswerte und rechnen keine Fachwerte neu.
Formularänderungen markieren Ergebnisse als unberechnet und starten keinen stillen Rechenlauf.

5. Styles

frontend/assets/css/styles.css
  gemeinsame Basisstile

frontend/assets/css/app-shell.css
  Navigation und App-Rahmen

frontend/assets/css/single-analysis.css
  Einzelanalyse, KPI-Assessments, ScenarioRatings und Restschuld-Chart

weitere CSS-Dateien
  klar abgegrenzte Funktions- oder Reportbereiche

6. Maschinenlesbares Modell

model/
├── config/
│   ├── model-manifest.json
│   ├── default-assumptions.json
│   ├── object-types.json
│   └── scenario-presets.json
├── schema/
│   ├── property-input.schema.json
│   ├── analysis-result.schema.json
│   ├── property-record.schema.json
│   ├── rent-estimate.schema.json
│   ├── market-rent-import.schema.json
│   └── analysis-data-quality.schema.json
└── test-cases/

Frontend-Kopien unter frontend/assets/config/ müssen bytegleich zu den kanonischen Modell- und Schemadateien sein.

Grundsatz:

Markdown erklärt.
JSON konfiguriert und validiert.
Code berechnet.
Tests kontrollieren.

7. Tests und Hilfsskripte

scripts/
├── check-active-frontend-syntax.mjs
├── check-frontend-config-sync.sh
├── check-engine-version-sync.mjs
├── validate-property-input.mjs
├── check-baseline.mjs
├── check-analysis-contract.mjs
├── check-property-record-store.mjs
├── check-property-record-adapter.mjs
├── check-single-analysis-controller.mjs
├── check-market-rent-aggregation.mjs
├── check-specification-consistency.mjs
├── check-frontend-baseline.sh
├── deploy-and-verify.sh
└── lib/
    └── json-schema-validator.mjs

check-single-analysis-controller.mjs prüft zusätzlich:

gebundenen PropertyInput-Snapshot
kanonische ScenarioRatings im Szenariovergleich
Trennung von Case Rating und Investment Rating
Restschuld-Chartmodell
Zinsreset-Erkennung
lesbare Achsenskalierung

json-schema-validator.mjs prüft die im Repository eingesetzten JSON-Schema-Funktionen einschließlich lokaler und externer $ref, konditionaler Regeln und strikter Objektverträge.

8. CI

.github/workflows/contract-check.yml

Der Pull-Request-Workflow prüft die Vertrags-, Modell-, Frontend-, Speicher-, Marktmiet-, Docker- und Dokumentationskette vor einem Merge nach main.

9. Deployment

docker-compose.yml
├── immohai-web
└── immohai-docs

Lokale Bindings auf dem Server:

App:   127.0.0.1:8200
Doku:  127.0.0.1:8201

Öffentliche Ziele:

https://immohai.ohaisoft.com
https://docs.immohai.ohaisoft.com

10. Spätere Schichten

Backend
  API, serverseitige Engine, Persistenz und Reports

Datenbank
  Migrationen, Datenbankschema und Backups

spätere Modellmodule
  Batch-Analyse, Monte Carlo und korrelierte Annahmen

Diese Schichten sind Zieloptionen und keine bereits vorhandenen produktiven Repository-Verzeichnisse. Sie werden erst nach stabilem Frontend-, Vertrags- und Snapshotkern aktiviert und benötigen vor Einführung eine dokumentierte Architekturentscheidung.