Шаблон описания Pull Request

Напиши описание PR по теме «{{pr_topic}}». Тикет: {{tracker_link}}.

Базовая аксиома: PR-описание — это подарок ревьюеру и будущему археологу. У них нет твоей контекстной памяти. Если ревьюер тратит 10 минут чтобы понять «что это и зачем» — описание плохое.

Шаблон

## What
<Одна-две фразы по-человечески. БЕЗ «реализован PaymentService». С «пользователь теперь может оплатить картой».>

## Why
<Бизнес-цель. Что было раньше / какой багу/боль это решает. Ссылка на тикет/спеку обязательна.>

## How
<Короткое технологическое объяснение: какие куски тронуты, какой подход выбран, какие альтернативы отвергли и почему. 3-6 буллетов.>

## How to test
1. `git checkout this-branch && pnpm i && pnpm dev`
2. Открой http://localhost:3000/checkout
3. Выбери способ оплаты «карта»
4. Введи 4242 4242 4242 4242, любую дату, любой CVC
5. Жми «оплатить» → должно появиться «Спасибо за заказ» + email в почте

(не «потестируйте оплату» — конкретные шаги, конкретные ожидания)

## Risks
- Меняется DB-схема — миграция `20250517_add_payment_method.sql`, не откатывается без потери данных
- Включается за фича-флагом `payments_v2`, выключено по умолчанию
- Зависит от прод-секрета `STRIPE_KEY` (уже в Vault)
- Touch: 14 файлов; основной риск — `apps/checkout/page.tsx` (рендер дерева пересобран)

## Out of scope
- Apple Pay — отдельный PR #1234
- Перевод текстов — после QA

## Screenshots / Recordings
| До | После |
|---|---|
| ![before](url) | ![after](url) |

(для UI-изменений — обязательно. Для backend — не нужно)

## Related
- Ticket: PROJ-123
- Spec / ADR: notion.so/...
- Depends on: #1230 (must merge first)
- Follow-up: #1240 (after this)
- Slack discussion: link

## Checklist
- [ ] Тесты добавлены / обновлены
- [ ] Документация обновлена (README / API docs / changelog)
- [ ] Миграция / фича-флаг готовы
- [ ] Замер производительности (если затрагивает hot path)
- [ ] Self-review сделан (прошёл по diff'у глазами)

Принципы по секциям

Title

• < 70 символов, в императиве: «Add card payment to checkout»
• Префикс по convention (feat:, fix:, refactor:) если в команде принято
• Не «WIP», не «fixes», не «small change»

What

• В первой фразе: поймёт ли менеджер?
• Не пересказ кода — результат для пользователя/системы
• Если PR чисто-технический (рефакторинг) — так и напиши «внутреннее: разделил X на Y, поведение не меняется»

Why

• Без «почему» PR — это загадка. Через год никто не помнит
• Ссылка на тикет/issue/спеку — must. Если нет тикета — короткий контекст в теле
• Для багфиксов: цитата шага репро / стек-трейса

How

• Не пересказывай diff — ревьюер видит его сам
• Объясни выбор: «почему именно так, а не иначе»
• Перечисли неочевидные изменения (миграции, конфиги, env)
• Если есть TODO/known issue — назови их прямо в How, не прячь в коде

How to test

• Конкретные шаги от git checkout. Не «запусти тесты»
• Указать env vars, фикстуры, тестовые карты, тестовые юзеры
• Что считать «прошло» vs «не прошло»
• Для бэка — curl команда или Postman-коллекция

Risks

• Что может сломаться в проде: миграция, перформанс, обратная совместимость API, breaking change SDK
• Rollback план: «как откатить если что» (revert + redeploy / down-migration / фича-флаг off)
• Дата/окно деплоя если важно (не катить в пятницу)

Screenshots

• До/после side-by-side, не одно «после»
• Для responsive — desktop и mobile
• Для анимации — gif/loom, не статика
• Скриншот error state, если правил error handling

Related

• Тикет (всегда)
• Зависимости (depends on #X / blocks #Y)
• Документ дизайна / ADR / RFC
• Slack/Discord-обсуждение, где принималось решение

Checklist

• Не лей чек-листа на 30 пунктов — никто не читает
• Только то, что реально проверяется (миграция, флаг, тест, docs)
• Self-review — обязательно: пройдись по diff'у в UI GitHub до того, как звать ревьюера

Анти-паттерны

• ❌ Пустое описание / «see commits»
• ❌ Только Jira-ссылка без контекста — ревьюер должен открывать ещё одно окно
• ❌ Title «fixes», «updates», «WIP» — не информативно
• ❌ «Тестируйте сами» вместо шагов
• ❌ Скрытые breaking changes без отметки в Risks
• ❌ Миграция без указания обратимости
• ❌ Скриншот «после» без «до» — непонятно что изменилось
• ❌ PR на 2000 строк диффа без объяснения структуры — никто не ревьюит внимательно
• ❌ Игнор review comments без ответа — повторно отправляешь и удивляешься
• ❌ Merge без своего же self-review
• ❌ Подмешано несвязанное («ну заодно поправил линтер») — ревьюер не знает, что критично
• ❌ Спрятанные TODO в коде, не упомянутые в описании

Что отдать

Готовое описание для своего PR по шаблону выше, с заполненными секциями (или прямо «нет» — не пропускать, а отвечать). После — self-review своего же diff'а перед запросом ревью.