XOLIB SCORE — ERGÄNZUNGS-PROMPT¶
Fehlende Teile aus v2-Spezifikation · Aufbauend auf bereits implementiertem Score-Feature¶
KONTEXT¶
Der Xolib Score ist bereits implementiert (Prisma-Modelle, Calculator, Background Job, API-Endpunkte, UI-Komponenten). Dieser Prompt ergänzt zwei Teile die in der ursprünglichen Implementierung nicht vollständig abgedeckt wurden:
- Explizite Kategorie-Zuordnung — welche neuen Datenpunkte fließen in welche Score-Kategorie
- V1/V2/V3 Versionierungs-Badge — UI-Element im ScoreFactorDrawer das zeigt ob ein Datenpunkt heute verfügbar, in 6-12 Monaten oder erst langfristig messbar ist
Lies zuerst CLAUDE.md und MEMORY.md. Mach dich mit dem bereits implementierten Score-Code vertraut bevor du Änderungen vornimmst.
ERGÄNZUNG 1 — EXPLIZITE KATEGORIE-ZUORDNUNG¶
Die neuen Datenpunkte müssen explizit den richtigen Kategorien zugeordnet werden. Prüfe in src/lib/score/calculator.ts ob diese Zuordnung korrekt implementiert ist. Falls nicht, korrigiere sie:
KATEGORIE: SUBSTANZ (Gewicht 25%)¶
Bestehende Faktoren bleiben unverändert. Zusätzlich neu einbeziehen:
Energieausweis als Substanz-Proxy (aus Dokument-Vollständigkeit)
- Faktor-Key: substanz_energieausweis_vorhanden
- Gewicht innerhalb Kategorie: 10%
- Logik: Energieausweis vorhanden + gültig = 100 · abgelaufen = 20 · fehlt = 0
- Datenquelle: Documents-Modell (type = 'energy_certificate')
- Begründung: Energieausweis ist gesetzliche Pflicht (§16 GEG) und direktes Substanz-Signal
Wartungsvertragsdokumentation
- Faktor-Key: substanz_wartungsvertraege
- Gewicht innerhalb Kategorie: 10%
- Logik: Alle relevanten Wartungsverträge dokumentiert = 100 · je fehlender Kategorie -25 Pkt
- Kategorien: Heizungsinspektion, Aufzug (nur wenn vorhanden), Rauchwarnmelder, Feuerschutz
- Datenquelle: Documents-Modell (type IN ['maintenance_contract', 'inspection_report'])
KATEGORIE: TECHNOLOGIE (Gewicht 25%)¶
Bestehende Faktoren bleiben. Zusätzlich:
Realer Energieverbrauch (aus EnergyReading)
- Faktor-Key: technologie_energie_verbrauch_kwh
- Gewicht innerhalb Kategorie: 35% (ersetzt teilweise den Energiezertifikat-Proxy)
- Normalisierung: <50 kWh/m²/Jahr = 100 · <80 = 85 · <120 = 65 · <160 = 40 · >160 = 15
- Wenn keine EnergyReadings vorhanden: Wert = 50 (neutral), dataFreshness = 'missing', voller Beitrag zur Konfidenz-Reduktion
- Datenquelle: EnergyReading-Modell, aggregiert auf Jahresbasis
Verbrauchstrend
- Faktor-Key: technologie_energie_trend
- Gewicht innerhalb Kategorie: 15%
- Normalisierung: >10% Reduktion/Jahr = 100 · stabil = 60 · Anstieg = 20
- Nur berechenbar wenn EnergyReadings über mindestens 24 Monate vorhanden
- Wenn nicht berechenbar: dataFreshness = 'missing', neutraler Wert 50
KATEGORIE: ERTRAG (Gewicht 25%)¶
Bestehende Faktoren bleiben. Zusätzlich:
BK-Abweichungsquote (aus OperatingCost)
- Faktor-Key: ertrag_bk_abweichung
- Gewicht innerhalb Kategorie: 15%
- Normalisierung Nachzahlungsquote: <10% Nachzahler = 100 · <25% = 80 · <40% = 55 · <60% = 30 · >60% = 0
- Normalisierung Abweichungshöhe: <50 EUR/Einheit = 100 · <100 = 80 · <200 = 55 · <400 = 25 · >400 = 0
- Gesamtfaktor: Durchschnitt beider Werte
- Wenn keine Abrechnung vorhanden: dataFreshness = 'missing', neutraler Wert 50
- Datenquelle: OperatingCost-Modell
Zahlungstrend
- Faktor-Key: ertrag_zahlung_trend
- Gewicht innerhalb Kategorie: 10%
- Bereits in ursprünglichem Prompt spezifiziert — sicherstellen dass es in ERTRAG landet, nicht eigenständig
Chronische Zahler
- Faktor-Key: ertrag_chronische_zahler
- Gewicht innerhalb Kategorie: 10%
- Bereits spezifiziert — sicherstellen dass in ERTRAG
KATEGORIE: COMPLIANCE (Gewicht 15%)¶
Bestehende Faktoren bleiben. Zusätzlich:
Vollständige Dokument-Checkliste
- Faktor-Key: compliance_dokumente_vollstaendig
- Gewicht innerhalb Kategorie: 30%
- Pflichtdokumente je Property prüfen:
- Energieausweis (§16 GEG) — immer Pflicht
- Gebäudehaftpflichtversicherung — immer Pflicht
- Wohngebäudeversicherung — immer Pflicht
- Freistellungsbescheinigungen (§48 EStG) — Pflicht je aktivem Dienstleister
- Übergabeprotokolle — Pflicht je aktivem Mietverhältnis
- Aufzug-TÜV — Pflicht wenn hasElevator = true
- Normalisierung: 100% vorhanden = 100 · je fehlendem Pflichtdokument -15 Pkt · minimum 0
- Datenquelle: Documents-Modell + ServiceProvider + Tenancy + Property.hasElevator
Abrechnungspünktlichkeit
- Faktor-Key: compliance_bk_puenktlichkeit
- Gewicht innerhalb Kategorie: 15%
- Normalisierung: Fristgerecht (innerhalb 12 Monate nach Abrechnungsjahr) = 100 · <30 Tage verspätet = 60 · <90 Tage = 20 · >90 Tage oder fehlend = 0
- Datenquelle: OperatingCost-Modell (Abrechnungsdatum vs. gesetzliche Frist §556 BGB)
KATEGORIE: INSTANDHALTUNG (Gewicht 15%)¶
Bestehende Faktoren bleiben. Zusätzlich:
Handwerker-Durchschnittsbewertung
- Faktor-Key: instandhaltung_handwerker_rating
- Gewicht innerhalb Kategorie: 20%
- Normalisierung: Ø5,0 Sterne = 100 · Ø4,5 = 85 · Ø4,0 = 70 · Ø3,5 = 50 · <3,0 = 0
- Mindestanzahl: 5 Bewertungen erforderlich, sonst neutraler Wert 50
- Datenquelle: WorkerRating-Modell, gefiltert auf Property, letzte 12 Monate
Nachbearbeitungsquote
- Faktor-Key: instandhaltung_nachbearbeitung
- Gewicht innerhalb Kategorie: 15%
- Normalisierung: 0% = 100 · <5% = 80 · <10% = 55 · <20% = 25 · >20% = 0
- Datenquelle: WorkerRating.reworkRequired
Kommunikations-Sentiment
- Faktor-Key: instandhaltung_sentiment
- Gewicht innerhalb Kategorie: 15%
- Normalisierung: direkter NLP-Score 0-100 aus Ticket.sentimentScore
- Durchschnitt aller Ticket-Sentiments der letzten 90 Tage
- Wenn keine Tickets: neutraler Wert 70
- Datenquelle: Ticket.sentimentScore (berechnet via analyzeSentiment beim Ticket-Erstellen)
ERGÄNZUNG 2 — V1/V2/V3 VERSIONS-BADGE IM SCOREFACTORDRAWER¶
Hintergrund¶
Jeder Score-Faktor hat eine Datenqualitäts-Stufe: - V1 — heute verfügbar: manuell eingegeben oder aus bestehenden Xolib-Daten automatisch berechnet - V2 — in 6-12 Monaten: erfordert API-Integrationen (Techem/Ista) oder NLP-Verarbeitung - V3 — langfristig (2+ Jahre): IoT-Sensoren, externe Datenquellen, eigenes KI-Modell
Diese Information ist bereits als dataVersion Feld im ScoreFactor-Modell gespeichert ('v1_manual' | 'v2_auto' | 'v3_iot'). Sie muss jetzt im UI sichtbar gemacht werden.
Implementierung: VersionBadge Komponente¶
Erstelle src/components/score/VersionBadge.tsx:
interface VersionBadgeProps {
version: 'v1_manual' | 'v2_auto' | 'v3_iot'
showLabel?: boolean // true = "V1 — Sofort verfügbar", false = nur "V1"
}
Visuelle Gestaltung: - V1 — grünes Badge: Hintergrund #D8F3DC, Text #2D6A4F, Label: "V1 — Verfügbar" - V2 — gelbes Badge: Hintergrund #FFF9DB, Text #92400E, Label: "V2 — In Entwicklung" - V3 — lila Badge: Hintergrund #F3E8FF, Text #6B21A8, Label: "V3 — Zukünftig" - Kein Emoji — nur Text-Badge mit farbigem Hintergrund und passendem Lucide-Icon: - V1: CheckCircle Icon - V2: Clock Icon - V3: Sparkles Icon (oder Zap wenn Sparkles nicht verfügbar in lucide-react@0.383.0)
Einbau in ScoreFactorDrawer¶
In der Faktor-Tabelle des ScoreFactorDrawers: je Faktor-Zeile ein VersionBadge rechts neben dem Faktor-Namen.
Zusätzlich: Drei-Spalten-Übersicht oben im Drawer (vor der Faktor-Liste):
┌─────────────────┬─────────────────┬─────────────────┐
│ V1 — Verfügbar │ V2 — Entwicklung│ V3 — Zukünftig │
│ X Faktoren │ Y Faktoren │ Z Faktoren │
│ grüner Rand │ gelber Rand │ lila Rand │
└─────────────────┴─────────────────┴─────────────────┘
Klick auf eine Spalte: filtert die Faktor-Liste auf diese Version.
Einbau in ScoreCategoryGrid¶
Auf jeder Kategorie-Karte: kleine Zusammenfassung unter dem Score: - "X von Y Faktoren vollständig (V1)" - Wenn V2/V3-Faktoren fehlen: "Bei vollständiger Integration erreichbar: +Z Pkt"
dataVersion Mapping im Calculator¶
Sicherstellen dass calculator.ts beim Erstellen der ScoreFactors den richtigen dataVersion-Wert setzt:
// V1 — sofort verfügbar (aus bestehenden Daten oder manuell)
'substanz_baujahr' → 'v1_manual'
'substanz_sanierung' → 'v1_manual'
'substanz_dach' → 'v1_manual'
'substanz_fenster' → 'v1_manual'
'substanz_heizungsalter' → 'v1_manual'
'substanz_energieausweis' → 'v1_manual'
'substanz_wartungsvertraege' → 'v1_manual'
'technologie_energiezertifikat' → 'v1_manual'
'technologie_heizungstyp' → 'v1_manual'
'technologie_smart_infra' → 'v1_manual'
'ertrag_belegungsquote' → 'v1_manual'
'ertrag_zahlungsverspaetung' → 'v1_manual'
'ertrag_leerstandstage' → 'v1_manual'
'ertrag_zahlung_trend' → 'v1_manual'
'ertrag_chronische_zahler' → 'v1_manual'
'ertrag_bk_abweichung' → 'v1_manual'
'compliance_freistellungen' → 'v1_manual'
'compliance_versicherung' → 'v1_manual'
'compliance_dokumente' → 'v1_manual'
'compliance_bk_puenktlichkeit' → 'v1_manual'
'instandhaltung_loesungsrate' → 'v1_manual'
'instandhaltung_loesungszeit' → 'v1_manual'
'instandhaltung_kritisch' → 'v1_manual'
'instandhaltung_praevention' → 'v1_manual'
'instandhaltung_nachbearbeitung'→ 'v1_manual'
// V2 — erfordert Entwicklung (API-Integration oder NLP)
'technologie_energie_verbrauch' → 'v2_auto' // Techem/Ista API
'technologie_energie_trend' → 'v2_auto' // Techem/Ista API
'instandhaltung_handwerker' → 'v2_auto' // WorkerRating muss erst befüllt werden
'instandhaltung_sentiment' → 'v2_auto' // NLP-Verarbeitung
// V3 — langfristig
'technologie_energie_anomalien' → 'v3_iot' // Smart Meter Echtzeit
'substanz_digitaler_pass' → 'v3_iot' // EU-Gebäudepass ab 2030
ERGÄNZUNG 3 — KONFIDENZ-ANZEIGE IM SCOREHERO VERBESSERN¶
Der ScoreHero zeigt bereits einen Konfidenz-Wert. Ergänze folgende visuelle Logik:
Konfidenz-Aufschlüsselung: Tooltip oder ausklappbarer Bereich unter dem Konfidenz-Badge zeigt: - "X von Y Faktoren vollständig gemessen" - "Fehlende Faktoren: [Liste der fehlenden Faktor-Labels]" - "Bei vollständiger Datenbasis erreichbar: Score XX (aktuell: YY)"
Konfidenz-Schwellen: - ≥80%: grünes Badge "Verifiziert" + Shield-Icon - 60–79%: gelbes Badge "Unvollständig" + AlertCircle-Icon - 40–59%: oranges Badge "Eingeschränkt" + AlertTriangle-Icon - <40%: rotes Badge "Schätzung" + XCircle-Icon
Wichtig: Score-Zahl selbst bleibt immer sichtbar und gleich groß — Konfidenz ist eine separate Dimension, sie beeinflusst nicht die Darstellungsgröße des Scores.
ABSCHLUSS¶
Nach Implementierung: 1. Prüfen ob alle dataVersion-Werte korrekt in ScoreFactors gespeichert werden 2. VersionBadge in ScoreFactorDrawer und ScoreCategoryGrid sichtbar 3. Konfidenz-Aufschlüsselung im ScoreHero funktioniert 4. CLAUDE.md aktualisieren: Ergänzungen dokumentieren 5. MEMORY.md aktualisieren: V1/V2/V3-Mapping als implementiert markieren
Ergänzungs-Prompt zu Xolib Score v2 — aufbauend auf bestehendem Score-Feature