Block Generation Delivery Plan

1. Область поставки

В поставку функции входят:

  • engine integration для explicit single-block generation;

  • GUI authoring workflow в редакторе блоков;

  • prompt policy и provider behavior;

  • review-before-save модель;

  • минимальный quality loop для create и revise сценариев.

2. Текущий статус

Текущее состояние:

  • базовый workflow уже реализован в engine и GUI;

  • create и revise сценарии уже существуют;

  • архитектурные границы описаны;

  • не хватает более формального quality corpus и устойчивой prompt governance.

3. Рабочие потоки и владельцы

Основные workstreams:

  • engine owner Контракт, orchestration, validation, compatibility with block lifecycle.

  • AI owner Prompt policy, provider behavior, response parsing quality.

  • GUI owner Review UX, edit workflow, статусы и user-visible failures.

4. Карта зависимостей

Ключевые зависимости:

  • provider configuration;

  • generator adapter;

  • BlockEditorViewModel;

  • session-level engine rebuild;

  • representative prompt corpus.

5. Этапы rollout

Следующие практические шаги:

  1. Формализовать acceptance наборы для create mode.

  2. Добавить representative revise cases.

  3. Зафиксировать prompt versions и change discipline.

  4. Уточнить fallback policy при transport/auth/parsing failures.

  5. Проверить regressions после изменения provider config или prompt policy.

6. Блокеры и риски

Основные блокеры:

  • отсутствие formal benchmark set;

  • отсутствие prompt version governance как отдельной дисциплины;

  • зависимость от внешнего provider behavior.

Основные риски rollout:

  • ухудшение качества drafts после prompt policy change;

  • неверный type selection;

  • revision mode с недостаточным сохранением identity.

7. Критерии готовности

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

  • representative prompts собраны;

  • review workflow стабилен;

  • failures понятны пользователю;

  • create mode и revise mode покрыты eval cases;

  • manual fallback остаётся простым и рабочим.

8. Следующий шаг после текущей итерации

После текущего документирования разумно:

  • собрать curated prompt corpus;

  • привязать реальные rejected examples к evaluation process;

  • отдельно отслеживать quality drift между версиями prompt policy.