PV-Standortertrag im Adressreport (#562)

Vertrag vor Implementierung festgelegt am 9. September 2026. Verbindliche Produktentscheidung: Variante A. Ausgangscommit: db2725a9d5c7c1b583a12517506b835fd6794b7d.

Neue Reportberechnung

Das Szenario pv-freiflaeche erhält pv_report_mode: "specific_yield_v1". cost ist null, cost_components ist leer. kennzahlen enthält ausschließlich spez_ertrag_kwh_pro_kwp, sofern ein positiver endlicher PVGIS-Standortertrag mit gespeicherter Quellenbezeichnung vorliegt; andernfalls fehlt kennzahlen. Keine Ableitung aus Parzellenfläche, keine 500-m²-Ersatzfläche, kein Konfigurationsertrag, kein Strompreis und keine Gesamtenergie oder Investition. Das allgemeine optionale Zahlenobjekt und nullable Kostenfeld bleiben erhalten. Verbraucher müssen fehlende Kennzahlen behandeln und dürfen sie nicht als null Euro oder null kWh interpretieren.

Der PVGIS-Snapshot unter solar speichert zusätzlich systemverlust_pct und modell_leistung_kwp (1 kWp im aktuellen Adapter). Die schon bestehenden Neigungs-, Azimut-, Datenbank- und Quellenstandfelder bleiben erhalten. quelle_stand bezeichnet den Abfragetag, nicht das Ende der Klimazeitreihe.

Historische Reports und Exporte

Keine Migration, keine Neuberechnung, kein Schreiben beim Lesen. GET nach ID und Roh-JSON-Export reichen den gespeicherten Snapshot unverändert weiter. MCP generate_report reicht neue API-Snapshots unverändert weiter; report_summary ergänzt solar und den PV-Modus, hält PV-Kosten neutral. Die lesbare Skill-Ausgabe unterdrückt historische PV-Kosten und Narrative; --json behält den Rohdatensatz. export_report liefert Permalink/PDF zum Snapshot. Fehlendes pv_report_mode bedeutet Altvertrag: alte kWp-/kWh-/Eurofelder können noch enthalten sein. Sie dokumentieren historische unbestätigte Modellwerte und sind keine aktuelle Standortpotenzialempfehlung. API-Konsumenten sollen für Standortkennzahlen solar verwenden und die Semantik explizit prüfen.

Web, PDF und Karte sind eine gemeinsame sichere Sicht auf den Snapshot: PV-Kosten, Komponenten, Gesamtkennzahlen und historische freie PV-Narrative werden ausgeblendet, auch in Vergleichstabellen. Das verändert keine gespeicherten Daten. Es werden nur vorhandene gültige Standortwerte angezeigt. Fehlende Systemverluste, Neigung, Azimut, Modellleistung, Quelle oder Quellenstand heißen ausdrücklich „Nicht gespeichert“; keine heutige 14-%-Annahme im Altbestand. Fehlender oder ungültiger Ertrag heißt „Nicht verfügbar“, niemals 0.

Die Kartenanzeige benennt den Standortertrag; eine Parzellenmarkierung dient nur der Orientierung und behauptet keine nutzbare Belegungsfläche. Ohne verwendbare Kartengeometrie gibt es keinen Sprung auf eine nicht vorhandene Ebene.

Rechner und Scope

Der Link /werkzeuge/pv-ertrag überträgt keine Adresse, Koordinate oder Anlagenleistung. Der Nutzer öffnet ihn bewusst und gibt seine Leistung im bestehenden Rechner an. Dessen eigene Berechnung bleibt erhalten. Szenarioampeln, Förderregeln, andere Kostenmodelle, Premium-Google-Solar und PDF/UA-Freigaben werden nicht geändert. #291 bleibt offen.

Abnahme

Rote/grüne Regressionen für 26.483 m², fehlende Fläche, fehlendes Solar, teilweise fehlende Annahmen, unveränderte Altbestände und neue API-Semantik; Web/PDF/Karte, Rechner, responsive Bedienung und visuell gelesene PDF-Seiten. CI/Preview, unabhängiges PM-MergeGo, Main-CI, Deployment und Live-Readback sind im Issue/PR commitgebunden festgehalten. Abgeschlossen am 10. September 2026: PR #566 (Merge-Commit 9fa468a14225e303685c69d3216c2e5bcd421f82), Produktions- deployment dpl_6xYFyqDfGTjtV5H73fRcCCCU2k63, Live-Abruf des bestehenden Reports als JSON, HTML und PDF mit 200; das JSON war byteidentisch zur Vorher-Referenz, das PDF nannte den PVGIS-Standortertrag und keine alten Parzellen-/Euro-Angaben (Abschlusskommentar in #562). Grenzen bleiben: Es gibt keinen Nachweis einer neuen positiven Live-PVGIS-Persistenz, und der mobile Fehler #557 ist separat.

Lokaler Prüfstand vor PR

• Node 24.19.0: 3.654 Tests bestanden, 43 bewusst übersprungen; Typecheck, ESLint, Content-/SEO-Audit und Produktionsbuild erfolgreich.
• Schulflächen-/Fallback-/fehlendes-Solar-Regression zuerst rot, danach grün. Historische Webansicht, Kartendaten, OpenAPI, Snapshot-GET, MCP-Kurzfassung und Skill-Ausgabe geprüft; rekursiv eingefrorene Eingaben bleiben unverändert.
• Drei neue Browserfälle bei 390/1.440 px: historischer Report, neuer Snapshot, fehlendes Solar, kein horizontaler Überlauf, Tastaturwechsel zum Rechner ohne URL-Parameter. Das bestehende 8-kWp-Rechnerbeispiel ist unabhängig vom Report; individuelle Eingabe bleibt editierbar. Acht bestehende Rechnerfälle bestehen einschließlich erfolgreicher Rechnung, Fehler- und Freigabepfaden.
• Vier synthetische PDF-Profile: historisch, neu, fehlende Daten und überlange Quelle. Alle Seiten gerastert; PV-Karten, Einheiten, Annahmen und Seitenwechsel tatsächlich visuell gelesen. Wortgeometrie und PDF-Rechnerlink geprüft.
• Der Langquellentest reproduzierte abgeschnittenen Inhalt wegen wrap=false. PV-Karten können nun umbrechen; derselbe Test findet das Quellenende und den Rechnerlink auf gültigen Seiten. Andere Szenariokarten bleiben ungeteilt.
• Bestehende Poppler- und Entscheidungsseiten-Layoutregressionen bestehen. Dies ist keine PDF/UA- oder fachliche Freigabe.

Die commitgebundene vollständige CI, das abschließende READY-Preview, das unabhängige PM-MergeGo und der Produktions-Readback sind im PR und in #562 dokumentiert (siehe Abschnitt „Abnahme“). Keine Neuberechnung oder Mutation alter Produktionsreports, keine neuen personenbezogenen Produktionsreports.

Ein zusätzlicher negativer Narrativtest belegt: Auch wenn das Sprachmodell unaufgefordert pv-freiflaeche zurückgibt, wird dieser Text vor der Snapshot-Assemblierung verworfen. Der Fall war rot und ist nach dem expliziten PV-Ausgabefilter grün; zusätzlich verwirft der Builder solche Texte vor dem serialisierbaren Snapshot. Beide Grenzfälle sind separat rot/grün getestet; andere Szenario-Narrative bleiben unverändert.