Team workflows: specs in code review

Спор о сорока строках спеки стоит минуты; тот же спор над двумя тысячами строк готового diff стоит итерации переделки и чьей-то мотивации. Поэтому в командном SDD ревью спеки — отдельный гейт до начала реализации: спека публикуется как маленький PR (только spec.md), и реализация не стартует до его апрува.

Кто участвует: автор спеки, инженер, который будет вести реализацию (если это разные люди), и представитель продукта, если фича пользовательская. Смежные команды зовутся, когда спека трогает их контракты — общий API, общие данные. Что проверяет ревьюер спеки — три вопроса. Полнота: все ли роли, состояния и негативные сценарии названы; самый дешёвый способ — мысленно пройти путь злонамеренного или невезучего пользователя. Непротиворечивость: не конфликтуют ли критерии между собой и с constitution; классика — критерий скорости против критерия полноты данных. Проверяемость: каждый ли критерий можно превратить в тест; если нет — возвращаем на доработку по шаблонам второго урока.

Частое возражение: «это же водопад, мы теряем скорость». Опыт обратный: гейт занимает часы, а отменяет он недельные переделки. Водопад — это когда спека замораживается на год; здесь она живёт и меняется, просто изменения проходят через тот же дешёвый гейт. Скорость команды определяется не скоростью печати — с агентами она бесконечна, — а числом переделок.

Когда реализация готова, PR оформляется так, чтобы ревьюер мог принять его по контракту, а не расшифровывать намерения по diff. Шаблон описания PR:

## Спека
specs/001-csv-export/spec.md (апрув: #142)

## Критерии
- [x] AC-1: 10k строк < 5с — тест ac1.spec.ts
- [x] AC-2: 403 для viewer — тест ac2.spec.ts
- [ ] AC-6: фоновый экспорт — отложен, issue #157

## Изменения спеки в этом PR
AC-4 уточнён: кодировка UTF-8 with BOM.

Ревью сгенерированного кода отличается от классического. Вычитывать построчно две тысячи сгенерированных строк — бессмысленно и не нужно: корректность поведения уже доказывается тестами по критериям. Ревьюер работает сверху вниз: сверяет чек-лист критериев с тестами (все ли AC закрыты, честные ли тесты); проверяет, что изменения спеки в PR осмысленны и апрувнуты; и выборочно ныряет в рискованные места — безопасность, деньги, миграции, конкурентность — где цена ошибки оправдывает построчное чтение.

Красные флаги, требующие остановки: PR меняет поведение без изменения спеки (привет, drift из прошлого урока); тесты переписаны так, что критерий формально зелёный, но проверяет меньше, чем обещает; в diff есть код, не сводимый ни к одной задаче из tasks.md, — самодеятельность генератора, которую нужно либо легализовать, либо убрать.

В команде, где часть кода пишут агенты, роли смещаются, и полезно назвать их явно. Владелец спеки — человек, отвечающий за контракт фичи: он сводит вердикты re-sync, апрувит изменения критериев, его слово решает споры о поведении. Драйвер реализации — тот, кто ведёт агентов по конвейеру: отвечает на clarify, ревьюит план, принимает задачи. Ревьюер — внешние глаза: проверяет PR по чек-листу критериев. В маленькой команде две первые роли часто совмещаются; совмещать драйвера и ревьюера не стоит — теряется смысл внешней проверки.

Constitution из третьего урока на командном уровне превращается в главный разгрузочный механизм ревью. Всё, что записано в constitution — стек, стандарты тестов, правила обработки ошибок, запреты, — не обсуждается в каждом PR заново: ревьюер ссылается на пункт, а не ведёт дискуссию. Спор в комментариях PR, повторившийся дважды, — кандидат на новый пункт constitution: решите один раз и ссылайтесь.

Отдельный выигрыш — онбординг. Новый инженер (или новый агент) читает constitution и три-четыре спеки ключевых модулей — и получает то, что раньше добывалось месяцем вопросов в чатах: что система обязана делать, чего ей делать нельзя и почему. Спеки здесь работают документацией, которая не врёт, — ровно потому, что процессы предыдущих уроков не дают ей отстать от кода.

Процесс, который не мерят, деградирует молча. Для командного SDD достаточно четырёх метрик, каждая считается почти бесплатно из git и трекера.

Доля PR со спекой — какой процент содержательных PR ссылается на спеку (правки опечаток не в счёт). Здоровье — рост к 80–90%; падение означает, что команда возвращается к ad-hoc, обычно под дедлайном, и это разговор про приоритеты, а не про дисциплину. Spec churn — сколько раз спека правится после старта реализации. Ноль — подозрительно (спеку не сверяют с реальностью), постоянный шторм правок — сигнал, что гейт ревью спеки пропускает сырые контракты: clarify отрабатывают формально. Rework rate — доля задач, возвращённых с приёмки или ревью на переделку. Это главная метрика, ради которой всё затевалось: у команд на ad-hoc промптинге она достигает трети задач; работающий SDD давит её кратно. Время до первого ревью спеки — сколько спека ждёт первых глаз. Если дни, гейт стал бутылочным горлышком, и команда начнёт его обходить; лечится нормой «ревью спеки — в течение рабочего дня» и малым размером спек.

Важно, чем эти метрики не являются: это термометр процесса, а не KPI людей. Как только spec churn попадает в персональные цели, спеки перестают править после старта — вместе с правдой в них. Смотрите на тренды по команде, обсуждайте на ретро, и метрики останутся полезными.