Altlasten: Erneuerung und Inhaltsreview

Vertrag: ADR-0058. Wiederherstellung #556.

Aktuellen Zustand lesen

Maßgeblich ist die öffentliche Provenance, insbesondere activeRelease.id, activationRef.pointerVersion und freshness.state/freshUntil. Der Abrufzeitpunkt ist technisch, kein fachlicher Datenstand. Ein historischer Produktionsnachweis garantiert keine heutige Frische. Der Report zeigt bei gesperrter Quelle „Altlasten-Prüfung für diese Adresse nicht verfügbar.“ Das ist kein Nullbefund. Persistierte Reports behalten ihren damaligen Zustand.

Täglicher Betrieb und rechtzeitige Warnung

Der Workflow renew-altlasten-snapshot.yml läuft täglich ab 03:37 UTC; GitHub kann den tatsächlichen Start verzögern. Drei vollständig identische Abrufe sind Pflicht. Die Frist beträgt unverändert höchstens 48 Stunden, die Erneuerungsreserve 24 Stunden. Nur ein vollständig inhalts- und vertragsgleicher Abruf bei offenem Public-Gate darf automatisch erneuert werden. Ein bereits abgelaufener Release braucht auch bei gleicher Quelle eine explizite Aktivierung.

Jede Änderung bleibt gesperrt: qualifizierter Kandidat, fehlgeschlagener Renewal, GitHub-Fehlerannotation und Job Summary mit aktiver Frist, separater Kandidatenfrist, Public-Gate und Published-/Source-Delta. Der Admin zeigt bei einem neueren erfolgreichen, nicht aktiven Altlastenimport ausdrücklich den offenen Kandidaten. Ein technischer Importerfolg ist keine Inhaltsfreigabe.

Die Actions-Artefakte altlasten-renewal-review-<run> enthalten Ergebnis und geometriefreies Quellinventar (UBAID, Scopeklassifikation, Zeilen- und Geometriehash). Sie bleiben 90 Tage im bestehenden Repositorykanal. Keine Rohgeometrie, Report-ID oder Zugangsdaten hineinschreiben. Bei langfristiger Reviewpause die Inventare vor Ablauf privat sichern; nach Ablauf ist die Detailrekonstruktion außerhalb des Produktscopes gegebenenfalls nicht mehr möglich. Ein Abruffehler vor einem vollständigen Snapshot erzeugt kein scheinbares Inventar.

Der stündliche Driftmonitor zeigt außerdem due ab 24 Stunden vor Ablauf und stale nach Ablauf im Admin. Am 5. September war dessen vorhandene Mailzustellung wegen einer unverifizierten Resend-Domain fehlgeschlagen. Mail ist deshalb kein abgenommener Warnkanal. GitHub-Actions und Adminstatus sind der überprüfbare Reviewweg; die Zustelllücke ist offen. #556 verändert keine Mail-/DNS-Einstellungen und versendet keine Testmail. Die verantwortliche Projektbetreuung prüft einen roten Renewal vor der im Summary genannten aktiven Frist.

Review ohne Mutation

Mit bestehendem projektbezogenem DB-Zugang in der Prozessumgebung:

node scripts/review-altlasten-snapshot.mjs /privater/pfad/altlasten-review.json

Das Script liest den neuesten qualifizierten Kandidaten, vergleicht beide Published-/Excluded-Bestände feldweise und liest die amtliche Quelle erneut vollständig dreimal. Ein abweichender aktueller WFS oder ein zwischenzeitlich geänderter Pointer stoppt den Review. Die Ausgabe enthält keine Rohgeometrien. automaticApproval: false ist verbindlich: Auch unveränderte Geometrien erlauben keine allgemeine Ausnahme für neue Attributänderungen.

Vor Aktivierung prüfen: exakter Release/Manifest, aktiver Pointer-CAS, aktuelle Uhrzeit und Frist, Rechte-/Scope-/Transformbindung, neun erforderliche Qualitätsprüfungen, gespeicherte Zeilen gegen den aktuellen WFS und konkreter Einfluss auf den Report. Gleiche Counts genügen nie. Fehlende historische Quellenzeilen ausdrücklich als Evidenzlücke behandeln. Eine neue unbekannte Änderung braucht eine neue Entscheidung.

Kontrollierte Aktivierung

Die Entscheidung dokumentiert Zielrelease, Gesamtmanifest, Expected-Current, Rechteentscheidung, Delta, Gültigkeit und Rückweg. Nach PM-Abnahme:

node scripts/publish-altlasten-release.mjs \
  --activate-release=<geprüfter-release> \
  --expected-current-release=<frisch-gelesener-aktiver-release> \
  --confirmation='ACTIVATE altlasten public'

Kein direktes UPDATE auf Fristen, Rechte oder Pointer. Danach öffentlichen Release/Pointer, neue anonyme öffentliche Referenzreports (Hit/No-Hit) und Web/API/PDF rücklesen. Keine bestehenden persönlichen Reports suchen oder ändern. Den normalen Renewal-Pfad erneut ausführen: Bei ausreichender Reserve ist ein belegter Skip korrekt; ein erzwungener Fristwechsel wäre es nicht. Einen kontrollierten Lauf nie als bereits erfolgten nächsten planmäßigen Lauf ausgeben.

Rollback und Wiederanlauf

Der generische Rollback verlangt einen früher aktivierten und weiterhin frischen und zulässigen Release, aktuellen CAS, Operation-ID und Grund:

node scripts/publish-altlasten-release.mjs \
  --rollback-to=<zulässiger-früherer-release> \
  --expected-current-release=<aktueller-release> \
  --rollback-reason='<konkreter-grund>' \
  --confirmation='ROLLBACK altlasten public'

Der Initialrelease vom 26. August ist seit 28. August stale und damit kein verwendbares Rollbackziel für #556. Ein Code-Rollback auf den vorherigen Main-Commit lässt das unveränderte DB-Schema und den freigegebenen Quellenpointer bestehen. Bei einem Quellenproblem gibt es ohne frischen früheren Release keinen zulässigen Datenrollback: Review stoppen, keine Folgeaktivierung, geschlossene Gates respektieren und nach frischem Drei-Pass-Abruf einen neuen Kandidaten qualifizieren und separat entscheiden. Kein Wiederbeleben alter Daten durch Fristverlängerung. Stale-/Rechte-/Rollback-Sperren werden lokal getestet, nicht absichtlich in Produktion ausgelöst.