Runbook rollbacku

Jak deployujecie: [DEPLOY]. Czy są migracje: [MIGRACJE]. Czy jest feature flag: [FLAG].

NIE pisz wiki. NIE rollback biznesowy (zwroty, maile do klientów). NIE zgaduj platformy.
Jeśli [DEPLOY] puste - zapytaj Vercel / k8s / VM / inny i stop. Bez sposobu wdrożenia nie ma rollbacku.
Jeśli [MIGRACJE] puste - w sekcji danych `[DO UZUPEŁNIENIA]`, nie zgaduj że schematu nie ruszacie.
Jeśli zmiana to docs - stop, ten skill nie jest potrzebny.

Zwracasz jedną stronę:

# Rollback: [nazwa zmiany, 6 słów]
Czas docelowy: 15 min od decyzji.

## Sygnał
co znaczy "wracamy" (health, error rate, jeden kanoniczny request). Próg liczbowy, nie "jakoś wolno".

## Rollback kodu
dokładna komenda albo klik, nie "wróć poprzednią wersję":
- Vercel: `vercel rollback <url-poprzedniej>` albo promote poprzedniej deployment
- k8s: `kubectl rollout undo deploy/<nazwa>` albo pin image:digest
- VM: poprzedni artefakt (ścieżka / tag), komenda restartu
Podaj kto zatwierdza (rola, nie imię zmyślone).

## Rollback danych
osobna sekcja. Legalne odpowiedzi:
- migracja w dół: komenda + czas + czy jest backup
- migracja tylko w górę: rollback kodu BEZ DB; co zostaje w schemacie
- "nie da się" - napisz wprost, co wtedy (restore snapshot, feature off, hotfix)

## Flaga
jeśli [FLAG] jest - najpierw wyłącz flagę (nazwa, panel, stan bezpieczny). Rollback artefaktu drugi.

## Weryfikacja po
1. health endpoint
2. jeden request kanoniczny (ścieżka + oczekiwany status/ciało)
3. metryka, która spadła, wraca (nazwa + okno)

Na dole: czego ten runbook NIE pokrywa (3 punkty). Dywiz "-".