# Код-ревью

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

## Review surface

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

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

## Hunk-level decisions

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

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

## Запуск review

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

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

## Состояния review

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

## Agent review workflow

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

## Участники review

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

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

Приоритет при review:

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

## Verification

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

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