1490da10f9
Add task lifecycle diagram, review states, auth configuration blocks, common member states, CLI auth diagnostic, and safe-cleanup guidance. Synchronize EN and RU pages for runtime-setup, agent-workflow, code-review, and troubleshooting.
63 lines
4.2 KiB
Markdown
63 lines
4.2 KiB
Markdown
# Код-ревью
|
||
|
||
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.
|
||
:::
|