Opis PR z konsekwencją

Diff albo lista commitów: [DIFF]. Ticket (opcjonalnie): [TICKET]. Jak testowałeś: [TESTY].

NIE recenzuj ludzi. NIE recenzuj diffa (to `review-senior`). Tu autor pisze PR, zanim ktoś recenzuje.
Jeśli [DIFF] puste - poproś o `git diff <target>...HEAD` albo listę commitów i stop.
Jeśli to jeden-linijkowy draft "do siebie na jutro" - jedno zdanie i stop, nie szablon.

Zwracasz gotowy opis do wklejenia:

## Tytuł
skutek dla użytkownika albo systemu, max ~70 znaków, tryb rozkazujący. Zero "fix stuff", zero "WIP", zero em dash.

## Cel
1-3 zdania: co będzie prawdą po merge. Jeśli [TICKET] jest - link w pierwszej linii.

## Poza zakresem
3 rzeczy, których ten PR NIE robi (żeby recenzent nie dopisywał).

## Test plan
komendy albo klikalna ścieżka z [TESTY]. Zakaz: "przetestowane lokalnie", "działa u mnie". Każdy punkt = da się powtórzyć na CI albo na staging. Jeśli [TESTY] puste - w tej sekcji `[DO UZUPEŁNIENIA]`, nie zmyślaj komend.

## Ryzyko
co może paść (dane, auth, kontrakt API, perf). Jeśli nic - napisz "niskie" i dlaczego w 1 zdaniu, nie zostawiaj puste.

## Rollback
jedna z opcji, konkret:
- revert SHA (podaj jak powstanie po merge)
- feature flag (nazwa flagi + stan bezpieczny)
- migracja wstecz (komenda albo "migracja tylko w górę")
Jeśli rollbacku nie ma - napisz wprost "nie da się" i co wtedy (hotfix, restore backup). Milczenie zakazane.

## Checklist
- [ ] suita zielona
- [ ] sekrety nie w diffie
- [ ] rollback przeczytany

Sąsiad `review-senior` idzie na ten sam diff PO otwarciu PR. Dywiz "-".