@gian-tiaga/eda 1.0.5 → 2.1.0

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

@@ -1,204 +1,88 @@
 ---
 name: eda-plan-polish
-description: 'Проверяет и улучшает готовый план реализации итерациями до заданной оценки.'
+description: 'Оркестрирует review и исправления готового плана до подтверждённой оценки готовности.'
 ---
 
 # Скил: Полировка плана (eda-plan-polish)
 
-Берёшь готовый план из `docs/plans/` и доводишь его до состояния, когда его можно передать в `eda-plan-execute`. Порог по умолчанию — `95`, лимит по умолчанию — `5` итераций. В `strict` каждая итерация после трёх моделей дополнительно отдаёт план соседнему CLI на кросс-ревью.
-
-Каждая итерация начинается с трёх независимых моделей с одним и тем же промптом. Основной агент не ставит предварительную оценку сам: он оценивает план только после ответов агентов, принимает или отклоняет предложения, правит план при оценке ниже порога и запускает новую итерацию.
+Оркестрируй цикл `eda-plan-review` → `eda-plan-review-fix` → повторный `eda-plan-review`. Основной агент только выбирает план, запускает каждый скил в отдельном изолированном субагенте, проверяет артефакты и управляет остановкой.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла — главный вход. Разбери путь к плану, название или часть названия, «последний план», порог, лимит итераций, ограничения и прямые запреты.
+Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold, limit, отключённые/принудительные проверки, разовые модели и ограничения. Передавай overrides в каждый review.
 
-Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, найдено несколько равных вариантов или есть риск полировать не тот план. Старую историю не считай входом, если пользователь не связал её с текущим вызовом явно.
+Если план выбирается однозначно, продолжай без вопроса. При нескольких равных вариантах передай выбор первому `eda-plan-review` или используй `AskUserQuestion` по правилам среды.
 
 ## Настройки
 
-Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
-
-Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `plan-polish.strict: false`.
-
-- `plan-polish.strict` включает кросс-CLI ревью плана после трёх агентов в каждой итерации; выключение: `normal`, `без strict`, `без строгого режима`.
-- Порог качества по умолчанию — `95`, можно переопределить словами `до 90`, `threshold 90`, `цель 90`.
-- Лимит по умолчанию — `5` итераций, можно переопределить словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
-- Оценка `95–100` означает готовность к исполнению; `80–94` — нужно уточнить; `60–79` — рискованный план; ниже `60` — нужен серьёзный переплан или вопросы пользователю.
-
-## Жёсткие правила
-
-1. Работай только с готовым файлом плана в `docs/plans/`.
-2. Не правишь код. Содержательно менять можно только выбранный файл плана; в `strict` можно создать или обновить только вспомогательный файл `${PLAN_FILE%.md}_strict_cli_review.md`. Миграции, конфиги, зависимости и lock-файлы не трогай.
-3. Не запускай проверки и исполняющие команды: `test`, `lint`, `build`, `typecheck`, `check`, `dev`, `start`, миграции, seed, smoke-тесты, браузерные проверки и API-запросы. При полировке плана можно читать файлы и искать по коду, но нельзя проверять проект выполнением команд.
-4. Не ставь предварительную оценку без агентов. Сразу запускай три изолированных агента параллельно, одним batch, до чтения любого результата.
-5. Итоговую оценку 0–100 выставляй только после чтения результатов всех трёх агентов, а в `strict` — ещё и результата соседнего CLI.
-6. У всех трёх агентов один общий промпт: каждый проверяет весь план целиком, а не отдельную роль.
-7. Не добавляй неподтверждённые существенные решения: БД/API-контракты, зависимости, архитектурные развилки, auth/permissions/payments/secrets/персональные данные и миграции.
-8. Сохраняй структуру `eda-plan`: `Целевой алгоритм`, `Контракты реализации`, `Фазы выполнения`, `Тесты`, `Логирование`, если эти разделы есть или должны быть по формату.
-9. Не пропускай кросс-CLI молча в `strict`: если соседней CLI нет, спроси через `AskUserQuestion`, завершить как normal или прервать.
-10. Если качество не растёт два круга подряд, достигнут лимит или нужен ответ пользователя, остановись и честно назови причину.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это блокирующий вопрос:
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его; иначе задай один короткий вопрос в чат с вариантами 1–3 и остановись до ответа.
-- Codex exec / non-interactive: не читай stdin; если без ответа нельзя безопасно продолжать, заверши со статусом `blocked: нужен ответ пользователя`.
-
-## Процесс
-
-### 1. Выбрать план
-
-Определи `$PLAN_FILE`:
-- указан путь — используй его;
-- указано название или часть названия — найди совпадение в `docs/plans/`;
-- сказано «последний план» — возьми самый новый файл из `docs/plans/`;
-- входа нет — спроси, показав несколько последних планов;
-- `docs/plans/` нет или она пуста — остановись: `blocked: нужен готовый план`.
-
-Прочитай только выбранный план целиком. По front matter извлеки `status`, `mode`, `plan_size`, `test_strategy`, `logging_strategy`, `sources.rules`, `sources.arch`, `sources.references`, `sources.research`, `meta_reviewers`.
-
-Сам не читай `docs/rules.md`, `docs/arch.md`, `sources.references`, `sources.research` и релевантный код на этом шаге. Передай эти пути агентам в общем промпте: проверка правил, архитектуры, эталонов, research и кода — их работа. Если старый план не содержит `sources.references`, но существует `docs/references.md`, передай агентам индекс: они должны выбрать только применимые карточки. Если индекса нет, продолжай без references. Основной агент может открыть внешний файл только позже и точечно, если нужно проверить конкретное предложение агента перед правкой плана. Не запускай проверки.
-
-### 2. Запустить три модели
-
-В каждой итерации, включая первую, запускай в одном batch три изолированных агента:
-
-| Уровень | Claude Code (`Agent` tool) | Codex interactive (`spawn_agent`) | Codex exec / non-interactive fallback |
-|---|---|---|---|
-| Быстрая модель | `haiku` | `gpt-5.4-mini` | `gpt-5.4-mini` |
-| Кодовая модель | `sonnet` | `gpt-5.3-codex` | `gpt-5.3-codex` |
-| Флагманская модель | `opus` | `gpt-5.5` | `gpt-5.5` |
-
-- Claude Code: используй `Agent` tool с моделями из таблицы.
-- Codex interactive: если доступен `spawn_agent` или аналог, используй субагентов с моделями из таблицы. Не используй отдельные `codex exec`, когда субагенты доступны.
-- Codex exec / non-interactive fallback: если субагентов нет, запусти три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
-- Если модель недоступна, возьми ближайшую code-capable модель того же уровня. Не заменяй три уровня одной моделью.
-
-Общий промпт каждому агенту:
-
-```text
-Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, прочитай docs/references.md и выбери только применимые карточки.
-
-Проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и применимым эталонам, обоснованность отклонений от примеров, полноту целевого алгоритма, БД/API/внешние контракты, связность и размер фаз для одного исполнителя на фазу, тестовые сценарии, логирование, неподтверждённые решения, скрытые риски и места, где eda-plan-execute не сможет продолжить без нового исследования.
-
-Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы.
-
-Ответь кратко:
-score: <0–100>
-+ Принять: <конкретная правка и куда встроить>
-~ Уточнить: <что переформулировать>
--- Убрать: <что неверно, лишнее или противоречит контексту>
-? Вопрос: <что нельзя безопасно решить без пользователя>
-```
-
-### 3. Strict: кросс-CLI ревью плана
-
-Обычный режим пропускает этот этап. В `strict` после ответов трёх агентов, но до итоговой оценки, отдай план соседнему CLI через `Bash`.
-
-Если ты в Claude Code — запускай Codex CLI:
-
-```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, выбери применимые карточки через docs/references.md. Глубоко проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и эталонам, обоснованность отклонений, полноту целевого алгоритма, БД/API/внешние контракты, связность и размер фаз для одного исполнителя на фазу, тесты, логирование, неподтверждённые решения и скрытые риски. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
-```
-
-Если ты в Codex — запускай Claude CLI:
-
-```bash
-claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, выбери применимые карточки через docs/references.md. Глубоко проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и эталонам, обоснованность отклонений, полноту целевого алгоритма, БД/API/внешние контракты, связность и размер фаз для одного исполнителя на фазу, тесты, логирование, неподтверждённые решения и скрытые риски. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
-```
-
-Если соседней CLI нет — `AskUserQuestion`: продолжить как `normal` без кросс-CLI или прервать полировку. Не заменяй кросс-CLI четвёртым локальным субагентом.
-
-Прочитай ответ соседнего CLI и дальше оцени его вместе с тремя агентами. Файл `${PLAN_FILE%.md}_strict_cli_review.md` можно создать и обновлять в `strict`; это единственный вспомогательный файл, кроме самого плана, который разрешён в strict-режиме.
-
-### 4. Оценить результаты
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`; иначе используй defaults и предупреди.
 
-Когда все три агента ответили, а в `strict` ещё и соседний CLI, прочитай их замечания и оценки. После этого основной агент выставляет итоговый `$SCORE` по шкале 0–100.
+- threshold берётся из `plan-review.threshold`, default `95`, допустим `1–100`;
+- limit берётся из `plan-polish.limit`, default `3`, это положительное целое число;
+- прямые `threshold N` и `limit N` важнее settings.
 
-Оцени:
-- план следует `docs/rules.md` и `docs/arch.md`;
-- план следует применимым карточкам или содержит подтверждённую причину отклонения;
-- нет неподтверждённых существенных решений;
-- `Целевой алгоритм` описывает сквозное поведение;
-- `Контракты реализации` конкретны, особенно БД/API/внешние контракты;
-- фазы имеют цель, шаги, результат, сценарии тестирования и проверку;
-- каждая фаза связна и выполнима одним агентом за один проход;
-- `test_strategy` и `logging_strategy` отражены в фазах и разделах;
-- нет альтернатив вида «выбрать», «решить», «уточнить позже»;
-- план можно передать в `eda-plan-execute` без нового исследования.
+`strict` и кросс-CLI не поддерживаются. Не читай устаревшие поля настроек и не запускай соседний CLI: используй только специализированный workflow этого скилла.
 
-Если `$SCORE >= threshold`, не вноси содержательные правки ради формы. Только добавь или обнови:
+## Правила
 
-```markdown
-## Оценка plan-polish
-- **Итоговая оценка:** <score>/100
-- **Порог:** <threshold>/100
-- **Итерации:** <N>
-- **Модели:** <фактически запущенные модели и соседний CLI в strict>
-- **Режим:** <normal | strict>
-- **Решение:** план готов к исполнению.
-```
+1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix` запускай отдельным изолированным субагентом с чистым контекстом.
+2. Если нативные субагенты или вложенная делегация недоступны, остановись; не выполняй review/fix основным агентом и не используй CLI-fallback.
+3. Успех определяется только review со статусом `ready`, без открытых находок и `score >= threshold`.
+4. Limit считает подтверждающие review-итерации. После review на последней итерации не запускай fix, который нельзя перепроверить.
+5. Основной агент не делает содержательных правок плана. После ready он может обновить только front matter: `status`, `plan_review`, `plan_review_fix`.
+6. Не запускай проверки проекта и не коммить.
 
-На этом остановись.
+## Вопросы
 
-### 5. Отредактировать план
+Если вложенный скил вернул `blocked` с вопросом, передай пользователю только этот вопрос и после ответа продолжи тот же шаг с полным предыдущим контекстом.
 
-Если `$SCORE < threshold`, сгруппируй замечания:
-- **Принять** — подтверждено планом, правилами, архитектурой, research или кодом и улучшает исполнимость без новой развилки.
-- **Отклонить** — противоречит контексту, дублирует уже закрытое, расширяет задачу или требует неподтверждённого решения.
-- **Спросить** — полезно, но требует выбора пользователя или меняет подтверждённое решение.
+- Claude Code: `AskUserQuestion`.
+- Codex interactive: `request_user_input`, если доступен, иначе короткий вопрос с вариантами.
+- Codex exec/non-interactive: остановись `blocked: нужен ответ пользователя`.
 
-Если есть вопросы класса **Спросить**, задай один сгруппированный `AskUserQuestion` и не редактируй план до ответа. Если предложение можно безопасно отклонить как расширение задачи, отклони его и продолжай.
+## Цикл
 
-Принятые замечания встраивай в основные разделы плана. Журнал в конце держи коротким:
+Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: iteration, review path, plan SHA-256, score, состояния находок, fix path и причина продолжения.
 
-```markdown
-## Изменения после plan-polish
+Для `$ITERATION` от `1` до `$LIMIT`:
 
-### Итерация <N>
-- **Оценка после проверки:** <score>/100
-- **Модели:** <фактически запущенные модели и соседний CLI в strict>
-- **+ Добавлено:** <3–7 главных изменений>
-- **~ Уточнено:** <1–5 важных уточнений>
-- **− Убрано:** <если удалено>
-- **Отклонено:** <существенные отклонённые предложения и причина>
-- **Вопросы пользователя:** <если были, кратко решение>
-```
+1. Запусти новый изолированный субагент:
 
-В `meta_reviewers`, если поле есть, добавь фактически запущенные модели и имя соседнего CLI в `strict`. Если `status: draft` и открытых вопросов не осталось, поменяй на `status: meta-reviewed`; `meta-reviewed` и `reviewed` не понижай.
+   ```text
+   Используй eda-plan-review для <PLAN_FILE> с threshold <THRESHOLD>.
+   Previous review: <PREVIOUS_REVIEW | none>.
+   Previous fix: <PREVIOUS_FIX | none>.
+   Overrides проверок и моделей: <из текущего вызова | none>.
+   Верни путь, status, plan_sha256, score, открытые ID и coverage.
+   ```
 
-### 6. Продолжить или остановиться
+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 ID и score, остановись `blocked: review не показывает прогресса`.
+6. Если status `changes-required`, но открытых находок нет, остановись `blocked: review нарушает контракт gate`; score ниже threshold нельзя исправлять без конкретных находок.
+7. Запусти новый изолированный субагент:
 
-После правок обнови:
+   ```text
+   Используй eda-plan-review-fix для <REVIEW_FILE>.
+   Примени все открытые находки минимальным изменением плана.
+   Верни путь к fix, before_sha256, after_sha256 и applied ID.
+   ```
 
-```markdown
-## Оценка plan-polish
-- **Итоговая оценка:** <score>/100
-- **Порог:** <threshold>/100
-- **Итерации:** <N>
-- **Модели:** <фактически запущенные модели и соседний CLI в strict>
-- **Режим:** <normal | strict>
-- **Решение:** <готов к исполнению | нужен следующий круг | blocked | достигнут лимит>
-```
+8. Проверь, что `before_sha256` равен `plan_sha256` review. Если `after_sha256` равен `before_sha256`, остановись `blocked: fix не изменил план`.
+9. Сохрани review/fix как previous chain и начни следующую review-итерацию.
 
-Если оценка ниже порога и лимит не достигнут, запускай новую итерацию с тремя агентами. Если оценка не выросла два круга подряд — остановись `blocked: score не растёт`. Если лимит достигнут — остановись и явно скажи, что порог не достигнут.
+Score не повышай и не пересчитывай сам: используй только полный `eda-plan-review`.
 
 ## Финал
 
-Сообщи кратко: режим (`normal` или `strict`), путь к плану, путь к strict-review-файлу при наличии, итоговую оценку и порог, число итераций, какие модели и CLI запускались, главные принятые изменения, существенные отклонения, причину остановки и следующий шаг `eda-plan-execute <PLAN_FILE>` при успехе. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-plan-polish strict <PLAN_FILE>`».
+Сообщи результат (`ready`, limit, no progress, invalid gate или blocked), план, последний review/fix, score/threshold, число review-итераций, open ID и coverage warnings. При ready предложи `eda-plan-execute`; при неуспехе перечисли конкретные оставшиеся находки.
 
 ## Чего НЕ делать
 
-- Создавать новый план вместо полировки существующего.
-- Править код, миграции, конфиги, lock-файлы или зависимости.
-- Запускать любые проверки проекта, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы.
-- Ставить предварительную оценку без трёх агентных проверок.
-- Запускать агентов последовательно или давать им разные промпты.
-- Запускать все три прохода на одной модели.
-- Пропускать кросс-CLI молча в `strict`.
-- Вставлять предложения агентов без анализа.
-- Добавлять существенные решения без подтверждения пользователя.
-- Превращать план в длинный отчёт о ревью.
-- Коммитить, пушить или запускать `eda-plan-execute`.
+- Делать review, выставлять score или исправлять содержание плана основным агентом.
+- Запускать старые три общих ревью одним промптом.
+- Запускать кросс-CLI, `strict`, `codex exec` или `claude -p`.
+- Запускать fix после последней review-итерации.
+- Ждать два одинаковых круга: один подтверждённый круг без прогресса уже останавливает цикл.
+- Писать длинный журнал полировки в план, менять код или запускать проверки проекта.

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

@@ -0,0 +1,189 @@
+---
+name: eda-plan-review
+description: 'Проводит специализированное read-only ревью готового плана и сохраняет находки с оценкой готовности.'
+---
+
+# Скил: Ревью плана (eda-plan-review)
+
+Работай как оркестратор установленных `eda-plan-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их prompts в task-сообщения. Выбери план и проверки, запусти агентов, проверь структурированные ответы, дедуплицируй подтверждённые находки, выставь экспертный score и сохрани один review-артефакт.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold, предыдущие review/fix, отключённые или принудительно включённые проверки и разовые модели.
+
+Если входа достаточно, продолжай без вопроса. `AskUserQuestion` используй только если план нельзя выбрать однозначно или переданная цепочка review/fix противоречива. Старую историю диалога не считай входом без явной связи с текущим вызовом.
+
+## Настройки
+
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`; при другой версии или невалидном поле используй defaults и добавь warning. Прямое указание пользователя важнее файла.
+
+Используй `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: нужен план или решение пользователя`.
+
+## Подготовить контекст
+
+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. Несвязанную историю не подмешивай.
+
+## Выбрать проверки
+
+- `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.
+
+Запиши skipped-проверки и причины. Forced-проверка запускается даже если auto-критерий не найден; агент может вернуть `not_applicable`.
+
+## Запустить агентов
+
+Запусти все выбранные проверки одним параллельным пакетом через установленных нативных агентов:
+
+- 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.
+
+В task-сообщение передавай только рабочую директорию, `PLAN_FILE`, `PLAN_SHA256`, `BUSINESS_FILES`, `REFERENCE_FILES`, `RESEARCH_FILE`, `PREVIOUS_REVIEW`, `PREVIOUS_FIX`, `MODEL` и `$PLAN_CONTEXT`. Полная семантика проверки хранится в prompt агента.
+
+## Проверить ответы
+
+Для каждого ответа проверь:
+
+- один YAML-блок и допустимый `status`;
+- `check` совпадает с ролью, `model` — с фактической моделью;
+- `находки` и `предыдущие_находки` — массивы;
+- у каждой находки есть fingerprint, severity, plan_location, problem, evidence, impact, fix, acceptance;
+- `blocked` содержит question; `not_applicable` не содержит находок.
+
+Невалидного или упавшего агента один раз повтори на той же модели с указанием только нарушения контракта. Повторный сбой любой выбранной проверки блокирует всё ревью; итоговый файл не сохраняй.
+
+## Агрегировать находки
+
+1. Подтверди evidence точечным чтением указанных файлов. Не добавляй самостоятельные domain-находки.
+2. Прими находку только когда план обязательно нужно изменить: есть точное место, доказательство, практическая ошибка или существенная неоднозначность, минимальная правка и проверяемая приёмка. Если замечание можно без последствий не применять, это не находка.
+3. Отклони недоказанное, вкусовое, уже закрытое, выходящее за scope или противоречащее подтверждённому решению. Также отклоняй «лучше подробнее», дополнительные пояснения, обоснования и стилистические улучшения, если без них план уже однозначно исполним.
+4. Недостаток конкретики подтверждён только когда исполнителю придётся заново исследовать область, принять незафиксированное существенное решение или можно получить две существенно разные реализации. Вода или повтор подтверждены, когда точный фрагмент не меняет действие, контракт, зависимость, проверку или решение; исправление для них должно быть удалением либо короткой заменой.
+5. Объедини находки с одной первопричиной и одной правкой, сохранив все checks и evidence.
+6. Для совпадающего fingerprint сохрани прежний ID. Новой находке дай следующий свободный `PR-NNN`; номер не переиспользуй.
+7. В итог включай только открытые находки и состояния прошлых ID. Предложения, которые не требуют обязательной правки плана, сохраняй только в `Отклонённые предложения` и не учитывай в score.
+
+## Выставить score и gate
+
+Score выставляет главный агент экспертно после обработки всех агентов. Не усредняй оценки, не используй формулу вычетов и не проси агентов ставить score.
+
+- `100`: открытых находок нет, план конкретен и исполним.
+- `95–99`: остаются только локальные, но обязательные находки low.
+- `80–94`: есть находка medium или несколько находок low.
+- `60–79`: есть находка high.
+- ниже `60`: есть critical или требуется серьёзное перепланирование.
+- при отсутствии открытых находок score равен `100`.
+- если состояния open/resolved/regressed не изменились относительно предыдущего review, score не меняй.
+- каждое изменение score объясни закрытыми, новыми или регрессировавшими ID.
+
+Статус `ready` ставь только когда нет открытых находок и `$SCORE >= $THRESHOLD`. Любая открытая находка даёт `changes-required`, независимо от score. Score ниже threshold без открытых находок недопустим: не снижай оценку за необязательные пожелания и не выдумывай находку только ради числа.
+
+## Сохранить review
+
+После успешной обработки всех выбранных агентов создай `docs/plan-reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+
+```markdown
+---
+plan: <docs/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>
+```
+
+Review содержит только проблемы и техническое покрытие, без похвалы и длинного пересказа плана.
+
+## Финал
+
+Сообщи путь, status, score/threshold, открытые ID, completed/skipped и previous chain. При `changes-required` предложи `eda-plan-review-fix`; при `ready` — `eda-plan-execute` или возврат вызывающему `eda-plan-polish`.
+
+## Чего НЕ делать
+
+- Править план, код, настройки или документацию проекта.
+- Запускать тесты, lint, build, typecheck, серверы, миграции, браузерные проверки или API-запросы.
+- Выполнять специализированную роль главным агентом.
+- Запускать другой CLI или generic-fallback.
+- Усреднять score агентов, менять score без изменения находок или снижать его за необязательные пожелания.
+- Принимать косметическое расширение текста, дополнительное объяснение или вкусовую формулировку как находку.
+- Сохранять итог после повторного сбоя выбранного агента.

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

@@ -0,0 +1,88 @@
+---
+name: eda-plan-review-fix
+description: 'Исправляет готовый план по всем находкам сохранённого plan-review.'
+---
+
+# Скил: Исправитель плана по ревью (eda-plan-review-fix)
+
+Применяй подтверждённые находки из `docs/plan-reviews/` только к связанному плану. Не делай новое ревью: твой контракт — точечно изменить основные разделы плана и сохранить проверяемую цепочку SHA-256.
+
+## Вход из сообщения пользователя
+
+Разбери путь или название review, «последнее ревью», ограничения и явные решения пользователя. Если вход однозначен, продолжай без вопроса. При нескольких равных review или противоречивом target используй `AskUserQuestion`.
+
+## Вопросы
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с вариантами и остановись.
+- Codex exec/non-interactive: не читай 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 не изменил план` и не выдавай успех.
+
+После успешного изменения:
+
+- если 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`:
+
+```markdown
+---
+review: <docs/plan-reviews/...>
+plan: <docs/plans/...>
+before_sha256: <sha256 из review>
+after_sha256: <sha256 после изменения>
+status: done
+date: <YYYY-MM-DD HH:MM>
+---
+
+# Исправления плана по ревью: <название>
+
+## Применённые находки
+| ID | Что изменено | Раздел плана | Статус |
+|---|---|---|---|
+| PR-001 | <конкретная правка> | <раздел> | applied |
+
+## Цепочка
+- **Before SHA-256:** `<hash>`
+- **After SHA-256:** `<hash>`
+- **Нужен подтверждающий review:** да
+```
+
+После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком applied ID. Не дублируй раздел при повторном продолжении того же запуска.
+
+## Финал
+
+Сообщи пути к plan/review/fix, before/after SHA-256, applied ID, оставшиеся блокеры и что изменения не закоммичены. Следующий шаг — `eda-plan-review` для подтверждения или возврат вызывающему `eda-plan-polish`.
+
+## Чего НЕ делать
+
+- Делать новое ревью или выставлять score.
+- Исправлять код или файлы вне выбранного плана, review и fix-отчёта.
+- Применять stale review к другому SHA-256.
+- Молча пропускать находку или самостоятельно разрешать продуктовый конфликт.
+- Раздувать план пояснениями и повторами вместо минимального удаления или замены.
+- Добавлять журнал итераций в тело плана.
+- Коммитить, запускать тесты, lint, build, typecheck, миграции или другой CLI.