@gian-tiaga/eda 2.1.0 → 3.1.1

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

@@ -1,189 +1,142 @@
 ---
 name: eda-plan-review
-description: 'Проводит специализированное read-only ревью готового плана и сохраняет находки с оценкой готовности.'
+description: 'Проверяет готовый план по фиксированному чек-листу и сохраняет отчёт с оценкой готовности.'
 ---
 
 # Скил: Ревью плана (eda-plan-review)
 
-Работай как оркестратор установленных `eda-plan-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их prompts в task-сообщения. Выбери план и проверки, запусти агентов, проверь структурированные ответы, дедуплицируй подтверждённые находки, выставь экспертный score и сохрани один review-артефакт.
+Read-only проверка одного плана по списку ниже. Список конечный и один и тот же для всех планов: поэтому проверка заканчивается, а оценка растёт по мере закрытия пунктов.
 
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold, предыдущие review/fix, отключённые или принудительно включённые проверки и разовые модели.
-
-Если входа достаточно, продолжай без вопроса. `AskUserQuestion` используй только если план нельзя выбрать однозначно или переданная цепочка review/fix противоречива. Старую историю диалога не считай входом без явной связи с текущим вызовом.
-
-## Настройки
-
-Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`; при другой версии или невалидном поле используй defaults и добавь warning. Прямое указание пользователя важнее файла.
+Ты проверяешь **исполнимость плана**, а не правильность решений. Вопрос: «можно это исполнить, не переспрашивая?» Правильность решений закрыта на этапе Plan Mode через `decision_mode`, а ошибки в чужих API дешевле ловит статический анализ на коде.
 
-Используй `plan-review.threshold` и `plan-review.agents.<check>.mode/model`. Threshold по умолчанию `95`, допустимы целые значения `1–100`.
+Всю работу делай сам, одним проходом. Не запускай субагентов и не дроби проверку по ролям.
 
-| Проверка | Default mode | Claude | Codex |
-|---|---|---|---|
-| `requirements` | `always` | `sonnet` | `gpt-5.6-terra` |
-| `rules` | `always` | `haiku` | `gpt-5.6-luna` |
-| `architecture` | `always` | `opus` | `gpt-5.6-sol` |
-| `feasibility` | `always` | `opus` | `gpt-5.6-sol` |
-| `execution` | `always` | `sonnet` | `gpt-5.6-terra` |
-| `verification` | `always` | `sonnet` | `gpt-5.6-terra` |
-| `api` | `auto` | `sonnet` | `gpt-5.6-terra` |
-| `database` | `auto` | `opus` | `gpt-5.6-sol` |
-| `security` | `auto` | `opus` | `gpt-5.6-sol` |
-| `frontend` | `auto` | `sonnet` | `gpt-5.6-terra` |
-| `performance` | `auto` | `opus` | `gpt-5.6-sol` |
-| `previous` | `auto` | `haiku` | `gpt-5.6-luna` |
-
-Режимы: `always` — каждый раз, `auto` — только по применимости, `off` — не запускать. Неизвестную модель замени default конкретного агента и добавь warning.
-
-## Вопросы
-
-Когда нужен блокирующий вопрос:
-
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 2–3 вариантами и остановись.
-- Codex exec/non-interactive: не читай stdin; верни `blocked: нужен план или решение пользователя`.
+## Вход из сообщения пользователя
 
-## Подготовить контекст
+Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold и предыдущий review.
 
-1. Выбери `$PLAN_FILE` только в `docs/plans/`: явный путь, однозначное совпадение или самый новый файл при словах «последний план». Без готового плана остановись.
-2. Прочитай план целиком и вычисли SHA-256 его байтов как `$PLAN_SHA256` доступной read-only командой.
-3. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и front matter плана настолько, чтобы выбрать проверки, но не делай собственное ревью.
-4. Определи `$BUSINESS_FILES`: используй относящиеся к задаче пути из `sources.business`; для старого плана выбери только применимые карточки через `docs/business.md`. Если подходящих нет — `none`.
-5. Определи `$REFERENCE_FILES`: используй применимые пути из `sources.references`; для старого плана выбери только карточки затронутых компонентов через `docs/references.md`. Не загружай весь каталог.
-6. Определи `$RESEARCH_FILE` из `sources.research` или `none`.
-7. Сформируй краткий `$PLAN_CONTEXT`: исходная задача, scope, критерии готовности, затронутые компоненты, подтверждённые решения и пути к документам. Если задача неизвестна, напиши `task: unknown`.
-8. Определи `$PREVIOUS_REVIEW` и `$PREVIOUS_FIX`. Явные пути имеют приоритет. Иначе используй последний review для того же канонического пути только когда его `plan_sha256` равен текущему SHA-256 или `after_sha256` связанного fix равен текущему SHA-256. Несвязанную историю не подмешивай.
+`$PLAN_FILE` ищи только в `docs/artifacts/plans/`: явный путь, однозначное совпадение или самый новый файл при словах «последний план». Без плана остановись. Если вариантов несколько и выбрать нельзя — `AskUserQuestion`.
 
-## Выбрать проверки
+## Настройки
 
-- `requirements`, `rules`, `architecture`, `feasibility`, `execution`, `verification` запускай по `always/auto/off`; их default `always`.
-- `api` в auto включай для endpoint, handler, DTO, GraphQL/RPC, events, queues, webhooks и внешних интеграций.
-- `database` в auto включай для схем, моделей хранения, SQL, миграций, индексов и транзакций.
-- `security` в auto включай для auth, permissions, внешнего ввода, файлов, сети, секретов, криптографии и чувствительных данных.
-- `frontend` в auto включай для UI-компонентов, стилей, клиентских маршрутов и пользовательского состояния.
-- `performance` в auto включай для запросов, пакетной обработки, кешей, конкурентности, памяти и горячих путей.
-- `previous` в auto включай только при непустой связанной цепочке.
-- Прямые «без X», «включи X» и разовая модель важнее settings.
+Прочитай `docs/settings.yaml`, если есть. Поддерживается только `version: 3`; иначе defaults и warning.
 
-Запиши skipped-проверки и причины. Forced-проверка запускается даже если auto-критерий не найден; агент может вернуть `not_applicable`.
+`plan-review.threshold` — доля закрытых обязательных пунктов для `ready`, в процентах. Default `100`. Прямое указание в сообщении важнее файла.
 
-## Запустить агентов
+## Подготовка
 
-Запусти все выбранные проверки одним параллельным пакетом через установленных нативных агентов:
+1. Прочитай план целиком и вычисли SHA-256 его байтов как `$PLAN_SHA256`.
+2. Прочитай `docs/rules.md`, `docs/arch.md` и только применимые карточки из `sources.business` и `sources.references` плана. Для старого плана выбери только применимые карточки через `docs/business.md`, а для старого плана выбери только карточки затронутых компонентов через `docs/references.md`; нерелевантные не загружай.
+3. Определи `$PREVIOUS_REVIEW`: явный путь либо последний review того же плана, у которого `plan_sha256` совпадает с текущим SHA-256 или с `after_sha256` связанного fix. Несвязанную историю не подмешивай.
 
-- Claude Code: custom agent `eda-plan-review-<check>` через `Agent` tool с настроенной моделью.
-- Codex: custom agent `eda-plan-review-<check>` через `spawn_agent` или точный аналог с настроенной моделью.
+## Чек-лист
 
-Если нативные packaged-агенты недоступны, остановись. Не используй generic-субагентов, `codex exec`, `claude -p` или основной агент как fallback.
+Для каждого пункта верни `pass`, `fail` или `n/a`. Любой ответ подкрепи доказательством: цитатой из плана, путём к файлу или ссылкой на раздел. `n/a` ставь только когда пункт неприменим к этому плану, и пиши причину.
 
-В task-сообщение передавай только рабочую директорию, `PLAN_FILE`, `PLAN_SHA256`, `BUSINESS_FILES`, `REFERENCE_FILES`, `RESEARCH_FILE`, `PREVIOUS_REVIEW`, `PREVIOUS_FIX`, `MODEL` и `$PLAN_CONTEXT`. Полная семантика проверки хранится в prompt агента.
+| № | Пункт |
+|---|---|
+| 1 | Каждая часть запроса покрыта планом |
+| 2 | В плане нет работы вне запроса |
+| 3 | Применимые business-карточки записаны в `sources.business` и отражены в результатах фаз |
+| 4 | План не отклоняется от `docs/rules.md`, `docs/arch.md` и карточек. Где нужно другое поведение, есть отдельный пункт на изменение самого документа до зависимой реализации |
+| 5 | Все существенные решения имеют источник подтверждения: ответ пользователя, research или `autonomous` с причиной |
+| 6 | В плане не осталось решений, которые придётся принимать исполнителю |
+| 7 | Пакеты, библиотеки и сервисы имеют конкретные версии или ссылку на существующий lock |
+| 8 | Есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД` и `API и внешние контракты` |
+| 9 | Ни один факт не описан в двух разделах |
+| 10 | В плане нет сигнатур чужих методов, формул, приведений типов и пересказа кодовых примеров карточек |
+| 11 | У каждой фазы есть цель, что сделать, результат и проверка |
+| 12 | Каждая фаза выполнима одним агентом за один проход вместе с её проверками |
+| 13 | Команды в `Проверке` фазы существуют к моменту её выполнения или создаются в этой же фазе |
+| 14 | План доведён до точки, где результат можно запустить и проверить целиком |
+| 15 | Объём в пределах потолка: `normal` — 40 КБ, `short` — 12 КБ и 2 фазы |
+| 16 | В плане нет раздела `Открытые вопросы` и незакрытых развилок |
 
-## Проверить ответы
+### Как проверять пункт 6
 
-Для каждого ответа проверь:
+Ищи шесть форм. Для каждой находки приведи цитату.
 
-- один YAML-блок и допустимый `status`;
-- `check` совпадает с ролью, `model` — с фактической моделью;
-- `находки` и `предыдущие_находки` — массивы;
-- у каждой находки есть fingerprint, severity, plan_location, problem, evidence, impact, fix, acceptance;
-- `blocked` содержит question; `not_applicable` не содержит находок.
+| Форма | Пример | Как должно быть |
+|---|---|---|
+| Прямая альтернатива | «Redis или Memcached», «можно так или так» | «Кэш — Redis 7.4» |
+| Делегирование решения | «выбрать подходящий драйвер», «на усмотрение исполнителя», «определить в процессе» | назван конкретный драйвер |
+| Мягкая модальность | «предпочтительно», «желательно», «по возможности» | либо требование, либо пункта нет |
+| Число без числа | «разумный таймаут», «оптимальный размер батча», «достаточное количество попыток» | «таймаут 30 с», «батч 100» |
+| Отложенное решение | «уточнить позже», «решить при реализации», «TBD» | решено до сохранения плана |
+| Обобщение вместо требования | «обработать ошибки корректно», «добавить нужные индексы», «настроить логирование» | что происходит при ошибке; какие индексы; какие поля в логах |
 
-Невалидного или упавшего агента один раз повтори на той же модели с указанием только нарушения контракта. Повторный сбой любой выбранной проверки блокирует всё ревью; итоговый файл не сохраняй.
+Критерий: если по формулировке два исполнителя сделают существенно разные вещи — `fail`.
 
-## Агрегировать находки
+Пункт не касается: условных веток («при ошибке — повтор» это описание ветки, а не модальность) и умолчаний, заданных `rules.md` или карточкой — их повторять в плане не нужно.
 
-1. Подтверди evidence точечным чтением указанных файлов. Не добавляй самостоятельные domain-находки.
-2. Прими находку только когда план обязательно нужно изменить: есть точное место, доказательство, практическая ошибка или существенная неоднозначность, минимальная правка и проверяемая приёмка. Если замечание можно без последствий не применять, это не находка.
-3. Отклони недоказанное, вкусовое, уже закрытое, выходящее за scope или противоречащее подтверждённому решению. Также отклоняй «лучше подробнее», дополнительные пояснения, обоснования и стилистические улучшения, если без них план уже однозначно исполним.
-4. Недостаток конкретики подтверждён только когда исполнителю придётся заново исследовать область, принять незафиксированное существенное решение или можно получить две существенно разные реализации. Вода или повтор подтверждены, когда точный фрагмент не меняет действие, контракт, зависимость, проверку или решение; исправление для них должно быть удалением либо короткой заменой.
-5. Объедини находки с одной первопричиной и одной правкой, сохранив все checks и evidence.
-6. Для совпадающего fingerprint сохрани прежний ID. Новой находке дай следующий свободный `PR-NNN`; номер не переиспользуй.
-7. В итог включай только открытые находки и состояния прошлых ID. Предложения, которые не требуют обязательной правки плана, сохраняй только в `Отклонённые предложения` и не учитывай в score.
+## Правила проверки
 
-## Выставить score и gate
+1. Не правь план, код и документацию. Не запускай тесты, линтеры, сборку, миграции и внешние запросы.
+2. Проверяй только пункты списка. Замечание, которое не ложится ни в один пункт, в отчёт не идёт: список — это и есть определение готовности.
+3. Не оценивай качество решений: выбор библиотеки, схему таблиц, архитектурный подход. Их подтверждает пользователь, а не ревью.
+4. Каждый `fail` называет конкретное место в плане и минимальную правку. Правка не должна требовать нового текста больше абзаца; если требует — пункт всё равно `fail`, но в исправлении напиши, что его нужно решить сокращением, а не дописыванием.
+5. Не предлагай расширять текст «для полноты», добавлять пояснения, обоснования и примеры.
+6. Для пункта, закрытого в предыдущем review, ставь `fail` снова только с новым доказательством регресса.
 
-Score выставляет главный агент экспертно после обработки всех агентов. Не усредняй оценки, не используй формулу вычетов и не проси агентов ставить score.
+## Оценка
 
-- `100`: открытых находок нет, план конкретен и исполним.
-- `95–99`: остаются только локальные, но обязательные находки low.
-- `80–94`: есть находка medium или несколько находок low.
-- `60–79`: есть находка high.
-- ниже `60`: есть critical или требуется серьёзное перепланирование.
-- при отсутствии открытых находок score равен `100`.
-- если состояния open/resolved/regressed не изменились относительно предыдущего review, score не меняй.
-- каждое изменение score объясни закрытыми, новыми или регрессировавшими ID.
+```
+всего     = число пунктов со статусом pass или fail
+закрыто   = число пунктов со статусом pass
+score     = round(100 * закрыто / всего)
+status    = ready, если score >= threshold, иначе changes-required
+```
 
-Статус `ready` ставь только когда нет открытых находок и `$SCORE >= $THRESHOLD`. Любая открытая находка даёт `changes-required`, независимо от score. Score ниже threshold без открытых находок недопустим: не снижай оценку за необязательные пожелания и не выдумывай находку только ради числа.
+Пункты `n/a` в знаменатель не входят. Score не выставляй экспертно и не корректируй вручную.
 
-## Сохранить review
+## Сохранить отчёт
 
-После успешной обработки всех выбранных агентов создай `docs/plan-reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+Создай `docs/artifacts/plan-reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
 
 ```markdown
 ---
-plan: <docs/plans/...>
+plan: <docs/artifacts/plans/...>
 plan_sha256: <sha256>
 previous_review: <path | none>
-previous_fix: <path | none>
 score: <0..100>
 threshold: <1..100>
 status: <ready | changes-required>
 date: <YYYY-MM-DD HH:MM>
-checks:
-  - name: <check>
-    model: <model>
-    status: <completed | skipped>
-    reason: <применимость или причина пропуска>
 ---
 
 # Ревью плана: <название>
 
-## Оценка
-**<score>/100.** <экспертное объяснение и изменение относительно предыдущего score>
-
-## Покрытие
-- **Completed:** <checks и модели>
-- **Skipped:** <checks и причины>
-- **Warnings:** <warnings или «нет»>
-
-## Состояние предыдущих находок
-| ID | Статус | Доказательство |
+## Чек-лист
+| № | Статус | Доказательство |
 |---|---|---|
-
-## Находки
-
-### PR-001. <заголовок>
-- **Checks:** <роли>
-- **Severity:** <critical | high | medium | low>
-- **Fingerprint:** `<fingerprint>`
-- **Место в плане:** <раздел или задача>
-- **Проблема:** <что не так>
-- **Доказательства:** <evidence>
-- **Риск:** <impact>
-- **Исправление:** <fix>
-- **Приёмка:** <acceptance>
-
-## Отклонённые предложения
-- `<fingerprint>` — <причина или «нет»>
-
-## Gate
-- **Открытые находки:** <ID или «нет»>
-- **Результат:** <ready | changes-required>
+| 1 | pass | «Готово, когда приложение поднимается…» — покрывает обе части запроса |
+| 6 | fail | [Фаза 3] «настроить разумный таймаут» — число не задано |
+| 3 | n/a | `docs/business.md` в проекте нет |
+
+## Что исправить
+
+### Пункт 6
+- **Место:** Фаза 3, «Что сделать».
+- **Проблема:** «разумный таймаут» — исполнитель выберет любое значение.
+- **Исправление:** назвать число или сослаться на настройку, где оно задано.
+
+## Итог
+- **Закрыто:** 14 из 16 → score 88
+- **Порог:** 100
+- **Результат:** changes-required
+- **Открытые пункты:** 6, 9
 ```
 
-Review содержит только проблемы и техническое покрытие, без похвалы и длинного пересказа плана.
-
 ## Финал
 
-Сообщи путь, status, score/threshold, открытые ID, completed/skipped и previous chain. При `changes-required` предложи `eda-plan-review-fix`; при `ready` — `eda-plan-execute` или возврат вызывающему `eda-plan-polish`.
+Сообщи путь к отчёту, score, порог, статус, номера открытых пунктов и что менялось относительно предыдущего review. При `changes-required` предложи `eda-plan-review-fix`; при `ready` — `eda-plan-execute` или возврат вызывающему `eda-plan-polish`.
 
 ## Чего НЕ делать
 
+- Запускать субагентов, другой CLI или делить проверку по ролям.
 - Править план, код, настройки или документацию проекта.
-- Запускать тесты, lint, build, typecheck, серверы, миграции, браузерные проверки или API-запросы.
-- Выполнять специализированную роль главным агентом.
-- Запускать другой CLI или generic-fallback.
-- Усреднять score агентов, менять score без изменения находок или снижать его за необязательные пожелания.
-- Принимать косметическое расширение текста, дополнительное объяснение или вкусовую формулировку как находку.
-- Сохранять итог после повторного сбоя выбранного агента.
+- Запускать тесты, линтеры, сборку, миграции, серверы и внешние запросы.
+- Добавлять находки вне списка пунктов.
+- Оценивать правильность решений вместо исполнимости плана.
+- Выставлять или корректировать score вручную.
+- Принимать за дефект отсутствие пояснений, обоснований и примеров.

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

@@ -1,88 +1,80 @@
 ---
 name: eda-plan-review-fix
-description: 'Исправляет готовый план по всем находкам сохранённого plan-review.'
+description: 'Закрывает проваленные пункты чек-листа в плане по сохранённому ревью.'
 ---
 
 # Скил: Исправитель плана по ревью (eda-plan-review-fix)
 
-Применяй подтверждённые находки из `docs/plan-reviews/` только к связанному плану. Не делай новое ревью: твой контракт — точечно изменить основные разделы плана и сохранить проверяемую цепочку SHA-256.
+Применяй проваленные пункты из отчёта `docs/artifacts/plan-reviews/` только к связанному плану. Новое ревью не делай: твой контракт — закрыть перечисленные пункты и сохранить проверяемую цепочку SHA-256.
 
 ## Вход из сообщения пользователя
 
-Разбери путь или название review, «последнее ревью», ограничения и явные решения пользователя. Если вход однозначен, продолжай без вопроса. При нескольких равных review или противоречивом target используй `AskUserQuestion`.
+Текст рядом с вызовом — главный вход. Разбери путь или название review, «последнее ревью» и прямые указания пользователя. Если вход однозначен, продолжай без вопроса; при нескольких равных review или противоречивом target — `AskUserQuestion`.
 
-## Вопросы
-
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с вариантами и остановись.
-- Codex exec/non-interactive: не читай stdin; верни `blocked: нужен ответ пользователя` до любых рискованных правок.
+В Codex exec не читай stdin: верни `blocked: нужен ответ пользователя` до любых правок.
 
 ## Правила
 
-1. Работай только с review из `docs/plan-reviews/` и его `plan` из `docs/plans/`.
-2. Вычисли SHA-256 текущего плана до правок. Он обязан совпадать с `plan_sha256` review. При несовпадении остановись: review устарел, нужен новый `eda-plan-review`.
-3. Перед правкой прочитай план, `docs/rules.md`, `docs/arch.md`, только применимые `sources.business`, `sources.references` и `sources.research`.
-4. Не переоценивай находки и не создавай новые. Каждая находка в итоговом review требует исправления. Если находка недоказана, противоречит контексту или непонятна, остановись и попроси повторное review либо решение пользователя.
-5. Не пропускай находку и не заменяй её пожеланием на будущее. Продуктовый выбор, конфликт с business/rules/architecture или расширение scope передай пользователю одним блокирующим вопросом до любых правок.
-6. Делай минимально достаточный diff. Сначала удаляй лишнее или заменяй существующую формулировку; не добавляй новый абзац, если достаточно одной строки, не повторяй сведения между разделами и не добавляй rationale, примеры или фон, которых не требует находка.
-7. Встраивай правки в `Целевой алгоритм`, `Контракты реализации`, фазы, тесты, логирование и эксплуатацию. Не создавай длинный журнал ревью в теле плана.
-8. Сохраняй ID задач и прямые зависимости; при структурной правке актуализируй все ссылки.
-9. Не правь код, конфиги, зависимости, миграции или другие документы. Не запускай проверки проекта.
-
-## Применить находки
-
-1. Прочитай раздел `Gate`, все открытые находки и `Отклонённые предложения`.
-2. До редактирования собери все реальные блокирующие вопросы. Не делай частичную правку до ответа.
-3. Примени все открытые находки одним связным минимальным изменением плана. Отклонённые предложения не применяй.
-4. Для каждого ID зафиксируй `applied`; не меняй fingerprint.
-5. Заранее определи `$FIX_FILE`, обнови front matter плана полями `status`, `plan_review` и `plan_review_fix`, затем вычисли окончательный SHA-256 как `$AFTER_SHA256`.
-6. Если находки были, но итоговый SHA-256 не изменился, остановись `blocked: fix не изменил план` и не выдавай успех.
+1. Работай только с review из `docs/artifacts/plan-reviews/` и его `plan` из `docs/artifacts/plans/`.
+2. Вычисли SHA-256 плана до правок. Он обязан совпасть с `plan_sha256` review. Не совпал — остановись: review устарел, нужен новый `eda-plan-review`.
+3. Перед правкой прочитай план, `docs/rules.md`, `docs/arch.md` и только применимые карточки из `sources.business` и `sources.references`; для старого плана выбери только применимые карточки через `docs/business.md` и `docs/references.md`.
+4. Закрой каждый пункт со статусом `fail`. Пункты `pass` и `n/a` не трогай. Своих замечаний не добавляй: чего нет в отчёте, того нет в работе.
+5. **План не растёт.** Сначала ищи, что удалить или заменить, и только потом — что дописать. Прирост объёма за один fix не больше 3%; если пункт иначе не закрывается, остановись и верни `blocked: пункт требует роста плана` с объяснением.
+6. Не повторяй один факт в двух разделах: поведение живёт в `Целевом алгоритме`, контракты — в `Контрактах реализации`, фаза на них ссылается.
+7. Не добавляй в план сигнатуры чужих методов, формулы, приведения типов, форму классов и пересказ карточек — это те же пункты 9 и 10 чек-листа, только с другой стороны.
+8. Продуктовый выбор, конфликт с business, rules или architecture и расширение scope не решай сам: собери все такие случаи и задай один блокирующий вопрос до любых правок.
+9. Не правь код, конфиги, зависимости, миграции и другие документы. Не запускай проверки проекта.
 
-После успешного изменения:
+## Работа
 
-- если review был `changes-required`, установи в front matter плана `status: meta-reviewed`;
-- установи `plan_review: <REVIEW_FILE>` и `plan_review_fix: <FIX_FILE>` до вычисления after SHA-256 и записи отчёта;
-- не ставь `status: reviewed`: это может сделать только подтверждающий review с gate `ready`.
+1. Прочитай `## Чек-лист` и `## Что исправить` в review. Собери список пунктов `fail` с местами.
+2. Собери реальные блокирующие вопросы. Частичную правку до ответа не делай.
+3. Закрой все пункты одним связным минимальным изменением плана.
+4. Обнови front matter плана: `status: meta-reviewed`, `plan_review`, `plan_review_fix`. `status: reviewed` не ставь — это может сделать только подтверждающий review.
+5. Вычисли SHA-256 после правок как `$AFTER_SHA256`. Если пункты были, а хеш не изменился, остановись: `blocked: fix не изменил план`.
 
-## Сохранить fix-отчёт
+## Отчёт
 
-Создай `docs/plan-review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+Создай `docs/artifacts/plan-review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
 
 ```markdown
 ---
-review: <docs/plan-reviews/...>
-plan: <docs/plans/...>
+review: <docs/artifacts/plan-reviews/...>
+plan: <docs/artifacts/plans/...>
 before_sha256: <sha256 из review>
 after_sha256: <sha256 после изменения>
+before_bytes: <размер до>
+after_bytes: <размер после>
 status: done
 date: <YYYY-MM-DD HH:MM>
 ---
 
 # Исправления плана по ревью: <название>
 
-## Применённые находки
-| ID | Что изменено | Раздел плана | Статус |
-|---|---|---|---|
-| PR-001 | <конкретная правка> | <раздел> | applied |
+## Закрытые пункты
+| № | Что изменено | Раздел плана |
+|---|---|---|
+| 6 | «разумный таймаут» заменён на «30 с» | Фаза 3 |
 
 ## Цепочка
 - **Before SHA-256:** `<hash>`
 - **After SHA-256:** `<hash>`
+- **Объём:** `<до>` → `<после>` (`<+N%>`)
 - **Нужен подтверждающий review:** да
 ```
 
-После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком applied ID. Не дублируй раздел при повторном продолжении того же запуска.
+После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком закрытых пунктов.
 
 ## Финал
 
-Сообщи пути к plan/review/fix, before/after SHA-256, applied ID, оставшиеся блокеры и что изменения не закоммичены. Следующий шаг — `eda-plan-review` для подтверждения или возврат вызывающему `eda-plan-polish`.
+Сообщи пути к плану, review и fix, before/after SHA-256, изменение объёма, закрытые пункты, оставшиеся блокеры и что изменения не закоммичены. Дальше — подтверждающий `eda-plan-review` или возврат вызывающему `eda-plan-polish`.
 
 ## Чего НЕ делать
 
-- Делать новое ревью или выставлять score.
-- Исправлять код или файлы вне выбранного плана, review и fix-отчёта.
-- Применять stale review к другому SHA-256.
-- Молча пропускать находку или самостоятельно разрешать продуктовый конфликт.
-- Раздувать план пояснениями и повторами вместо минимального удаления или замены.
-- Добавлять журнал итераций в тело плана.
-- Коммитить, запускать тесты, lint, build, typecheck, миграции или другой CLI.
+- Делать новое ревью, выставлять score или добавлять свои замечания.
+- Трогать пункты `pass` и `n/a`.
+- Раздувать план пояснениями вместо удаления и замены.
+- Добавлять код, сигнатуры и пересказ карточек.
+- Применять устаревший review к другому SHA-256.
+- Молча разрешать продуктовый конфликт или расширять scope.
+- Править код, файлы вне плана и отчёта, коммитить или запускать проверки проекта.

package/skills/eda-polish/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-polish
-description: 'Итеративно ревьюит и исправляет изменения до чистого результата и заданной оценки качества.'
+description: 'Итеративно ревьюит и исправляет изменения до чистого результата.'
 ---
 
 # Скил: Полировка изменений (eda-polish)
@@ -9,18 +9,18 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, желаемый порог, лимит итераций и ограничения. Передавай в каждый `eda-review` разовые overrides проверок и моделей из запроса пользователя.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций и ограничения. Передавай в каждый `eda-review` разовые overrides проверок и моделей из запроса пользователя.
 
-Порог по умолчанию — `95`, лимит — `5` итераций. Пользователь может задать `до 90`, `threshold 90`, `цель 90` и `limit N`; допустимый score — 1–100, лимит — положительное целое число.
+Лимит по умолчанию — `5` итераций; пользователь может задать `limit N` положительным целым числом. Порога у цикла нет: устаревшие `threshold N`, `до 90` и `цель 90` не применяй и скажи об этом в финале.
 
 ## Правила
 
 1. Каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
 2. Если нативные субагенты недоступны, остановись; не заменяй шаги CLI-процессами.
-3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean`, ноль находок и `score >= threshold`.
-4. Любая находка обязательно исправляется независимо от score. Порог не превращает найденную проблему в допустимую.
+3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean` и ноль находок. Score — только справочное число, условием завершения он не является.
+4. Любая находка обязательно исправляется. Отклонить находку может только `eda-fix-by-review` и только при её фактической неверности.
 5. Не коммить и не отправляй ревью.
-6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, неизменном наборе находок один полный круг или достижении лимита.
+6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, несокращении числа открытых находок за полный круг или достижении лимита.
 
 ## Вопросы
 
@@ -28,7 +28,7 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Цикл
 
-Сформируй `$TARGET_CONTEXT`, `$THRESHOLD`, `$LIMIT` и журнал: номер итерации, review file, result, score, список находок, fix report и причина продолжения.
+Сформируй `$TARGET_CONTEXT`, `$LIMIT` и журнал: номер итерации, review file, result, число открытых находок, список находок, fix report и причина продолжения.
 
 Для каждой итерации:
 
@@ -38,32 +38,34 @@ description: 'Итеративно ревьюит и исправляет изм
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
    Overrides проверок и моделей: <из запроса | none>.
+   Ранее отклонённые находки: <предыдущий review file и fix report | none>.
    Верни путь к файлу, status, result, score, находки и coverage.
    ```
 
 2. Если review остановился из-за обязательного агента, останови цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён.
-3. Если `result: clean`, находок нет и `score >= threshold`, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
+3. Если `result: clean` и находок нет, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
 4. Если находки есть, запусти отдельного субагента:
 
    ```text
    Используй eda-fix-by-review для <REVIEW_FILE>.
-   Примени все находки минимальными достаточными правками и выполни проверки.
-   Верни путь к fix-отчёту и результат проверок.
+   Примени находки минимальными достаточными правками и выполни проверки.
+   Фактически неверную находку отклони с доказательством в отчёте.
+   Верни путь к fix-отчёту, число применённых и отклонённых находок и результат проверок.
    ```
 
 5. После успешных исправлений начни новую итерацию с полным `eda-review`.
 
-Если после полного круга набор находок не изменился, остановись раньше лимита с конкретными оставшимися проблемами. При достижении лимита не скрывай незавершённую сходимость. Состояние `clean` со score ниже threshold является несогласованным с контрактом `eda-review`: при отсутствии находок score должен быть `100`; остановись как на ошибке контракта.
+Если после полного круга число открытых находок не уменьшилось, остановись раньше лимита с конкретными оставшимися проблемами. При достижении лимита не скрывай незавершённую сходимость.
 
 ## Финал
 
-Сообщи результат, итоговый result и score, порог, число итераций, последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
+Сообщи результат, итоговый result и score, число итераций, счётчик находок по кругам («было 12, осталось 3»), последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
 
 ## Чего НЕ делать
 
 - Делать ревью или исправления основным агентом.
 - Запускать отдельный этап проверки готового ревью.
-- Считать цикл успешным только по score при наличии находок.
-- Выбирать или отклонять принятые находки.
-- Переписывать `docs/settings.yaml`, правила или архитектуру ради score.
+- Считать цикл успешным при наличии находок или завершать его по score.
+- Выбирать или отклонять находки основным агентом: отклонение — работа `eda-fix-by-review`.
+- Переписывать `docs/settings.yaml`, правила или архитектуру ради чистого результата.
 - Коммитить, пушить или отправлять ревью.

package/skills/eda-prepare-ai/SKILL.md

@@ -38,7 +38,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 Определи языки, фреймворки, точки входа, зависимости, тесты, хранилища данных, внешние интеграции, инфраструктуру, CI, инструменты качества, структуру директорий и сложившиеся соглашения. Для команд и соглашений используй конфиги и git-историю, а не догадки.
 
-Если вызов пришёл из `eda-new-project`, прочитай переданный `docs/project-starts/*.md`. Подтверждённые требования, основной стек и архитектурные драйверы считай источником целевого состояния; открытые вопросы и отклонённые варианты фактами не считай. Не требуй от стартового документа готовой архитектуры, правил, матрицы проверок или AI/MCP-рекомендаций — их обязан спроектировать этот скил.
+Если вызов пришёл из `eda-new-project`, прочитай переданный `docs/artifacts/project-starts/*.md`. Подтверждённые требования, основной стек и архитектурные драйверы считай источником целевого состояния; открытые вопросы и отклонённые варианты фактами не считай. Не требуй от стартового документа готовой архитектуры, правил, матрицы проверок или AI/MCP-рекомендаций — их обязан спроектировать этот скил.
 
 ### 2. Прочитать существующую документацию