В кейсе 4 прошлого урока мы видели один пример: требование, которое описывало HTTP-вызов и useState. Системная проблема масштабнее: спека начинается правильно, но с каждой итерацией обрастает деталями реализации. Через месяц в requirements.md уже живут конкретные классы, имена методов и схемы БД.

Диагностический вопрос: если мы сменим архитектуру, придётся переписывать requirements.md? Если да — граница «что/как» стёрта.

Ориентир: требование описывает поведение, которое пользователь мог бы наблюдать или проверить. Если пользователь не может наблюдать «вызов searchProducts()» — это не требование.

# ❌ Over-specified: реализация просочилась в спеку
WHEN пользователь нажимает «Поиск»
  AND searchProducts() вызывается через GET /api/v1/search
THEN useState обновляет массив results в компоненте SearchResults

# ✅ Правильно: только наблюдаемое поведение
WHEN пользователь вводит поисковый запрос и нажимает «Поиск»
THEN система отображает список подходящих товаров не более чем за 2 секунды

Спека написана, фича сделана, PR смёрджен. Следующая задача — и спека не обновляется. После трёх спринтов requirements.md описывает систему, которой уже нет.

Spec rot — не лень, а структурная проблема: нет момента принуждения (moment of friction), который заставлял бы обновлять спеку. В TDD такой friction встроен: упавший тест останавливает работу. В SDD аналог нужно создавать вручную — например, ввести ревью спеки в DoD (Definition of Done) каждой задачи.

Простой инвариант: спека и код описывают одно и то же поведение. Когда они расходятся — один из них лжёт.

Команда завела три обязательных файла — requirements.md, design.md, tasks.md. Все их заполняют перед стартом. Проблема: файлы превратились в шаблоны для галочки, а не в инструмент снятия неоднозначности.

Признак: спека есть, но агент всё равно делает неверные допущения или задаёт вопросы, ответы на которые «очевидно должны быть в спеке». Значит, документ существует, но информации в нём нет.

Вопрос для самопроверки: что изменилось бы в реализации, если бы эту спеку не написали? Если ответ «ничего» — перед вами бюрократическая спека.

Три дня на настройку Kiro, интеграцию с CI, шаблоны в Notion и скрипт автогенерации tasks.md из Jira. Первая реальная спека ещё не написана.

Тулинг должен снижать трение, а не создавать его. Spec Kit и Kiro — хорошие инструменты, но они не обязательны для старта. requirements.md — это Markdown-файл, который достаточно создать в корне репозитория.

flowchart TD
    A[Новая задача / фича] --> B{Требования стабильны\nна горизонте итерации?}
    B -->|Нет| C[Быстрый прототип\nбез спеки]
    B -->|Да| D{Кто реализует?}
    D -->|Только я,\nдомен в голове| E[Опционально:\nминимальный чеклист AC]
    D -->|Агент или команда| F{Объём больше 1 дня?}
    F -->|Нет| G[1 EARS-требование\n+ 2–3 AC в PR]
    F -->|Да| H[Полный SDD-цикл:\nrequirements + design + tasks]

Быстро меняющиеся требования. Если продуктовые гипотезы обновляются быстрее, чем обновляется спека, spec rot неизбежен с самого старта. SDD хорошо работает там, где поведение системы достаточно стабильно, чтобы его зафиксировать до начала реализации.

Enterprise-легаси с кросс-командными зависимостями. В крупных компаниях со сложными легаси-системами спека описывает желаемое поведение, а реальность ограничена унаследованными контрактами, которые невозможно честно зафиксировать в трёх Markdown-файлах. Команда тратит время на «объяснение» легаси в спеке вместо реальной работы.

Одноразовые скрипты и исследовательский код. Migration-скрипт на час работы или ноутбук для проверки гипотезы — стоимость спеки превышает её ценность.

Домен полностью в голове одного человека. Спека ценна, когда нужно передать намерение агенту или команде. Если вы единственный владелец контекста и пишете для себя — накладные расходы не окупаются.

SDD не требует сразу трёх файлов, Kiro и CI-интеграции. Минимальный старт:

1. Одно требование в EARS-нотации — прямо в описании PR или задачи в трекере.

2. Два–три acceptance criteria — конкретных, проверяемых.

3. Проверка: прочитать требование и ответить на вопрос «что агент сделает в граничном случае?»

Если ответ неочевиден — дописать требование. Если очевиден — спека уже работает.

# Пример минимального requirements.md

WHEN авторизованный пользователь подтверждает заказ
  AND корзина содержит хотя бы один товар
THEN система создаёт заказ и отображает номер подтверждения

## Acceptance Criteria
- [ ] Номер заказа отображается в течение 3 секунд
- [ ] Корзина очищается после успешного оформления
- [ ] При ошибке оплаты содержимое корзины сохраняется

Инструменты добавляйте только тогда, когда процесс работает без них. Spec Kit полезен, когда есть устойчивая привычка писать требования. Kiro полезен, когда понятно, что именно трассировать. До этого момента Markdown-файл с тремя WHEN-предложениями — это уже SDD.