# Код-ревью

Код-ревью в Agent Teams строится вокруг задачи. Вы смотрите изменения конкретной задачи, а не огромный неструктурированный diff.

## Поверхность ревью

Для каждой завершённой задачи, затронувшей файлы, review UI позволяет:

- Смотреть changed files с контекстом до/после
- Принимать или отклонять отдельные hunks
- Оставлять inline comments
- Связывать diff с описанием задачи и логами агента

## Решения на уровне hunk

Принимайте маленькие правильные изменения и отклоняйте отдельные ошибки без удаления всей работы. Это полезно, когда агент в целом решил задачу, но переборщил в одном файле.

::: tip Принимайте по частям
Если diff в основном верен, сначала примите хорошие hunks и запросите правки только для проблемных частей. Это не даёт доске застопориться.
:::

## Инициирование ревью

1. Откройте завершённую задачу
2. Перейдите на вкладку **Changes**
3. Если diff выглядит разумно, нажмите **Request Review**, чтобы переместить задачу в колонку review

Во время ревью задача ещё не считается завершённой, поэтому другие teammates или lead могут всё ещё комментировать её.

## Состояния ревью

| Состояние | Значение |
|-----------|---------|
| `none` | Задача новая, в работе или завершена, но ещё не на ревью |
| `review` | Задача активно на ревью |
| `needsFix` | Запрошены правки; владелец должен обновить до повторного approve |
| `approved` | Ревью принято, задача финализирована |

## Рабочий процесс ревью агентами

Команды могут ревьюить работу друг друга до вашего финального решения. Это ловит очевидные регрессии, но risky areas всё равно стоит проверять вручную.

## Участники ревью

Team lead — ревьюер по умолчанию. Вы можете настроить дополнительных ревьюеров в настройках Kanban, если хотите, чтобы peers ревьюили работу друг друга.

## Что проверять вручную

Приоритетные области при ревью:

- **Provider auth и runtime detection** — не сломает ли агент настройку runtime для других путей?
- **IPC, preload и filesystem boundaries** — сохраняйте разделение ответственности Electron
- **Git и worktree behavior** — проверяйте имена веток, коммиты и push
- **Parsing и task lifecycle logic** — изменения в task references, chunking или filtering могут сломать доставку сообщений
- **Persistence и code review flows** — изменения в хранении задач или review state должны оставаться консистентными через IPC layers

## Верификация

Лучше запускать focused verification commands. Broad formatting или lint-fix команды не стоит использовать, если задача явно не про форматирование.

::: warning Не запускайте автоформатирование по всему проекту
Если задача не специфически про форматирование, избегайте `pnpm lint:fix` на несвязанных файлах. Это создаёт шум в review surface.
:::