Technische Spec

Beobachteter Startpfad

Der Mechanismus entscheidet nicht aus einem Label wie Install, Restore oder Upgrade. Komponenten dürfen zusammenarbeiten; Übergangsverantwortung und aktuelle Fertigmeldung müssen eindeutig sein. Nach jeder Zustandsänderung wird erneut beobachtet.

until serving():
    local = observe_local_state()
    if local.exists:
        engine version vs local.version:
            equal:    serving()
            engine >: migrate(local)
            engine <: abort("downgrade")
    else:
        backup = observe_backup()
        if backup.valid: restore(backup)
        else:            init()

Auswertung

Gültiger lokaler Zustand und gleiche Version

Die Anwendung kann bedienen.

Gültiger lokaler Zustand und neuere Engine

Die native produktspezifische Migration läuft. Nicht unterstützte Übergänge oder Fehler stoppen den Start; Erfolg führt zur erneuten Beobachtung.

Gültiger lokaler Zustand und ältere Engine

Der Start bricht als unzulässiger Downgrade ab.

Kein lokaler Zustand und gültiger Sicherungsstand

Der neueste geprüfte Stand für Kunde und Anwendung wird nativ wiederhergestellt. Fehler stoppen den Start; Erfolg führt zur erneuten Beobachtung.

Kein lokaler Zustand und kein Sicherungsstand

Native Initialisierung erzeugt neuen Zustand. Fehler stoppen den Start; Erfolg führt zur erneuten Beobachtung. Eine fehlgeschlagene Backup-Abfrage ist kein fehlender Sicherungsstand.

Ungültige, unvollständige, widersprüchliche oder nicht beurteilbare Eingaben

Der Start bricht kontrolliert ab, bevor Zustand verändert oder bedient wird.

Invarianten des Mechanismus

Eine Implementierung folgt dem Muster nur, wenn diese Eigenschaften über alle Startfälle erhalten bleiben.

Eine Entscheidungsschleife

Normalstart, Erstinitialisierung und Restore beginnen mit derselben Beobachtung und verwenden dieselben Abbruchbedingungen.

Fail-closed

Beschädigter oder teilweise erzeugter Zustand, unvollständige Sicherungen und widersprüchliche Versionen werden nicht als leerer Startzustand umgedeutet.

Prüfung vor Verwendung

Ein Sicherungsstand wird erst nach erfolgreicher Prüfung seiner Veröffentlichung, seines Inventars und seiner Integrität wiederhergestellt.

Migration gehört zum Produkt

Bartl koordiniert den Übergang. Vorhandene native Initialisierung und Migration bleiben beim Produkt; ergänzt werden nur fehlende Beobachtung, Koordination und Prüfung.

Erneute Beobachtung

Initialisierung, Restore und Migration führen zurück an den Anfang. Erst ein gültiger kompatibler Zustand erreicht serving().

Kontrollierter Abbruch

Downgrade, Inkonsistenz und fehlende Voraussetzungen enden sichtbar. Der Mechanismus rät keinen Ersatzwert und überspringt keine Prüfung.

Pflichten der Anwendung

Die Anwendung liefert die konkreten Verfahren für ihren eigenen Zustand. Eine gemeinsame Entscheidungsstruktur verlangt weder identischen Code noch einen universellen Operator. Mehrere Komponenten können über ein eindeutiges Protokoll zusammenarbeiten.

• Zustandsgrenze: eigenes vollständiges Inventar und Konsistenzbeziehungen deklarieren; fremde oder gemeinsam genutzte Persistenz nur innerhalb ausdrücklich zugewiesener Verantwortung verändern.
• Beobachtung: leeren, gültigen, unvollständigen, beschädigten und nicht beurteilbaren Zustand samt relevanter Version zuverlässig unterscheiden; Marker allein genügen nicht.
• Lifecycle: Normalstart, Initialisierung, Restore und Migration aus derselben Beobachtung ableiten; native Fehler stoppen den Start, erfolgreiche Änderungen führen zur erneuten Beobachtung.
• Sicherung und Rekonstruktion: vollständige konsistente Recovery-Punkte erzeugen, vor Verwendung prüfen und ohne Quelle wiederherstellen; Software, Schlüssel und Zielvoraussetzungen benennen.
• Sichere Ausführung: Unterbrechungen, Wiederholungen und konkurrierende Änderungen beherrschen; veraltete Fertigmeldungen und ungeprüfte Teilzustände dürfen keine Bedienung freigeben.
• Ergebnisprüfung: native Übergangsergebnisse vor dem normalen Start prüfen und Fehler maschinenlesbar melden. Die Paketqualifikation belegt die vereinbarte Fachleistung; sie ist keine privilegierte Abnahme bei jedem Start.

Nachweise für die Katalogaufnahme

Je Anwendung wird zunächst eine begründete unterstützte Konfiguration mit Releases, Übergängen, Persistenz und Zielvoraussetzungen festgelegt. Die folgenden Fälle benötigen ausführbare Nachweise mit konkreten Artefakten und Aussagegrenzen. Einzelne bestandene Fälle sind keine vollständige Qualifikation; ein gemeinsamer Test-Runner ist nicht vorgeschrieben.

• Erstinitialisierung: nachweislich leerer eigener Zustand ergibt durch native Initialisierung eine nutzbare Installation, sowohl ohne konfigurierten Backup-Store als auch mit einem Store ohne Sicherung.
• Normaler Wiederanlauf: gültiger Zustand und Identität bleiben ohne Backup-Zugriff, erneute Initialisierung oder unnötigen Restore erhalten.
• Restore ohne Quelle: der neueste geprüfte vollständige Stand für Kunde und Anwendung stellt die vorgesehenen Daten, Identitäten und Rechte wieder her.
• Versionswechsel: unterstützte native Migration gelingt; unbekannte Übergänge und Downgrades werden ohne destruktiven Ersatzpfad abgewiesen.
• Unterbrechung und Wiederholung: Teilzustände werden erkannt; Wiederholung, konkurrierende Ausführung und veraltete Fertigmeldungen enden sicher.
• Fehlende oder widersprüchliche Eingaben: unerreichbarer Speicher, beschädigte Daten und unvollständige Backups werden nicht zur Erlaubnis für eine leere Installation.
• Fremder Zustand: ein Fehler der Anwendung setzt weder eine gemeinsam genutzte Datenbank noch einen anderen Dienst zurück.
• Fachliche Abnahme: die Paketqualifikation belegt die vereinbarte Nutzbarkeit nach jedem unterstützten Übergang; ein erfolgreicher Container oder Job reicht nicht.

Ausführbare WordPress-Referenz

bartl-wordpress illustriert den Startmechanismus für eine konkrete WordPress-, MySQL- und Docker-Compose-Konfiguration. Die folgenden Angaben beschreiben die vorhandene Referenz, nicht zusätzliche normative Startbedingungen. Ihr Nachweis ist keine pauschale Bestätigung aller Katalogfälle.

Deklarierter Zustand

MySQL-Datenbank und wp-content/uploads

Unveränderliches Release

WordPress-Core, Plugins und Themes im Image

Sicherungsformat

database.sql, uploads.tar, state.json und SHA256SUMS in einem Archiv

Veröffentlichung

Archiv plus .sha256-Sidecar, wobei das Sidecar als Commit-Marker zuletzt erscheint

Restore

Neuester vollständig veröffentlichter Stand auf einem leeren kompatiblen Ziel

Fehlerverhalten

Auf einem leeren Ziel Abbruch bei fehlendem Store-Mount sowie immer bei unvollständigem Paar, falschen Prüfsummen oder ungültigem Inventar

Aussagegrenze

Die Spec beschreibt nur den Startmechanismus für Anwendung und deklarierten Zustand.

Die WordPress-Referenz belegt diese Eigenschaften nur für ihre festgeschriebene Konfiguration. Andere Anwendungen benötigen ein eigenes Zustandsinventar, Sicherungsformat, Migrationslogik und ausführbaren Nachweis.