# Playbook для каждого PR

## Основной принцип

Каждый PR должен быть завершенным вертикальным срезом, а не "заготовкой под будущее".

Хороший PR:
- добавляет новый работающий путь;
- переводит на него всех потребителей в рамках выбранного сценария;
- удаляет старый путь или фиксирует короткий staged cutover `expand -> migrate -> contract`, если live-safe sequence не позволяет удалить его сразу;
- обновляет docs;
- обновляет Issues.

Плохой PR:
- добавляет сервис, но не переводит вызовы;
- добавляет таблицы, но оставляет старые таблицы рабочими без плана удаления;
- редактирует уже применённые миграции вместо новой forward-only миграции;
- ломает `proto`, OpenAPI, AsyncAPI или обязательный env без согласованного обновления потребителей и live rollout path;
- обновляет код без документации;
- оставляет "temporary" код без issue на удаление.

## Обязательная структура этапного PR

1. Краткое описание доменного среза.
2. Список use cases, которые теперь принадлежат новому сервису.
3. Список новых таблиц и БД.
4. Список обновленных gRPC вызовов.
5. Список удаленного legacy-кода.
6. Список обновленных документов.
7. Список связанных Issues и их новый статус.

## Definition of Done для PR

PR можно считать готовым только если одновременно выполнены все условия:
- есть новый сервис или новый завершенный доменный срез;
- все нужные потребители переведены на новый gRPC API;
- legacy code path удален или имеет явный staged cutover с ближайшим срезом удаления;
- ownership данных описан явно;
- миграции и backfill описаны и проверены; уже применённые migration-файлы не редактируются;
- документация обновлена;
- Issues обновлены;
- тесты покрывают новый поток.

## Обязательные проверки в ревью

Ревьюер и агент обязаны проверить:
- нет ли прямого доступа к чужой БД;
- не появился ли новый shared repository package с доменной логикой;
- удален ли старый путь действительно полностью;
- обновлены ли docs не только для архитектуры, но и для продукта;
- есть ли явный owner у нового сервиса;
- есть ли live-safe rollout/cutover notes для миграций, контрактов, env/secrets/config и deploy path.

## Минимальный набор артефактов в PR

### Код
- сервис
- proto
- клиенты
- миграции
- конфигурация
- тесты

### Документация
- сервисный README
- архитектурные markdown-файлы
- продуктовая документация
- ADR при изменении boundaries
- changelog или release notes, если в репозитории это принято
- live-safe rollout/cutover notes, если меняются миграции, контракты, env/secrets/config или deploy path

### Управление задачами
- ссылка на эпик этапа
- ссылка на подзадачу удаления legacy-кода
- ссылка на подзадачу docs update
- ссылка на post-merge cleanup issue, если что-то осталось строго по делу

## Когда нужно заводить ADR

ADR обязателен, если PR:
- меняет ownership таблиц;
- меняет число целевых сервисов;
- объединяет или разделяет bounded contexts;
- вводит новый cross-service контракт;
- меняет порядок этапов roadmap.

## Когда PR надо останавливать

PR нужно вернуть на доработку, если:
- в нем остался старый код "на всякий случай";
- нет обновления markdown-документации;
- новый сервис все еще ходит в shared DB старого домена;
- не перечислено, что именно удалено;
- phase issue не обновлен;
- старый и новый путь работают параллельно без явной причины.
- breaking change не имеет staged path или согласованного обновления всех live-потребителей.
