Lock Recovery

Stand: 2026-05-26

Ziel

Lock Recovery behandelt orphaned, failed-release, stale, expired und emergency-hold Locks nachvollziehbar und approval-basiert. Es gibt kein Blind Release und kein Loeschen von Lock-Historie.

Recovery States

• orphaned
• failed_release
• stale
• expired
• emergency_hold

Erlaubte Actions

• mark_reviewed
• release_after_verification
• expire_after_verification
• keep_blocking
• escalate_to_manual_hold

Nicht erlaubt:

• hard_delete_lock
• blind_release
• overwrite_lock_owner
• bypass_policy

Approval Model

Jede Recovery braucht eine eigene Approval-ID:

• target_system=dependency_locks
• action_type=lock_recovery
• lock_id
• object_id
• reason
• verification_required=true
• audit_required=true

Verification vor Recovery

Vor release_after_verification oder expire_after_verification muss geprueft werden:

• Zielobjekt existiert noch oder dessen Fehlen ist verstanden.
• Es laeuft keine aktive Chain fuer das Objekt.
• Es gibt keinen ungeprueften offenen Rollback.
• State/Drift ist konsistent oder bewusst akzeptiert.
• Policy/Risk ist nach Recovery akzeptabel.

Empfohlene Operator-Reihenfolge:

1. inspect_lock
2. inspect_chain_status
3. state_drift_check
4. recovery_preflight
5. recovery_approval_request
6. release_after_verification nur nach gueltiger Approval

mock_noop ist kein Recovery-Ersatz. Es darf nicht als Freigabe- oder Sicherheitsnachweis fuer orphaned, failed-release oder stale Locks verwendet werden.

API

• GET /dependency-locks/recovery-policy
• POST /dependency-locks/recovery/preflight
• POST /dependency-locks/recovery/approve-request
• POST /dependency-locks/recovery/execute

Operator UX

Recovery-Previews muessen ruhig und konservativ wirken:

• orphaned: Chain vermutlich abgebrochen oder Abschluss nicht sauber dokumentiert.
• failed_release: Lock-Freigabe ist fehlgeschlagen; Objektzustand muss geprueft werden.
• stale: Zeitfenster ist abgelaufen, aber das ist kein automatischer Freibrief.
• expired: Status ist abgelaufen oder markiert; Review bleibt Pflicht.
• emergency_hold: blockiert bewusst und darf nicht normal released werden.

Release ist nur erlaubt, wenn:

• Zielobjekt und Chain-Status geprueft sind.
• State/Drift konsistent oder bewusst akzeptiert ist.
• Kein offener Rollback uebersprungen wird.
• Policy/Risk nach Recovery akzeptabel ist.
• Eine gueltige Recovery-Approval vorliegt.

Nicht erlaubt:

• Hard Delete
• Blind Release
• Auto-Release nur wegen Timeout
• Recovery ohne State-/Drift-/Policy-Review

execute verbraucht die Approval-ID. Replay wird blockiert.

Recovery UX

Recovery-Antworten enthalten fuer OpenCode:

• operator_summary
• recovery_artifact
• Recovery-Grund
• Verification-Checkliste
• empfohlene Aktion
• Manual-Review-Warnung
• exakter Freigabetext
• Impact-Hinweis

OpenCode soll bei Lock Recovery zuerst den Changeplan anzeigen. Execute ist nur mit gueltiger Recovery-Approval-ID erlaubt.

Zusätzlich wird unified_operator_response geliefert. Fuer Recovery ist action_classification=recovery; OpenCode soll highlight_recovery=true und manual_review_required=true prominent anzeigen.

Audit

Jeder Schritt schreibt ein Audit-Event mit:

• recovery_id
• approval_id
• lock_id
• alter Status
• neuer Status
• Verifier
• Verification Result
• Reason
• Timestamp
• Audit Reference

Secrets werden nicht gespeichert.