@gian-tiaga/eda 2.0.0 → 3.1.0

package/skills/eda-plan-execute/SKILL.md

@@ -1,74 +1,59 @@
 ---
 name: eda-plan-execute
-description: 'Выполняет готовый план из `docs/plans/` последовательно по фазам с независимой проверкой результата.'
+description: 'Выполняет готовый план последовательно по фазам с независимой проверкой каждой фазы.'
 ---
 
 # Скил: Управляющий выполнением плана (eda-plan-execute)
 
-Оркестрируй выполнение готового плана. Сам не реализуй задачи и не запускай проверки проекта: передавай каждую фазу целиком отдельному изолированному субагенту, а её приёмку — отдельному проверяющему. Связывай результаты фаз, обновляй прогресс плана и журнал выполнения.
+Оркестрируй выполнение плана. Сам не пиши код и не запускай проверки проекта: передавай каждую фазу целиком отдельному изолированному субагенту, а её приёмку — отдельному проверяющему. Связывай результаты фаз, обновляй прогресс и журнал.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом — главный вход. Разбери тему, путь к файлу, ограничения и прямые указания.
 
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не тот план. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных планов или есть риск выполнить не тот план.
 
 ## Главные правила
 
-1. **Основной агент только управляет.** Разрешены чтение контекста, построение очереди, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию проекта и git-состояние меняют только назначенные субагенты.
-2. **Фазы выполняй строго последовательно.** Не запускай следующую фазу, пока исполнитель текущей не завершил все её задачи и отдельная проверка фазы не прошла.
-3. **Одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Сохраняй идентификатор исполнителя и продолжай его же для вопросов и исправлений этой фазы, пока среда позволяет.
-4. **Рамку читает исполнитель фазы.** Каждый исполнитель целиком читает план, `docs/rules.md` и `docs/arch.md`. Для поведения своей фазы он читает карточки из `sources.business`; у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки. Для затронутых компонентов так же выбирает технические карточки через `sources.references` или `docs/references.md`. Нерелевантные карточки не загружает.
-5. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, исполнитель возвращает `blocked`, а основной агент показывает конфликт и через `AskUserQuestion` спрашивает: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`. Конфликты с rules, architecture или references также не разрешай молча.
-6. **Отмечай только подтверждённое.** Ставь задаче `[x]` только после `completed` от исполнителя и успешной точечной проверки. Фазу закрывай только после отдельного `passed` от проверяющего фазы. При последующем опровержении верни отметку в незавершённое состояние.
-7. **Проверки нельзя подавлять.** Не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, добавлять игноры или ослаблять команды и правила. Причину падения исправляет исполнитель соответствующей фазы, затем отдельный субагент повторяет проверку.
-8. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
+1. **Основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты.
+2. **Фазы выполняй строго последовательно.** Не запускай следующую, пока текущая не выполнена и её отдельная проверка не прошла.
+3. **Одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Идентификатор исполнителя сохраняй и продолжай его же для вопросов и исправлений этой фазы.
+4. **Рамку читает исполнитель фазы.** Каждый исполнитель целиком читает план, `docs/rules.md` и `docs/arch.md`. Для поведения своей фазы он читает карточки из `sources.business`; у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки. Для затронутых компонентов так же выбирает технические карточки через `sources.references` или `docs/references.md`. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением. Нерелевантные карточки не загружает.
+5. **Исполнитель не додумывает план.** Если в фазе не хватает решения, он возвращает `needs_input`, а не выбирает сам. Недостающее решение — это вопрос пользователю или возврат в `eda-plan`, но не импровизация в коде.
+6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, `rules.md`, `arch.md` или reference-карточке, исполнитель возвращает `blocked`. Основной агент показывает конфликт и через `AskUserQuestion` спрашивает: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
+7. **Отмечай только подтверждённое.** Фазу закрывай только после `completed` от исполнителя и отдельного `passed` от проверяющего. При последующем опровержении верни отметку в незавершённое состояние.
+8. **Проверки нельзя подавлять.** Не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, добавлять игноры или ослаблять команды и правила. Причину падения исправляет исполнитель фазы, затем отдельный субагент повторяет проверку.
+9. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
 
-## Интерактивные вопросы
+## Вопросы
 
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале.
+Блокирующий вопрос: Claude Code — `AskUserQuestion`; Codex interactive — `request_user_input` или короткий вопрос с вариантами 1–3; Codex exec — не читай stdin, заверши со статусом `blocked: нужен ответ пользователя`. Не запускай команды, ждущие интерактивного ввода.
 
 ## Этапы
 
 ### 1. Выбрать план
 
-- Если указан путь к плану — используй его как `$PLAN_FILE`.
-- Если указано название или часть названия — найди совпадение в `docs/plans/`.
-- Если написано «последний план» — возьми самый новый файл из `docs/plans/`.
-- Если вставлен текст плана — сохрани или однозначно привяжи его к файлу в `docs/plans/` до инициализации прогресса.
+Путь — используй как есть. Название или его часть — ищи совпадение в `docs/artifacts/plans/`. «Последний план» — бери самый новый файл. Вставленный текст плана сначала сохрани или однозначно привяжи к файлу.
 
-Если найден ровно один план, продолжай без вопроса. При нескольких равных вариантах используй `AskUserQuestion`. Если плана нет, остановись со статусом `blocked: нужен план`.
+Один план — продолжай без вопроса. Несколько равных — `AskUserQuestion`. Плана нет — `blocked: нужен план`.
 
-Не исполняй план со статусом `draft`, открытыми вопросами, отсутствующими ID задач или неразрешёнными зависимостями. Попроси сначала завершить `eda-plan` или `eda-plan-polish`.
+Не исполняй план с открытыми вопросами или неразрешёнными развилками: сначала заверши `eda-plan` или `eda-plan-polish`.
 
 ### 2. Выбрать место выполнения
 
 Через `AskUserQuestion` предложи текущую ветку, новую ветку от `main`, новую ветку от текущей или worktree от `main`. Если вызывающий оркестратор уже передал подтверждённый выбор, не спрашивай повторно.
 
-Сам git-команды не выполняй. Для выбранной новой ветки или worktree запусти отдельного изолированного субагента подготовки окружения. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. Если выбран worktree, после успешного создания остановись и дай готовую команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`: текущая сессия не переезжает в другую директорию.
+Сам git-команды не выполняй: для новой ветки или worktree запусти отдельного субагента подготовки окружения. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. После успешного создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
 
 ### 3. Прочитать план и проверить фазы
 
-Прочитай `$PLAN_FILE`. Для каждой фазы извлеки задачи, ID, прямые зависимости, ожидаемый результат, сценарии тестирования и проверки. До запуска проверь:
-
-- все ID уникальны, а ссылки ведут на существующие задачи;
-- зависимости не образуют цикл и не ведут в будущую фазу;
-- у каждой фазы есть проверяемый результат и команда либо критерий проверки.
-
-Поля `Параллельно` в старых планах не влияют на исполнение: все задачи фазы выполняет один субагент по зависимостям.
+Прочитай `$PLAN_FILE`. Для каждой фазы извлеки цель, что сделать, результат и проверку. До запуска убедись, что у каждой фазы есть проверяемый результат и команда или критерий проверки.
 
-Если граф неоднозначен или небезопасен, не исправляй смысл плана молча. Используй `AskUserQuestion` с предложением вернуть план в `eda-plan` или `eda-plan-polish`.
+Если фаза не описывает проверяемый результат или её проверку нечем выполнить, не достраивай смысл молча: через `AskUserQuestion` предложи вернуть план в `eda-plan` или `eda-plan-polish`.
 
 ### 4. Инициализировать прогресс
 
-Создай `$EXECUTION_FILE` по пути `docs/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. В `$PLAN_FILE` добавь или актуализируй один раздел `## Прогресс выполнения` со ссылкой на журнал, фазами и задачами по исходным ID.
-
-Используй в журнале структуру:
+Создай `$EXECUTION_FILE` по пути `docs/artifacts/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. В `$PLAN_FILE` добавь или актуализируй один раздел `## Прогресс выполнения` со ссылкой на журнал и списком фаз.
 
 ```markdown
 ---
@@ -81,7 +66,7 @@ current_phase: <номер>
 # Журнал выполнения: <заголовок>
 
 ## Фазы
-| Фаза | Задачи | Проверка | Статус |
+| Фаза | Результат | Проверка | Статус |
 |---|---|---|---|
 
 ## Запуски субагентов
@@ -97,26 +82,16 @@ current_phase: <номер>
 
 ### 5. Запускать изолированных субагентов
 
-В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог. В Claude Code используй новый `Agent` с самодостаточным task-сообщением. Если чистая изоляция или субагенты недоступны, остановись с `blocked: недоступно изолированное выполнение`; не выполняй работу основным агентом и не добавляй CLI-fallback.
-
-Каждому исполнителю фазы передай:
+В Codex используй `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция или субагенты недоступны, остановись: `blocked: недоступно изолированное выполнение`. Работу основным агентом не делай и CLI-fallback не добавляй.
 
-- рабочую директорию, `$PLAN_FILE`, номер и полный текст текущей фазы;
-- краткие результаты уже завершённых фаз;
-- пути к `docs/rules.md`, `docs/arch.md`, `docs/business.md` и `docs/references.md`;
-- ограничения пользователя, команды и критерии проверки фазы, запрет коммитить и запрет менять план и журнал.
+Каждому исполнителю фазы передай: рабочую директорию, `$PLAN_FILE`, номер и полный текст фазы, краткие результаты завершённых фаз, пути к `docs/rules.md`, `docs/arch.md`, `docs/business.md` и `docs/references.md`, ограничения пользователя, критерии проверки фазы и запрет коммитить и менять план и журнал.
 
-Исполнитель целиком читает `$PLAN_FILE`, `docs/rules.md` и `docs/arch.md`, затем выполняет все задачи назначенной фазы по прямым зависимостям. Перед изменением поведения он читает применимые карточки из `sources.business`; если поле отсутствует, выбирает их по описаниям из `docs/business.md`. Если подходящих карточек нет, продолжает без business-контекста. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением. После каждой задачи он выполняет её точечные проверки, а в конце — все проверки фазы. Требуй YAML-результат:
+Требуй YAML-результат:
 
 ```yaml
 status: completed | needs_input | failed | blocked
 phase: <номер>
 summary: <что сделано>
-tasks:
-  - id: <ID>
-    status: completed | failed | blocked
-    summary: <кратко>
-    checks: [<результаты точечных проверок>]
 files_changed: [<пути>]
 business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
@@ -129,22 +104,22 @@ risks: [<остаточные риски или пусто>]
 questions: [<вопросы или пусто>]
 ```
 
-Не принимай `completed`, если хотя бы одна задача или обязательная проверка фазы не прошла, исполнитель вышел за назначенный scope, молча отклонился от рамки или изменил план/журнал.
+Не принимай `completed`, если обязательная проверка фазы не прошла, исполнитель вышел за назначенный scope, молча отклонился от рамки или изменил план либо журнал.
 
 ### 6. Выполнять фазы
 
 Для каждой фазы по порядку:
 
 1. Запусти одного нового изолированного исполнителя и сохрани его идентификатор как исполнителя этой фазы.
-2. После ответа проверь YAML-контракт, фактический scope файлов и результаты точечных и фазовых проверок. Запиши запуск в журнал и поставь `[x]` только задачам со статусом `completed` и успешными точечными проверками.
-3. `needs_input` передай пользователю одним блокирующим вопросом. После ответа продолжи того же исполнителя фазы с ответом и его предыдущим результатом. Если среда не умеет продолжать завершённого субагента, запусти нового изолированного исполнителя этой же фазы и передай ему полный предыдущий результат.
-4. Для `failed` продолжи того же исполнителя фазы с полным неуспешным результатом и поручением исправить причину и повторить проверки. Если две попытки подряд возвращают ту же причину без содержательного изменения результата, остановись с `blocked: выполнение не сходится` и зафиксируй доказательства вместо бесконечного цикла.
-5. Для `blocked` останови выполнение. Если блокер внешний или требует изменения scope, задай вопрос; основной агент не устраняет его содержательно.
-6. После `completed` запусти независимую проверку фазы. Не переходи к следующей фазе, пока текущая не закрыта.
+2. Проверь YAML-контракт, фактический scope файлов и результаты проверок. Запиши запуск в журнал.
+3. `needs_input` передай пользователю одним блокирующим вопросом, затем продолжи того же исполнителя фазы с ответом и его предыдущим результатом. Если среда не умеет продолжать завершённого субагента, запусти нового с полным предыдущим результатом.
+4. `failed` — продолжи того же исполнителя фазы с полным неуспешным результатом и поручением исправить причину и повторить проверки. Если две попытки подряд дают ту же причину без содержательного изменения, остановись: `blocked: выполнение не сходится`.
+5. `blocked` — останови выполнение. Внешний блокер или изменение scope выноси вопросом; сам его не устраняй.
+6. После `completed` запусти независимую проверку фазы.
 
 ### 7. Проверять каждую фазу
 
-После `completed` от исполнителя запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`. Он читает только business-карточки, применимые к поведению этой фазы, и только reference-карточки затронутых компонентов; для старого плана использует соответствующие индексы как fallback. Отсутствие применимой business-карточки не блокирует проверку. Затем он выполняет все проверки из раздела фазы и подтверждает критерии результата. Требуй YAML:
+После `completed` запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, читает только применимые карточки, выполняет все проверки фазы и подтверждает критерии результата.
 
 ```yaml
 status: passed | failed | blocked
@@ -158,27 +133,27 @@ business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
 ```
 
-При `failed` передай полный результат проверки исполнителю этой фазы и поручи исправить все подтверждённые проблемы, затем запусти нового проверяющего всей фазы. Если продолжить прежнего исполнителя невозможно, запусти одного нового изолированного исполнителя для исправления всей фазы с её полным контекстом. Основной агент не чинит код и не переиспользует контекст прежнего проверяющего. При `passed` отметь фазу завершённой и только тогда переходи к следующей.
+При `failed` передай полный результат исполнителю этой фазы, поручи исправить подтверждённые проблемы и запусти нового проверяющего. Основной агент код не чинит и контекст прежнего проверяющего не переиспользует. При `passed` отметь фазу завершённой и только тогда переходи к следующей.
 
-### 8. Выполнить финальную проверку
+### 8. Финальная проверка
 
-После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет и не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, затем выбирает только business-карточки итогового изменённого поведения и reference-карточки затронутых компонентов. Отсутствие подходящей business-карточки не требует предупреждения и не блокирует проверку.
+После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения.
 
-Если финальная проверка упала из-за сделанных изменений, сопоставь ошибки с фазами и передай каждую группу исполнителю соответствующей фазы; несколько затронутых фаз исправляй по порядку плана. Если продолжить прежнего исполнителя невозможно, запусти одного нового изолированного исполнителя для каждой затронутой фазы. Затем повтори всю финальную проверку новым субагентом. Чужую или несвязанную поломку зафиксируй и используй `AskUserQuestion`, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
+Падение из-за сделанных изменений сопоставь с фазами и передай каждую группу исполнителю соответствующей фазы по порядку плана, затем повтори всю финальную проверку новым субагентом. Чужую или несвязанную поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 
-Запиши команды и результаты в `## Финальная проверка`. Только после `passed` поставь в журнале `status: done` и время завершения. Если обязательная проверка объективно недоступна, сохрани `status: blocked`, причину и непройденные критерии; не выдавай план за выполненный.
+Запиши команды и результаты в `## Финальная проверка`. Только после `passed` поставь `status: done` и время завершения. Если обязательная проверка объективно недоступна, сохрани `status: blocked`, причину и непройденные критерии; выполненным план не объявляй.
 
 ### 9. Финал
 
-Коротко сообщи пути к плану и журналу, завершённые фазы и задачи, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
+Коротко сообщи пути к плану и журналу, завершённые фазы, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
 
 - Самому менять код, тесты, миграции, конфиги, зависимости или проектную документацию.
-- Самому запускать тесты, линтеры, typecheck, сборку, миграции, серверы или другие команды разработки и проверки.
-- Дробить одну фазу между несколькими исполнителями или поручать одному исполнителю несколько фаз.
+- Самому запускать тесты, линтеры, typecheck, сборку, миграции, серверы и другие команды разработки и проверки.
+- Дробить фазу между исполнителями или давать одному исполнителю несколько фаз.
 - Запускать следующую фазу до успешной отдельной проверки текущей.
-- Давать субагентам историю диалога или разрешать им менять план и журнал.
-- Исправлять падение основным агентом либо продолжать после него без повторной проверки новым субагентом.
+- Позволять исполнителю додумывать недостающее решение вместо вопроса.
+- Давать субагентам историю диалога или разрешать менять план и журнал.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.
 - Коммитить, пушить, создавать PR или делать ревью.

package/skills/eda-plan-polish/SKILL.md

@@ -1,48 +1,49 @@
 ---
 name: eda-plan-polish
-description: 'Оркестрирует review и исправления готового плана до подтверждённой оценки готовности.'
+description: 'Доводит план циклом ревью и исправлений, останавливается при отсутствии роста и оставляет лучшую версию.'
 ---
 
 # Скил: Полировка плана (eda-plan-polish)
 
-Оркестрируй цикл `eda-plan-review` → `eda-plan-review-fix apply-optional` → повторный `eda-plan-review`. Основной агент только выбирает план, запускает каждый скил в отдельном изолированном субагенте, проверяет артефакты и управляет остановкой.
+Оркестрируй цикл `eda-plan-review` → `eda-plan-review-fix` → подтверждающий `eda-plan-review`. Сам план не правь и score не выставляй: ты выбираешь план, запускаешь каждый скил в отдельном изолированном субагенте, следишь за ростом оценки и решаешь, когда остановиться.
+
+Главное отличие от простого повторения итераций: **цикл останавливается, как только оценка перестаёт расти, и оставляет лучшую версию плана, а не последнюю.**
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold, limit, отключённые/принудительные проверки, разовые модели и ограничения. Передавай overrides в каждый review.
+Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold и limit.
 
-Если план выбирается однозначно, продолжай без вопроса. При нескольких равных вариантах передай выбор первому `eda-plan-review` или используй `AskUserQuestion` по правилам среды.
+Если план выбирается однозначно, продолжай без вопроса. При нескольких равных вариантах — `AskUserQuestion`.
 
 ## Настройки
 
-Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`; иначе используй defaults и предупреди.
+Прочитай `docs/settings.yaml`, если есть. Поддерживается только `version: 3`; иначе defaults и предупреждение.
 
-- threshold берётся из `plan-review.threshold`, default `95`, допустим `1–100`;
-- limit берётся из `plan-polish.limit`, default `3`, это положительное целое число;
-- прямые `threshold N` и `limit N` важнее settings.
+- `plan-review.threshold` — доля закрытых пунктов для `ready`, default `100`;
+- `plan-polish.limit` — максимум подтверждающих review-итераций, default `2`;
+- прямые `threshold N` и `limit N` в сообщении важнее файла.
 
-`strict` и кросс-CLI не поддерживаются. Не читай устаревшие поля настроек и не запускай соседний CLI: используй только специализированный workflow этого скилла.
+`strict` и кросс-CLI здесь не поддерживаются.
 
 ## Правила
 
-1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix apply-optional` запускай отдельным изолированным субагентом с чистым контекстом.
-2. Если нативные субагенты или вложенная делегация недоступны, остановись; не выполняй review/fix основным агентом и не используй CLI-fallback.
-3. Успех определяется только review со статусом `ready`, без required findings и `score >= threshold`.
-4. Limit считает подтверждающие review-итерации. После review на последней итерации не запускай fix, который нельзя перепроверить.
-5. Основной агент не делает содержательных правок плана. После ready он может обновить только front matter: `status`, `plan_review`, `plan_review_fix`.
-6. Не запускай проверки проекта и не коммить.
+1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix` запускай отдельным изолированным субагентом с чистым контекстом.
+2. Если нативные субагенты недоступны, остановись. Не делай review или fix сам и не используй CLI-fallback.
+3. Успех — только review со статусом `ready`.
+4. Основной агент не меняет содержание плана. После `ready` он может обновить только front matter: `status`, `plan_review`, `plan_review_fix`.
+5. Не запускай проверки проекта и не коммить.
+
+## Снапшот лучшей версии
 
-## Вопросы
+Перед первым fix скопируй план в `docs/artifacts/plan-snapshots/{slug}.md` и запомни его score как лучший.
 
-Если вложенный скил вернул `blocked` с вопросом, передай пользователю только этот вопрос и после ответа продолжи тот же шаг с полным предыдущим контекстом.
+Дальше на каждой итерации: если новый score выше лучшего — перезапиши снапшот и обнови лучший score. Если ниже или равен — снапшот не трогай.
 
-- Claude Code: `AskUserQuestion`.
-- Codex interactive: `request_user_input`, если доступен, иначе короткий вопрос с вариантами.
-- Codex exec/non-interactive: остановись `blocked: нужен ответ пользователя`.
+При остановке без `ready`: если последний score ниже лучшего, восстанови план из снапшота и скажи об этом прямо. После успешного `ready` удали снапшот.
 
 ## Цикл
 
-Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: iteration, review path, plan SHA-256, score, состояния findings, fix path и причина продолжения.
+Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и журнал: итерация, путь review, SHA-256 плана, score, открытые пункты, путь fix.
 
 Для `$ITERATION` от `1` до `$LIMIT`:
 
@@ -51,38 +52,46 @@ description: 'Оркестрирует review и исправления гото
    ```text
    Используй eda-plan-review для <PLAN_FILE> с threshold <THRESHOLD>.
    Previous review: <PREVIOUS_REVIEW | none>.
-   Previous fix: <PREVIOUS_FIX | none>.
-   Overrides проверок и моделей: <из текущего вызова | none>.
-   Верни путь, status, plan_sha256, score, required/optional ID и coverage.
+   Верни путь, status, plan_sha256, score и номера открытых пунктов.
    ```
 
-2. Прочитай review-артефакт и проверь, что status/score/threshold/findings согласованы.
-3. Если status `ready`, обнови front matter плана: `status: reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: <последний FIX_FILE | none>`. Заверши успешно.
-4. Если это последняя разрешённая review-итерация, остановись `достигнут limit`; fix не запускай.
-5. Если относительно предыдущего review не изменились open/resolved/regressed/waived ID и score, остановись `blocked: review не показывает прогресса`.
-6. Если ниже gate нет применимых findings, остановись `blocked: нет применимых правок для повышения оценки`.
-7. Запусти новый изолированный субагент:
+2. Прочитай отчёт и проверь, что score, порог и статус согласованы со списком пунктов.
+3. Обнови лучшую версию по правилу снапшота.
+4. Если статус `ready` — обнови front matter плана (`status: reviewed`, последние `plan_review` и `plan_review_fix`), удали снапшот, заверши успешно.
+5. **Стоп по отсутствию роста.** Если это не первая итерация и score не вырос относительно предыдущей — останови цикл, восстанови лучшую версию и сообщи, какая итерация была лучшей. Дальнейшие круги только ухудшают план.
+6. Если статус `changes-required`, но проваленных пунктов нет — остановись: `blocked: ревью нарушает контракт gate`.
+7. Если это последняя разрешённая итерация — остановись с причиной `достигнут limit`; fix не запускай, перепроверить его будет нечем.
+8. Запусти новый изолированный субагент:
 
    ```text
-   Используй eda-plan-review-fix apply-optional для <REVIEW_FILE>.
-   Примени все required, самостоятельно разбери optional и сохрани waived с причинами.
-   Верни путь к fix, before_sha256, after_sha256, applied и waived ID.
+   Используй eda-plan-review-fix для <REVIEW_FILE>.
+   Закрой все пункты со статусом fail минимальным изменением плана, без роста объёма.
+   Верни путь к fix, before_sha256, after_sha256, before_bytes, after_bytes и закрытые пункты.
    ```
 
-8. Проверь, что `before_sha256` равен `plan_sha256` review. Если `after_sha256` равен `before_sha256`, остановись `blocked: fix не изменил план`.
-9. Сохрани review/fix как previous chain и начни следующую review-итерацию.
+9. Проверь, что `before_sha256` равен `plan_sha256` из review. Если `after_sha256` равен `before_sha256` — остановись: `blocked: fix не изменил план`.
+10. Если план вырос больше чем на 3%, зафиксируй это в журнале как предупреждение: рост объёма — причина следующих находок.
+11. Сохрани review и fix как предыдущую цепочку и переходи к следующей итерации.
 
-Score не повышай и не пересчитывай сам: используй только полный `eda-plan-review`.
+Score сам не считай и не корректируй: он приходит только из `eda-plan-review`.
 
 ## Финал
 
-Сообщи результат (`ready`, limit, no progress, no applicable fixes или blocked), план, последний review/fix, score/threshold, число review-итераций, open ID и coverage warnings. При ready предложи `eda-plan-execute`; при неуспехе перечисли конкретные оставшиеся findings.
+Сообщи:
+
+- результат: `ready`, `limit`, `нет роста` или `blocked`;
+- путь к плану и какая версия в нём осталась — последняя или восстановленная лучшая;
+- траекторию score по итерациям и номер лучшей;
+- последние review и fix, порог, открытые пункты;
+- изменение объёма плана за весь цикл.
+
+При `ready` предложи `eda-plan-execute`. При неуспехе перечисли конкретные открытые пункты — без них следующий круг бессмысленен.
 
 ## Чего НЕ делать
 
-- Делать review, выставлять score или исправлять содержание плана основным агентом.
-- Запускать старые три общих ревью одним промптом.
+- Делать review, выставлять score или править содержание плана самому.
+- Продолжать цикл, когда score не растёт.
+- Оставлять последнюю версию, если лучшая была раньше.
+- Запускать fix после последней разрешённой итерации.
 - Запускать кросс-CLI, `strict`, `codex exec` или `claude -p`.
-- Запускать fix после последней review-итерации.
-- Ждать два одинаковых круга: один подтверждённый круг без прогресса уже останавливает цикл.
-- Писать длинный журнал полировки в план, менять код или запускать проверки проекта.
+- Писать журнал полировки в тело плана, менять код или запускать проверки проекта.