@gian-tiaga/eda 2.0.0 → 3.1.0

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

@@ -1,188 +1,142 @@
 ---
 name: eda-plan-review
-description: 'Проводит специализированное read-only ревью готового плана и сохраняет findings с оценкой готовности.'
+description: 'Проверяет готовый план по фиксированному чек-листу и сохраняет отчёт с оценкой готовности.'
 ---
 
 # Скил: Ревью плана (eda-plan-review)
 
-Работай как оркестратор установленных `eda-plan-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их prompts в task-сообщения. Выбери план и проверки, запусти агентов, проверь структурированные ответы, дедуплицируй подтверждённые findings, выставь экспертный 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` — с фактической моделью;
-- `findings` и `prior_findings` — массивы;
-- у каждого finding есть fingerprint, severity, recommendation, plan_location, problem, evidence, impact, fix, acceptance;
-- `blocked` содержит question; `not_applicable` не содержит findings.
+| Форма | Пример | Как должно быть |
+|---|---|---|
+| Прямая альтернатива | «Redis или Memcached», «можно так или так» | «Кэш — Redis 7.4» |
+| Делегирование решения | «выбрать подходящий драйвер», «на усмотрение исполнителя», «определить в процессе» | назван конкретный драйвер |
+| Мягкая модальность | «предпочтительно», «желательно», «по возможности» | либо требование, либо пункта нет |
+| Число без числа | «разумный таймаут», «оптимальный размер батча», «достаточное количество попыток» | «таймаут 30 с», «батч 100» |
+| Отложенное решение | «уточнить позже», «решить при реализации», «TBD» | решено до сохранения плана |
+| Обобщение вместо требования | «обработать ошибки корректно», «добавить нужные индексы», «настроить логирование» | что происходит при ошибке; какие индексы; какие поля в логах |
 
-Невалидного или упавшего агента один раз повтори на той же модели с указанием только нарушения контракта. Повторный сбой любой выбранной проверки блокирует всё ревью; итоговый файл не сохраняй.
+Критерий: если по формулировке два исполнителя сделают существенно разные вещи — `fail`.
 
-## Агрегировать findings
+Пункт не касается: условных веток («при ошибке — повтор» это описание ветки, а не модальность) и умолчаний, заданных `rules.md` или карточкой — их повторять в плане не нужно.
 
-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.
+## Правила проверки
 
-## Выставить score и gate
+1. Не правь план, код и документацию. Не запускай тесты, линтеры, сборку, миграции и внешние запросы.
+2. Проверяй только пункты списка. Замечание, которое не ложится ни в один пункт, в отчёт не идёт: список — это и есть определение готовности.
+3. Не оценивай качество решений: выбор библиотеки, схему таблиц, архитектурный подход. Их подтверждает пользователь, а не ревью.
+4. Каждый `fail` называет конкретное место в плане и минимальную правку. Правка не должна требовать нового текста больше абзаца; если требует — пункт всё равно `fail`, но в исправлении напиши, что его нужно решить сокращением, а не дописыванием.
+5. Не предлагай расширять текст «для полноты», добавлять пояснения, обоснования и примеры.
+6. Для пункта, закрытого в предыдущем review, ставь `fail` снова только с новым доказательством регресса.
 
-Score выставляет главный агент экспертно после обработки всех агентов. Не усредняй оценки, не используй формулу вычетов и не проси агентов ставить score.
+## Оценка
 
-- `95–100`: обязательных findings нет, план исполним.
-- `80–94`: остаётся required medium или несколько существенных optional.
-- `60–79`: есть required high.
-- ниже `60`: есть critical или требуется серьёзное перепланирование.
-- при отсутствии открытых findings score равен `100`.
-- если состояния open/resolved/regressed/waived не изменились относительно предыдущего review, score не меняй.
-- каждое изменение score объясни закрытыми, новыми или регрессировавшими ID.
+```
+всего     = число пунктов со статусом pass или fail
+закрыто   = число пунктов со статусом pass
+score     = round(100 * закрыто / всего)
+status    = ready, если score >= threshold, иначе changes-required
+```
 
-Статус `ready` ставь только когда нет открытых required и `$SCORE >= $THRESHOLD`. Иначе статус `changes-required`. Не выдумывай finding только ради достижения 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 или «нет»>
-
-## Состояние предыдущих findings
-| ID | Статус | Доказательство |
+## Чек-лист
+| № | Статус | Доказательство |
 |---|---|---|
-
-## Findings
-
-### PR-001. <заголовок>
-- **Checks:** <роли>
-- **Severity:** <critical | high | medium | low>
-- **Recommendation:** <required | optional>
-- **Fingerprint:** `<fingerprint>`
-- **Место в плане:** <раздел или задача>
-- **Проблема:** <что не так>
-- **Доказательства:** <evidence>
-- **Риск:** <impact>
-- **Исправление:** <fix>
-- **Приёмка:** <acceptance>
-
-## Отклонённые предложения
-- `<fingerprint>` — <причина или «нет»>
-
-## Gate
-- **Required open:** <ID или «нет»>
-- **Optional open:** <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, число required/optional, 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 без изменения findings или переоткрывать waived без нового evidence.
-- Сохранять итог после повторного сбоя выбранного агента.
+- Запускать тесты, линтеры, сборку, миграции, серверы и внешние запросы.
+- Добавлять находки вне списка пунктов.
+- Оценивать правильность решений вместо исполнимости плана.
+- Выставлять или корректировать score вручную.
+- Принимать за дефект отсутствие пояснений, обоснований и примеров.

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

@@ -1,105 +1,80 @@
 ---
 name: eda-plan-review-fix
-description: 'Исправляет готовый план по сохранённому plan-review и фиксирует решения по findings.'
+description: 'Закрывает проваленные пункты чек-листа в плане по сохранённому ревью.'
 ---
 
 # Скил: Исправитель плана по ревью (eda-plan-review-fix)
 
-Применяй подтверждённые findings из `docs/plan-reviews/` только к связанному плану. Не делай новое ревью: твой контракт — точечно изменить основные разделы плана и сохранить проверяемую цепочку SHA-256.
+Применяй проваленные пункты из отчёта `docs/artifacts/plan-reviews/` только к связанному плану. Новое ревью не делай: твой контракт — закрыть перечисленные пункты и сохранить проверяемую цепочку SHA-256.
 
 ## Вход из сообщения пользователя
 
-Разбери путь или название review, «последнее ревью», режим `apply-optional`, ограничения и явные решения по ID. Если вход однозначен, продолжай без вопроса. При нескольких равных review или противоречивом target используй `AskUserQuestion`.
+Текст рядом с вызовом — главный вход. Разбери путь или название review, «последнее ревью» и прямые указания пользователя. Если вход однозначен, продолжай без вопроса; при нескольких равных review или противоречивом target — `AskUserQuestion`.
 
-## Режимы
-
-Обычный режим:
-
-- все required применяй без дополнительного подтверждения;
-- optional собери в один-два раунда `AskUserQuestion`;
-- waived и отклонённые findings не применяй.
-
-`apply-optional`:
-
-- все required применяй;
-- optional применяй, если правка конкретна, обратима, остаётся в scope и улучшает исполнимость;
-- иначе пометь optional как `waived` с конкретной причиной;
-- продуктовое решение, конфликт с business/rules/architecture или расширение scope всё равно требует пользователя.
-
-## Вопросы
-
-- 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. Не переоценивай findings и не создавай новые. Если finding недоказан, противоречит контексту или непонятен, остановись и попроси повторное review либо решение пользователя.
-5. Required нельзя автономно отклонить или сделать waived.
-6. Встраивай правки в `Целевой алгоритм`, `Контракты реализации`, фазы, тесты, логирование и эксплуатацию. Не создавай длинный журнал ревью в теле плана.
-7. Сохраняй ID задач и прямые зависимости; при структурной правке актуализируй все ссылки.
-8. Не правь код, конфиги, зависимости, миграции или другие документы. Не запускай проверки проекта.
-
-## Применить findings
+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. Не правь код, конфиги, зависимости, миграции и другие документы. Не запускай проверки проекта.
 
-1. Прочитай раздел `Gate`, все открытые findings и `Отклонённые предложения`.
-2. До редактирования собери все вопросы и optional-решения. Не делай частичную правку до ответа на блокирующий вопрос.
-3. Примени required и выбранные optional одним связным изменением плана.
-4. Для каждого ID зафиксируй `applied` или `waived`; не меняй fingerprint.
-5. Заранее определи `$FIX_FILE`, обнови front matter плана полями `status`, `plan_review` и `plan_review_fix`, затем вычисли окончательный SHA-256 как `$AFTER_SHA256`.
-6. Если обязательные правки были, но итоговый SHA-256 не изменился, остановись `blocked: fix не изменил план` и не выдавай успех.
+## Работа
 
-После успешного изменения:
+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 не изменил план`.
 
-- если 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`.
+## Отчёт
 
-## Сохранить 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>
 ---
 
 # Исправления плана по ревью: <название>
 
-## Применённые findings
-| ID | Что изменено | Раздел плана | Статус |
-|---|---|---|---|
-| PR-001 | <конкретная правка> | <раздел> | applied |
-
-## Waived optional
-| ID | Причина | Новые доказательства для пересмотра |
+## Закрытые пункты
+| № | Что изменено | Раздел плана |
 |---|---|---|
+| 6 | «разумный таймаут» заменён на «30 с» | Фаза 3 |
 
 ## Цепочка
 - **Before SHA-256:** `<hash>`
 - **After SHA-256:** `<hash>`
+- **Объём:** `<до>` → `<после>` (`<+N%>`)
 - **Нужен подтверждающий review:** да
 ```
 
-После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком waived ID. Не дублируй раздел при повторном продолжении того же запуска.
+После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком закрытых пунктов.
 
 ## Финал
 
-Сообщи пути к plan/review/fix, before/after SHA-256, applied/waived, оставшиеся блокеры и что изменения не закоммичены. Следующий шаг — `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.
-- Молча отклонять required или продуктовый конфликт.
-- Добавлять журнал итераций в тело плана.
-- Коммитить, запускать тесты, lint, build, typecheck, миграции или другой CLI.
+- Делать новое ревью, выставлять score или добавлять свои замечания.
+- Трогать пункты `pass` и `n/a`.
+- Раздувать план пояснениями вместо удаления и замены.
+- Добавлять код, сигнатуры и пересказ карточек.
+- Применять устаревший review к другому SHA-256.
+- Молча разрешать продуктовый конфликт или расширять scope.
+- Править код, файлы вне плана и отчёта, коммитить или запускать проверки проекта.

package/skills/eda-polish/SKILL.md

@@ -1,27 +1,26 @@
 ---
 name: eda-polish
-description: 'Итеративно ревьюит и исправляет изменения до заданной оценки качества.'
+description: 'Итеративно ревьюит и исправляет изменения до чистого результата.'
 ---
 
 # Скил: Полировка изменений (eda-polish)
 
-Оркестрируй цикл `eda-review` → `eda-fix-by-review apply-optional` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат.
-В начале каждой итерации запускай полное `eda-review` целевого изменения.
+Оркестрируй цикл `eda-review` → `eda-fix-by-review` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат. В начале каждой итерации запускай полное `eda-review` целевого изменения.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери 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 apply-optional` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
+1. Каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
 2. Если нативные субагенты недоступны, остановись; не заменяй шаги CLI-процессами.
-3. Сравнивай порог только со `score` полного ревью со статусом `reviewed` или `reviewed-with-warnings`.
-4. Все пункты «править обязательно» исправь. Для каждого optional-пункта fix-агент сам решает, применять ли его, и сохраняет причины отклонения, чтобы следующие ревьюеры не повторяли решение без новых аргументов.
+3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean` и ноль находок. Score — только справочное число, условием завершения он не является.
+4. Любая находка обязательно исправляется. Отклонить находку может только `eda-fix-by-review` и только при её фактической неверности.
 5. Не коммить и не отправляй ревью.
-6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, отсутствии применимых замечаний ниже порога или если score не растёт два круга подряд.
+6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, несокращении числа открытых находок за полный круг или достижении лимита.
 
 ## Вопросы
 
@@ -29,53 +28,44 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Цикл
 
-Сформируй `$TARGET_CONTEXT`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: номер итерации, review file, score, fix report и причина продолжения.
+Сформируй `$TARGET_CONTEXT`, `$LIMIT` и журнал: номер итерации, review file, result, число открытых находок, список находок, fix report и причина продолжения.
 
 Для каждой итерации:
 
-1. Запусти отдельного субагента с задачей:
+1. Запусти отдельного субагента:
 
    ```text
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
    Overrides проверок и моделей: <из запроса | none>.
-   Верни путь к файлу, status, score и coverage.
+   Ранее отклонённые находки: <предыдущий review file и fix report | none>.
+   Верни путь к файлу, status, result, score, находки и coverage.
    ```
 
-2. Если review остановился из-за обязательного агента, останови весь цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён и не блокирует цикл.
-3. Если `score >= threshold`, заверши успешно.
-4. Если score ниже порога, прочитай рекомендации. Если обязательных и optional-пунктов нет, остановись `blocked: нет применимых замечаний для повышения оценки`.
-5. Запусти отдельного субагента:
+2. Если review остановился из-за обязательного агента, останови цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён.
+3. Если `result: clean` и находок нет, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
+4. Если находки есть, запусти отдельного субагента:
 
    ```text
-   Используй eda-fix-by-review apply-optional для <REVIEW_FILE>.
-   Примени все обязательные замечания. По каждому optional сам реши, применять ли его; отклонённые решения сохрани с причиной.
-   Верни путь к fix-отчёту и результат проверок.
+   Используй eda-fix-by-review для <REVIEW_FILE>.
+   Примени находки минимальными достаточными правками и выполни проверки.
+   Фактически неверную находку отклони с доказательством в отчёте.
+   Верни путь к fix-отчёту, число применённых и отклонённых находок и результат проверок.
    ```
 
-6. При успешных исправлениях начни следующую итерацию с новым полным `eda-review`.
+5. После успешных исправлений начни новую итерацию с полным `eda-review`.
 
-Если score не растёт два проверенных круга подряд, остановись раньше лимита. Если достигнут лимит, не скрывай незавершённую сходимость.
+Если после полного круга число открытых находок не уменьшилось, остановись раньше лимита с конкретными оставшимися проблемами. При достижении лимита не скрывай незавершённую сходимость.
 
 ## Финал
 
-Сообщи:
-
-- результат: достигнут порог, достигнут лимит, blocked, нет применимых замечаний или score не растёт;
-- итоговую оценку и порог;
-- количество итераций;
-- последний review file и fix report;
-- предупреждения coverage, если они были;
-- что изменения не закоммичены.
-
-При успехе предложи `eda-commit`. При неуспехе назови конкретный блокер или оставшиеся замечания.
+Сообщи результат, итоговый result и score, число итераций, счётчик находок по кругам («было 12, осталось 3»), последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
 
 ## Чего НЕ делать
 
 - Делать ревью или исправления основным агентом.
 - Запускать отдельный этап проверки готового ревью.
-- Сравнивать порог с неполным или заблокированным ревью.
-- Механически применять все optional-пункты.
-- Терять причины отклонённых optional-решений.
-- Переписывать `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. Прочитать существующую документацию