ARCH-2026-006 – Nachweisbarer Deployment- und Produktionsstand mit Drift-Erkennung¶

Status: Entwurf
Proposal-Status: under_review
Kategorie: architecture
Erstellt: 2026-07-07
Stand: 2026-07-07
Geprüfter Repository-Stand: f84c881aace65ff9aa857b43fc2de4b0a7998397

Anlass¶

Immohai dokumentiert Modell-, Engine- und teilweise Integrationsstände bereits in mehreren Dateien. Nach einem Deployment fehlt jedoch eine einzige belastbare technische Aussage darüber, welcher geprüfte Release tatsächlich in der produktiven App und Dokumentation aktiv ist.

Der aktuelle Deploymentpfad prüft Erreichbarkeit sowie Modell- und Engineversion, erzeugt aber keinen dauerhaft referenzierbaren Deploymentnachweis und erkennt keine Abweichung zwischen erwartetem Release, aktiven Containern, ausgelieferten App-Dateien, Dokumentationsstand und manueller Statusdokumentation.

Entstehung dieses Proposals¶

Auf dem geprüften main-Stand existierten ursprünglich nur ARCH-2026-001 bis ARCH-2026-005.

ARCH-2026-006 wird als eigenständiges neues Proposal erfasst, weil nach der Erweiterung von ARCH-2026-004 und ARCH-2026-005 eine klar abgrenzbare Restverantwortung verbleibt:

ARCH-2026-004
  erzeugt einen reproduzierbaren, unveränderbaren Release

ARCH-2026-005
  verifiziert den tatsächlich integrierten Repository-Commit

ARCH-2026-006
  weist nach, welcher Release in welcher Umgebung tatsächlich aktiv ist
  und erkennt Drift zwischen erwartetem und beobachtetem Produktionsstand

Bestätigte Teilentscheidung 1 – Umfang¶

Am 2026-07-07 wurde Variante B bestätigt:

ARCH-2026-006 wird nicht auf zusätzliche HTTP-Smoke-Checks nach dem
Deployment begrenzt.

Das Proposal definiert einen nachweisbaren Deployment- und Produktionsstand
mit eindeutiger Deployment-ID, Releasebezug, technischen Komponentenständen,
Post-Deployment-Verifikation, Browserabnahme-Referenz und Drift-Erkennung.

App und Dokumentation müssen denselben erwarteten Release-Bundle-Stand
nachweisen. Der beobachtete Produktionsstand wird gegen den freigegebenen
Release und den erfolgreichen IntegrationVerificationRecord geprüft.

Manuell wiederholte Commit- und Versionsangaben in README, Deploymentdoku
oder Arbeitsstand sind nicht die technische Produktionswahrheit.

Die konkrete Record-Ablage, Manifest-URL, Drift-Frequenz und Aufbewahrung bleiben Gegenstand weiterer Einzelentscheidungen.

Ausgangsproblem¶

Der aktuelle Ablauf ist vereinfacht:

main aktualisieren
-> Regressionen ausführen
-> docker compose up
-> lokale URLs prüfen
-> öffentliche URLs optional prüfen
-> Modell- und Engineversion aus App-Manifest vergleichen
-> Commit, Modell und Engine im Terminal ausgeben

Nicht formal nachgewiesen werden:

welcher unveränderbare Release aktiviert wurde
welches Web-Artefakt tatsächlich läuft
welches Docs-Artefakt tatsächlich läuft
ob App und Doku demselben Release-Bundle entsprechen
welcher IntegrationVerificationRecord den Release freigegeben hat
ob Runtime-Baseline und erwartete Containerstände übereinstimmen
ob Browserabnahme für genau diesen Release durchgeführt wurde
ob der aktuelle Zustand vom erwarteten Produktionsstand abweicht
welcher vorherige Release für Rollback verfügbar ist

Relevanter bestehender Stand¶

Betroffene Dateien und Prozesse mindestens:

scripts/deploy-and-verify.sh
docker-compose.yml
deploy/nginx/default.conf
frontend/assets/config/model-manifest.json
model/config/model-manifest.json
docs/operations/deployment.md
docs/operations/browser-acceptance.md
docs/roadmap/current-status.md
README.md
.github/workflows/contract-check.yml

Angrenzende Architektur-Proposals:

ARCH-2026-001
  Frontend-State, Render-Orchestrierung und View-Eigentümerschaft

ARCH-2026-002
  Snapshot-basierte Reportdatenpipeline

ARCH-2026-003
  schlanke Architecture Decision Records und Ablösung

ARCH-2026-004
  reproduzierbare Prüf-, Release- und Container-Baseline

ARCH-2026-005
  Post-Merge-Verifikation des integrierten Repository-Standes

Nachgewiesene aktuelle Lücken¶

1. Kein autoritativer DeploymentRecord¶

Nach einem Deployment existiert kein standardisierter maschinenlesbarer Nachweis mit mindestens:

Deployment-ID
Umgebung
Release-ID
Git-Commit
Integrationsnachweis
Web-Artefakt
Docs-Artefakt
Runtime-Baseline
Zeitpunkt
Ergebnis der technischen Verifikation
Ergebnis oder Referenz der Browserabnahme
vorheriger Release

2. Öffentliche Prüfung kontrolliert nur Modell und Engine¶

Das aktuelle Deploymentskript liest das veröffentlichte Modellmanifest und prüft:

model_version
calculation_engine_version

Zwei technisch unterschiedliche Releases können dieselben Modell- und Engineversionen besitzen.

Damit wird nicht bewiesen, dass exakt der erwartete Git-Commit oder das erwartete Release-Artefakt läuft.

3. App und Dokumentation können auseinanderlaufen¶

Die aktuelle App und Dokumentation werden über getrennte Container und getrennte öffentliche Endpunkte ausgeliefert.

Ohne gemeinsame Release-Bundle-ID kann nicht eindeutig erkannt werden:

App neu, Doku alt
App alt, Doku neu
unterschiedliche Git-Commits
unterschiedliche Runtime-Baselines
nur ein Service erfolgreich aktualisiert

4. Produktiver Stand wird mehrfach manuell beschrieben¶

README, Deploymentdokumentation, Arbeitsstand und Browserabnahme enthalten manuell gepflegte Angaben zu:

Modellversion
Engineversion
Integrationscommit
Deploymentstatus
Pull-Request-Status

Diese Angaben können untereinander konsistent und trotzdem gegenüber dem tatsächlich laufenden System veraltet sein.

5. Browserabnahme besitzt keinen technischen Record-Bezug¶

Das aktuelle Browserabnahmeprotokoll enthält Felder für Integrationscommit, Deploymentzeitpunkt und öffentliches Manifest, bleibt aber ein manuell gepflegter Dokumentblock.

Es fehlt eine stabile Referenz auf:

Deployment-ID
Release-ID
IntegrationVerificationRecord
konkrete App- und Docs-Artefakte

6. Deployment und Produktabnahme sind nicht sauber getrennt¶

Technisch erfolgreiche Bereitstellung und fachlich-visuelle Browserabnahme sind unterschiedliche Zustände.

Der aktuelle Prozess unterscheidet nicht formal zwischen:

deployed
  Release wurde aktiviert

technical_verified
  Endpunkte, Manifeste und Komponenten stimmen

accepted
  erforderliche interaktive Browserabnahme ist abgeschlossen

7. Keine Drift-Erkennung¶

Nach erfolgreichem Deployment gibt es keinen bewussten Wiederholungslauf, der den erwarteten Produktionsstand mit dem beobachteten System vergleicht.

Mögliche Drift:

Container manuell neu gestartet oder ersetzt
bewegliches Image neu gezogen
Dateien im Bind-Mount verändert
nur App oder nur Doku aktualisiert
Release-Manifest und aktive Dateien widersprechen sich
Reverse-Proxy zeigt auf falschen Service
Dokumentation nennt alten Commit
Rollback wurde durchgeführt, aber nicht dokumentiert

8. Rollback wird nicht als neues Deploymentereignis dokumentiert¶

Ein Rollback verändert den aktiven Produktionsstand. Ohne eigenen DeploymentRecord bleibt unklar:

welcher Release zurückgenommen wurde
welcher frühere Release wieder aktiviert wurde
warum der Rollback erfolgte
ob die Verifikation danach erfolgreich war

Zielprinzip¶

erfolgreich integrierter Commit nach ARCH-2026-005
-> reproduzierbarer Release nach ARCH-2026-004
-> Deployment in definierte Umgebung
-> DeploymentRecord erzeugen
-> lokalen Laufzeitstand beobachten
-> öffentliche App und Doku prüfen
-> erwarteten und beobachteten Stand vergleichen
-> technische Verifikation abschließen
-> interaktive Browserabnahme referenzieren
-> Produktionsstatus accepted oder Abweichung dokumentieren

Der technische Produktionsstand ergibt sich aus überprüfbaren Release- und Laufzeitinformationen, nicht aus manuell wiederholten Textangaben.

Geltungsbereich¶

ARCH-2026-006 umfasst:

eindeutige Deployment-ID
Umgebungsidentität
Verknüpfung zu Release-ID und Git-Commit
Verknüpfung zu IntegrationVerificationRecord
DeploymentRecord und aktueller EnvironmentState
beobachtete App- und Docs-Artefaktidentitäten
öffentliche Release-Manifeste
Vergleich von erwartetem und beobachtetem Zustand
Post-Deployment-Smoke- und Manifestprüfung
Drift-Erkennung
Browserabnahme-Referenz
Trennung von deployed, technical_verified und accepted
Rollback als nachvollziehbares Deploymentereignis
Aufbewahrung früherer Deploymentnachweise
Reduktion manueller doppelter Produktionswahrheiten

Nicht Teil dieses Proposals:

Frontend-State oder Rendererlogik aus ARCH-2026-001
Reportdaten oder Reportrenderer aus ARCH-2026-002
ADR-Lifecycle aus ARCH-2026-003
Build, Image-Pinning, Artefakterzeugung oder Aktivierungstechnik aus ARCH-2026-004
Post-Merge-Repositoryprüfung aus ARCH-2026-005
allgemeine Serverüberwachung oder Observability-Plattform
zentrales Logging-System
Backend oder Datenbank
fachliche Modell- oder Engineänderung
automatische Browserabnahme ohne menschliches Review

Abgrenzung zu ARCH-2026-001¶

ARCH-2026-001 definiert den internen Analyse- und Renderzustand der Frontend-App.

ARCH-2026-006 betrachtet ausschließlich den technischen Zustand einer bereitgestellten Umgebung.

AnalysisState
  Zustand einer Immobilienanalyse im Browser

EnvironmentState
  Zustand eines ausgelieferten Immohai-Releases in einer Umgebung

Diese Zustände dürfen weder dasselbe Objekt noch dieselbe Statuslogik verwenden.

Abgrenzung zu ARCH-2026-002¶

ARCH-2026-002 definiert Reportdaten und reporttypspezifische ViewModels.

ARCH-2026-006 bewertet keine Reports und erzeugt keine fachlichen Reportinhalte. Es prüft nur, dass die erwartete App- und Dokumentationsversion ausgeliefert wird und die erforderliche Browserabnahme für diesen Release referenziert ist.

Abgrenzung zu ARCH-2026-003¶

ARCH-2026-003 definiert Proposal-, ADR- und historische Entscheidungsnachweise.

Deploymentstatuswerte sind davon getrennt:

Proposal-Status
  new | under_review | accepted | rejected | deferred | integrated

ADR-Relevanz
  current | partial | historical

Deploymentstatus
  technisch definierter Zustand einer Umgebung

Ein DeploymentRecord ist keine ADR und keine fachliche Entscheidung.

Abgrenzung zu ARCH-2026-004¶

ARCH-2026-004 verantwortet:

fixierte Runtime-Baseline
kanonischen Contract Check
reproduzierbare Web- und Docs-Artefakte
Release-ID
Aktivierungs- und Rollbackmechanismus

ARCH-2026-006 übernimmt weder Build noch Aktivierungstechnik.

Wesentliche Grenze:

ARCH-2026-004 beantwortet:
  Wie wird ein Release gebaut, identifiziert, aktiviert und rückrollbar gehalten?

ARCH-2026-006 beantwortet:
  Welcher Release ist nach der Aktivierung tatsächlich in der Umgebung aktiv,
  stimmt der beobachtete Stand mit dem erwarteten Stand überein und ist die
  erforderliche Abnahme für genau diesen Release dokumentiert?

ARCH-2026-004 darf den DeploymentRecord technisch erzeugen oder anstoßen. Semantik, Vergleichsregeln und Produktionswahrheit gehören zu ARCH-2026-006.

Abgrenzung zu ARCH-2026-005¶

ARCH-2026-005 verifiziert den integrierten Repository-Commit vor Release und Deployment.

IntegrationVerificationRecord
  Nachweis des geprüften Repository-Standes

DeploymentRecord
  Nachweis eines konkreten Deploymentereignisses

EnvironmentState
  aktuell beobachteter Zustand einer Umgebung

Ein erfolgreicher IntegrationVerificationRecord beweist nicht, dass dieser Stand produktiv läuft. Ein erfolgreicher DeploymentRecord beweist nicht rückwirkend, dass ein ungeprüfter Commit integriert werden durfte.

Umgebungen¶

Für den aktuellen privaten MVP genügt mindestens:

production

Optional später:

local
staging
production

Jede Umgebung besitzt eine eindeutige ID. Umgebungsspezifische Secrets oder Zugangsdaten dürfen nicht in Records, Repository oder öffentliche Manifeste gelangen.

Release-Bundle¶

App und Dokumentation gehören zu einem gemeinsamen Immohai-Release-Bundle:

release_id
  gemeinsamer fachlich-technischer Releasebezug

web_artifact_identity
  konkrete App-Ausgabe

docs_artifact_identity
  konkrete Dokumentationsausgabe

App und Doku dürfen unterschiedliche Artefaktdigests besitzen, müssen aber dieselbe erwartete release_id und denselben git_commit ausweisen, sofern sie aus demselben Repository-Release stammen.

Öffentliches Release-Manifest¶

Jede ausgelieferte Komponente soll ein kleines technisches Manifest bereitstellen.

Empfohlene Mindestfelder:

release_manifest_schema_version
release_id
git_commit
component
artifact_identity
built_at
runtime_baseline_version
model_version
calculation_engine_version
schema_versions

Mögliche Komponenten:

web
docs

Konkrete Pfade bleiben offen, beispielsweise:

/assets/config/release-manifest.json
/release-manifest.json

Das Manifest enthält keine Secrets, Benutzerinformationen oder privaten Finanzdaten.

DeploymentRecord¶

Empfohlene Mindeststruktur:

deployment_record_schema_version
deployment_id
environment
release_id
git_commit
integration_verification_id
runtime_baseline_version
web_artifact_identity
docs_artifact_identity
previous_release_id optional
deployment_started_at
deployment_completed_at optional
technical_verified_at optional
accepted_at optional
status
expected_state
observed_state
verification_results
browser_acceptance_reference optional
rollback_of_deployment_id optional
failure_summary optional

Der Record ist technische Betriebsevidenz und kein fachlicher Datenvertrag.

EnvironmentState¶

Der aktuelle EnvironmentState ist eine kompakte Sicht auf den zuletzt beobachteten Stand:

environment
active_deployment_id
expected_release_id
observed_release_id
expected_git_commit
observed_web_git_commit
observed_docs_git_commit
web_artifact_identity
docs_artifact_identity
runtime_baseline_version
last_verified_at
technical_status
acceptance_status
drift_findings

Der EnvironmentState darf aus DeploymentRecord und aktueller Beobachtung abgeleitet werden. Er soll nicht als parallele manuell gepflegte Wahrheit entstehen.

Deploymentstatus¶

Empfohlene technische Statuswerte:

planned
  DeploymentRecord erzeugt, Aktivierung noch nicht begonnen

deploying
  Aktivierung läuft

deployed
  Aktivierung technisch abgeschlossen, Verifikation noch offen

technical_verified
  erwarteter und beobachteter technischer Stand stimmen überein

accepted
  erforderliche interaktive Abnahme ist abgeschlossen

failed
  Aktivierung oder Pflichtverifikation fehlgeschlagen

rolled_back
  Deployment wurde durch einen anderen Release ersetzt oder zurückgenommen

Diese Statuswerte sind unabhängig von Proposal- und ADR-Status.

Technische Verifikation¶

Nach Aktivierung sind mindestens zu prüfen:

lokale App erreichbar
lokale Doku erreichbar
öffentliche App erreichbar
öffentliche Doku erreichbar
Web-Manifest lesbar
Docs-Manifest lesbar
beide Manifeste nennen erwartete Release-ID
beide Manifeste nennen erwarteten Git-Commit
Artefaktidentitäten entsprechen dem DeploymentRecord
Modell-, Engine- und Schemaversionen entsprechen dem Release
aktive Runtime-Baseline entspricht Erwartung
Nginx- und Cache-Verhalten bleiben korrekt
keine Pflichtkomponente fehlt

Ein Release darf nur technical_verified werden, wenn alle Pflichtvergleiche erfolgreich sind.

Drift-Erkennung¶

Drift liegt vor, wenn erwarteter und beobachteter Zustand voneinander abweichen.

Mindestens zu erkennen:

release_id_mismatch
web_commit_mismatch
docs_commit_mismatch
web_docs_release_mismatch
web_artifact_mismatch
docs_artifact_mismatch
runtime_baseline_mismatch
model_version_mismatch
engine_version_mismatch
schema_version_mismatch
endpoint_unreachable
manifest_missing
manifest_invalid
browser_acceptance_missing
manual_state_documentation_stale

Nicht jede Drift ist gleich kritisch.

Empfohlene Kategorien:

critical
  erwarteter Release läuft nicht oder App und Doku widersprechen sich

warning
  technische Ausgabe stimmt, aber Abnahme- oder Dokumentationsreferenz fehlt

informational
  nicht produktionskritische Metadatenabweichung

Die genaue Schweregradmatrix bleibt eine offene Einzelentscheidung.

Wiederholungsprüfung¶

Der Produktionsstand soll bewusst erneut geprüft werden können:

nach jedem Deployment
nach jedem Rollback
manuell bei Verdacht auf Drift
vor einer wichtigen Abnahme oder Demonstration
optional später zeitgesteuert

Für den ersten privaten MVP ist kein dauerhaftes Monitoring-System erforderlich. Ein deterministischer manueller oder workflowbasierter Wiederholungslauf genügt.

Browserabnahme¶

Die interaktive Browserabnahme bleibt ein eigener bewusster Schritt.

Zielverknüpfung:

BrowserAcceptanceRecord
  deployment_id
  release_id
  git_commit
  Browser und Auflösung
  Prüffälle
  Ergebnis
  Abweichungen
  Prüfer und Datum

Der technische Status kann technical_verified sein, obwohl die Browserabnahme noch aussteht.

accepted ist erst zulässig, wenn die nach docs/operations/browser-acceptance.md erforderlichen Fälle für genau denselben Deployment- und Releasebezug abgeschlossen sind.

Eine rein automatisierte Headless-Browserprüfung ersetzt die interaktive Abnahme nicht.

Autoritative Produktionswahrheit¶

Die technische Produktionswahrheit soll sich zusammensetzen aus:

freigegebener Release nach ARCH-2026-004
+ erfolgreicher IntegrationVerificationRecord nach ARCH-2026-005
+ DeploymentRecord
+ beobachtete öffentliche Release-Manifeste
+ BrowserAcceptanceRecord, soweit erforderlich

README, current-status.md und Deploymentdokumentation dürfen diesen Stand erklären oder referenzieren, sollen ihn aber nicht unabhängig durch mehrfach kopierte Commitwerte neu definieren.

Vermeidung eines Commit-Zyklus¶

Der aktuelle Produktionsstand darf nicht zwingend in denselben Repository-Commit zurückgeschrieben werden, den er beschreibt. Sonst entsteht ein unauflösbarer Zyklus:

Commit A wird deployt
-> Produktionsstatus wird in Commit B dokumentiert
-> Commit B wäre anschließend der neueste Repository-Stand,
   aber nicht der ursprünglich deployte Release

Empfohlene Richtung:

DeploymentRecord und EnvironmentState repository-extern oder als
Workflow-/Serverartefakt speichern

Repositorydokumentation referenziert das System und seine Regeln,
nicht zwingend jeden aktuellen Wert

Eine separate unveränderbare Deploymenthistorie auf dem Server oder als Workflow-Artefakt ist zulässig. Die konkrete Ablage bleibt offen.

Rollback¶

Ein Rollback ist ein neues nachvollziehbares Deploymentereignis:

fehlgeschlagenes oder zurückgenommenes Deployment markieren
-> vorherigen freigegebenen Release aktivieren
-> neuen DeploymentRecord mit rollback_of_deployment_id erzeugen
-> technische Verifikation wiederholen
-> Browserabnahme nach Risikobewertung wiederholen

Der vorherige Record wird nicht überschrieben.

Sicherheits- und Datenschutzgrenzen¶

Nicht in öffentliche Manifeste oder DeploymentRecords gehören:

Secrets
Tokens
Passwörter
private Schlüssel
interne Zugangsdaten
personenbezogene Finanzdaten
vollständige reale Objektadressen
unnötige Serverdetails

Zulässig sind technische IDs, öffentliche Domains, Modell- und Engineversionen sowie Artefaktidentitäten.

Auswirkungen auf Architektur, Roadmap und Spezifikation¶

Architektur:

Deploymentereignis und aktueller EnvironmentState werden explizite technische Konzepte.
Repository-, Release- und Produktionszustand bleiben getrennt, aber referenziert.

Roadmap:

Stabilisierung des produktiven Betriebs
keine neue Produktfunktion
sinnvoll nach oder gemeinsam mit ARCH-2026-004 und ARCH-2026-005

Spezifikation:

Deployment- und Browserabnahmedokumentation werden nach Annahme ergänzt.
Keine fachliche Modellspezifikation wird geändert.

Auswirkungen auf Formeln, KPIs und Datenverträge¶

keine Änderung
keine Modellversion
keine Engineversion
keine Änderung fachlicher Schemas

DeploymentRecord, EnvironmentState und ReleaseManifest erhalten eigene technische Versionen außerhalb der fachlichen Schemafamilie.

Auswirkungen auf UI, Reporting und Speicherung¶

keine Änderung der Immobilienanalyse-UI
keine Änderung fachlicher Reports
keine Änderung von PropertyInput, AnalysisResult oder PropertyRecord
keine neue Browserpersistenz

Optional kann eine technische Versionsanzeige oder ein Diagnoseendpunkt später ergänzt werden. Dies ist keine fachliche Produktfunktion.

Auswirkungen auf Tests und Referenzfälle¶

Erforderlich:

DeploymentRecord referenziert gültigen Release und Integrationsnachweis
Web- und Docs-Manifeste sind valide
App und Doku nennen dieselbe Release-ID
App und Doku nennen denselben erwarteten Git-Commit
Artefaktidentitäten entsprechen dem aktivierten Release
falscher Commit wird als Drift erkannt
nur ein aktualisierter Service wird als Drift erkannt
fehlendes Manifest blockiert technical_verified
öffentliche und lokale Endpunkte werden getrennt geprüft
BrowserAcceptanceRecord kann eindeutig zugeordnet werden
Rollback erzeugt neuen Record und erhält Historie
manuelle Statusdokumentation wird nicht als technische Wahrheit verwendet
keine Secrets werden serialisiert

Referenzfälle:

normaler erfolgreicher Produktionsrelease
App aktuell, Doku veraltet
Doku aktuell, App veraltet
beide erreichbar, aber falsche Release-ID
Modell und Engine gleich, Git-Commit unterschiedlich
Rollback auf vorherigen Release
technisch verifiziert, Browserabnahme ausstehend
Browserabnahme für falsche Deployment-ID
manuelle Änderung eines aktiven Artefakts

Legacy- und Migrationsfolgen¶

keine Datenmigration
bestehende PropertyRecords bleiben unverändert
ältere Deployments besitzen rückwirkend nicht zwingend vollständige Records
der aktuelle produktive Stand wird bei Einführung als initiale Baseline erfasst
manuelle Statusangaben bleiben historisch erhalten, verlieren aber ihre Rolle als technische Wahrheit
bestehende Ports und öffentlichen URLs bleiben unverändert

Für den initialen DeploymentRecord muss klar gekennzeichnet werden, welche Informationen beobachtet und welche nur aus vorhandener Dokumentation übernommen wurden.

Risiken¶

zu komplexes Betriebsmodell für eine private App
DeploymentRecord und EnvironmentState werden doppelt gepflegt
öffentliche Manifeste geben unnötige technische Details preis
Records gehen durch begrenzte Workflow-Artefakt-Retention verloren
Drift-Check meldet harmlose Unterschiede als kritisch
Browserabnahme bleibt trotz Record-Verknüpfung manuell veraltet
Rollbackhistorie wird unvollständig
ARCH-2026-004 und ARCH-2026-006 duplizieren Aktivierungslogik

Gegenmaßnahmen:

kleines Record-Schema
EnvironmentState aus Records und Beobachtung ableiten
keine Secrets oder internen Pfade veröffentlichen
klare Eigentümerschaft gegenüber ARCH-2026-004
zunächst manuelle Wiederholungsprüfung statt Monitoringplattform
Retention und serverseitige Historie bewusst festlegen

Sicherungs- und Rückfallstrategie¶

Vor Integration:

aktuellen produktiven Commit dokumentieren
aktuelle Container-IDs, Image-IDs und Digests sichern
aktuelle Compose-Konfiguration sichern
lokale und öffentliche App-/Docs-Antworten prüfen
aktuelle Modell- und Engine-Manifeste speichern
Browserabnahmestand sichern
vorherigen funktionierenden Release nach ARCH-2026-004 verfügbar halten

Rollback der ARCH-2026-006-Mechanik:

zusätzliche Record- und Drift-Prüfung deaktivieren
bestehende Endpoint- und Manifestprüfung weiterverwenden
keine fachlichen Daten betroffen
bereits erzeugte Records nicht löschen

Empfohlene Umsetzungsstruktur nach vollständiger Annahme¶

Phase 0
  ARCH-2026-004 Artefakt- und Release-ID festlegen
  ARCH-2026-005 IntegrationVerificationRecord festlegen

Phase 1
  ReleaseManifest, DeploymentRecord und EnvironmentState spezifizieren
  aktuelle Produktion als initiale Baseline erfassen

Phase 2
  Web- und Docs-Release-Manifeste ausliefern
  Post-Deployment-Vergleich implementieren

Phase 3
  DeploymentRecord und technische Statusübergänge einführen
  Rollback als eigenes Ereignis dokumentieren

Phase 4
  Browserabnahme eindeutig mit Deployment-ID verbinden
  manuelle Produktionsangaben in Dokumenten reduzieren

Phase 5
  bewussten Drift-Wiederholungslauf und Retention etablieren

Weitere offene Einzelentscheidungen¶

2. Record-Ablage
   GitHub-Artefakt, serverseitige Historie oder Kombination?

3. Manifest-Pfade
   Wo werden Web- und Docs-Release-Manifeste veröffentlicht?

4. Statusmodell
   Welche Deploymentstatuswerte sind zwingend?

5. Drift-Schweregrade
   Welche Abweichungen sind critical, warning oder informational?

6. BrowserAcceptanceRecord
   eigene Datei, Recordfeld oder referenziertes Protokoll?

7. Retention
   wie viele Deployment- und Rollbackrecords bleiben erhalten?

8. Wiederholungsrhythmus
   nur nach Deployment und manuell oder zusätzlich zeitgesteuert?

9. Dokumentationsdarstellung
   welche manuellen produktiven Commitangaben werden entfernt oder nur referenziert?

10. Initiale Baseline
    wie wird der bereits laufende produktive Stand ohne vollständige historische Evidenz erfasst?

Entscheidungsmehrwert¶

eindeutig nachweisbarer produktiver Release
klare Trennung von Repository-, Release- und Environmentzustand
App und Dokumentation werden als gemeinsames Release-Bundle geprüft
Drift wird sichtbar statt durch manuelle Dokumentation verdeckt
Browserabnahme ist exakt einem Deployment zugeordnet
Rollback bleibt historisch nachvollziehbar
keine mehrfach gepflegte technische Produktionswahrheit
bessere Fehleranalyse bei abweichenden öffentlichen Ständen

Prüfergebnis¶

Die aktuelle Architektur besitzt bereits einzelne Bausteine:

Modell- und Engineversionen
Integrationscommit in Dokumenten
lokale und öffentliche Endpointprüfungen
Browserabnahmeprotokoll

Diese Bausteine ergeben jedoch noch keinen autoritativen, maschinenlesbaren und wiederholbar überprüfbaren Produktionsstand.

Nach Abgrenzung zu ARCH-2026-004 und ARCH-2026-005 bleibt ARCH-2026-006 als eigenständige Architekturverantwortung erforderlich:

nicht Release bauen
nicht Repository integrieren
sondern laufenden Environmentzustand nachweisen und Drift erkennen

Entscheidung¶

Teilentscheidung 1 am 2026-07-07 bestätigt:

Variante B – nachweisbarer Deployment- und Produktionsstand mit
DeploymentRecord, EnvironmentState, öffentlichen Release-Manifeste,
Browserabnahme-Referenz und Drift-Erkennung.

App und Dokumentation müssen denselben erwarteten Release-Bundle-Stand
nachweisen. Manuell kopierte Commit- oder Versionsangaben sind nicht die
autoritative technische Produktionswahrheit.

Gesamtentscheidung: offen
Proposal-Status: under_review

Zieldokumente bei späterer Annahme¶

technische Definition ReleaseManifest
technische Definition DeploymentRecord
technische Definition EnvironmentState
scripts/deploy-and-verify.sh
neues Deployment-State- oder Drift-Prüfskript
docker-compose.yml
Release-Builddefinitionen aus ARCH-2026-004
frontend-Auslieferungsartefakt
statisches Docs-Auslieferungsartefakt
docs/operations/deployment.md
docs/operations/browser-acceptance.md
docs/specification/architecture/overview.md
docs/specification/architecture/project-structure.md
docs/specification/data-quality-and-validation/validation.md
docs/roadmap/current-status.md
README.md
mkdocs.yml

Integrationscommit¶

offen