Produktstatus

Gültigkeitsstand: 26. August 2026. Dieses Dokument beschreibt den implementierten und im Repository überprüfbaren Ist-Stand. Es ist die kanonische Statusquelle für Produktfunktionen und UI-Routen.

Für die Einordnung gelten vier feste Begriffe:

Live: implementiert und im aktuellen Produktpfad nutzbar.
Live mit Grenze: implementiert, aber mit einer ausdrücklich genannten fachlichen, räumlichen oder betrieblichen Einschränkung.
Testmodus: technisch integriert, aber nicht für reale Transaktionen oder einen öffentlichen Verkauf freigegeben.
Geplant: nicht implementiert; steht ausschließlich in der Roadmap.

Historische Pläne und Gesprächsnotizen bleiben als Entscheidungsbelege erhalten, sind aber keine Statusquelle. Bei Widersprüchen hat dieses Dokument Vorrang vor älteren Abschnitten im Briefing und vor historischen ADRs.

Produktkern

Zweites eigenständiges öffentliches Werkzeug: Der Standort-Check unter /werkzeuge/standort-check liefert einen matrixgebundenen Datenpass mit sieben Quellenkarten. Er ist vom persistierten /report getrennt; seine konkrete Abdeckung, Rechte-, Freshness-, Pilot- und Datenschutzgrenzen sind im öffentlichen Standort-Check-Vertrag dokumentiert.

Fähigkeit	Status	Aktueller Umfang und Grenze	Nachweis
Öffentlicher Werkzeug-Hub	Live	`/werkzeuge` zeigt ausschließlich Registry-Einträge mit sichtbarem Status, Abdeckung und Quelle. Geplante Werkzeuge sind getrennt und nicht als nutzbar verlinkt.	`app/werkzeuge/page.tsx`, `lib/tools/registry.ts`
PV-Ertragsrechner	Live mit Grenze	Für ganz Österreich geprüftes, kostenloses PVGIS-5.3-Standortmodell für 0,5–100 kWp. Das Release-Gate ist mit 45/45 öffentlichen Referenzpunkten, fünf je Bundesland, bestanden; die private Share-Ansicht überträgt weder Adresse noch Koordinate und fragt PVGIS beim Öffnen nicht erneut ab. Optimale Ausrichtung bleibt ein Potenzialmodell; keine Dachvermessung, Verschattungs-, Statik-, Netz-, Tarif- oder Förderprüfung. Adresse, Koordinate und Ergebnis werden serverseitig nicht persistiert.	`/werkzeuge/pv-ertrag`, `/werkzeuge/pv-ertrag/teilen`, `docs/evidence/pv-release-45-points-2026-08-03.md`, `docs/evidence/pv-tool-02-production-2026-08-03.md`
Kennungsfreie Werkzeugmetriken	Live mit abgeschlossener Baseline	MET-01 misst für den PV-Rechner ausschließlich atomare Tagesaggregate und einen tag- und regionsfreien 14-Tage-Ausgangswert. Der fail-closed Produktionsreadback vom 18. August bestätigt 14/14 vollständig abgeschlossene Messtage, vorhandene Funnel- und Serverdaten, bestandene Integrität, vollständig zugeordnete Kosten und den stabilen Snapshot-SHA-256 `2fe33f3716f640c4ca7c847d701359f827ad5613126c349df71129aa4d51a997`. Die Stichprobe von zwei Starts, einem Abschluss und drei erfolgreichen Serverläufen ist der ehrliche Ausgangswert, keine Wirkungsbehauptung.	`/admin/metrics`, `/api/v1/admin/metrics`, `MET-01-D0`, `MET-02-Abschluss`
Source-/Release-Ledger	Live mit Grenze	FND-02 ist produktiv abgeschlossen; FND-03 bindet den BEV-Punkt-Lookup, #376 den BMLUK-Brachflächen-Potenzialhinweis, #404 den SPARTACUS-v3-Datensnapshot, #427 die Erdbeben-Ortstabelle, #454 die Local Climate Zones, #439 den historischen GeoSphere-Hitzelayer, #324 Umgebungslärm und #351 den Altlastenportal-WFS an qualifizierte Releases. Zwölf der 50 Katalogquellen sind release-gebunden, 38 bleiben ausdrücklich `legacyUnverified`. Der Runtime-Modus bleibt für diese feste Legacy-Positivliste bewusst `shadow`, ohne ihr dadurch Qualität oder Rechte zu attestieren; unbekannte Slugs/Fähigkeiten und Google Solar bleiben geschlossen.	`FND-02-Nachweis`, `FND-03-Nachweis`, `Brachflächen-Nachweis`, `SPARTACUS-v3-Aktivierung`, `HORA-Hitzelayer-Aktivierung`, `Lärminfo-Aktivierung`, `Erdbeben-Rechte-Review`, `DATA-02-Betriebsstatus`, `docs/decisions/0043-source-release-ledger.md`
Umgebungslärm	Live mit fachlicher Grenze	#324 bindet acht strategische Lärmkarten der Runde 2022 für Straße, Schiene, Flug und Industrie/IPPC atomar an Report-Lookup, Kartenbild und Legende. Release `63575c23-0121-506d-8baa-210a82dd957f` steht auf Pointer-Version 1; sechs Pflichtchecks, ein neutraler No-Hit, echte Flug- und Industrie/IPPC-Treffer, beide Kartenebenen, Legenden, Web-Permalink und PDF sind produktiv rückgelesen. Die Anzeige bleibt ein Screening berechneter Hauptquellenpegel in vier Metern Höhe, keine Messung und kein Gutachten; IPPC ist nur in ausgewiesenen Ballungsräumen kartiert. Der erste planmäßige Acht-Stunden-Renewal ist noch nicht als ausgeführt belegt.	`Produktionsnachweis`, `Rechteprüfung`, `/api/v1/data-sources/laerm/provenance`
Coverage-/Rechtematrix	Live mit Grenze	Für alle neun Bundesländer wird unter `/docs/data-sources` und als API-v1-Vertrag ein maschinenlesbarer Status ausgewiesen. Der produktiv rückgelesene, mit #351 aktualisierte Vertrag umfasst 34 für `pv-yield` und `site-check` relevante Public-Display-Lanes und 306 Zellen: 54 `available`, 11 `availableWithGaps`, 18 `gated`, 16 `outsideCoverage` und 207 `notConfigured`. `altlasten/report_lookup` bleibt ausschließlich Teil des Mehrwert-Berichts und ist deshalb bewusst keine `site-check`-Lane. Nur aktive Releases mit exaktem Coverage-, Rechte-, Distributions-, Fähigkeits-, Freshness-, Quality- und Consumer-Nachweis öffnen eine Zelle. 9/9 bedeutet dokumentiert, nicht flächendeckend verfügbar; Exportzwecke sind aus v1 ausgeschlossen.	`Erster Produktionsnachweis`, `DATA-02-Readback 17.08.`, `Altlasten-Cutover`, `/api/v1/data-sources/coverage-matrix`, `v1-Vertrag`
Pointergebundener Betriebsstatus	Live mit Grenze	`/admin/data-sources` und `GET /api/v1/admin/data-sources` trennen den neuesten technischen Lauf vom Betriebsnachweis des aktiven Releases. Der stündliche `monitor-data-source-drift` prüft quellspezifische Frische-, Coverage-, Zeilenzahl- und Qualitätsgrenzen; bekannte Teilabdeckung und freigegebene Warnungen bleiben eine akzeptierte Baseline. Zustände `fresh`, `due`, `stale`, `failed` und `unknown`, deduplizierte Alert-Übergänge sowie Zustellfehler bleiben sichtbar. Der Monitor verändert keinen Release oder Active Pointer; die bestehende Resend-Testmodusgrenze gilt weiter.	`ADR-0047`, `ADR-0048`, `DATA-02-Nachweis des ersten Slice`, Issue #493
Parzellenidentität / BEV-Pilot	Live mit enger Grenze	FND-03 ist für `bev-gaenserndorf-pilot-v1` abgeschlossen: Migrationen `0041`/`0043`, stabile interne `parcel_uid`, Originalaliases, release-gebundene Versionen und Quarantäne; der Active Release `655a7dc3-1f7a-5bdc-a329-d73f1c458320` steht über Run 57 und Pointer 2 weiterhin ausschließlich auf `public_display/point_lookup`. Quellenstand, Umfang und Qualitätsgrenze bleiben unverändert: 2026-04-01, 29.746 veröffentlichte und 15 quarantänisierte Geometrien. Der separate ADR-0055-Export-Pointer ist mit 28.535 vollständig umschlossenen Originalpolygonen produktiv aktiviert; GeoJSON/PDF/DXF sind release-gebunden, DXF wurde mit Dark Deploy, positivem und negativem Readback, GDAL-Parserprüfung und Rollback kontrolliert live geschaltet. Eigentümerdaten und nationale Katasterabdeckung bleiben ausgeschlossen.	`ADR-0044`, `ADR-0055`, `FND-03-Produktionsnachweis`, `Export-Aktivierung`, `DXF-Produktionsnachweis`
Brachflächen-Potenzial	Live mit fachlicher Grenze	#376 ist für `at-national-v1` produktiv abgeschlossen: aktiver v2-Release `57e2e12b-e240-5287-a0c4-ee1edba795df`, Run 56, Pointer 2, Modellstand 2024, 3.705 veröffentlichte und 17 quarantänisierte Quellgeometrien. Web, PDF, API, Renewal und Monitor sind rückgelesen. Ein Treffer ist ausschließlich ein KI-Potenzialhinweis, kein amtlicher Brachflächenbefund und keine Aussage zu Eigentum, Verfügbarkeit, Altlasten, Widmung oder Bebaubarkeit. Coverage bleibt wegen der Quarantäne und dieser Aussagegrenze `partial`; Geometrieexport ist nicht freigegeben.	`Brachflächen-Produktionsnachweis`, `ADR-0045`
Altlastenportal-Screening	Live mit Grenze	#351 bindet WFS 2.0.0 und Release `8ed8d136-f3f8-5a78-946b-4b419a050269`, Pointer 1, an `altlasten_current`. Scope-Zähler: 1.794/372/19/1.403. Die Geometrien bleiben in `EPSG:31287`; nur der Adresspunkt wird mit `ST_Covers` plus 1-km-Nähe geprüft. `UBAID` ist eindeutig, `ALTNR` nicht. API-Hit und No-Hit, Web, PDF und Headless-Ausgabe wurden mit #525/#526 produktiv rückgelesen; der Near-Hit-Gegencheck zeigt 703 m und UBAID `72113`. `retrieved_at` ist nur technisch, `source_vintage=null`. Pointer-, Frische-, Rechte-, Qualitäts- oder Scopefehler degradieren. Nur `public_display/report_lookup`, keine OGD-/CC-Behauptung und kein Rohgeometrieexport; Nicht-Listung garantiert keine Schadstofffreiheit.	`Produktionsnachweis`, `ADR-0058`, `Rechteprüfung`
SPARTACUS-v3-Klimaprofil	Live mit fachlicher Grenze	Der qualifizierte 2025-Jahressnapshot ist über Release `81ef8803-2d64-5d30-9d7f-cd526ce57e69` und Pointer 1 produktiv aktiviert: 106.610 unveränderliche 1-km-Zellen, Österreich-Coverage und inhaltsadressierte Manifest-/Artefakt-/Row-Bindung. Web, API und PDF lesen atomar denselben Provenienz-Tupel; v2.1-, `geosphere_cache`- und Provider-Live-Fallback sind für neue Reports gesperrt. Der tägliche read-only Monitor darf niemals automatisch publizieren, aktivieren oder zurückrollen. Die Werte bleiben regionale Klimaindikatoren, keine Messung oder Prognose für eine einzelne Parzelle.	`Produktionsnachweis`, `ADR-0046`
Erdbebenzone	Live mit fachlicher Grenze	Der release-gebundene Snapshot enthält 2.188 veröffentlichte Orte und alle fünf ÖNORM-Zonen für Österreich. Der Report zeigt neutral Zone, Herkunftsort, PLZ und Entfernung; gespiegelt wird die Ortstabelle, nicht das generalisierte Zonenpolygon. `EGA` und `PGA` bleiben uninterpretiert, die Zone erhält keine Ampel und keine Kostenwirkung. Ein Betriebs- oder Coveragefehler darf nie als fehlende Erdbebenzone erscheinen.	`Daten- und Betriebsbeschreibung`, `Rechte-Review`, `CHANGELOG.md`
Wissensbereich	Live mit Grenze	Sechs veröffentlichungsgegatete Fachbeiträge mit Primärquellen, Methodik, menschlichem Schlussreview, KI-Transparenz, Korrekturpfad und Wiedervorlage; RSS, BlogPosting-Daten, Sitemap und `llms.txt` enthalten ausschließlich freigegebene Artikel. CON-02 und das Sechs-Live-Beiträge-Gate sind abgeschlossen. Keine automatisierte Content-Farm, keine Publikation ohne menschliche Freigabe und aktuell keine offenen Entwürfe.	`CON-01-Produktionsnachweis`, `CON-02-Freigabe`, `/wissen`, `lib/content/articles.ts`, `/wissen/feed.xml`
Öffentliche Rechtsinformationen	Live mit Grenze	`/impressum` nennt die Atelier Deubner Lopez ZT OG und die Ostheimer OG als gemeinsame Betreiber. `/datenschutz` weist beide Unternehmen als gemeinsame Verantwortliche aus und beschreibt die tatsächlichen Datenflüsse, Empfänger, Speicherdauern und Betroffenenrechte. Formales Gate offen: Art.-26-Vereinbarung, nicht öffentlich ausgewiesene Beteiligungs-/Stimmrechtsverhältnisse der Atelier Deubner Lopez ZT OG und #290.	`app/impressum/page.tsx`, `app/datenschutz/page.tsx`, `lib/legal/operators.ts`
Adresse prüfen	Live mit Grenze	Anonyme Report-Erstellung ohne Login. Der release-gebundene BEV-Punkt-Lookup besitzt nur innerhalb der belegten Gänserndorf-Pilot-BBox qualifizierte Snapshot-Coverage; außerhalb bleibt der getrennte WMS-Identitätspfad ein eigener Legacy-Fallback ohne qualifizierte Snapshot-Geometrie. Der umfassende Standort-Report ist weiterhin auf Niederösterreich ausgerichtet.	`/`, `/report`, `app/report/page.tsx`, `docs/REPORT-SPEC.md`
Report	Live mit Grenze	Widmung, Klima, Altlasten-Indikation, sechs Nutzungsszenarien, Förderhinweise, zusätzliche Datenschichten und Quellen. Szenario- und Förderregeln sind fachliche Entwürfe; Ausfälle werden als degradiert ausgewiesen.	`components/ReportView.tsx`, `docs/REPORT-SPEC.md`
Permalink und PDF	Live; Mehrseiten-Viewer produktiv verifiziert, PDF/UA offen	Gespeicherter Report unter `/r/[id]`, PDF über die Report-API. #332 bindet feste Free-/Premium-Fixture-Eingaben in einem eigenen Ubuntu/Poppler-CI-Job an beide Renderer, weiße Seiten, sichtbaren Body-Ink, seitenspezifischen Body-Inhalt, Text, Links, Metadaten und Seitenzahlen. PDFium, Chrome und Apple Vorschau sind vollständig geprüft; der zwölfseitige Live-Readback lief auf Merge-SHA `734f22f3b17de1593da72ef997f7f1eac5e38e50`. Der Produktionsrenderer bleibt React-PDF und ist nicht als PDF/UA getaggt. #333 Slice A ist als synthetisches Chromium-/veraPDF-Machbarkeits- und Vertragsprüfgate abgeschlossen: Lokal bestand der an Commit `dbd46f3c3a94` gebundene Kandidat 106 Regeln und 4.679 Checks; Linux-CI-Lauf 32951907614 bestätigte 106 Regeln und 4.645 Checks, trennscharfe Gegenprobe und leere Artefaktliste. PR #532, Merge-Commit `e39272c56134bfbe4c9f3b7789e872baa88706e8`, Main-CI 32954309960 und Vercel-Deployment `dpl_27B3QDZtKAyT7kEi3xe1rFWk1qWB` sind produktiv gebunden; vier Doku-Routen bestanden den schreibfreien Live-Readback. Die Integration aller vier Report-Tiers, Runtime-/Viewergates und Screenreader-Abnahme bleiben offen.	`app/r/[id]/page.tsx`, `app/api/v1/report/[id]/pdf/route.ts`, Viewer-Vertrag, Produktionsnachweis, PDF/UA-Entscheidung, PDF/UA-Evidenzvertrag
Konto und Report-Ablage	Live; Quota-Entkopplung produktiv verifiziert	Report-Liste, Umbenennen, Filtern, Löschen und dauerhafte Speicherung nach Kontoübernahme. #312 trennt den Account-Quota-Bucket vom gemeinsamen IP-Zähler. Migration, Preview und sicherer Live-Readback sind an den exakten Produktionscommit gebunden; eine reale Mehrkonten-Nutzung bleibt davon getrennte Stakeholder-Beobachtung.	`/account`, `/account/reports`, Report-Quota-Vertrag, Produktionsnachweis
Organisation und Einladungen	Live mit Grenze	Mitglieder und Einladungen liegen gemeinsam unter `/org/[slug]`. Einladungslinks werden bis zur freigegebenen Versand-Domain manuell weitergegeben.	`app/org/[slug]/page.tsx`, `/invite/[token]`
Gemeinde-Überblick	Live mit Grenze	k-anonymes Aggregat bereits geprüfter Adressen. Keine Einzeladressen, keine Vollerhebung und kein systematisches Leerstandsinventar; Gemeinde-Zuordnung derzeit über grobe Ortstext-Suche.	`app/gemeinde/[slug]/page.tsx`, `lib/gemeinde/aggregate.ts`
Öffentliche API, MCP und Skill	Live mit Grenze	Versionierte REST-API, MCP-Server und Skill nutzen denselben Report-Contract. Der gehostete Remote-HTTP-MCP bleibt offen.	`docs/API.md`, `docs/MCP.md`, `docs/SKILLS.md`
Administration	Live	LLM-Modelle, Budgets, Nutzung, Benutzer, Impersonation, Datenquellen, Cron-Läufe, kennungsfreie Werkzeugmetriken und Wien-Overlay-POC. Plattform-Admin plus TOTP-2FA.	`/admin/**`, `app/admin/layout.tsx`
Planer-/Gemeinde-Abos	Testmodus	Stripe Checkout und Kundenportal sind technisch für das Planer-Abo verdrahtet. Live-Schlüssel werden absichtlich abgewiesen; reale Zahlungen und veröffentlichte Tarife sind nicht freigegeben.	`lib/stripe/client.ts`, `components/account/BillingSection.tsx`
BEV-Pilotexport	Live mit enger Grenze; Rollback bewiesen	Produktionslauf 32887690047 aktiviert den separaten Export-Release `7ae1d4da-e5d5-5c09-ae1f-15997506d4f7`, Pointer 1: 28.535 vollständig umschlossene Originalpolygone, 1.211 ausgeschlossene Public-Geometrien, 15 Quarantänefälle; der öffentliche Pilot bleibt bei 29.746 veröffentlichten Geometrien und Pointer 2. GeoJSON/PDF/DXF sind report- und release-gebunden. #412 wurde auf Merge-SHA `8b276764f8d5803e8dc6ecdbe54323d8b38445c1` mit positivem, negativem, GDAL-3.13.3-Parser- und Rollback-Readback abgeschlossen; finales Deployment `dpl_CaUMXVpyerL5iV6BzraupmboMgtr` steht auf `DXF_EXPORT_ENABLED=true`, `false` bleibt der bewiesene Kill-Switch. NÖGIS #413 und der externe SEO-01-Indexnachweis bleiben offen.	`ADR-0055`, `Produktionsaktivierung`, `DXF-Produktionsnachweis`, `/docs/bev-export-v1`
Leerstandsinventar	Geplant	Objektliste, Vollerhebung, Filter und Gemeindebericht existieren nicht.	`docs/ROADMAP.md`
Öffentliche Auffindbarkeit	Live mit Grenze	14 tatsächlich öffentliche Canonicals umfassen Homepage, Tool-Hub, zwei Werkzeuge, Wissensindex, sechs menschlich freigegebene Beiträge, Methodik und beide Rechtsseiten. Neun Detailseiten besitzen separate BreadcrumbList-Daten; private Report-, Doku-, Auth- und API-Pfade bleiben `noindex`. Der tatsächliche Google-/Bing-Indexstatus ist unbestätigt: Das geprüfte Google-Konto hat keinen Domain-Property-Zugriff und keine sichtbare URL-Prefix-Property; im geprüften Bing-Zugang ist kein Nachweis verfügbar. SEO-01 bleibt bis zum externen Indexnachweis offen.	`app/robots.ts`, `app/sitemap.ts`, `app/llms.txt/route.ts`, `ADR-0054`, `/methodik`, `/docs/seo-indexability-v1`

HORA-Hitzebelastung: Quelle und Report-Consumer produktiv live

Die eigenständige GeoSphere-Quelle geosphere-hora-hitzelayer ist für exakt die Distribution hora_hitzelayer-v1-1km, public_display, report_lookup und country:AT unter CC BY 4.0 geprüft. Der Operatorlauf 32895496768 hat Release d90ef5c8-17af-5de0-a4e7-22e01f78f164 qualifiziert und auf Pointer-Version 1 aktiviert. Der Produktionsreadback bestätigt 83.891 gespeicherte und 83.891 sichtbare österreichische 1-km-Rasterzellen in EPSG:3416, coverage=covered, quality=passed, rightsReviewCurrent=true und legacyHoraBlocked=true.

su30, su35, tr20 und kys beschreiben mittlere Hitzetage, extreme Hitzetage, Tropennächte und Tage in Kyselý-Episoden pro Jahr der historischen Klimaperiode 1991–2020.
Der bestehende SPARTACUS-v3-Klima-Block verwendet dagegen das abgeschlossene Referenzjahr 2025. Beide Produkte teilen die SPARTACUS-Temperaturdatenfamilie, nicht notwendig dieselbe Dataset-Version.
Die Darstellung bleibt neutral: keine Ampel, keine Prognose, kein Trend, keine Preiswirkung und keine parzellenscharfe Messung. Der technische Metadatenwert scenario=rcp26 begründet kein Zukunftsszenario.
PR #515 deployte den releasegebundenen Consumer mit Merge-Commit 08d55c32ea720f9d17419c039ae7bea21ce78508. Ein nicht persistierender öffentlicher GET /api/v1/report las danach am versionierten Referenzpunkt Gänserndorf exakt denselben Release und Raster 650500/498500 mit 21,6, 1,8, 4,033333… und 19,566667… Tagen pro Jahr. Antwort-Header, Provenienz und Rechtehinweise waren vollständig; report_id und Permalink fehlten wie für den GET-Vertrag vorgesehen.
HORA 3.0, HORA-Pass und LFRZ-WMS bleiben gesperrt; NÖGIS #413, der Parzellenpass sowie das offene externe SEO-Indexgate bleiben unverändert. Der getrennte DXF-Livegang #412 ist abgeschlossen.

Nachweise: ADR-0056, Rechteprüfung, Produktionsaktivierung und Consumer-Live-Readback, öffentlicher Quellenvertrag.

BEV-Export: zweckgebundener Pilot-Cutover, Aktivierung separat

Der bestehende öffentliche Punkt-Lookup verwendet weiterhin ausschließlich bev-parzellen/public, public_display und point_lookup. Ein eigener Export-Release darf nur die Distribution bev-dkm-gpkg-pilot-snapshot, den Kanal export, den Zweck export und den Pilot bev-gaenserndorf-pilot-v1 mit BBox [16.64,48.28,16.8,48.4] verwenden.

Der bestehende Public-Release behält 29.746 veröffentlichte Originalpolygone und 15 Quarantänefälle. Sein historischer Import mit ogr2ogr -spat umfasst auch vollständige Originalpolygone, die die Pilotgrenze schneiden. Die Migrationen 0048 und 0049 erlauben dem Export ausschließlich die unveränderte ST_CoveredBy-Teilmenge; outsideCoverageRowCount zählt alle nicht vollständig umschlossenen und daher ausgeschlossenen Public-Polygone. Der erfolgreiche Produktionslauf bestätigt 28.535 Exportpolygone, 1.211 ausgeschlossene Public-Originale, 15 Quarantänefälle und 28.550 Export-Quellzeilen. Public- und Export-Manifeste sowie ihre Zeilenzahlen bleiben getrennt gebunden. Der Export-Release 7ae1d4da-e5d5-5c09-ae1f-15997506d4f7 ist mit Pointer-Version 1 aktiv; GeoJSON und PDF bleiben an diesen Release gebunden und werden getrennt vom Infrastruktur-Readback verifiziert.
Die qualifizierbaren Capabilities lauten exakt parcel_geojson, pdf_parcel_outline und parcel_dxf; alle drei Consumer sind code-seitig release_bound. Der #412-Cutover wurde auf Merge-SHA 8b276764f8d5803e8dc6ecdbe54323d8b38445c1 mit Dark Deploy, kontrollierter Aktivierung, positivem und negativem Readback, GDAL-3.13.3-Parserprüfung, Flag-Rollback und finaler Reaktivierung abgeschlossen. DXF_EXPORT_ENABLED=true ist der aktuelle Produktionszustand; mit false liefert der DXF-Pfad 404 und fehlt im öffentlichen OpenAPI-Schema. Nur exakt true plus Release-Bindung öffnet die Dokumentation.
Die neun Exportbedingungen verlangen attribution, sourceLink, licenseLink, changeNotice, nonEndorsement, valueAddedReport, notStandaloneBevProduct, pilotCoverageOnly und noOwnerData. Das GeoJSON ist nur internes Report-/Kartenoverlay, kein eigenständiges BEV-Datenprodukt und kein allgemeiner Kataster-Download.
getReleasedParcelGeoJSON(lat, lon, capability, expectedPublicReleaseId) liest in einem atomaren SQL-Read ausschließlich aus parcel_versions_export_current. Der Report-Release, der aktive öffentliche Release und dessen Pointer-Version müssen mit dem Export-Release übereinstimmen; Rechte, Freshness, Quality, erfolgreicher Importlauf, Pilotgrenze, Quarantäne und mehrdeutige Grundstücksgrenzen bleiben gleichzeitig bindend.
/api/parcel-geojson verlangt die reportId eines bereits gespeicherten Reports mit exakt derselben Koordinate und mindestens einer Nicht-BEV- Datenquelle. Fehlender oder unbekannter Report bleibt 404; abweichender Standort oder fehlender Mehrwert bleibt 403; unsichere Release-Fälle erhalten 503. Alle Antworten bleiben private, no-store. Vorhandene Reports werden nur gelesen; es entstehen keine zusätzlichen personenbezogenen Produktionsschreibvorgänge. Die PDF zeichnet ausschließlich bei hit eine Outline und bleibt sonst ohne Parzellengeometrie.
Der manuelle Betreiber-Workflow unterstützt dry-run. Eine Aktivierung verlangt die erwartete öffentliche Release-ID, die exakte Bestätigung PUBLISH bev-parzellen export, eine additive Migration und einen getrennten Readback beider Pointer. Der erfolgreiche Produktionslauf belegt die aktivierte Exportbasis. Der getrennte DXF-Produktionsnachweis belegt den ausgelieferten Consumer, seine Parser-Lesbarkeit und den jederzeitigen Rollback.

#412 ist technisch durch den Produktions-, Parser- und Rollback-Readback abgeschlossen; #413 gibt keine NÖGIS- Nutzung frei. Der öffentliche Standort-Check, sechs freigegebene Wissensbeiträge und das offene externe SEO-01-Gate ändern sich nicht.

SEO-01: technische Indexierbarkeit, offener externer Nachweis

Die öffentliche Methodik unter /methodik ergänzt den tatsächlich indexierbaren Bestand auf 14 kanonische Seiten: Homepage, Werkzeug-Hub, beide öffentlichen Werkzeuge, Wissensindex, sechs menschlich freigegebene Beiträge, Methodik sowie Impressum und Datenschutzerklärung. Aktuell gibt es null unfreigegebene Artikelentwürfe.

Quellen- und Korrekturhinweise sind ausschließlich unter /methodik#quellen und /methodik#korrekturen verankert; tatsächliche Korrekturen laufen über /impressum#kontakt. Es gibt keine Produktseiten /datenquellen oder /korrekturen.
buildBreadcrumbJsonLd ergänzt ein eigenständiges BreadcrumbList-JSON-LD genau auf neun Detailseiten: Methodik, zwei Werkzeuge und sechs Artikel. Die bestehenden BlogPosting- beziehungsweise WebApplication-Daten bleiben getrennt erhalten.
Private Reports, Konten, Administration, API, /docs, die private PV-Share-Ansicht und künftige Entwürfe bleiben noindex beziehungsweise hinter ihren bestehenden Schutzgrenzen. Rechte, Datenschutz und der cookielose Standort-Check werden nicht erweitert.
npm run seo:audit prüft den Vertrag offline. Der optionale Origin- Readback npm run seo:audit -- --live unterscheidet Browser-, Googlebot- und Bingbot-Signale, aber keine tatsächliche Indexierung; providerIndexStatus lautet not_checked beziehungsweise not_verifiable_without_property_access.
Das konkret geprüfte angemeldete Google-Konto besitzt keinen Zugriff auf die Search-Console-Domain-Property landnutzen.at und zeigt keine passende URL-Prefix-Property. Im geprüften bestehenden Bing-Zugang ist ebenfalls kein Indexnachweis verfügbar. Andere Konten, Properties und der tatsächliche Google-/Bing-Indexstatus bleiben nicht feststellbar.
Technische Indexierbarkeit ist nachprüfbar; der autoritative externe Suchindexnachweis bleibt offen. SEO-01 ist nicht vollständig abgeschlossen.

Der SEO- und Indexierbarkeitsvertrag, die öffentliche Auffindbarkeitshilfe und ADR-0054 dokumentieren dieselbe Grenze.

Wissensbereich: sechs menschlich freigegebene Live-Beiträge

Der öffentliche Wissensbereich enthält genau sechs menschlich freigegebene und veröffentlichte Beiträge. Die drei zusätzlichen Beiträge zu Grundstücksklimadaten, Brachflächenpotenzial und Hochwasser wurden von Andreas Ostheimer am 2026-08-25T19:18:42+02:00 ausdrücklich freigegeben; der Freigabenachweis belegt die Entscheidung. Alle sechs Artikel erscheinen in ihren Produktionsrouten, im Wissensindex, in Sitemap, RSS-Feed und llms.txt. Aktuell gibt es null unfreigegebene Entwürfe.

Die Pipeline bindet Themenbrief, Quellenpaket, finalen Text, Bildbytes, sichtbare Metadaten und den menschlichen Schlussreview an SHA-256.
Ein semantischer Quellenfingerprint trennt den bloßen Pointer-Wechsel source_refreshed von einer fachlichen material_change. Materielle Änderungen erzeugen für alle gebundenen Beiträge review_required; eine fehlende Quelle ergibt source_unavailable und bleibt fail-closed.
Künftige unfreigegebene Entwürfe bleiben human_review_required und ausschließlich im geschützten Preview; Production und Indexierungsflächen schließen sie aus. Es gibt weder automatische Veröffentlichung noch automatische Depublikation. Ein Quellenaudit verändert ARTICLE_REGISTRY und bestehende Live-Routen nicht; vorhandene Beiträge bleiben bis zur redaktionellen Entscheidung bestehen. Es gibt keine zusätzliche personenbezogene Speicherung oder neue Content-API. Korrekturen laufen ausschließlich über /impressum#kontakt.
npm run content:audit prüft den Vertrag deterministisch und offline in CI; npm run content:audit -- --live ergänzt ausschließlich lesende öffentliche Provenienzabfragen.
CON-02 und das Phase-2-Ziel von sechs veröffentlichten Beiträgen sind abgeschlossen. SEO-01 ist der nächste eigenständige offene Schritt.

Der öffentliche Content-Pipeline-Vertrag, die Wissenshilfe und ADR-0053 dokumentieren dieselbe Grenze.

Öffentlicher Standort-Check: Datenpass statt gespeicherter Report

Der availability-aware Standort-Check aus #500 beantwortet ausschließlich, welche qualifizierten Daten an einer ausgewählten österreichischen Adresse tatsächlich verfügbar sind. Photon liefert eine signierte Standort- und Regionsauswahl. POST /api/tools/standort-check prüft beide Signaturen, das Bundesland, einen getrennten pseudonymen Tageszähler und für jede Quellenkarte zuerst die reale Coverage-/Rechtematrix.

Klima und Brachflächen können österreichweit anhand ihres jeweils freigegebenen Snapshots eingeordnet werden; die Brachflächen-Modelllücken bleiben sichtbar.
BEV-Parzellen sind nur im Gänserndorf-Pilot und der NÖ-Hochwasser-Snapshot nur im GF/Marchegg-Pilot verfügbar. Niederösterreich als Bundesland ist kein flächendeckender Punkt-Coverage-Nachweis. Hochwasser verwendet keinen WMS-Fallback.
Widmung bleibt wegen #413 gesperrt. Erdbeben und Local Climate Zones sind trotz aktiver Releases für den Werkzeug-Scope nicht konfiguriert.
Die acht Karten-Zustände lauten hit, no_hit, outside_coverage, ambiguous_boundary, stale, failed, gated und not_configured. Fehlende Evidenz ist kein negativer Fachbefund.
Adresse, Koordinate, Signaturen, Befunde und Ergebnis werden nicht als Report, Session oder Historie gespeichert. Das Werkzeug setzt keinen Report-/Session-Cookie und erzeugt keine Produkttelemetrie; MET-01 bleibt ausschließlich für den PV-Rechner aktiviert.
Ausschließlich auf dem exakten Werkzeugpfad wird kein Auth-SessionProvider gemountet und /api/auth/session nicht im Browser abgefragt. Links zu /report und /login erzeugen kein spekulatives prefetch; vor einer bewussten Navigation entstehen keine neuen Auth-, Report- oder Sitzungs-Cookies. Der serverseitige ImpersonationBanner und die normalen Auth-/Sicherheitsabläufe auf anderen Seiten bleiben unverändert.
Für höchstens 30 Anfragen pro Tag nutzt der Missbrauchsschutz ausschließlich den vorhandenen werkzeugspezifischen pseudonymen IP-Hash mit Tagesdatum und Zähler. Der getrennte BEV-Exportkanal verleiht dem Standort-Check keine Geometriefähigkeit; DXF bleibt dort unabhängig vom separat produktiv aktivierten Consumer ausgeschlossen.

Der öffentliche Vertrag, die Werkzeughilfe, ADR-0052 und /datenschutz#standort-check beschreiben dieselbe Grenze.

Anmeldung, Rollen und Übernahme anonymer Reports

#312 ist als getrennte Report-Quota implementiert: anonym bleiben es zehn Reports pro Tag und pseudonymem Request-IP-Bucket; eine sicher aufgelöste bestehende Kontositzung erhält zehn pro Tag und pseudonymem Account-Bucket; API-Keys behalten ihr jeweiliges Datenbanklimit. Zwei Konten hinter derselben IP teilen damit keinen Account-Zähler mehr.
Ein angebotener ungültiger oder widerrufener API-Key endet weiterhin mit 401 und fällt weder auf Sitzung noch anonym zurück. Fehler beim Auflösen einer Sitzung und gelöschte User verwenden den anonymen IP-Bucket. Header weisen X-Auth-Mode: anon|session|key und die Werte des tatsächlich gewählten Buckets aus.
Der Account-Bucket ist ein mit account:v1: markierter, domänenseparierter HMAC-SHA-256-Wert aus users.id und AUTH_SECRET; rohe User-ID und E-Mail werden nicht in rate_limits gespeichert. reports.ip_hash bleibt davon getrennt der pseudonyme Hash der tatsächlichen Request-IP. Eine interne FK-Zuordnung bindet alle HMAC-Generationen an den User; die Kontolöschung entfernt sie einschließlich paralleler Reste per Cascade. Der allgemeine 90-Tage-Prune bleibt reine Tabellen-Wachstumsbegrenzung.
Der Session-Modus nutzt nur die vorhandene gleich-originäre Browser-Sitzung; es gibt kein neues headless Cookie-Auth-Verfahren. Lokale Tests, Preview und CI belegen den Implementierungsvertrag. Der Produktionsnachweis vom 26. August 2026 bestätigt Migration, validierte Cascades und den öffentlichen 400-/401-Readback auf Merge-Commit 44a6df465d7c27487d08b69ab2acd20e826737e5, ohne künstliche Produktionskonten oder personenbezogene Schreibdaten. Der technische Vertrag ist damit produktiv verifiziert; reale Mehrkonten-Nutzung bleibt getrennte Stakeholder- beziehungsweise Betriebsbeobachtung.
Der produktive Login erfolgt per Magic-Link oder mit einem zuvor eingerichteten Passkey. Die Registrierung ist geschlossen und nur für freigeschaltete Konten bzw. definierte POC-Ausnahmen möglich. Migration 0042 und PASSKEY_ENABLED=1 sind seit 7. August 2026 produktiv aktiv und technisch rückgelesen. Die reale Geräteabnahme — Einrichtung im Konto, Abmeldung und erneuter Passkey-Login — wurde am 9. August 2026 erfolgreich abgeschlossen. Neue Passkeys können ausschließlich in einer bestehenden Sitzung unter /account angelegt und dort einzeln widerrufen werden. Magic-Link bleibt der Wiederherstellungsweg.
platform_admin wird nach dem Login über /go nach /admin geleitet und benötigt TOTP-2FA. Organisationsmitglieder landen in ihrer ersten Organisation, andere Konten unter /account.
Plattformrollen sind user, support und platform_admin. support ist im Schema und in der Benutzerverwaltung vorhanden, hat aber keinen eigenen Support-Screen und keine Admin-Berechtigung.
Organisationsrollen sind owner, admin, member, viewer und external_consultant. Die aktuelle Org-Oberfläche bietet Einladungen für admin, member und viewer; owner und admin verwalten, member und viewer lesen.
Beim ersten Login übernimmt /go alle anonymen Reports des aktuellen ln_anon-Browsers automatisch. Die Konvertierung ist fail-open und hat ein hartes Zeitbudget von zwei Sekunden.
Ein einzelner Report kann nach Login explizit über /r/[id]?claim=1 bzw. POST /api/v1/report/[id]/claim übernommen werden. Der Claim ist atomar und idempotent; bereits fremd zugeordnete oder abgelaufene Reports werden nicht übertragen.
Anonyme Reports laufen nach 90 Tagen ab. Ein einem Konto zugeordneter Report wird dauerhaft gespeichert, bis die Person ihn oder ihr Konto löscht.

Das ist ein echtes Session-/Report-Takeover mit klaren Grenzen: Die automatische Übernahme verbindet denselben Browser; für einen bekannten Report auf einem anderen Gerät ist der explizite Claim-Pfad vorgesehen. Es gibt keine pauschale Suche nach anonymen Reports nur anhand einer E-Mail-Adresse.

Stripe: drei getrennte Zustände

Zustand	Status
Checkout und Billing-Portal für `planer_abo`	Technisch live im Testmodus
Schutz vor versehentlichen Live-Schlüsseln	Live — `sk_live` und `pk_live` werden abgewiesen
Reale Produktionstransaktionen	Nicht freigegeben
Fachlich bestätigte und veröffentlichte Tarife	Offen
Weitere Produkte wie Gemeinde-Abo oder Beratung	Nicht als buchbarer Produktpfad implementiert

Die sichtbare Kontooberfläche kennzeichnet den Testmodus und verwendet nur Stripe-Testdaten. „Stripe integriert“ darf deshalb nicht mit „Zahlungen in Produktion aktiv“ gleichgesetzt werden.

Aktuelle UI-Routen

Die vollständige, aus app/**/page.tsx abgeleitete Liste mit Zugriffsschutz und Screen-Zweck steht in UI-SCREENS.md. Wichtige Korrekturen gegenüber älteren Planständen:

Report-Erstellung: /report; gespeicherter Report: /r/[id].
Öffentliche Tools: /werkzeuge; erster österreichweiter Rechner: /werkzeuge/pv-ertrag; eigenständiger, nicht persistierter Standort- Datenpass: /werkzeuge/standort-check; private, nicht indexierte PV- Ergebnisansicht: /werkzeuge/pv-ertrag/teilen.
Quellengeprüfte Beiträge: /wissen und /wissen/[slug]; RSS unter /wissen/feed.xml.
Öffentliche Rechtsinformationen: /impressum und /datenschutz.
Datenquellen: /docs/data-sources, öffentlicher Matrixvertrag unter /docs/coverage-rights-matrix-v1 und JSON unter /api/v1/data-sources/coverage-matrix; kein /datenquellen.
Report-Ablage: /account/reports; Kontolöschung: /account/delete.
Mitglieder und Einladungen sind Teil von /org/[slug]; es gibt keine Unterrouten /members oder /billing.
Es gibt keine Routen /account/upgrade, /convert, /legal/privacy oder /legal/terms. Die kanonischen Rechtsseiten liegen unter /impressum und /datenschutz; /docs/compliance bleibt die technische Compliance- Dokumentation und ersetzt diese öffentlichen Seiten nicht.

Öffentliche Rechtsseiten und offenes Formalisierungs-Gate

Am 3. August 2026 wurde ausdrücklich bestätigt, dass die Atelier Deubner Lopez ZT OG und die Ostheimer OG LandNutzen gemeinsam betreiben und beide Unternehmen gemeinsame Verantwortliche sind. Diese Angabe ist zentral hinterlegt und in /impressum sowie /datenschutz umgesetzt. Das formale Rechts-Gate bleibt offen, bis der wesentliche Inhalt der tatsächlichen Art.-26-Vereinbarung, die nicht öffentlich ausgewiesenen Beteiligungs-/Stimmrechtsverhältnisse der Atelier Deubner Lopez ZT OG und die externen AVV-/DPA-Nachweise aus #290 dokumentiert sind. Rechts-, Vertrags-, Tarif- und Zahlungs-Gates für kommerzielle Produktpfade bleiben davon ebenfalls unberührt offen.

Daten- und Produktgrenzen

Live-Datenquellen und ihre Grenzen werden kanonisch unter Datenquellen & Lizenzen gepflegt.
Der Hochwasser-PostGIS-Pfad ist im Pilotbereich Gänserndorf/Marchegg über FND-02-Run 53 und Release cb6640d0-b8da-573c-a51f-9d14a5c1f25b aktiv: Quellenstand 2024-11-17, 17.934 Polygon-Parts, 15 deterministisch reparierte Geometrien und drei bestandene Pflichtchecks. Innerhalb der Coverage ist source=mirror belegt. Außerhalb liefert der öffentliche Report nach dem Produktionsfix ausdrücklich outside_coverage, keinen Hochwasserblock, keine Hochwasserquelle und keinen grünen Ersatzbefund. Der streng anonyme #276-Abschlusslauf vom 17.07. hat alle vier Latenzgrenzen bestätigt (Abschlussbeleg); #276 ist geschlossen.
Das produktive Source-/Release-Ledger führt 50 Katalogquellen: zwölf registered mit aktivem, qualifiziertem Release und 38 bewusst legacyUnverified. Aktiv sind Hochwasser-WFS cb6640d0-b8da-573c-a51f-9d14a5c1f25b, Hochwasser-WMS 207c6e09-5467-5360-a0ce-707624c996aa (Pointer-Version 20), PVGIS fdb7c953-f3d3-5702-b817-a1821052584a (Pointer-Version 6) und basemap.at Orthofoto 4bf28562-a2b0-5af9-a385-19eb59fc6431 (Pointer-Version 112) sowie der BEV-Pilotrelease 655a7dc3-1f7a-5bdc-a329-d73f1c458320 aus Run 57 auf Pointer-Version 2 sowie der BMLUK-Brachflächen-v2-Release 57e2e12b-e240-5287-a0c4-ee1edba795df aus Run 56 auf Pointer-Version 2 und der SPARTACUS-v3-Release 81ef8803-2d64-5d30-9d7f-cd526ce57e69 auf Pointer-Version 1 sowie der Erdbeben-Release 263c80ac-94e0-4e57-97d5-03ca978f8b1d auf Pointer-Version 1, der LCZ-Release 1db4a15b-abb7-44e3-b83a-bec294526773 auf Pointer-Version 1 und der GeoSphere-Hitzelayer-Release d90ef5c8-17af-5de0-a4e7-22e01f78f164 auf Pointer-Version 1 sowie der Lärminfo-Live-Check-Release 63575c23-0121-506d-8baa-210a82dd957f auf Pointer-Version 1 und der Altlastenportal-WFS-Release 8ed8d136-f3f8-5a78-946b-4b419a050269 auf Pointer-Version 1. PR #393 lieferte den FND-02-Produktions-Rollout, PR #394 korrigierte die PostgreSQL-Typbindung des PVGIS-Nutzungsgates und PR #395 bewahrte outside_coverage bis zum öffentlichen Report. PR #398 ergänzte Migration 0041, die kanonische Parzellenidentität und den ersten release-gebundenen BEV-Punkt-Lookup. Provenienz-, ETag-, Cache-, Consumer-, Admin-, Cron-, Workflow- und Retry-Verträge sind im zentralen FND-02-Produktionsnachweis sowie im FND-03-Produktionsnachweis rückgelesen. PRs #399/#400 banden anschließend den Report-Consumer an den Active Release; Innen-/Außen-Coverage, Attribution und der öffentliche Statusvertrag sind gegen Runtime-Commit b941c9f belegt.
PRs #409/#410 und Migration 0042 banden die BMLUK/Umweltbundesamt-KI-Potenzialflächenkarte ausschließlich als neutralen potential_lookup an den Active Pointer. 3.705 valide und 17 quarantänisierte Geometrien ergeben exakt 3.722 Quellfeatures; sieben Pflichtchecks, zwei sichtbare Warnchecks, Provider-Workflow, täglicher Monitor sowie API-, Web- und PDF-Readback sind im Brachflächen-Produktionsnachweis belegt. Es gibt keinen Geometrieexport und keinen amtlichen Befund.
Der SPARTACUS-v3-Produktionslauf 30964182823 aktivierte Release 81ef8803-2d64-5d30-9d7f-cd526ce57e69 mit Pointer-Version 1 und 106.610 Zellen. Manifest, Artefakt, Row-Hash-Kette und Source-to-Rows-Bindung sind im Aktivierungsnachweis festgehalten. Der neue tägliche Monitor ist ausschließlich lesend gegenüber Source-/Release- und Klimadaten; Provider- oder DB-Drift führt zum Cron-Fehleralarm, nie zu automatischem Publish, Aktivieren oder Rollback. PR #419 schloss den atomaren Consumer-Cutover ab; ein einziger anonymer Produktionsreport wurde in Web, API und PDF mit identischem Release-Tupel, sichtbarer Attribution und Aussagegrenze rückgelesen. PRs #424/#426 korrigierten anschließend die PDF-Kopfzeile; alle elf Seiten des finalen Produktions-PDFs sind visuell geprüft.
PRs #431/#434/#435 ergänzten Migration 0045, den qualifizierten erdbeben-oenorm/public-Release und den neutralen Reportbaustein. Der Snapshot führt 2.188 Orte, alle fünf Zonen und den Quellenstand 2026-03-27; ein echter Gänserndorf-Readback ergab Zone 2 mit Herkunftsort, PLZ und Entfernung. Die Ortstabelle ist maßgeblich, das generalisierte Zonenpolygon wird nicht als Parzellenbefund verwendet. Ampel, Kostenwirkung sowie eine Interpretation von EGA und PGA bleiben ausdrücklich offen.
eBOD wurde mit Produktionslauf 47 als atomarer Snapshot beider Themen veröffentlicht: 1.805 Datensätze, Stand 2024-10-25. AEST-Lauf 48 veröffentlichte 30.693 Gemeinde-Jahreszeilen; Bevölkerungs-/Wanderungslauf 49 veröffentlichte 63.420 Zeilen bis Bevölkerungsstand 1.1.2026 und Wanderungsjahr 2025. Nach dem Readback war kein relevanter Lauf running.
Die Produkteinstufung ist keine rechtsverbindliche Widmungs-, Grundbuch-, Vermessungs-, Umwelt- oder Förderauskunft.
Sechs Szenarien werden angezeigt. Ihre Eignungs-, Kosten- und Förderregeln bleiben bis zur fachlichen Freigabe als Entwurf gekennzeichnet.
Das Gemeinde-Dashboard verdichtet vorhandene Reports; es beweist weder Leerstand noch Vollständigkeit.
Der umfassende Standort-Report ist weiterhin auf Niederösterreich ausgerichtet. Der PV-Ertragsrechner ist wegen seiner qualifizierten EU-PVGIS-Quelle für ganz Österreich freigegeben. Der getrennte Standort- Check zeigt österreichweit nur die je Bundesland und konkretem Punkt belegten Quellenkarten. Das ist keine Behauptung, dass bereits alle Parzellen- und Fachdatenschichten bundesweit vorliegen.

Abgleichsnachweis

Der Ausgangsaudit am 15. Juli 2026 verglich die produktive Landing, den Report-Pfad, das Dokumentationsportal und das Briefing mit dem Repository. Am 2. August wurden zusätzlich Tool-, Wissens-, Feed-, Robots- und Sitemap-Routen inventarisiert sowie Daten-, Privacy-, Indexierungs- und Providerfehlerpfade direkt im Code und über Regressionstests geprüft. Am 3. August kamen die bestätigten gemeinsamen Betreiber- und Verantwortlichenangaben sowie die öffentlichen Routen /impressum und /datenschutz hinzu. Ebenfalls am 3. August wurden MET-01-Migration, Produktionsdeployment, echte Photon-/PVGIS-Anfrage, kennungsfreie DB-Aggregate, Admin- und Cron-Schutz sowie Desktop-/Mobilansicht produktiv rückgelesen; der vollständige Nachweis steht in docs/evidence/met-01-live-2026-08-03.md. TOOL-02 wurde ebenfalls am 3. August mit 45/45 öffentlichen PVGIS- Referenzpunkten, privater Share-Ansicht, grüner Main-CI und öffentlichem Produktions-Readback abgeschlossen. Werkzeugseite, Share-Header, signierter Österreich-Standortpfad und PVGIS-Antwort wurden auf www.landnutzen.at rückgelesen; der Nachweis steht in docs/evidence/pv-tool-02-production-2026-08-03.md. Am 4. August folgten der FND-02-Produktionsrollout aus PR #393, der Runtime-Gate-Hotfix aus PR #394 und der Outside-Coverage-Report-Fix aus PR #395. Vier aktive Releases mit Pointer-Version 2, der 46-Einträge-Katalog, die shadow-Grenze, öffentliche Provenienz, Consumerpfade, autorisierte Vercel-Crons samt kontrolliertem WMS-Retry und der GitHub-Renewal-Workflow sind im FND-02-Produktionsnachweis zusammengeführt. FND-02 ist produktiv abgeschlossen; die 42 legacyUnverified-Quellen waren der damalige FND-02-Snapshot.

Ebenfalls am 4. August wurde PR #398 mit Produktionscommit e5295aa3b477bffbad0e1442157e692a829f6548 ausgerollt und Migration 0041 zweimal idempotent angewandt. Der BEV-Pilotrelease cb735e6f-6c32-5de0-87fd-594aa34a1903 wurde zunächst über Run 54 und Pointer-Version 1 aktiviert; damit standen zunächst fünf Quellen auf qualifizierten Releases und 41 blieben legacyUnverified. 29.746 von 29.761 Quellgeometrien wurden unverändert veröffentlicht, 15 ungültige Geometrien quarantänisiert und 21 Zeilen eines älteren Stands ausgeschlossen. Öffentliche und administrative Provenienz sind im FND-03-Produktionsnachweis rückgelesen. PRs #399/#400 schlossen den Consumer-Cutover auf Runtime-Commit b941c9f ab: echter qualifizierter Innentreffer, ehrlicher Außenfall, vollständige Attribution sowie erneut geschützte Public-/Admin-Provenienz. Dieser Beleg ist ausdrücklich ein enger Gänserndorf-Pilot und keine Österreich-Vollständigkeit.

Nach der schriftlichen BEV-Bestätigung versionierte PR #414 die getrennten Zwecke public_display und export; Migration 0043 ersetzte ausschließlich das erledigte Rechtswarte-Gap durch das weiterhin offene technische Release-Gap. Der neu qualifizierte Active Release 655a7dc3-1f7a-5bdc-a329-d73f1c458320 steht über Run 57 und Pointer-Version 2 weiterhin nur auf public_display/point_lookup. Innen-/Außenfall, öffentliche Provenienz, ETag/304 sowie DXF-404 und der weiterhin fehlende DXF-Pfad im OpenAPI-Schema wurden gegen Produktionscommit dd7c4b1 rückgelesen. Die Rechteklärung #77 ist damit erfüllt; Export-Cutover #412 und NÖGIS-Rechte #413 waren zu diesem damaligen Readback getrennte offene Gates.

Der spätere ADR-0055 ergänzt darauf aufbauend den getrennten bev-parzellen/export-Kanal und den fail-closed GeoJSON-/PDF-Cutover. Dadurch erhält der historische FND-03-Readback weder rückwirkend eine Exportfreigabe noch einen zusätzlichen Produktionsnachweis. DXF bleibt in dieser historischen Evidenz gesperrt; jeder tatsächliche Export-Pointer verlangt einen eigenen aktuellen Readback. Der separate #412-Nachweis vom 26. August 2026 erfüllt diesen Consumer-Cutover auf Merge-SHA 8b276764f8d5803e8dc6ecdbe54323d8b38445c1 einschließlich GDAL-Parser- und Rollback-Prüfung. Der finale Produktionszustand ist aktiviert; #413 bleibt unabhängig offen.

Danach wurde #376 über PRs #409/#410 und Produktionscommit d2c367d4a5fec6c5ec850566dddb90732d27a48f abgeschlossen. Migration 0042 wurde zweimal idempotent angewandt. Der erfolgreiche Providerlauf 30941095169 aktivierte den v2-Release 57e2e12b-e240-5287-a0c4-ee1edba795df über Run 56 und Pointer-Version 2, ohne den historischen v1-Release umzuschreiben. Der geschützte Monitorlauf 261 meldete degraded=false; der echte positive Produktionsfall wurde in API, Browser und achtseitigem PDF samt Attribution, Datenstand und Pflichtgrenzen rückgelesen. Der vollständige Nachweis steht im Brachflächen-Produktionsnachweis.

PR #416 ergänzte danach die fail-closed Coverage-/Rechtematrix und wurde als Produktionscommit 010c1bcf106714f35c33dab3b78a9b4d50954e1c ausgeliefert. Main-CI 30957886659 und Vercel-Deployment dpl_D4qj6ij4VcdDa33qqqdYe3ogBbY2 sind grün. API, ETag/304, OpenAPI- und Vertragsroute sowie neun Regionen bei 320, 390 und 1.440 Pixeln wurden öffentlich rückgelesen. Die Matrix dokumentiert 9/9, ohne unqualifizierte Bereiche oder Exportzwecke freizugeben; der vollständige Beleg steht im Matrix-Produktionsnachweis.

Der SPARTACUS-v3-Publisherlauf 30964182823 aktivierte anschließend den qualifizierten Release 81ef8803-2d64-5d30-9d7f-cd526ce57e69 mit Pointer-Version 1 und 106.610 Zellen. Dieser Produktionsbeleg betrifft die Datenbasis. Ein Runtime-Cutover des Reportpfads ist darin ausdrücklich nicht enthalten und wird erst nach separatem Merge, Deployment sowie Web-, API- und PDF-Readback als live eingestuft. Der vollständige Aktivierungs- und Betriebsnachweis steht unter docs/evidence/spartacus-v3-production-activation-2026-08-05.md. PR #419 und der Abschlussabgleich #433 lieferten diese getrennten Runtime- und Produktionsbelege anschließend vollständig.

PRs #431/#434/#435 aktivierten danach die Erdbeben-Ortstabelle als achten qualifizierten Release und banden den neutralen Reportbaustein release-gebunden an. Der damalige Produktionsreadback im Phase-1-Abgleich bestätigt 48 Katalogquellen mit acht registered, 34 öffentliche Matrix-Lanes und 306 fail-closed Statuszellen. Damit ersetzt dieser Readback die früheren Zwischenzähler 47/7 beziehungsweise 33/297, ohne den historischen Matrix-Erstnachweis umzuschreiben.

PR #459 aktivierte anschließend die Local Climate Zones als neunten qualifizierten Release. Der aktuelle schreibgeschützte DATA-02-Abgleich bestätigt 49 Katalogquellen mit neun registered, 35 öffentliche Matrix-Lanes und 315 fail-closed Statuszellen. Die historischen Zwischenstände bleiben als zeitgebundene Nachweise bestehen.

Neun der 49 Katalogquellen waren zu diesem Stichtag release-gebunden.

Der Operatorlauf vom 25. August ergänzte danach den historischen GeoSphere-Hitzelayer als zehnte release-gebundene Quelle. Der Produktionsnachweis bestätigt 50 Katalogquellen insgesamt, den aktiven Release d90ef5c8-17af-5de0-a4e7-22e01f78f164, Pointer-Version 1 sowie 83.891 gespeicherte und sichtbare Rasterzellen. Er belegt die Quellenbasis; PR #515 und der öffentliche, nicht persistierende Report-/API-Readback auf Merge 08d55c3 erbrachten den getrennten Consumer-Nachweis anschließend. Web und PDF gehören zum selben geprüften Produktionsbuild, ohne dass allein für die Evidenz ein Report gespeichert wurde.

Der manuell bestätigte Operatorlauf vom 26. August ergänzte danach Lärminfo als elfte release-gebundene Quelle. Der Produktionsnachweis belegt Release 63575c23-0121-506d-8baa-210a82dd957f, Pointer-Version 1, sechs bestandene Pflichtchecks sowie Report-, Karten-, Legenden-, Web- und PDF-Readbacks. Der erste planmäßige Vercel-Cron-Renewal wurde zu diesem Zeitpunkt noch nicht beobachtet und bleibt deshalb ein getrennter Betriebsnachweis.

Migration 0052 hob anschließend den bestehenden Legacy-Eintrag altlasten auf die zwölfte release-gebundene Quelle; die Gesamtzahl blieb deshalb bei 50. Der Candidate-Lauf 32925774398 qualifizierte Release 8ed8d136-f3f8-5a78-946b-4b419a050269 mit 1.794 Quellzeilen, 372 veröffentlichten, 19 exakt ausgeschlossenen und 1.403 scopefremden Zeilen. Der getrennt bestätigte Aktivierungslauf 32926014904 setzte Pointer-Version 1; der anschließende Renewal-Readback 32926111534 bestätigte denselben aktiven Release und die verbleibende Frischereserve, ohne den Pointer zu verändern. Der Report-Consumer liest ausschließlich altlasten_current; seine vom Quellenpointer getrennte API-, Web-, PDF- und Headless-Abnahme wurde mit #525/#526 und dem öffentlichen Readback erbracht.

Nach der Synchronisierung wurden ausgeführt:

vollständige Vitest-Suite,
TypeScript-Prüfung,
ESLint,
Next.js-Produktions-Build,
HTTP-Smoke-Tests des gebauten /docs/status und /briefing.

Der Routenabgleich ist als Regressionstest gespeichert und läuft bei jeder künftigen Unit-Test-Ausführung erneut.

Pflege und Drift-Schutz

Bei Änderungen an Funktionen oder Routen müssen in derselben Änderung geprüft werden:

docs/STATUS.md für den Ist-Stand,
docs/UI-SCREENS.md für Routen und Personas,
docs/ROADMAP.md für ausschließlich zukünftige Arbeit,
public/briefing/index.html für die Management-Zusammenfassung,
CHANGELOG.md für die nachvollziehbare Änderungshistorie.

Automatisierte Dokumentationstests gleichen die tatsächlichen App-Routen mit dem Screen-Inventar ab und schützen zentrale Aussagen zu Szenariozahl, Session-Übernahme, Stripe-Testmodus, Inhaltsverzeichnis und festen Zählwerten.