Composition Rewrite PRD

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

Composition Rewrite нужен для controlled AI-assisted обновления существующей композиции без разрушения block-oriented model.

Проблема продукта:

  • ручное обновление composition может быть медленным;

  • при большой композиции легко нарушить текущую структуру;

  • пользователь хочет доработать содержание, но не пересобирать всё с нуля.

Цель функции:

  • дать способ переписать содержание блоков по новой инструкции;

  • сохранить reviewability и versioning;

  • не превращать rewrite в скрытый redesign композиции.

2. Постановка проблемы

Текущий ручной путь:

  • открыть composition;

  • найти нужные блоки;

  • редактировать их вручную;

  • выпустить новые версии;

  • затем сохранить новую версию композиции.

Это надёжно, но затратно:

  • сложно быстро обновить набор связанных блоков;

  • трудно массово улучшить phrasing, tone или policy wording;

  • есть риск случайно сломать placeholders или нарушить consistency.

Почему здесь нужен ML/LLM:

  • semantic rewrite по пользовательской инструкции естественно ложится на модель;

  • при этом нужно сочетать rewrite с жёсткими constraints на сохранение состава и структуры.

3. Пользователи и сценарии

Основные пользователи:

  • authors editing compositions;

  • владельцы reusable prompt flows;

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

Ключевые сценарии:

  • preview AI rewrite over current composition;

  • inspect patches before apply;

  • update composition while preserving existing blocks and placeholders;

  • использовать AI как ускоритель controlled revision, а не как автогенератор новой структуры.

4. Область охвата и не-цели

В области охвата

  • preview/apply rewrite workflow;

  • patch-oriented output;

  • explicit user review;

  • выпуск новых версий затронутых блоков;

  • публикация новой версии композиции после apply.

Вне области охвата

  • blind overwrite of composition;

  • structural redesign composition;

  • automatic apply without preview;

  • добавление и удаление блоков через AI в рамках этой функции.

5. Критерии успеха

Функция считается успешной, если:

  • preview достаточно понятен для человеческого решения;

  • apply обновляет композицию без скрытых мутаций;

  • rewrite сохраняет placeholders и основную структуру;

  • пользователь получает ускорение в сравнении с полностью ручным массовым редактированием.

Качественные индикаторы:

  • полезность preview на representative compositions;

  • низкая доля reject из-за structural breakage;

  • стабильное поведение preview/apply в repeated use.

6. Функциональные требования

Система должна:

  • разделять preview и apply;

  • формировать patch-like результат по блокам;

  • работать только с блоками, уже присутствующими в композиции;

  • требовать явного пользовательского approve перед mutation;

  • выпускать новые версии затронутых блоков;

  • публиковать новую версию композиции после успешного apply;

  • проверять placeholders до сохранения rewritten blocks.

7. Нефункциональные требования

Функция должна:

  • сохранять inspectability;

  • явно сообщать об ошибках preview и apply;

  • не размывать границу между suggestion и mutation;

  • быть совместимой с текущим versioned lifecycle блоков и композиций.

8. Ограничения и допущения

Ограничения:

  • provider видит содержимое composition blocks;

  • качество результата зависит от ясности инструкции и preservation guidance;

  • некоторые sensitive blocks могут требовать ручной ревизии даже после preview.

Допущения:

  • composition уже существует и выбрана пользователем;

  • пользователь готов review-ить patch summary перед apply;

  • block structure остаётся главной unit of maintenance.

9. Зависимости и заинтересованные стороны

Зависимости:

  • ICompositionBlockRewriter;

  • CompositionBlockRewriteRequest;

  • CompositionBlockRewritePreview;

  • GUI rewrite dialog;

  • engine apply flow.

Заинтересованные стороны:

  • composition authors;

  • AI workflow owner;

  • core composition owner;

  • владельцы block library.

10. Критерии приёмки

Пилот считается успешным, если:

  • representative compositions дают полезные previews;

  • apply стабильно публикует новые версии без hidden mutation;

  • placeholders не ломаются на ключевых сценариях.

Функция считается готовой к регулярному использованию, если:

  • preview/apply понятен пользователю;

  • patch quality достаточно стабильна;

  • manual fallback остаётся простым и доступным.