63 lines
4.3 KiB
Markdown
63 lines
4.3 KiB
Markdown
# Код-ревью
|
||
|
||
Код-ревью в 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.
|
||
:::
|