От промптов к спецификациям

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

Сами промпты у меня уже давно проходят через трекер и в нем подтверждаются. Очень полезно бывает переключиться из терминала с кодексом, прочитать в трекере результирующий промпт, уточнить его и только потом одобрить — это уже сильно стабилизирует изменения.

Следующий этап: ввел 4 типа карточек (задач в других трекерах):

• S (Система) — это объединяющая задача, описывает систему (подсистему), ее применимость и границы. К ней уже привязываются остальные типы карточек спецификации и подсистемы. Из систем выстраивается иерархия проекта, где в листьях — простейшие подсистемы, отдельные компоненты.
• D (Определения) — это словари: карточки с точными определениями терминов, используемых в спецификации системы.
• R (Требования) — это описания свойств, ограничения и все, что входит в само описание системы. Используется английский с шаблонными MUST, MAY и остальными оборотами из RFC.
• A (Сценарии) — это сценарии, которые на примерах показывают, как система должна работать, фактически — набор тестов.

Есть еще тип Q — вопрос-ответ, но он сам в спецификации не участвует: когда на вопрос есть ответ, должны как-то поменяться связанные с ним карточки D, R, A.

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

Версии простые: единственная сервис-таска BPMN — зафиксировать версию. У карточки есть текущая версия (последняя зафиксированная), черновик (обычные редактируемые поля) и прошлые версии, если уже успели накопиться. Карточки систем при фиксации версии запоминают не только себя, но и состав всех карточек D, R, A ниже по иерархии и их текущие версии — вот и версия подсистемы. Планирую выделять удачные подсистемы в библиотеки и переиспользовать.

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

Плюс есть базовый проект — метадизайн (привет, @anton_kotoriy), в котором описаны общие для всех проектов и стеков вещи. Принципы минимализма, переиспользования кода и разделения его на слои, сама эта система спецификаций, работа с фичаветками, работа с миграциями сторонних сервисов типа базы данных или n8n, система мониторинга, проверки безопасности по MITRE и OWASP, система деплоя.

Продолжаю наблюдение.