@gian-tiaga/eda 2.0.0 → 2.1.0

package/skills/eda-fix-by-review/SKILL.md

@@ -5,80 +5,72 @@ description: 'Исправляет код по готовому ревью из
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
 
-Берёшь готовое ревью из `docs/reviews/`, применяешь замечания к коду, сохраняешь отчёт о фиксах в `docs/review-fixes/`. После всех правок — полный прогон тестов и линтеров.
+Берёшь готовое ревью из `docs/reviews/` или сообщения, применяешь все находки к коду и сохраняешь отчёт в `docs/review-fixes/`. После правок выполняешь полный прогон тестов и линтеров.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Сначала разбери тему, задачу, путь к файлу, номера замечаний, ограничения и прямые указания. Если входа достаточно, продолжай без вопроса. Старое обсуждение не считай входом, если пользователь явно не связал его с текущим вызовом.
 
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Режим запуска
-
-Обычный режим: все пункты «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
-
-Режим `apply-optional`: все пункты «Править обязательно» применяешь без исключений. По каждому пункту «На усмотрение автора» сам принимаешь решение без вопроса: применяешь, если правка явно улучшает качество, снижает риск или стоит дёшево; отклоняешь, если польза спорная, правка расширяет scope, создаёт риск регрессии, конфликтует с правилами/архитектурой или требует продуктового решения. Название режима означает «разобрать optional без вопроса», а не «механически применить все optional». Пункты «Не править» всё равно пропускаешь.
+У нового формата ревью одна группа находок: каждый пункт обязательно исправить. Режимов выбора рекомендаций нет. Если дан старый файл с разделами `Править обязательно`, `На усмотрение автора` и `Не править`, применяй только пункты из `Править обязательно`; остальные старые предложения не переноси в работу и отчёт.
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Сначала определи замечания и затронутое ими поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов. Если подходящих business-карточек нет, продолжай без них. Сделай это один раз в начале.
-2. **Интерактивные вопросы** — по разделу ниже.
-3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
-4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
-5. **Логика по группам ревью:** «Править обязательно» — правишь все сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`, где сам решаешь применить или отклонить; «Не править» — пропускаешь и отмечаешь в отчёте.
-6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
-7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
-8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
+1. Перед правкой прочитай `docs/rules.md` и `docs/arch.md`. Определи замечания и затронутое поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов.
+2. Применяй все выбранные находки. Не переоценивай их полезность и не превращай исправление в более широкий рефакторинг.
+3. Задавай вопрос только если находка неоднозначна, противоречит коду или обязательной документации, требует продуктового решения, расширяет scope либо ведёт к рискованному действию. В остальных случаях работай автономно.
+4. Не делай новое ревью и не коммить. Только исправляй замечания и пиши отчёт.
+5. Если находка касается поведения, добавь или обнови точечный тест в той же правке и прогони его.
+6. В конце обязательно прогони полный набор тестов и линтеров один раз.
+7. Пиши просто и конкретно; в отчёте используй таблицу.
 
 ## Интерактивные вопросы
 
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+Когда без ответа нельзя безопасно продолжать:
+
 - Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`, где решение принимает сам агент; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 2–3 вариантами и остановись до ответа.
+- Codex exec и другой неинтерактивный запуск: не читай stdin; верни `blocked: нужен ответ пользователя`, перечисли вопрос и варианты, не выполняй рискованное действие.
+
+Не запускай команды, которые ждут интерактивного ввода в терминале. Вопрос не разрешает молча заменить находку другой правкой или исправлять несвязанные поломки.
 
 ## Этапы
 
 ### 1. Выбрать ревью
-Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», номера замечаний или вставленный текст замечаний. Если замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
 
-Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
+Разбери путь к ревью, название, «последнее ревью», номера находок или вставленный текст. Для текста используй `$REVIEW_SOURCE=review_text`, не выбирай файл и сохраняй отчёт с `review: text`.
+
+Если найден ровно один файл, используй `$REVIEW_SOURCE=review_file`. Если найдено несколько равно подходящих файлов или входа нет, задай один вопрос со списком. Если `docs/reviews/` пуста и текст замечаний не дан, остановись с `blocked: нужно ревью`.
 
 ### 2. Прочитать контекст
-Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Если связанный план содержит `sources.business`, прочитай только перечисленные карточки, относящиеся к исправляемым замечаниям; иначе выбери их по описаниям через `docs/business.md`. Отсутствие подходящей карточки не является блокером. Через `docs/references.md` выбери только применимые технические карточки. Если связанный план содержит `sources.references`, прочитай перечисленные карточки и не загружай остальные.
 
-Если `$REVIEW_SOURCE=review_file`, прочитай сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
+Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Для исправляемого поведения выбери только применимые business-карточки и технические reference-карточки. Если связанный план уже задаёт `sources.business` или `sources.references`, используй относящиеся к находкам пути из этих списков.
+
+При `$REVIEW_SOURCE=review_file` прочитай ревью целиком, а также явно связанные план и research. При `$REVIEW_SOURCE=review_text` работай по текущему сообщению. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи план или research без явной ссылки.
 
-Если `$REVIEW_SOURCE=review_text`, работай по замечаниям из текущего сообщения пользователя. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи связанные plan/research, если они не указаны в тексте.
+### 3. Применить находки
 
-### 3. Применить замечания
-Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
-- **Править обязательно** → правишь все пункты сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
-- **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
-- **Не править** → пропусти.
+Исправь все находки нового формата либо выбранные пользователем номера. Для старого формата возьми только пункты из `Править обязательно`. Делай минимальную достаточную правку и точечную проверку после каждого логического изменения.
 
-Останавливайся и спрашивай, если замечание непонятно, противоречит коду или проектной документации либо задевает рискованное вне ревью (удаление, миграции, секреты). Если исправление противоречит применимой business-карточке, покажи конфликт и спроси: изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Не разрешай такой конфликт автоматически даже в `apply-optional`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
+Остановись с вопросом при неоднозначности, конфликте с правилами, архитектурой или business-карточкой, необходимости расширить scope либо выполнить рискованное действие. При конфликте с business-карточкой предложи изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
 
 ### 4. Финальная проверка
-Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
 
-### 5. Сохранить отчёт о фиксах и связать с ревью
-Сохрани отчёт в `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же что у ревью или близкий). Если `$REVIEW_SOURCE=review_file`, затем **допиши в конец файла ревью** (`$REVIEW_FILE`) раздел со ссылкой:
+Прогони полный сьют тестов и линтеры стандартными командами проекта. Свои поломки исправь и повтори проверку. При чужой или несвязанной ошибке остановись с конкретным блокером.
+
+### 5. Сохранить отчёт и связать с ревью
+
+Сохрани `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Если `$REVIEW_SOURCE=review_file`, допиши в конец `$REVIEW_FILE`:
 
 ```markdown
 ## Применённые фиксы
 Отчёт: `docs/review-fixes/{file}.md`
 ```
 
-Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: такого файла нет. В отчёте укажи `review: text`.
-
-Шаблон отчёта:
+Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: исходного файла нет.
 
 ```markdown
 ---
-review: <путь к docs/reviews/...>
+review: <docs/reviews/... | text>
 date: <YYYY-MM-DD HH:MM>
 status: done
 ---
@@ -89,13 +81,6 @@ status: done
 | # | Замечание | Файлы | Тесты | Статус |
 |---|-----------|-------|-------|--------|
 | 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
-| 2 | ... | ... | — | ✓ применено |
-| 3 | ... | — | — | ✗ отклонено (на усмотрение, причина: <короткое обоснование>) |
-| 4 | ... | — | — | — не править (по решению ревью) |
-
-## Решения по optional
-- **Принято:** <номера и коротко почему>
-- **Отклонено:** <номера и коротко почему, чтобы следующие ревьюеры не повторяли это как открытое замечание>
 
 ## Финальная проверка
 - **Тесты:** `<команда>` — ✓ / ✗
@@ -103,18 +88,16 @@ status: done
 - **Заметки:** <если что-то осталось не зелёным — почему>
 ```
 
-Если `$REVIEW_SOURCE=review_file` и в режиме `apply-optional` отклонены пункты «На усмотрение автора», в добавляемом в ревью разделе `## Применённые фиксы` после ссылки на отчёт добавь короткий список `Отклонённые optional-решения` с причинами. Это нужно, чтобы следующие ревьюеры видели уже принятое решение и не повторяли тот же optional-пункт без новых аргументов.
-
 ### 6. Финал
-Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
+
+Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к fix-отчёту, сколько находок применено, результат финальной проверки и состояние git «не закоммичено». Предложи `eda-commit`.
 
 ## Чего НЕ делать
+
 - Делать само ревью — это `eda-review`.
-- Коммитить, пушить — это `eda-commit`.
-- Применять или отклонять «на усмотрение» молча без явного режима `apply-optional` или ответа пользователя.
-- Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
-- Гонять полный сьют и линтеры на каждой правке — только в конце.
-- Пропускать финальную проверку.
-- Сохранять отчёт куда-либо кроме `docs/review-fixes/`.
-- Загружать несвязанные business-карточки или расширять ими состав исправлений.
-- Игнорировать применимую карточку или молча отклоняться от её требований либо примера.
+- Коммитить или пушить — это `eda-commit`.
+- Выбирать, какие находки достойны исправления: принятая находка уже обязательна.
+- Расширять scope ради улучшений, которых нет в находках.
+- Гонять полный сьют после каждого пункта или пропускать финальную проверку.
+- Сохранять отчёт вне `docs/review-fixes/`.
+- Загружать несвязанные business-карточки или молча отклоняться от применимого правила.

package/skills/eda-orhestra/SKILL.md

@@ -119,7 +119,7 @@ orhestra:
 1. Запусти скилл с подготовленным вводом.
 2. Обработай его вопрос по режиму.
 3. Прочитай сохранённый артефакт и явный статус. `blocked`, неполный обязательный результат или непройденная обязательная проверка останавливают цепочку.
-4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings` и `score >= threshold`; отдельного polish-файла нет.
+4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean`, без находок и с `score >= threshold`; отдельного polish-файла нет.
 5. Для успешного шага сохрани все пути и передай их следующему.
 
 Если `eda-manual-test` вернул `failed`:

package/skills/eda-plan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: eda-plan
-description: 'Создаёт подробный исполнимый план реализации задачи и сохраняет его в `docs/plans/`.'
+description: 'Создаёт конкретный исполнимый план реализации задачи и сохраняет его в `docs/plans/`.'
 ---
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом. По настройкам запускаешь один специализированный `eda-plan-review`, при необходимости один `eda-plan-review-fix`, а в strict — независимую кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом. По настройкам запускаешь специализированный цикл `eda-plan-polish`, а в strict — независимую кросс-CLI проверку.
 
 ## Режим запуска
 
@@ -66,6 +66,7 @@ description: 'Создаёт подробный исполнимый план р
 9. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
 10. Если выбран `plan.size: short`, но задача не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
 11. Каждой задаче в фазах присвой уникальный ID и укажи её прямые зависимости. Собери каждую фазу вокруг одной связной цели и объёма, который один исполнитель может реализовать и проверить за один проход; слишком крупную или несвязную фазу раздели.
+12. Пиши конкретно и без воды. Каждая формулировка должна определять действие, место изменения, поведение или контракт, зависимость, проверку либо существенное принятое решение. Если её удаление ничего из этого не меняет, удали её из плана.
 
 ## Этапы
 
@@ -92,6 +93,7 @@ description: 'Создаёт подробный исполнимый план р
 6. Требование: план следует правилам, архитектуре и применимым эталонам с указанным приоритетом; при конфликте или необоснованном отклонении остановиться и спросить пользователя.
 7. Требование: финальный план нормализуется в структуру ниже, не смешивает исследование с исполнением и не добавляет неподтверждённые существенные решения.
 8. Требование: каждая задача получает уникальный ID и прямые зависимости, а каждая фаза образует связный объём работы для одного исполнителя.
+9. Требование: конкретика не равна максимальной подробности. Не пересказывать запрос и существующий код, не повторять один контракт в нескольких разделах, не добавлять очевидные пояснения и не выдумывать пути, символы или API ради видимости конкретики.
 
 Не выходи из Plan Mode, пока пользователь не подтвердил план.
 
@@ -175,6 +177,8 @@ sources:
 - Одну фазу целиком выполняет один изолированный субагент `eda-plan-execute`. Задачи фазы должны относиться к общей цели, иметь согласованный scope и помещаться в один исполнительский проход вместе с точечными и фазовыми проверками.
 - В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты; если область не затрагивается, напиши `Не затрагивается`.
 - В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
+- Не дублируй один и тот же контракт, решение или критерий между разделами. Зафиксируй его в наиболее подходящем месте, а в задачах укажи только действие, которое опирается на него.
+- Не пересказывай задачу, кодовую базу и очевидные механические шаги. Оставляй только сведения, которые меняют реализацию или способ её проверки; точные пути и символы указывай только когда они подтверждены контекстом.
 - Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай plan-review до ответа пользователя.
 
 Quality gate перед сохранением и после каждой включённой проверки:
@@ -191,42 +195,33 @@ Quality gate перед сохранением и после каждой вкл
 - для `short` не больше 2 фаз и явно указан ожидаемый объём;
 - пакеты/ПО имеют конкретные версии или ссылку на существующий lock/config;
 - нет неподтверждённых существенных решений и неразрешённых альтернатив;
+- нет общих призывов, повторов и пояснений, удаление которых не меняет действия, контракты, зависимости, проверки или принятые решения;
 - план можно передать в `eda-plan-execute` без нового исследования.
 
-### 4. Специализированный plan-review и один fix
+### 4. Специализированная полировка плана
 
 Если `plan.review: false`, пропусти этап, оставь `plan_review: none`, `plan_review_fix: none` и перейди к strict-этапу или финалу. Не запускай старое общее мета-ревью.
 
-Если `plan.review: true`, каждый вложенный скил запускай в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает их работу. При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
+Если `plan.review: true`, запусти `eda-plan-polish` в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает review или fix. При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
 
-1. Запусти один `eda-plan-review`:
+1. Запусти один `eda-plan-polish`:
 
    ```text
-   Используй eda-plan-review для <PLAN_FILE>.
+   Используй eda-plan-polish для <PLAN_FILE>.
    Исходная задача и решения: <текущий запрос и ответы пользователя>.
-   Верни путь к review, status, score, threshold и required/optional ID.
+   Верни результат, последний review/fix, score, threshold и открытые ID.
    ```
 
-2. Если review имеет `status: ready`, обнови front matter: `status: reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: none`. Содержательных правок не делай.
-3. Если review имеет `status: changes-required`, запусти ровно один новый изолированный субагент:
-
-   ```text
-   Используй eda-plan-review-fix apply-optional для <REVIEW_FILE>.
-   Примени все required, самостоятельно разбери optional и сохрани waived с причинами.
-   Верни путь к fix, before_sha256, after_sha256, applied и waived ID.
-   ```
-
-4. Проверь связь SHA-256. После успешного fix установи `status: meta-reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: <FIX_FILE>` и снова прогони локальный quality gate структуры плана. Не запускай второй review внутри `eda-plan`.
-5. При `blocked` передай один конкретный вопрос пользователю и продолжи тот же вложенный шаг после ответа.
-
-`meta-reviewed` означает один review и один неперепроверенный fix и остаётся допустимым входом для `eda-plan-execute`. Подтверждённый gate после fix выполняет отдельный `eda-plan-polish`.
+2. Проверь артефакты и SHA-256 цепочку, затем снова прогони локальный quality gate структуры плана.
+3. При `ready` убедись, что front matter содержит `status: reviewed`, последний `plan_review` и последний `plan_review_fix` либо `none`. Содержательных правок не делай.
+4. При limit, отсутствии прогресса или `blocked` не выдавай план за подтверждённый; сообщи открытые ID и передай пользователю только конкретный вопрос, если он действительно нужен.
 
 ### 5. Strict: кросс-CLI и допил
 
 `plan.strict` не зависит от `plan.review`. Обычный режим пропускает этот этап. В `strict` отдай файл соседнему CLI:
 
 ```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, применимые карточки из sources.business и sources.references и связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, нарушения бизнес-требований, неучтённые зависимости, нарушения правил, архитектуры и эталонов, необоснованные отклонения, скрытые риски, недостающие тесты и шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, применимые карточки из sources.business и sources.references и связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Верни только конкретные ошибки и неточности, которые обязательно исправить: для каждой укажи место, доказательство, практический риск и минимальную правку. Не предлагай стилистические улучшения, дополнительные пояснения или расширение текста, если без них план уже однозначно исполним. Список '- [тип] описание — что исправить'." > "${PLAN_FILE%.md}_review.md"
 ```
 
 Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать.
@@ -235,7 +230,7 @@ codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, приме
 
 ### 6. Финал
 
-Коротко сообщи режим, выполнялись ли plan-review/fix и strict, путь к плану, пути к plan-review/plan-review-fix и strict-review при наличии, итоговый status, 3–5 главных шагов и что дальше делает `eda-plan-execute`. Для `meta-reviewed` явно укажи, что подтверждающий gate выполняет `eda-plan-polish`.
+Коротко сообщи режим, выполнялись ли plan-polish и strict, путь к плану, пути к последним plan-review/plan-review-fix и strict-review при наличии, итоговый status, score/threshold, открытые ID, 3–5 главных шагов и что дальше делает `eda-plan-execute`.
 
 ## Чего НЕ делать
 
@@ -249,5 +244,5 @@ codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, приме
 - Сохранять сырой текст Plan Mode без нормализации.
 - Оставлять финальный план исследованием, списком наблюдений или журналом мета-ревью.
 - Смешивать альтернативы с принятыми решениями.
-- Выполнять plan-review или plan-review-fix основным агентом, запускать старые три общих ревьюера или делать второй review внутри `eda-plan`.
+- Выполнять plan-review, plan-review-fix или plan-polish основным агентом либо запускать старые три общих ревьюера.
 - Пропускать кросс-CLI молча в `strict`: если CLI нет, спроси.

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

@@ -5,7 +5,7 @@ description: 'Оркестрирует review и исправления гото
 
 # Скил: Полировка плана (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`. Основной агент только выбирает план, запускает каждый скил в отдельном изолированном субагенте, проверяет артефакты и управляет остановкой.
 
 ## Вход из сообщения пользователя
 
@@ -25,9 +25,9 @@ description: 'Оркестрирует review и исправления гото
 
 ## Правила
 
-1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix apply-optional` запускай отдельным изолированным субагентом с чистым контекстом.
+1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix` запускай отдельным изолированным субагентом с чистым контекстом.
 2. Если нативные субагенты или вложенная делегация недоступны, остановись; не выполняй review/fix основным агентом и не используй CLI-fallback.
-3. Успех определяется только review со статусом `ready`, без required findings и `score >= threshold`.
+3. Успех определяется только review со статусом `ready`, без открытых находок и `score >= threshold`.
 4. Limit считает подтверждающие review-итерации. После review на последней итерации не запускай fix, который нельзя перепроверить.
 5. Основной агент не делает содержательных правок плана. После ready он может обновить только front matter: `status`, `plan_review`, `plan_review_fix`.
 6. Не запускай проверки проекта и не коммить.
@@ -42,7 +42,7 @@ description: 'Оркестрирует review и исправления гото
 
 ## Цикл
 
-Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: iteration, review path, plan SHA-256, score, состояния findings, fix path и причина продолжения.
+Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: iteration, review path, plan SHA-256, score, состояния находок, fix path и причина продолжения.
 
 Для `$ITERATION` от `1` до `$LIMIT`:
 
@@ -53,20 +53,20 @@ description: 'Оркестрирует review и исправления гото
    Previous review: <PREVIOUS_REVIEW | none>.
    Previous fix: <PREVIOUS_FIX | none>.
    Overrides проверок и моделей: <из текущего вызова | none>.
-   Верни путь, status, plan_sha256, score, required/optional ID и coverage.
+   Верни путь, status, plan_sha256, score, открытые ID и coverage.
    ```
 
-2. Прочитай review-артефакт и проверь, что status/score/threshold/findings согласованы.
+2. Прочитай review-артефакт и проверь, что status/score/threshold/находки согласованы.
 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: нет применимых правок для повышения оценки`.
+5. Если относительно предыдущего review не изменились open/resolved/regressed ID и score, остановись `blocked: review не показывает прогресса`.
+6. Если status `changes-required`, но открытых находок нет, остановись `blocked: review нарушает контракт gate`; score ниже threshold нельзя исправлять без конкретных находок.
 7. Запусти новый изолированный субагент:
 
    ```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>.
+   Примени все открытые находки минимальным изменением плана.
+   Верни путь к fix, before_sha256, after_sha256 и applied ID.
    ```
 
 8. Проверь, что `before_sha256` равен `plan_sha256` review. Если `after_sha256` равен `before_sha256`, остановись `blocked: fix не изменил план`.
@@ -76,7 +76,7 @@ Score не повышай и не пересчитывай сам: исполь
 
 ## Финал
 
-Сообщи результат (`ready`, limit, no progress, no applicable fixes или blocked), план, последний review/fix, score/threshold, число review-итераций, open ID и coverage warnings. При ready предложи `eda-plan-execute`; при неуспехе перечисли конкретные оставшиеся findings.
+Сообщи результат (`ready`, limit, no progress, invalid gate или blocked), план, последний review/fix, score/threshold, число review-итераций, open ID и coverage warnings. При ready предложи `eda-plan-execute`; при неуспехе перечисли конкретные оставшиеся находки.
 
 ## Чего НЕ делать
 

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

@@ -1,11 +1,11 @@
 ---
 name: eda-plan-review
-description: 'Проводит специализированное read-only ревью готового плана и сохраняет findings с оценкой готовности.'
+description: 'Проводит специализированное read-only ревью готового плана и сохраняет находки с оценкой готовности.'
 ---
 
 # Скил: Ревью плана (eda-plan-review)
 
-Работай как оркестратор установленных `eda-plan-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их prompts в task-сообщения. Выбери план и проверки, запусти агентов, проверь структурированные ответы, дедуплицируй подтверждённые findings, выставь экспертный score и сохрани один review-артефакт.
+Работай как оркестратор установленных `eda-plan-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их prompts в task-сообщения. Выбери план и проверки, запусти агентов, проверь структурированные ответы, дедуплицируй подтверждённые находки, выставь экспертный score и сохрани один review-артефакт.
 
 ## Вход из сообщения пользователя
 
@@ -85,34 +85,36 @@ description: 'Проводит специализированное read-only р
 
 - один YAML-блок и допустимый `status`;
 - `check` совпадает с ролью, `model` — с фактической моделью;
-- `findings` и `prior_findings` — массивы;
-- у каждого finding есть fingerprint, severity, recommendation, plan_location, problem, evidence, impact, fix, acceptance;
-- `blocked` содержит question; `not_applicable` не содержит findings.
+- `находки` и `предыдущие_находки` — массивы;
+- у каждой находки есть fingerprint, severity, plan_location, problem, evidence, impact, fix, acceptance;
+- `blocked` содержит question; `not_applicable` не содержит находок.
 
 Невалидного или упавшего агента один раз повтори на той же модели с указанием только нарушения контракта. Повторный сбой любой выбранной проверки блокирует всё ревью; итоговый файл не сохраняй.
 
-## Агрегировать findings
+## Агрегировать находки
 
 1. Подтверди evidence точечным чтением указанных файлов. Не добавляй самостоятельные domain-находки.
-2. Отклони недоказанное, вкусовое, уже закрытое, выходящее за scope или противоречащее подтверждённому решению. Существенные отклонения сохрани с fingerprint и причиной.
-3. Объедини findings с одной первопричиной и одной правкой, сохранив все checks и evidence.
-4. Для совпадающего fingerprint сохрани прежний ID. Новому finding дай следующий свободный `PR-NNN`; номер не переиспользуй.
-5. Статусы `waived` сохраняй без повторного открытия, пока нет нового evidence. Required нельзя сделать waived без явного решения пользователя, меняющего исходное требование.
-6. В итог включай только открытые required/optional findings и состояния прошлых ID.
+2. Прими находку только когда план обязательно нужно изменить: есть точное место, доказательство, практическая ошибка или существенная неоднозначность, минимальная правка и проверяемая приёмка. Если замечание можно без последствий не применять, это не находка.
+3. Отклони недоказанное, вкусовое, уже закрытое, выходящее за scope или противоречащее подтверждённому решению. Также отклоняй «лучше подробнее», дополнительные пояснения, обоснования и стилистические улучшения, если без них план уже однозначно исполним.
+4. Недостаток конкретики подтверждён только когда исполнителю придётся заново исследовать область, принять незафиксированное существенное решение или можно получить две существенно разные реализации. Вода или повтор подтверждены, когда точный фрагмент не меняет действие, контракт, зависимость, проверку или решение; исправление для них должно быть удалением либо короткой заменой.
+5. Объедини находки с одной первопричиной и одной правкой, сохранив все checks и evidence.
+6. Для совпадающего fingerprint сохрани прежний ID. Новой находке дай следующий свободный `PR-NNN`; номер не переиспользуй.
+7. В итог включай только открытые находки и состояния прошлых ID. Предложения, которые не требуют обязательной правки плана, сохраняй только в `Отклонённые предложения` и не учитывай в score.
 
 ## Выставить score и gate
 
 Score выставляет главный агент экспертно после обработки всех агентов. Не усредняй оценки, не используй формулу вычетов и не проси агентов ставить score.
 
-- `95–100`: обязательных findings нет, план исполним.
-- `80–94`: остаётся required medium или несколько существенных optional.
-- `60–79`: есть required high.
+- `100`: открытых находок нет, план конкретен и исполним.
+- `95–99`: остаются только локальные, но обязательные находки low.
+- `80–94`: есть находка medium или несколько находок low.
+- `60–79`: есть находка high.
 - ниже `60`: есть critical или требуется серьёзное перепланирование.
-- при отсутствии открытых findings score равен `100`.
-- если состояния open/resolved/regressed/waived не изменились относительно предыдущего review, score не меняй.
+- при отсутствии открытых находок score равен `100`.
+- если состояния open/resolved/regressed не изменились относительно предыдущего review, score не меняй.
 - каждое изменение score объясни закрытыми, новыми или регрессировавшими ID.
 
-Статус `ready` ставь только когда нет открытых required и `$SCORE >= $THRESHOLD`. Иначе статус `changes-required`. Не выдумывай finding только ради достижения threshold.
+Статус `ready` ставь только когда нет открытых находок и `$SCORE >= $THRESHOLD`. Любая открытая находка даёт `changes-required`, независимо от score. Score ниже threshold без открытых находок недопустим: не снижай оценку за необязательные пожелания и не выдумывай находку только ради числа.
 
 ## Сохранить review
 
@@ -145,16 +147,15 @@ checks:
 - **Skipped:** <checks и причины>
 - **Warnings:** <warnings или «нет»>
 
-## Состояние предыдущих findings
+## Состояние предыдущих находок
 | ID | Статус | Доказательство |
 |---|---|---|
 
-## Findings
+## Находки
 
 ### PR-001. <заголовок>
 - **Checks:** <роли>
 - **Severity:** <critical | high | medium | low>
-- **Recommendation:** <required | optional>
 - **Fingerprint:** `<fingerprint>`
 - **Место в плане:** <раздел или задача>
 - **Проблема:** <что не так>
@@ -167,8 +168,7 @@ checks:
 - `<fingerprint>` — <причина или «нет»>
 
 ## Gate
-- **Required open:** <ID или «нет»>
-- **Optional open:** <ID или «нет»>
+- **Открытые находки:** <ID или «нет»>
 - **Результат:** <ready | changes-required>
 ```
 
@@ -176,7 +176,7 @@ Review содержит только проблемы и техническое
 
 ## Финал
 
-Сообщи путь, status, score/threshold, число required/optional, completed/skipped и previous chain. При `changes-required` предложи `eda-plan-review-fix`; при `ready` — `eda-plan-execute` или возврат вызывающему `eda-plan-polish`.
+Сообщи путь, status, score/threshold, открытые ID, completed/skipped и previous chain. При `changes-required` предложи `eda-plan-review-fix`; при `ready` — `eda-plan-execute` или возврат вызывающему `eda-plan-polish`.
 
 ## Чего НЕ делать
 
@@ -184,5 +184,6 @@ Review содержит только проблемы и техническое
 - Запускать тесты, lint, build, typecheck, серверы, миграции, браузерные проверки или API-запросы.
 - Выполнять специализированную роль главным агентом.
 - Запускать другой CLI или generic-fallback.
-- Усреднять score агентов, менять score без изменения findings или переоткрывать waived без нового evidence.
+- Усреднять score агентов, менять score без изменения находок или снижать его за необязательные пожелания.
+- Принимать косметическое расширение текста, дополнительное объяснение или вкусовую формулировку как находку.
 - Сохранять итог после повторного сбоя выбранного агента.