Composition Authoring PRD

Table of Contents

1. Цель и продуктовый контекст

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

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

Основные пользователи: авторы промптов, редакторы системных сценариев, владельцы продуктовых prompt flows.
Вторичные пользователи: QA и инженеры, проверяющие структуру композиции, воспроизводимость и корректность ссылок на блоки.
Основные сценарии:
создать новую композицию
открыть существующую версию композиции на редактирование
собрать композицию из ссылок на блоки, текста и разделителей
переставить фрагменты местами
вставить новый фрагмент до или после выбранного
выпустить новую версию композиции
снять версию композиции с использования
удалить композицию

пользователь понимает структуру композиции и может ею управлять без правки низкоуровневых данных
состав фрагментов редактируется предсказуемо
выпуск новой версии композиции ясен и не скрыт
ссылки на блоки сохраняют воспроизводимость выбранной версии
предупреждения и сообщения об ошибках понятны пользователю

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

композиции хранятся локально в репозитории композиций через engine
ссылка на блок должна быть привязана к конкретной версии для воспроизводимости
редактор работает как инструмент авторинга, а не как удалённый runtime
дополнительные сценарии вроде нормализации и переписывания блоков живут рядом, но не подменяют базовый редактор композиции