Поднимаем SDD на уровень продукта

Spec-driven development хорошо работает, пока продукт помещается в один репозиторий. У нас это не так: фронт и бэк живут в разных монорепах, а общая фича начала превращаться в две разные спеки.

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

Недавно в OpenSpec появились Stores — отдельные Git-репозитории для общих specs и changes, на которые могут ссылаться кодовые репозитории. Наши бэк и фронт живут в разных монорепах, поэтому модель хорошо ложится на продукт.

На выходе мы получаем довольно интересный docs-as-code:
➡️ Аналитик пишет общие proposal и specs.
➡️ Разработка и QA ревьюят их и при необходимости добавляют designs и tasks.
➡️ Реализация остаётся в репозиториях с кодом.
➡️ Где хранить designs и tasks (в общей репе или у каждой команды отдельно), пока не решили — проверим оба варианта.

Так у нас появится единая точка правды о том, как должен работать продукт. Спека остаётся после реализации фичи, поэтому знания хранятся не только в головах старожилов.

Конечно, OpenSpec — это просто инструмент. Нам всё ещё нужно определить ownership документации, настроить её обновление и написать кастомные скиллы. К тому же Stores пока в бете.

Я же посмотрю на результат через пару месяцев. Если команды продолжат использовать общую спеку при изменении продукта, эксперимент сработал.

// А у вас требования к сквозным фичам живут в одном месте или собираются по кусочкам из нескольких репозиториев?