P0 · Adapter operations
Adapter Recovery
Runbook
Timeout nie mówi, czy operacja się nie wydarzyła. Runbook oddziela bezpieczny retry od konfliktu idempotency, quarantine i ręcznego recovery.
- Deterministic
- Idempotency-first
- No execution
no payloadRunbook czeka na fixture
Uruchom bezpieczny timeout albo kontrolowany konflikt. Zobaczysz decyzję retry, wymagania idempotency, recovery steps i granicę rollbacku.
Runbook wydaje rekomendację dla deklarowanych metadanych. Nie odczytuje stanu providera, nie uruchamia adaptera i nie wykonuje retry, rollbacku ani zmiany polityki produkcyjnej.
Recovery bez zgadywania
Cztery bramki przed kolejną próbą.
Klasa błędu to dopiero początek. Decyzja retry musi uwzględnić skutek uboczny, spójność requestu, budżet prób i możliwość odtworzenia stanu.
- 01Classify
Rozdziel timeout, rate limit, błąd auth, schemat i odrzucenie biznesowe.
- 02Protect identity
Dla operacji zmieniającej stan zachowaj ten sam klucz i fingerprint.
- 03Observe state
Sprawdź correlation_id, zanim timeout zamienisz w kolejne create.
- 04Recover deliberately
Retry, quarantine lub compensating action wymagają jawnego evidence.
Granica automatyzacji
Recommended action ≠ executed action.
Publiczny runbook nie zna rzeczywistego stanu dokumentu ani kontraktu providera. Rekomendacja jest hipotezą operacyjną dla fixture; wykonanie wymaga odczytu stanu, autoryzowanego środowiska, polityki klienta i decyzji odpowiedzialnego operatora.
Dołącz decyzję do Evidence Packa →Pilot dwóch adapterów
Testuj nie tylko sukces, ale też kontrolowane awarie.
W pilocie definiujemy idempotency key, retry budget, quarantine, correlation i recovery evidence osobno dla każdego kontraktu.
Sprawdź zakres pilota