Выполнение по спецификации

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

Выполняй и анализируй расхождения​

Для каждого цикла работы:

Изучи одобренное намерение + текущий код
  ↓
Спланируй следующее ограниченное изменение
  ↓
Выполни и проверь
  ↓
Сравни результат со спецификацией

Анализ расхождений задаёт вопросы:

1. Какие намерение и границы установила спецификация?
2. Что на самом деле делает текущий код?
3. Чего не хватает, что противоречит требованиям, а что лишнее?
4. Какое одобренное решение разрешает каждое дополнительное поведение?
5. Реализация отклонилась от курса или новые данные показали, что спецификация неверна?

Невыполненное требование порождает следующий план реализации. Неодобренный дополнительный код удаляют или откладывают. Если находка обосновывает изменение цели, относись к ней как к доказательству, а не разрешению: преврати её в предложение о пересмотре спецификации и получи одобрение до продолжения реализации. Решение о приемлемости оставшегося расхождения может признавать явный недостаток или компромисс; оно не должно молча узаконивать дополнения, которых никто не разрешал. Так спецификация сохраняет силу, не притворяясь безошибочной.

Глубина проверки должна соответствовать риску. Обратимому изменению может хватить одного сравнения и обычных тестов. Построчное ревью diff находится на дорогом конце шкалы: это наиболее подробная форма проверки человеком, доступная лишь квалифицированным инженерам. Оставляй её для изменений, последствия которых оправдывают такие затраты. Для большинства задач достаточны проверка результата по критериям и границам спецификации и запуск CI. Работа с более высоким риском может оправдывать независимых проверяющих, более сильные доказательства для приёмки или ручное исследование опасных путей. Выбор такого контроля описан в главе «Рычаги надёжности».

Спецификация, больше не отражающая одобренное намерение, вредна. Обновляй её при изменении решений или перестань использовать её как контракт. Не заставляй будущие запуски согласовывать заведомо устаревший артефакт с текущим кодом.

Когда оставшееся расхождение приемлемо, вступает в действие обычный процесс ревью команды. Передавай одобренное намерение вместе с изменениями кода: предоставь полную спецификацию, выдели её ключевые намерение и границы либо добавь ссылку или вложение в pull request. До коммита проведи проверку с глубиной, оправданной риском, затем проведи изменение через обычные командные этапы pull request, CI и одобрения. На каждом ревью сравнивай полученную реализацию с переданным намерением, а не оценивай качество кода само по себе.

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

Главные выводы​

• Выполнение остаётся подотчётным одобренному намерению. Проверяй результат по критериям и границам спецификации; удаляй неодобренные дополнения.
• Анализ расхождений — дисциплинированное сравнение. Спрашивай, что установила спецификация, что делает код, чего не хватает или что лишнее и чем разрешено каждое отклонение.
• Глубина должна соответствовать риску. Обратимому изменению может хватить одного сравнения и CI. Оставляй построчное ревью diff для изменений, последствия которых оправдывают его цену.
• Устаревшие спецификации вредны. Обновляй спецификацию при изменении решений; не заставляй будущие запуски согласовывать заведомо устаревший артефакт.