Spec Kit en Full-Stack Réel : Comment 17 Sprints ont Mené le Suivi des Habitudes en Production

Spec-Driven Development удалось дотянуть не до демо на один вечер, а до полноценного full-stack релиза. Кейс с LifeSync описывает 17 спринтов разработки трекера привычек и целей, два отдельных репозитория, сотни тестов и выход в продакшен — и подводит к главному выводу: на большом объёме SDD полезен не скоростью генерации кода, а тем, что не даёт потерять управляемость, когда backend, frontend и инфраструктура начинают тянуть проект в разные стороны. В качестве примера взят B2C-сервис для привычек и целей.

Backend собран на Spring Boot 3.5 и Java 21, разложен по hexagonal architecture на шесть Maven-модулей, использует jOOQ вместо JPA, Kafka для событийной логики, JWT RS256 и OpenAPI 3.1 как основной контракт API.

Frontend построен на React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand и shadcn/ui с Tailwind CSS. За 17 спринтов проект дорос до 251 теста на серверной части и 77 тестов на клиенте, получил 19 Liquibase-миграций и был выведен в продакшен: backend задеплоен на Railway, frontend — на Vercel.

Центральная мысль кейса — масштаб потребовал другой дисциплины работы с ИИ. Если в маленьком проекте хватало одного думающего чата и одного исполнительного окружения, то на full-stack автор пришёл к схеме из трёх чатов. Отдельный контекст нужен для backend, отдельный — для frontend, и ещё один — для координации общих решений, которые затрагивают оба репозитория: деплой, сквозные фичи, изменения API и ретроспективы.

Это дополняется двумя разными constitution-файлами. Для backend документ со временем вырос с шаблона до 437 строк и вобрал правила по миграциям, коммитам, стилю и OpenAPI. Для frontend конституция оказалась заметно компактнее — 137 строк, потому что стек и паттерны там с самого начала были жёстче определены.

Отдельный акцент сделан на команде speckit.analyze, которую автор использует как обязательный контур обратной связи после каждого спринта. Она не заменяет тесты и не притворяется линтером, а сверяет между собой spec.

md, plan.md, tasks.md и фактическую реализацию.

Именно такой анализ, по словам автора, помог поймать критичную проблему в backend-спринте с Kafka: публикация событий в нескольких use case происходила внутри транзакции без защитного try-catch. В тестовом окружении ошибка не проявлялась, потому что Kafka в контейнерах была всегда доступна, но в реальном сбое это могло бы откатывать уже сохранённые данные и оставлять систему в неконсистентном состоянии. После анализа в код добавили защиту, доработали логику retry и расширили интеграционные проверки.

Ещё одна важная опора — API-first подход как договор между двумя репозиториями. В проекте для этого выделен отдельный модуль с OpenAPI-спецификацией примерно на 2669 строк и 32 endpoint'а. Backend генерирует из неё Java-интерфейсы контроллеров, а frontend ориентируется на тот же YAML как на единственный источник правды и вручную поддерживает TypeScript-типы под реальные UI-сценарии.

Автор отдельно подчёркивает, что speckit.analyze не умеет автоматически валидировать согласованность сразу между двумя репозиториями, поэтому кросс-репозиторные проверки всё ещё приходится делать вручную через координационный контекст. Но даже в таком виде схема снижает риск тихого рассинхрона между сервером и интерфейсом: если API меняется, это сначала фиксируется в спецификации, а затем проявляется на этапе генерации интерфейсов или компиляции фронта.

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