OPERATIONAL_RUNBOOK_RECOVERY

Operational Runbook and Recovery#

Zweck#

Dieses Runbook realisiert GAP KT-0021. Es ermöglicht , Wiederanlauf, Recovery und Übergabe ohne Chat-Vorwissen.

Kanonische Eingaben#

Eine produktive Ausführung beginnt ausschließlich mit:

gap-000.zip
                source_bundle.zip
                target_bundle.zip

Vor jedem Schreibzugriff muss erfolgreich laufen. GAP-Manifest, aktiver Work Item, Allowed Target Scope und Source-Bundle-Hash sind anschließend die alleinige Prozessautorität.

Operator-Ablauf#

Eingabearchive unverändert in einen neuen Arbeitsbereich kopieren.
aller drei Archive erfassen.
Bundle ausführen und Ergebnis sichern.
GAP AI_STARTS_HERE.md, Manifest, Contracts und aktiven Work Item lesen.
Zielrepositorys nur im Allowed Target Scope entpacken und bearbeiten.
Vor produktiven Änderungen einen Checkpoint mit Zustand prepared schreiben.
Während der Ausführung Checkpoint auf executing setzen und jede geänderte Repository-Identität erfassen.
Repository-Validierungen durchführen.
Checkpoint erst nach erfolgreicher atomarer Validierung auf validated setzen.
Vollständige Einzel-ZIPs erzeugen und clean-unpack prüfen.
Checkpoint auf handoff-ready setzen und Hashes der Auslieferungen erfassen.
GAP aktualisieren, ausliefern und stoppen.

Checkpoint-Zustände#

prepared → executing → validated → handoff-ready
                                    ↘ failed

Ein Zustand darf nicht übersprungen werden. failed ist terminal für den betreffenden Versuch; ein Wiederanlauf erzeugt einen neuen Versuch mit Verweis auf den unterbrochenen Versuch.

Unterbrechung und Wiederanlauf#

Nach Unterbrechung:

Originalarchive erneut hashen.
Letzten Checkpoint lesen.
Source-Bundle-Hash und GAP-Baseline mit dem Checkpoint vergleichen.
Vorhandene Ausgaben als unvertrauenswürdig behandeln, solange handoff-ready nicht erreicht wurde.
Bei prepared oder executing aus unveränderten Eingaben in einem neuen Arbeitsverzeichnis neu starten.
Bei validated Packaging und clean-unpack erneut durchführen; Validierung darf erneut ausgeführt werden.
Bei handoff-ready Auslieferungshashes prüfen; bei Abweichung neu paketieren.
Bei veränderten Eingaben, unauflösbarer Identität oder Scopeabweichung blockieren und keine vorhandenen Zwischenstände übernehmen.

Recovery-Regeln#

Source Bundle bleibt unverändert; eine Hashabweichung blockiert Recovery.
Target Bundle ist ausschließlich Eingabecontainer und wird niemals zurückgegeben.
Teilpakete gelten nicht als vollständige Auslieferung.
Ein neuer Versuch darf nur aus verifizierten Eingaben oder einem vollständig validierten Checkpoint fortgesetzt werden.
Wiederholte Validatorausführung muss idempotent sein: dieselben Eingaben ergeben dieselbe fachliche Entscheidung; Zeitstempel und Evidence-Hashes dürfen neu entstehen.
Recovery führt weder Deployment noch aus.

Operator-Handover#

Eine Übergabe ist vollständig, wenn sie enthält:

GAP-, Source- und Target-Archivhashes,
GAP-Version und aktiven Work Item,
Allowed Target Scope,
letzten Checkpointzustand,
geänderte und unveränderte Repositorys,
Validatorergebnisse,
Auslieferungsdateien und ,
bekannte Findings und blockierende Fehler,
eindeutige nächste Aktion.

Ausführbare Prüfung#

python 40-validation/validate-operational-recovery.py   <gap-root> <repository-roots> <runtime-root>   --source-bundle <source_bundle.zip>   --checkpoint <checkpoint.json>   --work-item KT-0021

Der Validator prüft Runbook-Vollständigkeit, Recovery-Entscheidung, unveränderte Source-Evidenz und Phase-4-Kriterien. Er verändert keine Eingaben, installiert nichts und führt keine aus.