ARCH-2026-001 – Frontend-State, Render-Orchestrierung und eindeutige View-Eigentümerschaft¶

Status: Entwurf
Proposal-Status: under_review
Kategorie: architecture
Erstellt: 2026-07-05
Stand: 2026-07-07
Geprüfter Repository-Stand: f84c881aace65ff9aa857b43fc2de4b0a7998397

Anlass¶

Die Einzelanalyse besitzt formal einen aktiven SingleAnalysisController. Der tatsächlich sichtbare Ergebniszustand entsteht jedoch aus einer Kette mehrerer Module, die denselben Analysezustand über globale window.immohai*-Variablen, Events, Timer, künstliche Klicks und MutationObserver weiterreichen oder bereits gerenderte DOM-Bereiche nachträglich verändern.

Das ursprüngliche Proposal betrachtete hauptsächlich die doppelte Eigentümerschaft von Szenariotabelle und Restschuld-Chart. Die Prüfung des aktuellen Repository-Standes zeigt, dass die Abweichung inzwischen die gesamte Ergebnisorchestrierung der Einzelanalyse betrifft.

Bestätigte Teilentscheidung 1 – Umfang¶

Am 2026-07-07 wurde Variante B bestätigt:

ARCH-2026-001 wird nicht auf einzelne bekannte Doppelrenderer begrenzt.

Das Proposal umfasst den vollständigen Einzelanalyse-Ergebniszustand und alle Module,
die diesen Zustand veröffentlichen, zeitversetzt weiterreichen oder bestehende
Ergebnisbereiche nachträglich verändern.

Jeder fachliche Ergebnisbereich soll genau einen schreibenden Renderer erhalten.
Andere Module dürfen Ergebnisdaten lesen, aber denselben DOM-Zielbereich nicht
nachträglich korrigieren, umgruppieren oder ersetzen.

Diese Teilentscheidung erweitert den Prüf- und Entscheidungsumfang. Sie nimmt die konkrete Zielimplementierung, die Annahme des Gesamtproposals und die spätere Integration noch nicht vorweg.

Ausgangsproblem¶

Der aktuelle Einzelanalysepfad besitzt keine durchgängig eindeutige Eigentümerschaft für State, Lifecycle und Rendering.

Vereinfacht:

Formular
-> SingleAnalysisController
-> PropertyInput
-> ScenarioInputs
-> AnalysisResult
-> globale window-Zustände
-> immohai:analysis-state-changed
-> mehrere direkte und zeitversetzte Renderer
-> DOM-Beobachter und Korrekturmodule
-> endgültig sichtbarer Browserzustand

Der finale Browserzustand funktioniert für die derzeit geprüften Fälle. Er ist jedoch von Ausführungsreihenfolge, Timerintervallen, Eventreihenfolge und DOM-Mutationen abhängig.

Relevanter bestehender Stand¶

Führende Regeln:

docs/specification/model-and-calculations/calculation-interfaces.md
  ein einziger aktiver Controller orchestriert den Einzelanalysepfad
  eine Neuberechnung erfolgt nur durch bewusste Nutzeraktion
  Reports und Vergleiche verwenden Snapshots

docs/specification/architecture/project-structure.md
  SingleAnalysisController orchestriert den Rechenlauf
  die UI verwendet gespeicherte Ergebniswerte und Ratings
  Formularänderungen markieren Ergebnisse als unberechnet

docs/specification/data-quality-and-validation/validation.md
  Frontend-Controller- und Browserpfad müssen geprüft werden
  unberechnete Formularwerte verändern keinen Report
  Snapshot-Öffnen startet keine automatische Neuberechnung

Betroffene Implementierung¶

frontend/assets/js/single-analysis-controller.js
frontend/assets/js/analysis-result.js
frontend/assets/js/baseline-integrity.js
frontend/assets/js/reports-entry.js
frontend/assets/js/reports.js
frontend/assets/js/result-visualization-ui.js
frontend/assets/js/result-summary-layout.js
frontend/assets/js/kpi-assessment-ui.js
frontend/assets/js/dashboard-kpi-layout.js
frontend/assets/js/plausibility-summary-ui.js
frontend/assets/js/scenario-rating-findings-ui.js
frontend/assets/js/chart-standardization-ui.js
frontend/assets/js/chart-format-fixes.js
frontend/assets/js/cashflow-projection-chart.js
frontend/assets/js/property-record-ui.js
frontend/assets/js/property-record-adapter-v2.js

Betroffene Prüfungen mindestens:

scripts/check-single-analysis-controller.mjs
scripts/check-single-analysis-browser.mjs
scripts/check-chart-standardization-browser-v3.mjs
scripts/check-dashboard-kpi-layout.mjs
scripts/check-scenario-rating-findings.mjs
scripts/check-assumption-origin-layout.mjs
scripts/check-analysis-submit-guard.mjs
scripts/check-property-record-adapter.mjs
scripts/check-browser-acceptance-readiness.mjs

Nachgewiesene aktuelle Architekturabweichungen¶

1. Mehrere schreibende Owner für dieselben DOM-Ziele¶

Nachgewiesene Beispiele:

#summary
  single-analysis-controller.js
  result-summary-layout.js

#kpi-grid
  single-analysis-controller.js
  kpi-assessment-ui.js
  dashboard-kpi-layout.js

#scenario-table-body
  single-analysis-controller.js
  result-visualization-ui.js
  scenario-rating-findings-ui.js

#plausibility-list
  single-analysis-controller.js
  plausibility-summary-ui.js

#financing-chart
  single-analysis-controller.js
  result-visualization-ui.js
  chart-standardization-ui.js
  chart-format-fixes.js

#projection-chart
  cashflow-projection-chart.js
  chart-standardization-ui.js

#wealth-chart
  single-analysis-controller.js
  chart-standardization-ui.js
  chart-format-fixes.js

Die Module übernehmen dabei nicht nur Formatierung. Sie ersetzen, gruppieren, ergänzen oder korrigieren bereits gerenderte Inhalte.

2. Zeitabhängige Render- und Korrekturketten¶

Aktiv verwendet werden unter anderem:

setTimeout(..., 0)
setTimeout(..., 20)
setTimeout(..., 40)
setTimeout(..., 60)
setTimeout(..., 80)
setTimeout(..., 120)
MutationObserver auf Ergebniscontainern
künstliche .click()-Aufrufe zur Reportaktualisierung

Damit ist die sichtbare Darstellung nicht allein das Ergebnis eines expliziten Renderaufrufs, sondern das Ergebnis mehrerer nachgelagerter Anpassungen.

3. Verteilter globaler Zustand¶

Aktuell werden unter anderem folgende globale Zustände verwendet:

window.immohaiCurrentAnalysis
window.immohaiCurrentPropertyInput
window.immohaiCurrentBaseInput
window.immohaiCurrentScenarioInputs
window.immohaiLoadedPropertyInputSnapshot
window.immohaiAnalysisDirty

reports-entry.js ersetzt window.immohaiCurrentAnalysis zusätzlich durch einen Getter/Setter und koppelt daran die Reportaktualisierung.

Es existiert kein einzelnes explizites State-Modul mit klar definiertem Schreibzugriff, Lifecycle und Subscriber-Vertrag.

4. Automatische Initialberechnung mit anschließendem Löschen¶

Der SingleAnalysisController startet während der Initialisierung einen Rechenlauf. baseline-integrity.js unterdrückt den sichtbaren Initialzustand, indem es beim ersten Analyseevent den AnalysisResult und weitere globale Zustände wieder auf null setzt und die Ergebniscontainer leert.

Der sichtbare Zustand „Noch nicht berechnet“ entsteht daher aktuell durch:

automatische Berechnung
-> Veröffentlichung des AnalysisResult
-> Analyseevent
-> nachträgliches Löschen des Ergebnisses

Das widerspricht dem gewünschten Lifecycle, nach dem ein Rechenlauf erst durch bewusste Nutzeraktion entsteht.

5. DOM als Zwischen-Datenquelle¶

cashflow-projection-chart.js liest die bereits formatierte Projektionstabelle, parst deutsche Währungsstrings zurück in Zahlen und erzeugt daraus einen Chart. Weitere UI-Module suchen Karten und Zielbereiche anhand sichtbarer Beschriftungen.

Damit werden Darstellung und technische Datenweitergabe unnötig gekoppelt.

Die reine Snapshot-Quelle für Reports wird gesondert in ARCH-2026-002 behandelt. Innerhalb von ARCH-2026-001 ist jedoch zu verhindern, dass UI-Renderer fachliche Ergebnisdaten aus bereits gerendertem DOM zurücklesen müssen.

6. Tests sichern den Endzustand, nicht die Eigentümerschaft¶

Der Headless-Chrome-Test prüft erfolgreich den konvergierten finalen Browserzustand. Er weist aber nicht nach:

dass jedes DOM-Ziel nur einen schreibenden Owner besitzt
dass keine zeitversetzte Korrektur erforderlich ist
dass keine Zwischenzustände mit falschem Rating sichtbar sind
dass der Initialzustand ohne vorherige Berechnung entsteht
dass Reportaktualisierung ohne künstlichen Klick erfolgt

Einige statische Tests verlangen derzeit sogar ausdrücklich die bestehende Unterdrückung der automatischen Initialanalyse. Diese Erwartungen müssen bei einer späteren Integration bewusst ersetzt werden.

Geltungsbereich¶

ARCH-2026-001 umfasst:

Lifecycle der Einzelanalyse
bewusster Initial-, Calculated-, Dirty-, Loaded- und Error-Zustand
Veröffentlichung des aktuellen AnalysisResult
Bindung des zugehörigen PropertyInput-Snapshots
Verfügbarkeit der ScenarioInputs, soweit für Darstellung erforderlich
eindeutige DOM- und View-Eigentümerschaft
direkte und nachvollziehbare Render-Orchestrierung
Aktualisierungsimpuls für Reportansichten
Kompatibilitätsgrenze zu PropertyRecord-Laden und -Speichern
Entfernung zeitabhängiger DOM-Korrekturketten
Tests für State-Übergänge und Renderer-Eigentümerschaft

Nicht Teil dieses Proposals:

Änderung von Finanzformeln
Änderung von KPIs, Schwellen oder Ratings
Änderung der PropertyInput-, AnalysisResult- oder PropertyRecord-Verträge
fachliche Neuberechnung in UI oder Reports
vollständige ReportDataBuilder-Architektur aus ARCH-2026-002
Einführung eines Frontend-Frameworks
Backend- oder Datenbankeinführung
neue Produktfunktion

Vorgeschlagenes Zielprinzip¶

Das Proposal soll ein eindeutiges Orchestrierungsmodell festlegen:

SingleAnalysisController
  steuert Nutzeraktionen und den Rechenlauf
  veröffentlicht einen vollständigen, konsistenten Analysezustand

AnalysisState
  besitzt eine klar definierte Schreibstelle
  bildet den Lifecycle der Einzelanalyse ab
  enthält oder referenziert den gebundenen AnalysisResult-Snapshot

View-Renderer
  erhalten State oder fachliche View-Daten als Parameter
  besitzen jeweils klar abgegrenzte Zielbereiche
  werden explizit aufgerufen oder über einen definierten Subscriber-Vertrag aktiviert

DOM
  ist Ausgabeziel
  ist keine Rücklesequelle für fachliche Ergebnisdaten

Verbindliches Zielprinzip nach Annahme:

Ein fachlicher Ergebnisbereich besitzt genau einen schreibenden Renderer.

Kein Modul korrigiert oder ersetzt denselben Zielbereich nur deshalb zeitversetzt,
weil ein anderer Renderer zuvor einen unvollständigen Zwischenzustand erzeugt hat.

Die konkrete State-Schnittstelle, Owner-Matrix und Migrationsfolge bleiben Gegenstand der weiteren Einzelentscheidungen.

Erwartete Zielbereiche mit eindeutiger Eigentümerschaft¶

Mindestens folgende Bereiche sind vor einer Annahme vollständig zuzuordnen:

Initial- und Fehlerzustand
Ratinganzeige und Zusammenfassung
KPI-Dashboard einschließlich Assessments und Gruppierung
Plausibilitätsprüfung und Datenqualität
Szenariovergleich einschließlich Case Rating und Befunden
Finanzierungsübersicht und Restschuld-Chart
Cashflowübersicht, Tabelle und Chart
Vermögensübersicht, Tabelle und Chart
Annahmenherkunft
Reportauswahl und Reportvorschau
Snapshot-Laden, Dirty-State und Speichern

Weitere offene Einzelentscheidungen¶

Die folgenden Entscheidungen werden nacheinander getroffen und anschließend in diesem Proposal dokumentiert:

2. State-Modell
   Welche Zustände und Daten enthält AnalysisState?
   Welche Stelle besitzt exklusiven Schreibzugriff?

3. View-Owner-Matrix
   Welches Modul besitzt welchen DOM-Zielbereich?
   Welche heutigen Nachbearbeitungsmodule entfallen oder werden zu reinen Hilfsfunktionen?

4. Render-Auslösung
   Direkte Controller-Aufrufe oder expliziter Subscriber-Vertrag?
   Welche Events bleiben zulässig?

5. Initial- und Dirty-Lifecycle
   Wie entstehen initial, calculated, dirty, loaded und failed ohne Scheinberechnung?

6. Globale Kompatibilität
   Welche window-Schnittstellen werden noch benötigt?
   Welche dürfen nur vorübergehend read-only bestehen?

7. Reporting-Grenze
   Wie erhält die Reportansicht einen expliziten State-Impuls ohne künstlichen Klick?
   Welche weitergehenden Änderungen verbleiben in ARCH-2026-002?

8. Migrationsfolge
   Welche kleinen, rückrollbaren Umsetzungsschritte werden festgelegt?

9. Versionierung
   Ist eine Erhöhung der Frontend-Engine-Version erforderlich?

Entscheidungsmehrwert¶

eindeutige Verantwortungsgrenzen
deterministischer Ergebnis-Lifecycle
kein falscher oder nur kurzzeitig sichtbarer Zwischenzustand
keine zeitabhängige Überschreibung derselben DOM-Ziele
kein künstlicher Klick als technische State-Schnittstelle
keine Rücklese fachlicher Werte aus formatiertem DOM
bessere Browser-, Integrations- und Regressionstests
weniger globale Kopplung
kontrollierbare Grundlage für Expert Mode und weiteren Reporting-Ausbau
keine zusätzliche Framework-Komplexität

Auswirkungen auf Architektur, Roadmap und Spezifikation¶

Architektur:

Orchestrierung, State und Rendering werden explizit getrennt.
Jeder Ergebnisbereich erhält eine eindeutige View-Eigentümerschaft.
Frontend-State erhält eine definierte Schreibstelle und einen dokumentierten Lifecycle.
DOM-Nachbearbeitung wird durch direkte View-Erzeugung ersetzt.

Roadmap:

keine neue Produktfunktion
technische Stabilisierung vor Expert Mode und weiterem Reporting-Ausbau
ARCH-2026-002 baut auf einer stabilen State- und Render-Orchestrierung auf

Spezifikation:

Calculation Interfaces, Projektstruktur, Frontend-MVP und Validierung sind nach Annahme zu präzisieren.
Keine Änderung von Finanzformeln oder fachlichen Datenverträgen.

Auswirkungen auf Formeln und KPIs¶

keine Änderung

Die spätere Umsetzung muss durch Regressionen nachweisen, dass identische PropertyInputs identische ScenarioResults, KPIs, Ratings und Snapshots erzeugen.

Auswirkungen auf Datenverträge und Versionen¶

keine Schemaänderung erwartet
keine Modellversionserhöhung erwartet
keine Änderung der gespeicherten PropertyRecord-Struktur erwartet
Engine-Version ist bei Änderung aktiver Frontend-Orchestrierung ausdrücklich zu prüfen

Ein rein internes State-Objekt ist zunächst kein persistierter Datenvertrag. Sobald es gespeichert, extern konsumiert oder als formaler API-Vertrag verwendet werden soll, ist eine separate Vertragsentscheidung erforderlich.

Auswirkungen auf UI, Reporting und Speicherung¶

sichtbare fachliche Ergebnisse sollen unverändert bleiben
Initialzustand entsteht ohne vorherigen Rechenlauf
ScenarioRating wird unmittelbar aus dem gespeicherten ScenarioResult gerendert
Investment Rating und Case Ratings bleiben getrennt
Reports erhalten einen expliziten Aktualisierungsimpuls aus demselben State
PropertyRecord-Speicherung bleibt bewusst und snapshotbasiert
Snapshot-Öffnen startet keine automatische Neuberechnung
Formularänderungen markieren den bestehenden AnalysisState als dirty

Die reine Reportdatengewinnung aus AnalysisResult oder PropertyRecord bleibt Gegenstand von ARCH-2026-002.

Auswirkungen auf Tests und Referenzfälle¶

Erforderlich:

DOM-Integrationstest des vollständigen Submit-Pfads
Initialzustand ohne vorherige Analyseveröffentlichung
explizite Tests der State-Übergänge initial -> calculated -> dirty
Snapshot öffnen -> loaded ohne Neuberechnung
loaded -> dirty nach Formularänderung
bewusste Neuberechnung -> calculated mit neuem AnalysisResult
Fehlerzustand ohne teilweise veraltete Darstellung
Nachweis, dass jedes Ergebnisziel nur einen schreibenden Owner besitzt
Base Case zeigt gespeichertes ScenarioRating unmittelbar
keine setTimeout-basierte Korrekturkette für fachliche Ergebnisbereiche
keine MutationObserver-basierte Korrekturkette für fachliche Ergebnisbereiche
Reportaktualisierung ohne künstlichen Klick
Charts verwenden Snapshotwerte statt gerenderter Tabellenwerte
Dirty-State und Speichersperre bleiben korrekt
bestehende Modell-, KPI-, Rating- und Snapshot-Regressionen bleiben grün
Browserabnahme ohne Console- und Netzwerkfehler

Die Tests sollen nicht nur auf Quelltextfragmente prüfen. Für State und Renderer sind Verhaltens- und Browsertests erforderlich.

Legacy- und Migrationsfolgen¶

keine Datenmigration erwartet
bestehende PropertyRecords dürfen nicht still verändert werden
bestehende globale window-Schnittstellen können vorübergehend als read-only Kompatibilitätsadapter bestehen
jede verbleibende globale Schnittstelle benötigt einen benannten Verbraucher und ein Entfernungskriterium
alte DOM-Korrekturmodule werden erst entfernt, wenn ihr Zielverhalten im neuen Owner nachgewiesen ist

Die Migration soll in kleinen, unabhängig testbaren Schritten erfolgen. Ein vollständiger gleichzeitiger Austausch aller State- und Rendererpfade ist zu vermeiden.

Risikoanalyse¶

Risiko der aktuellen Proposal-Aktualisierung¶

niedrig

Es werden nur der nicht verbindliche Vorschlag und seine Übersicht aktualisiert. Code, Spezifikationen, Datenverträge und produktive Laufzeit bleiben unverändert.

Risiko einer späteren technischen Umsetzung¶

mittel bis hoch

Die Änderung ist grundsätzlich umsetzbar. Sie ist jedoch kein einfacher mechanischer Refactor, weil viele Module denselben Endzustand gemeinsam erzeugen.

Besonders regressionsgefährdet:

Initialisierung der App
Submit-Validierung und bewusster Rechenlauf
Reihenfolge der AnalysisResult-Veröffentlichung
Dirty-State und Speichersperre
PropertyRecord öffnen und erneut berechnen
Zusammenfassung und Ratinganzeige
KPI-Gruppierung und Assessments
Szenariotabelle und Befunde
Plausibilitäts- und Datenqualitätsdarstellung
Restschuld-, Cashflow- und Vermögenscharts
Reportauswahl und Reportvorschau
CSS-Klassen und responsive Darstellung
Browser- und Timingverhalten

Mögliche Fehlerbilder:

leere oder nur teilweise gerenderte Ergebnisbereiche
veralteter AnalysisResult nach Formularänderung
falsche Zuordnung von Investment Rating und ScenarioRating
Report zeigt vorherigen Snapshot
Speichern bleibt fälschlich erlaubt oder wird fälschlich blockiert
Snapshot-Laden löst unbeabsichtigt eine Neuberechnung aus
Charts fehlen oder verwenden falsche Datenreihen
DOM-Observer erzeugen Schleifen während der Übergangsphase
bestehende Tests bleiben grün, obwohl Zwischenzustände fehlerhaft sind

Das Risiko wird beherrschbar, wenn die Umsetzung nach vollständiger Entscheidung in kleinen Schritten, mit vorheriger Baseline-Sicherung und Browserabnahme erfolgt.

Verbindliche Sicherungs- und Rückfallstrategie vor Umsetzung¶

Vor dem ersten Code-Commit zur Integration von ARCH-2026-001 sind mindestens folgende Sicherungen erforderlich:

1. Git-Baseline¶

aktuellen main-Commit festhalten
vollständigen Contract Check auf diesem Commit nachweisen
Backup-Branch vom verifizierten Commit anlegen
annotierten Git-Tag für pre-ARCH-2026-001 anlegen
keine Umsetzung direkt auf main

Empfohlene Benennung:

backup/pre-arch-2026-001
baseline/pre-arch-2026-001-YYYYMMDD

2. Deployment-Baseline¶

aktuell deployten Commit auf dem Server verifizieren
Docker-Compose-Status dokumentieren
öffentlichen App- und Dokumentations-Smoke-Test ausführen
Rollback auf den bestätigten Deployment-Commit vorbereiten

3. Lokale PropertyRecord-Snapshots¶

Da gespeicherte Objekte aktuell browserlokal sein können:

vor einem produktiven Deployment vorhandene lokale PropertyRecords exportieren oder sichern
keine Änderung bestehender gespeicherter Snapshots ohne explizite Migration
Öffnen, Anzeigen und erneutes Berechnen gesicherter Snapshots als Abnahmetest verwenden

4. Rückfallregel¶

Jeder Integrationsschritt muss separat rückrollbar bleiben.
Bei einer Regression wird der betroffene Schritt zurückgenommen,
nicht durch einen weiteren zeitversetzten Korrekturrenderer überdeckt.

Empfohlene Umsetzungsstruktur nach vollständiger Annahme¶

Noch nicht entschieden, aber zur Risikobegrenzung empfohlen:

Phase 0
  Baseline, Backup und vollständige Browserabnahme

Phase 1
  Owner-Matrix festlegen und je Zielbereich doppelte Schreibzugriffe beseitigen
  vorhandene globale Zustände zunächst kompatibel belassen

Phase 2
  explizites AnalysisState-Modul und Lifecycle einführen
  Initialberechnung mit anschließendem Reset entfernen

Phase 3
  künstliche Klicks, Timer- und MutationObserver-Korrekturen entfernen
  Reports explizit aus State aktualisieren

Phase 4
  verbleibende Kompatibilitätsadapter entfernen
  Spezifikation, Tests, Roadmap und Status synchronisieren

Diese Struktur wird erst nach den offenen Einzelentscheidungen verbindlich.

Offene Fragen¶

Welche Felder und Lifecycle-Zustände gehören in AnalysisState?

Soll der Controller die Renderer direkt aufrufen oder soll ein kleines explizites Subscriber-Modell verwendet werden?

Welche Module werden zu reinen View-Buildern oder Hilfsfunktionen, welche entfallen vollständig?

Welche globalen window-Schnittstellen werden tatsächlich noch von Meine Objekte, Marktmiete oder Legacy-Modulen benötigt?

Wie wird die Grenze zwischen ARCH-2026-001 und ARCH-2026-002 für Reportaktualisierung und ReportDataBuilder exakt gezogen?

Welche Engine-Version ist für die spätere Integration erforderlich?

Prüfergebnis¶

Die ursprüngliche Problemfeststellung ist weiterhin korrekt. Die aktuelle Implementierung zeigt jedoch eine deutlich breitere Abweichung als im ersten Proposal dokumentiert.

Nachgewiesen sind:

mehrfache schreibende Eigentümerschaft zentraler Ergebnisbereiche
zeitabhängige Timer- und MutationObserver-Ketten
verteilter globaler State ohne klaren Schreibvertrag
automatische Initialberechnung mit anschließendem Löschen
aus DOM zurückgelesene Ergebnisdaten
Tests, die überwiegend den final konvergierten Zustand statt die Orchestrierung prüfen

Die Erweiterung auf den vollständigen Einzelanalyse-State und die gesamte Render-Orchestrierung ist deshalb sachlich erforderlich.

Die technische Korrektur ist möglich, aber aufgrund der breiten Kopplung mittel bis hoch riskant. Sie darf erst nach Abschluss der offenen Entscheidungen, einer verifizierten Sicherung und einer kleinteiligen Integrationsplanung umgesetzt werden.

Entscheidung¶

Teilentscheidung 1 am 2026-07-07 bestätigt:

Variante B – ARCH-2026-001 umfasst den vollständigen Einzelanalyse-Ergebniszustand,
die Render-Orchestrierung und die eindeutige View-Eigentümerschaft.

Gesamtentscheidung: offen
Proposal-Status: under_review

Zieldokumente bei späterer Annahme¶

docs/specification/architecture/overview.md
docs/specification/architecture/project-structure.md
docs/specification/model-and-calculations/calculation-interfaces.md
docs/specification/data-quality-and-validation/validation.md
docs/specification/user-interface-and-reporting/frontend-mvp.md
docs/specification/user-interface-and-reporting/reporting.md, soweit Aktualisierungsgrenzen betroffen sind
docs/roadmap/roadmap.md
docs/roadmap/current-status.md

Integrationscommit¶

offen