@gian-tiaga/eda 3.7.0 → 3.9.0

package/MIGRATION.md

@@ -86,7 +86,7 @@ docs/
 Что в 3.x изменится в уже настроенном проекте:
 
 - **Удалены двенадцать агентов `eda-plan-review-*`.** Проверку плана целиком выполняет один субагент по фиксированному чек-листу. `eda update` стирает файлы этих агентов из `.claude/agents/` и `.codex/agents/`.
-- **Секция `plan-review.agents` больше не читается.** Начиная с 3.1.1 `eda update` находит её в готовом файле настроек и убирает вместе с другими устаревшими ключами — `review-check`, `review.strict`, `review.include_code_quality`. Дефолт `plan-review.threshold` — `100`, `plan-polish.limit` — `2`.
+- **Секция `plan-review.agents` больше не читается.** Начиная с 3.1.1 `eda update` находит её в готовом файле настроек и убирает вместе с другими устаревшими ключами — `review-check`, `review.strict`, `review.include_code_quality`. Дефолт `plan-review.threshold` — `100`, `plan-polish.limit` — `1`: с 3.9.0 лимит считает итерации «проверка + исправление», а не review-проходы, поэтому сохранённое значение `2` теперь означает два круга правок вместо одного.
 - **Режим `single` переименован в `main`.** `eda update` переносит `review.execution: single` и `plan-execute.mode: single` в `main`, а `orhestra.execution: single` и `single_propagated` — в `main` и `main_propagated`. В `main` работу выполняет основной агент без субагентов; модели отдельных `review.agents` не применяются.
 - **У `eda-review` есть режим исполнения.** `review.execution` принимает `subagents` или `main`; default `subagents` сохраняет прежнее поведение. Безусловный Claude `context: fork` удалён, поэтому `main` не создаёт отдельного агента для ревью.
 - **У `eda-orhestra` появился режим исполнения.** `orhestra.execution` принимает `subagents`, `main` или `main_propagated`; default `subagents` сохраняет прежнее поведение. `main` выполняет верхние этапы текущим агентом, а `main_propagated` дополнительно передаёт `main` совместимым execute/review-этапам.

package/README.md

@@ -3,7 +3,7 @@
 > Поточная разработка с AI-агентами — на русском языке.
 > Пакет готовых скилов и специализированных агентов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
 
-`eda` — это двадцать два скила и пакетные агенты для повторяемых ролей. Скил отвечает за пользовательский workflow и оркестрацию, агент — за изолированную работу с закреплённой моделью и ограничениями. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+`eda` — это двадцать три скила и пакетные агенты для повторяемых ролей. Скил отвечает за пользовательский workflow и оркестрацию, агент — за изолированную работу с закреплённой моделью и ограничениями. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
 
 ---
 
@@ -47,11 +47,12 @@ eda update-all ~/Code
 | `eda-business` | Совместно с человеком описывает целевое поведение проекта по тематическим карточкам: сложные темы фиксирует подробно, но без шума, соседних модулей и привязки к текущему коду. Может закрепить значимый механизм вроде JWT или серверного хранения токенов, но не язык, библиотеку или конкретную СУБД. `about` содержит лишь короткое описание проекта и основные возможности | `docs/business.md`, `docs/business/` |
 | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/artifacts/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. После определения темы читает только применимые business- и reference-карточки. В дефолтном режиме ведёт исследование как диалог; для пакетов и ПО проверяет актуальные стабильные версии | `docs/artifacts/researches/` |
-| `eda-plan` | Пишет план реализации через Plan Mode: фиксирует решения, БД/API-контракты и фазы, каждую из которых один агент выполняет и проверяет за один проход. Задач с идентификаторами внутри фаз нет. Реализацию не описывает — её задают `docs/rules.md`, `docs/arch.md` и карточки. Если целевое поведение ещё не описано в business-карточках, до реализации добавляет `Дополнить бизнесовые правила`; если решение противоречит правилам или архитектуре, сначала меняет сам документ. По `plan.review` запускает изолированный `eda-plan-polish`; `plan.strict` независимо включает кросс-CLI ревью | `docs/artifacts/plans/`, опционально plan-review артефакты |
+| `eda-plan` | Пишет план реализации через Plan Mode: фиксирует решения, БД/API-контракты и фазы, каждую из которых один агент выполняет и проверяет за один проход. Задач с идентификаторами внутри фаз нет. Реализацию не описывает — её задают `docs/rules.md`, `docs/arch.md` и карточки. Если целевое поведение ещё не описано в business-карточках, до реализации добавляет `Дополнить бизнесовые правила`; если решение противоречит правилам или архитектуре, сначала меняет сам документ. По `plan.review` запускает изолированный `eda-plan-polish` ровно на одну итерацию полировки (`limit 1`); `plan.strict` независимо включает кросс-CLI ревью | `docs/artifacts/plans/`, опционально plan-review артефакты |
 | `eda-plan-review` | Одним read-only проходом проверяет план по фиксированному чек-листу из 16 пунктов: покрытие запроса, отсутствие развилок, соответствие правилам и архитектуре, дубли, регистр текста, фазы и объём. Замечания вне списка не принимает. Оценка — доля закрытых пунктов, поэтому растёт монотонно. План не меняет | `docs/artifacts/plan-reviews/` |
 | `eda-plan-review-fix` | Закрывает проваленные пункты чек-листа минимальным изменением плана с совпадающим SHA-256. План не растёт: сначала удаление и замена, прирост объёма за один заход не больше 3%. Новое ревью не делает и код не меняет | `docs/artifacts/plan-review-fixes/` |
-| `eda-plan-polish` | Оркестрирует изолированный цикл plan-review → plan-review-fix. Хранит снапшот лучшей версии плана: как только score перестаёт расти, останавливается и восстанавливает лучшую версию, а не последнюю. По умолчанию две review-итерации. Кросс-CLI strict не используется | `docs/artifacts/plan-reviews/`, `docs/artifacts/plan-review-fixes/` |
+| `eda-plan-polish` | Оркестрирует изолированный цикл plan-review → plan-review-fix. Хранит снапшот лучшей версии плана: как только score перестаёт расти, останавливается и восстанавливает лучшую версию, а не последнюю. По умолчанию одна итерация: проверка и исправление. Исправление проверяет ревью следующей итерации, поэтому при `limit 1` последняя правка остаётся неперепроверенной. Кросс-CLI strict не используется | `docs/artifacts/plan-reviews/`, `docs/artifacts/plan-review-fixes/` |
 | `eda-plan-execute` | Управляет выполнением плана по фазам в режиме `subagents`, `main` или `auto`. В `subagents` каждую фазу целиком выполняет отдельный изолированный субагент: он читает план, правила, архитектуру и только business/reference-карточки затронутого поведения и компонентов. Фазы проходят строго последовательно и принимаются независимыми проверяющими. В `main` весь план по тем же правилам выполняет и проверяет основной агент в одном контексте, а `auto` выбирает режим по плану. Отметки подтверждённых задач и журнал ведёт основной агент | `docs/artifacts/executions/` |
+| `eda-just-do-it` | Сразу выполняет задачу из текста рядом с вызовом: определяет scope, загружает только необходимые проектные инструкции, business/reference-карточки, код и тесты, вносит нужные изменения и проверяет результат. Не подменяет выполнение планом и не делает git- или внешние действия без прямого указания | `docs/artifacts/just-do-it/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или плану. Перед правками читает правила, архитектуру и только применимые карточки, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/artifacts/fixes/` |
 | `eda-review` | Оркестрирует отдельные read-only проверки корректности, архитектуры, правил, references, business-правил, плана, качества, тестов, безопасности, производительности, frontend/UI/UX, API, БД, документации и предыдущих ревью. Сохраняет только доказанные дефекты, которые обязательно исправить; косметические и спекулятивные предложения отбрасывает. Любая находка даёт `changes-required`, а чистое ревью — `clean` и 100/100. Без аргументов ревьюит `git diff HEAD` | `docs/artifacts/reviews/` |
 | `eda-fix-by-review` | Применяет все находки из ревью с учётом правил, архитектуры и применимых карточек. Спрашивает только при неоднозначности, конфликте, расширении scope или рискованном действии. В конце ссылается на отчёт прямо в файле ревью | `docs/artifacts/review-fixes/` |
@@ -138,7 +139,7 @@ eda update-all ~/Code
 | `eda-plan` | `strict`, `без ревью плана`, `без проверок` | `strict` независимо включает кросс-CLI проверку; `без ревью плана` отключает встроенный review/fix; `без проверок` отключает оба вида ревью | Когда нужно разделить создание плана и его последующую полировку |
 | `eda-plan-review` | `threshold N` | Разово меняет долю закрытых пунктов, при которой план считается готовым | Для самостоятельного аудита готового плана |
 | `eda-plan-execute` | `subagents` / `main` / `auto` | Разово меняет, где выполняются фазы, поверх `plan-execute.mode` | `main` для небольшого плана в одном контексте, `subagents` для большого или тяжёлого |
-| `eda-plan-polish` | `threshold N`, `limit N` | Меняет gate и максимальное число подтверждающих review-итераций | Для доводки ответственных планов перед `eda-plan-execute` |
+| `eda-plan-polish` | `threshold N`, `limit N` | Меняет gate и максимальное число итераций «проверка + исправление» | Для доводки ответственных планов перед `eda-plan-execute` |
 | `eda-manual-test` | `full` / `полная проверка`, `smoke` / `быстро` | Разово меняет глубину ручной проверки поверх `manual-test.depth` | `smoke` для короткой правки, `full` — когда нужно закрыть все области после плана |
 | `eda-review` | `subagents` / `main` | Разово меняет способ выполнения выбранных проверок поверх `review.execution` | `main` экономит контекст на частых локальных ревью; `subagents` сохраняет независимость ролей для ответственных изменений |
 
@@ -234,8 +235,8 @@ plan-review:
   threshold: 100
 
 plan-polish:
-  # Максимальное число подтверждающих review-итераций.
-  limit: 2
+  # Максимальное число итераций «проверка + исправление».
+  limit: 1
 
 plan-execute:
   # Где eda-plan-execute выполняет фазы плана.
@@ -396,10 +397,10 @@ discover-automations:
 - `steps[].on_failure` — настраивает исправление failed manual-test прямо рядом с этим шагом: `skill` и `args` задают фикс, `then` — повторяемые id шагов, `max_cycles` — лимит. Если обработчика нет, оркестратор сохраняет failed-отчёт и останавливается.
 - `aim.mode` — `automatic` самостоятельно выбирает безопасные ответы на рабочие вопросы; `manual` передаёт вопросы человеку. Явный режим в текущем вызове имеет приоритет.
 - `explore.strict` и `explore.decision_mode` — кросс-CLI ревью и способ выбора по исследовательским развилкам в `eda-explore`.
-- `plan.review` — изолированный цикл `eda-plan-polish` внутри `eda-plan`; `plan.strict` независимо управляет кросс-CLI ревью.
+- `plan.review` — изолированный цикл `eda-plan-polish` внутри `eda-plan`, ровно одна итерация полировки (`limit 1`); `plan.strict` независимо управляет кросс-CLI ревью.
 - `plan.size`, `plan.decision_mode`, `plan.test_strategy`, `plan.logging_strategy` — режим и структура работы `eda-plan`.
 - `plan-review.threshold` — доля закрытых пунктов чек-листа для статуса `ready`, default `100`. Отдельных агентов у `plan-review` больше нет: проверку целиком делает один субагент.
-- `plan-polish.limit` — максимальное число подтверждающих review-итераций; default `2`. Цикл останавливается раньше, если score перестал расти.
+- `plan-polish.limit` — максимальное число итераций «проверка + исправление»; default `1`. Отдельного подтверждающего прохода нет: исправление проверяет ревью следующей итерации. Цикл останавливается раньше, если score перестал расти.
 - `plan-execute.mode` — где `eda-plan-execute` выполняет фазы: `subagents` — каждая фаза в отдельном изолированном субагенте с независимой проверкой, `main` — весь план одним контекстом без субагентов, `auto` — выбор по плану; default `auto`. Явный режим в вызове имеет приоритет.
 - `manual-test.depth` — глубина ручной проверки в `eda-manual-test`: `full` — закрыть все применимые области матрицы покрытия, `smoke` — только запуск и основной сценарий изменённой области, `ask_each_time` — спрашивать каждый раз; default `full`. Явная глубина в вызове имеет приоритет.
 - `review.execution` — где выполняются проверки `eda-review`: `subagents` запускает отдельные специализированные роли, `main` выполняет те же выбранные проверки основным агентом без субагентов и с однократной загрузкой общего контекста; default `subagents`. Явный режим в вызове имеет приоритет.
@@ -459,14 +460,14 @@ roadmap ────────> explore ─────> plan ───> plan-
                                                       fix ─────────────> manual-test
 
 polish = полное review ─> fix-by-review всех находок ─> подтверждающий review до clean и нужной оценки
-plan-polish = специализированный plan-review ─> plan-review-fix всех находок ─> подтверждающий review до gate или limit
+plan-polish = итерации «plan-review ─> plan-review-fix всех находок» до gate или limit
 
 discover-automations может запускаться от review, fix-by-review или fix.
 ```
 
 `eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API, базу, консольные команды, интерфейс и алгоритмы перед ревью или коммитом.
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra main <задача>`, `eda-orhestra main_propagated <задача>`, `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный режим исполнения задаётся в `orhestra.execution`, порядок и аргументы — в `orhestra.steps`. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra main <задача>`, `eda-orhestra main_propagated <задача>`, `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный режим исполнения задаётся в `orhestra.execution`, порядок и аргументы — в `orhestra.steps`. Для прямой задачи без отдельного процесса вызови `eda-just-do-it <задача>`: скил сам выберет необходимый контекст, выполнит работу и сохранит отчёт. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 
 Вызов `eda-commit` без контекста охватывает все незакоммиченные tracked-изменения и содержательные untracked-файлы; очевидные кэши, временные и локальные служебные артефакты остаются вне коммитов. Executor сам делит полный состав на необходимое число логически цельных коммитов — один, три или больше. Например, запрос `eda-commit сразу отправь ветку, создай PR и дай ссылку` использует тот же полный состав и выполняет всю указанную цепочку без отдельного вопроса после серии коммитов.
 

package/lib/install.js

@@ -273,7 +273,7 @@ const DEFAULT_SETTINGS = {
     threshold: 100
   },
   planPolish: {
-    limit: 2
+    limit: 1
   },
   planExecute: {
     mode: 'auto'
@@ -785,7 +785,7 @@ export async function askSettings({
     ['plan', 'plan.testStrategy', settings.plan, 'testStrategy', 'Какую стратегию тестов eda-plan использовать по умолчанию?', TEST_STRATEGY_CHOICES],
     ['plan', 'plan.loggingStrategy', settings.plan, 'loggingStrategy', 'Какую стратегию логирования eda-plan использовать по умолчанию?', LOGGING_STRATEGY_CHOICES],
     ['plan-review', 'planReview.threshold', settings.planReview, 'threshold', 'Какой порог готовности использовать в eda-plan-review?', PLAN_REVIEW_THRESHOLD_CHOICES],
-    ['plan-polish', 'planPolish.limit', settings.planPolish, 'limit', 'Сколько review-итераций разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES],
+    ['plan-polish', 'planPolish.limit', settings.planPolish, 'limit', 'Сколько итераций «проверка + исправление» разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES],
     ['plan-execute', 'planExecute.mode', settings.planExecute, 'mode', 'Как eda-plan-execute должен выполнять фазы по умолчанию?', PLAN_EXECUTE_MODE_CHOICES],
     ['manual-test', 'manualTest.depth', settings.manualTest, 'depth', 'Какую глубину ручной проверки использовать в eda-manual-test по умолчанию?', MANUAL_TEST_DEPTH_CHOICES],
     ['review', 'review.execution', settings.review, 'execution', 'Как eda-review должен выполнять проверки по умолчанию?', REVIEW_EXECUTION_CHOICES]
@@ -1485,7 +1485,7 @@ plan-review:
   threshold: ${settings.planReview.threshold}
 
 plan-polish:
-  # Максимальное число подтверждающих review-итераций.
+  # Максимальное число итераций «проверка + исправление».
   # Положительное целое число.
   limit: ${settings.planPolish.limit}
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "3.7.0",
+  "version": "3.9.0",
   "description": "Пакет скилов и специализированных агентов eda-* для Claude Code и Codex CLI",
   "type": "module",
   "bin": {

package/skills/eda-just-do-it/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: eda-just-do-it
+description: 'Прямо выполняет задачу, указанную пользователем рядом с вызовом скилла.'
+---
+
+# Скил: Просто сделай (eda-just-do-it)
+
+Сразу доведи задачу пользователя до проверяемого результата в текущем проекте. Не заменяй выполнение планом, исследованием или ревью, если пользователь не попросил именно такой результат.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: требуемый результат, scope, пути, ограничения и явно разрешённые внешние действия. Старое обсуждение используй только там, где пользователь прямо связал его с текущей задачей.
+
+Если входа достаточно, продолжай без подтверждения и без пересказа плана действий. `AskUserQuestion` задавай только когда отсутствует обязательный выбор, требования противоречат друг другу, есть несколько равнозначных целей или без ответа возникает существенный риск сделать не то.
+
+## Главные правила
+
+1. **Делай то, что попросили.** Сам выполни задачу в текущем контексте. Не отправляй пользователя к другому `eda-*`-скилу только потому, что существует более специализированный процесс. Другой скил применяй, только если пользователь явно включил его в задачу.
+2. **Не расширяй scope.** Выполняй необходимые сопутствующие изменения, но не добавляй улучшения, которые не нужны для заданного результата.
+3. **Загружай только нужный контекст.** Сначала определи scope, затем читай относящиеся к нему инструкции, документы, код и тесты. Не загружай все business- и reference-карточки на всякий случай.
+4. **Сохраняй пользовательскую работу.** Перед изменениями проверь текущее состояние рабочей директории и не перезаписывай несвязанные правки.
+5. **Проверяй результат.** Для изменений поведения добавь или обнови точечные тесты. Выполни применимые тесты, линтеры, typecheck, сборку или предметную проверку; не заявляй о том, что не запускалось.
+6. **Внешние и git-действия — только по запросу.** Не коммить, не пушь, не создавай PR, не публикуй и не деплой без прямого указания рядом с вызовом. Для необратимого или разрушительного действия нужен однозначный target; при неоднозначности спроси.
+7. **Артефакт обязателен.** Создай отчёт до первого содержательного изменения и поддерживай его в актуальном состоянии. Заверши отчёт даже при частичном результате, блокере или ошибке.
+
+## Как выбрать контекст
+
+1. Прочитай применимые `AGENTS.md` и другие проектные инструкции для затронутых путей.
+2. Прочитай файлы и артефакты, прямо названные пользователем.
+3. Если меняется проект, прочитай `docs/rules.md` и `docs/arch.md`, когда они существуют.
+4. Сначала определи затронутое поведение. Если есть `docs/business.md`, выбери по описаниям и прочитай только применимые business-карточки из `docs/business/`. Отсутствие подходящей карточки не блокирует работу.
+5. Если есть `docs/references.md`, выбери по индексу и прочитай только карточки затронутых компонентов из `docs/references/`.
+6. Найди минимальный набор исходников, тестов, конфигурации и документации, необходимый для выполнения и проверки задачи. Расширяй контекст только когда обнаруженная зависимость действительно влияет на результат.
+
+Если запрос противоречит проектной инструкции, business-правилу или архитектурному ограничению, не обходи их молча: зафиксируй конфликт в отчёте и запроси недостающее решение через `AskUserQuestion`.
+
+## Выполнение
+
+1. Сформулируй для себя проверяемый результат и границы задачи.
+2. Собери необходимый контекст по правилам выше и проверь текущее состояние проекта.
+3. Создай файл отчёта со статусом `in-progress`.
+4. Выполни задачу полностью. Исправляй ошибки, вызванные своими изменениями; несвязанные проблемы не маскируй и не чини без необходимости.
+5. Проверь фактический результат подходящими командами или наблюдаемым сценарием.
+6. Обнови отчёт только подтверждёнными действиями и результатами, поставь итоговый статус `done`, `partial`, `blocked` или `failed`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, запиши вопрос и варианты в отчёт.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Артефакт
+
+Сохрани отчёт в `docs/artifacts/just-do-it/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Если имя занято, добавь числовой суффикс. Даже если задача завершилась до изменений, оказалась заблокирована или упала, отчёт должен существовать и честно описывать результат.
+
+```markdown
+---
+date: <YYYY-MM-DD HH:MM>
+status: in-progress
+---
+
+# Just do it: <краткий заголовок>
+
+## Запрос
+<что пользователь поручил сделать>
+
+## Учтённый контекст
+- `<путь>` — <зачем прочитан>
+
+## Что сделано
+| # | Действие или файл | Результат |
+|---|-------------------|-----------|
+| 1 | ... | ... |
+
+## Проверки
+| Команда или сценарий | Результат | Заметки |
+|----------------------|-----------|---------|
+| `<command>` | ✓ / ✗ / не запускалась | ... |
+
+## Осталось
+<«Ничего» либо конкретный остаток, блокер и требуемое решение>
+```
+
+Перед завершением замени `in-progress` на итоговый статус. Не включай в артефакт секреты, токены и лишний вывод команд.
+
+## Финал
+
+Коротко сообщи: что выполнено, чем проверено, что осталось и путь к обязательному отчёту. Если были git- или внешние действия, перечисли только фактически выполненные.

package/skills/eda-plan/SKILL.md

@@ -201,10 +201,13 @@ Quality gate перед сохранением и после каждой вкл
 
 Иначе запусти `eda-plan-polish` в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает review или fix сам.
 
+Прогоняется ровно одна итерация полировки — `limit 1`: одна проверка и одно исправление. Второй круг здесь не нужен: план уже прошёл quality gate, и лишние итерации чаще раздувают текст, чем улучшают его. Плата за это — исправление остаётся неперепроверенным, поэтому `status: reviewed` появится только если ревью сразу вернуло `ready`.
+
 1. Запусти один `eda-plan-polish`:
 
 ```text
-Используй eda-plan-polish для <PLAN_FILE>.
+Используй eda-plan-polish для <PLAN_FILE> с limit 1.
+Прогони ровно одну итерацию полировки: проверка и исправление. Дальше не иди.
 Исходная задача и решения: <текущий запрос и ответы пользователя>.
 Верни результат, последний review/fix, score, threshold и открытые ID.
 ```

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

@@ -5,7 +5,7 @@ description: 'Доводит план циклом ревью и исправл
 
 # Скил: Полировка плана (eda-plan-polish)
 
-Оркестрируй цикл `eda-plan-review` → `eda-plan-review-fix` → подтверждающий `eda-plan-review`. Сам план не правь и score не выставляй: ты выбираешь план, запускаешь каждый скил в отдельном изолированном субагенте, следишь за ростом оценки и решаешь, когда остановиться.
+Оркестрируй цикл `eda-plan-review` → `eda-plan-review-fix`. Сам план не правь и score не выставляй: ты выбираешь план, запускаешь каждый скил в отдельном изолированном субагенте, следишь за ростом оценки и решаешь, когда остановиться.
 
 Главное отличие от простого повторения итераций: **цикл останавливается, как только оценка перестаёт расти, и оставляет лучшую версию плана, а не последнюю.**
 
@@ -20,7 +20,7 @@ description: 'Доводит план циклом ревью и исправл
 Прочитай `docs/settings.yaml`, если есть. Поддерживается только `version: 3`; иначе defaults и предупреждение.
 
 - `plan-review.threshold` — доля закрытых пунктов для `ready`, default `100`;
-- `plan-polish.limit` — максимум подтверждающих review-итераций, default `2`;
+- `plan-polish.limit` — максимум итераций «проверка + исправление», default `1`;
 - прямые `threshold N` и `limit N` в сообщении важнее файла.
 
 `strict` и кросс-CLI здесь не поддерживаются.
@@ -29,7 +29,7 @@ description: 'Доводит план циклом ревью и исправл
 
 1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix` запускай отдельным изолированным субагентом с чистым контекстом.
 2. Если нативные субагенты недоступны, остановись. Не делай review или fix сам и не используй CLI-fallback.
-3. Успех — только review со статусом `ready`.
+3. Успех — только review со статусом `ready`. Остановка сразу после fix успехом не считается.
 4. Основной агент не меняет содержание плана. После `ready` он может обновить только front matter: `status`, `plan_review`, `plan_review_fix`.
 5. Не запускай проверки проекта и не коммить.
 
@@ -44,7 +44,7 @@ description: 'Доводит план циклом ревью и исправл
 - временная API-, server-, overload- или network-ошибка — один раз продолжи того же агента; если resume недоступен, один раз запусти ту же роль с исходным входом, полным частичным результатом и требованием сначала сверить текущее состояние; повторный такой сбой заверши как `blocked` с исходной ошибкой;
 - неизвестная техническая ошибка — не угадывай причину и не зацикливай retry; заверши `blocked: техническая ошибка субагента` с полным исходным текстом.
 
-Ожидание слота и один технический retry не расходуют `$LIMIT` и не считаются новой review-итерацией.
+Ожидание слота и один технический retry не расходуют `$LIMIT` и не считаются новой итерацией.
 
 ## Снапшот лучшей версии
 
@@ -52,10 +52,12 @@ description: 'Доводит план циклом ревью и исправл
 
 Дальше на каждой итерации: если новый score выше лучшего — перезапиши снапшот и обнови лучший score. Если ниже или равен — снапшот не трогай.
 
-При остановке без `ready`: если последний score ниже лучшего, восстанови план из снапшота и скажи об этом прямо. После успешного `ready` удали снапшот.
+При остановке без `ready`: если последний score ниже лучшего, восстанови план из снапшота и скажи об этом прямо. Если цикл кончился сразу после fix, score этой версии не измерен — план не откатывай, но скажи, что последнее исправление не перепроверялось. После успешного `ready` удали снапшот.
 
 ## Цикл
 
+Итерация — это `eda-plan-review` плюс `eda-plan-review-fix`. `$LIMIT` считает именно их, поэтому `limit 1` означает одну проверку и одно исправление. Отдельного подтверждающего прохода нет: исправление проверяет review следующей итерации, а после последнего исправления цикл заканчивается непроверенным — это цена низкого лимита.
+
 Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и журнал: итерация, путь review, SHA-256 плана, score, открытые пункты, путь fix.
 
 Для `$ITERATION` от `1` до `$LIMIT`:
@@ -73,8 +75,7 @@ description: 'Доводит план циклом ревью и исправл
 4. Если статус `ready` — обнови front matter плана (`status: reviewed`, последние `plan_review` и `plan_review_fix`), удали снапшот, заверши успешно.
 5. **Стоп по отсутствию роста.** Если это не первая итерация и score не вырос относительно предыдущей — останови цикл, восстанови лучшую версию и сообщи, какая итерация была лучшей. Дальнейшие круги только ухудшают план.
 6. Если статус `changes-required`, но проваленных пунктов нет — остановись: `blocked: ревью нарушает контракт gate`.
-7. Если это последняя разрешённая итерация — остановись с причиной `достигнут limit`; fix не запускай, перепроверить его будет нечем.
-8. Запусти новый изолированный субагент:
+7. Запусти новый изолированный субагент:
 
    ```text
    Используй eda-plan-review-fix для <REVIEW_FILE>.
@@ -82,9 +83,9 @@ description: 'Доводит план циклом ревью и исправл
    Верни путь к fix, before_sha256, after_sha256, before_bytes, after_bytes и закрытые пункты.
    ```
 
-9. Проверь, что `before_sha256` равен `plan_sha256` из review. Если `after_sha256` равен `before_sha256` — остановись: `blocked: fix не изменил план`.
-10. Если план вырос больше чем на 3%, зафиксируй это в журнале как предупреждение: рост объёма — причина следующих находок.
-11. Сохрани review и fix как предыдущую цепочку и переходи к следующей итерации.
+8. Проверь, что `before_sha256` равен `plan_sha256` из review. Если `after_sha256` равен `before_sha256` — остановись: `blocked: fix не изменил план`.
+9. Если план вырос больше чем на 3%, зафиксируй это в журнале как предупреждение: рост объёма — причина следующих находок.
+10. Сохрани review и fix как предыдущую цепочку. Есть неизрасходованные итерации — начни следующую: её review заодно проверит это исправление. Иначе остановись с причиной `достигнут limit`.
 
 Score сам не считай и не корректируй: он приходит только из `eda-plan-review`.
 
@@ -92,7 +93,7 @@ Score сам не считай и не корректируй: он приход
 
 Сообщи:
 
-- результат: `ready`, `limit`, `нет роста` или `blocked`;
+- результат: `ready`, `limit`, `нет роста` или `blocked`, и было ли последнее исправление перепроверено;
 - путь к плану и какая версия в нём осталась — последняя или восстановленная лучшая;
 - траекторию score по итерациям и номер лучшей;
 - последние review и fix, порог, открытые пункты;
@@ -105,6 +106,6 @@ Score сам не считай и не корректируй: он приход
 - Делать review, выставлять score или править содержание плана самому.
 - Продолжать цикл, когда score не растёт.
 - Оставлять последнюю версию, если лучшая была раньше.
-- Запускать fix после последней разрешённой итерации.
+- Выдавать план за подтверждённый, когда после последнего исправления review не было.
 - Запускать кросс-CLI, `strict`, `codex exec` или `claude -p`.
 - Писать журнал полировки в тело плана, менять код или запускать проверки проекта.