Composition Rewrite Evaluation Plan

1. Цель оценки

Качество Composition Rewrite означает:

  • rewrite полезен по смыслу;

  • existing structure сохраняется в безопасной степени;

  • preview достаточно понятен для human approval;

  • apply faithfully следует approved preview.

Главные риски:

  • destructive rewrite;

  • low-clarity preview;

  • incorrect patch application;

  • placeholder breakage;

  • скрытый structural redesign.

2. Измерения качества

Оцениваемые измерения:

  • preservation of existing blocks Насколько rewrite сохраняет состав и роль существующих blocks.

  • patch clarity Насколько preview помогает понять proposed changes.

  • semantic usefulness Насколько rewrite реально улучшает композицию по инструкции.

  • safety of apply step Насколько apply соответствует preview и не ломает invariants.

  • placeholder preservation Сохраняются ли executable constraints blocks.

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

Функция считается проходящей оценку, если:

  • preview ясно объясняет proposed changes;

  • preserved fraction of important blocks остаётся приемлемой;

  • apply result соответствует approved preview;

  • placeholder checks надёжно предотвращают unsafe patches;

  • rewrite полезен хотя бы на representative composition set.

4. Стратегия датасета

Нужно собирать:

  • representative compositions с mixed block types;

  • cases с safety и constraint blocks;

  • update cases, где измениться должна только часть composition;

  • cases with repeated references to same block;

  • negative cases с ambiguous instruction.

5. Offline evaluation

Нужно проводить:

  • сравнение preview output с expected preservation goals;

  • inspection applied result against preview;

  • проверку placeholder-preservation;

  • review patch clarity;

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

6. Ручная проверка

Ревьюеры:

  • composition author;

  • domain owner;

  • владелец composition workflow.

Что проверять:

  • clarity;

  • preservation;

  • semantic improvement;

  • safety of apply.

7. Пороговые значения и правило решения

Go, если:

  • rewrite остаётся reviewable;

  • intended structure mostly preserved;

  • preview и apply согласованы;

  • destructive patches редки и корректно отсеиваются.

No-Go, если:

  • preview часто непонятен;

  • apply расходится с preview;

  • destructive patches frequent;

  • placeholder violations часто появляются на representative cases.

8. Политика регрессий

Регрессией считается:

  • lower preservation;

  • worse preview clarity;

  • mismatch between preview and apply;

  • more placeholder-related apply failures.

9. Post-release review

После изменений prompt policy или apply logic нужно:

  • собирать failed rewrite cases;

  • анализировать rejected previews;

  • обновлять golden compositions;

  • отдельно отслеживать mismatch между preview и apply.