feature-by-speclisted

# Новая функциональность по конвейеру Порядок здесь не косметический. Тест, написанный после реализации, проверяет то, что получилось, а не то, что требовалось, и как надзорный слой бесполезен. ## 1. Спека — до всего остального Сформулируй поведение на человеческом языке и **покажи пользователю до начала работы**. Формат Gherkin, без артефактов уровня кода: ```gherkin Функция: Оплата заказа Сценарий: успешная оплата Дано заказ на 1500 рублей в статусе "ожидает оплаты" Когда покупатель оплачивает его картой Тогда заказ переходит в статус "оплачен" И покупателю уходит письмо с чеком Сценарий: повторная оплата не проходит Дано заказ в статусе "оплачен" Когда покупатель оплачивает его ещё раз Тогда деньги не списываются И покупатель видит сообщение "заказ уже оплачен" ``` Обязательно перечисли несчастливые пути: нет прав, невалидный ввод, повтор операции, внешний сервис недоступен, конкурентное изменение. Значения в примерах — конкретные. Они потом мутируются, чтобы проверить, что тест вообще связан с приложением. **Не начинай кодировать, пока пользователь не подтвердил спеку.** Это единственная точка, где ошибка не ловится ничем ниже по конвейеру. ## 2. Тесты — из спеки, до реализации Переведи каждый сценарий в тест. Запусти и **убедись, что тесты падают**, причём по правильной причине: «метод не найден» — правильно, «синтаксическая ошибка в тесте» — нет. Тест обр��щается к приложению через его публичную границу (HTTP-эндпоинт, кон