Zum Inhalt

SPEC-2026-004 – Strukturierte Annahmenherkunft

Status: Entwurf
Proposal-Status: accepted
Kategorie: specification
Erstellt: 2026-07-06
Stand: 2026-07-06

Anlass

Die Annahmenherkunft wird derzeit als lange einspaltige Folge angezeigt. Dadurch nimmt der Bereich viel vertikalen Platz ein und fachlich zusammengehörige Annahmen sind nur schwer zu überblicken.

Ausgangsproblem

Annahmenherkunft:
  eine Karte pro Zeile
  keine fachlichen Gruppen
  hoher vertikaler Platzbedarf

Relevanter bestehender Stand

  • docs/specification/user-interface-and-reporting/reporting.md verlangt die transparente Anzeige von Annahmenwert und Herkunft.
  • frontend/assets/js/single-analysis-controller.js rendert Annahmenwert und origin in #assumption-list.
  • Die Herkunftswerte bleiben Bestandteil des gebundenen PropertyInput bzw. des aufgelösten Base-Szenarios.

Vorgeschlagene Änderung

  1. Auf Desktop werden vier Annahmenkarten nebeneinander angeordnet.
  2. Auf kleineren Bildschirmbreiten reduziert sich das Raster responsiv auf zwei bzw. eine Spalte.
  3. Die Annahmen werden fachlich gegliedert:
  4. Objekt & Vermietung
  5. Erwerb & Finanzierung
  6. Laufende Kosten & CAPEX
  7. Wachstum, Vergleich & Exit
  8. Jede Karte zeigt unverändert Bezeichnung, Wert und Herkunft.
  9. Unbekannte oder später ergänzte Annahmen erscheinen unter Weitere Annahmen und werden nicht ausgeblendet.

Entscheidungsmehrwert

Die Herkunft der Eingaben und Defaults kann schneller geprüft werden. Gleichzeitig bleibt der vollständige Audit-Trail sichtbar und der Dashboardbereich wird deutlich kompakter.

Auswirkungen auf Architektur, Roadmap und Spezifikation

Architektur: keine Änderung
Roadmap: keine Änderung
Reporting-Vertrag: keine inhaltliche Änderung
Frontend-Darstellung: Änderung

Auswirkungen auf Formeln und KPIs

Keine.

Auswirkungen auf Datenverträge und Versionen

PropertyInput: unverändert
AnalysisResult: unverändert
PropertyRecord: unverändert
Modellversion: unverändert
Engine-Version: unverändert
Schemaversionen: unverändert

Auswirkungen auf UI, Reporting und Speicherung

  • vier Spalten auf Desktop
  • sichtbare Gruppenüberschriften
  • responsive Darstellung
  • keine Speicherung von Layoutinformationen
  • keine Änderung der Herkunftscodes

Auswirkungen auf Tests und Referenzfälle

Zu prüfen:

  • alle derzeit gerenderten Annahmen bleiben sichtbar
  • Annahmen erscheinen in stabiler fachlicher Reihenfolge
  • unbekannte Labels werden unter Weitere Annahmen erhalten
  • Desktop-Raster verwendet vier Spalten
  • Browser- und Contract-Checks bleiben erfolgreich

Legacy- und Migrationsfolgen

Keine. Legacy-Snapshots ohne vollständigen PropertyInput behalten ihren bestehenden Hinweis.

Risiken und offene Fragen

Lange Werte oder Herkunftsbezeichnungen können einzelne Karten verbreitern. Das Raster verwendet daher minmax(0, 1fr) und erlaubt Zeilenumbruch innerhalb der Karten.

Prüfergebnis

Die Änderung wurde gegen Reporting-Vertrag, PropertyInput-Herkunft, Snapshot-Kompatibilität und die bestehende Renderer-Verantwortung geprüft. Sie ordnet ausschließlich vorhandene DOM-Karten neu an.

Entscheidung

Angenommen. Umsetzung als reine Darstellungsänderung ohne Modell-, Engine- oder Schemaversionserhöhung.

Zieldokumente

frontend/assets/js/assumption-origin-layout.js
frontend/assets/css/assumption-origin-layout.css
frontend/assets/js/legal-footer.js
scripts/check-assumption-origin-layout.mjs
.github/workflows/contract-check.yml
docs/changes/proposals/specification-additions.md

Integrationscommit

Offen bis erfolgreichem Contract Check und Browserreview.