Ревью кода

Ветка готова к проверке. Как получить разбор, который остаётся в проекте и привязан к задачам.

Ситуация

Ветка готова. Нужен разбор — не «выглядит нормально», а конкретные замечания. И нужно, чтобы разбор не потерялся в чате: через две недели, когда всплывёт та же проблема, полезно видеть, что о ней уже говорили.

Что делаете вы

Решаете, что делать с замечаниями. Ревью — это мнение, а не приговор. Часть замечаний вы отклоните, и это нормально.

Запускаете повторно после правок. Каждый прогон добавляет итерацию, а не затирает предыдущую: видно, что изменилось между заходами.

Что делает агент

в сессии агента, на ветке с готовым кодом

/flownix-review AF-TASK-42

Слаг можно и не называть — тогда ревью будет по текущему дифу и ни к чему не привязано. Привязка к задаче стоит одного слова и окупается через две недели.

Что за этим стоит:

get_node_by_slug(slug: "AF-TASK-42") — что вообще должно было получиться.
rag_query по затронутой подсистеме: замечание «так у нас не делают» должно опираться на то, где это записано.
Разбор дифа git diff и формулировка замечаний.
create_review с хэшем коммита и текстом заключения, set_review_nodes — привязка к задачам.

Повторный прогон после правок добавляет итерацию (add_review_iteration), а не затирает предыдущую:

в сессии агента, после правок

/flownix-review AF-TASK-42

Что получится

Ревью живёт во вкладке «Ревью» проекта, привязанное к задачам, с историей итераций. Из задачи видно, что её ревьюили; из ревью — какие задачи оно затрагивает.

Повторные прогоны накапливаются: первая итерация с замечаниями, вторая после правок, третья если понадобилась. История правок видна целиком.

Границы

Агент не заменяет ревьюера-человека там, где решение архитектурное. Он хорошо находит несоответствие принятым решениям и невнимательность; он плохо решает, стоит ли вообще делать так, как сделано.

Качество замечаний зависит от того, что записано в проекте. На проекте без спеки и без документов агенту не с чем сверять — он скатится в общие советы про стиль.