@gian-tiaga/eda 1.0.5 → 2.0.0

package/skills/eda-plan/SKILL.md

@@ -5,17 +5,18 @@ description: 'Создаёт подробный исполнимый план р
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом. По настройкам запускаешь один специализированный `eda-plan-review`, при необходимости один `eda-plan-review-fix`, а в strict — независимую кросс-CLI проверку.
 
 ## Режим запуска
 
 Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
 
-Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `plan.strict: false`, `plan.size: normal`, `plan.decision_mode: recommend_and_ask`, `plan.test_strategy: ask_each_time`, `plan.logging_strategy: ask_each_time`.
+Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `plan.strict: false`, `plan.review: true`, `plan.size: normal`, `plan.decision_mode: recommend_and_ask`, `plan.test_strategy: ask_each_time`, `plan.logging_strategy: ask_each_time`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
 | `plan.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
+| `plan.review` | `true`, `false` | включение: `с ревью плана`, `с plan-review`; выключение: `без ревью плана`, `без plan-review` |
 | `plan.size` | `normal`, `short`, `ask_each_time` | `short`; обычный: `обычный план`, `не short` |
 | `plan.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
 | `plan.test_strategy` | `after_each_phase`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов |
@@ -27,6 +28,8 @@ description: 'Создаёт подробный исполнимый план р
 
 `test_strategy` обязан менять план: `tdd_each_phase` начинает каждую фазу с тестов, `after_each_phase` добавляет тесты после реализации каждой фазы, `end_of_plan` выносит тесты в отдельную финальную фазу. `logging_strategy` обязан отражаться в алгоритме, фазах и разделе `Логирование`.
 
+`без проверок` одновременно устанавливает `plan.review: false` и `plan.strict: false`. `plan.review` и `plan.strict` независимы: можно оставить только один вид проверки. Более конкретное прямое указание в том же сообщении имеет приоритет.
+
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Разбери тему, задачу, путь к файлу, режим, ограничения и прямые указания.
@@ -54,14 +57,15 @@ description: 'Создаёт подробный исполнимый план р
 
 1. Никаких правок кода, миграций, конфигов и зависимостей. Запись только в `docs/plans/`.
 2. `docs/rules.md` и `docs/arch.md` — обязательная рамка планирования, а не справочный контекст. Прочитай их, выдели применимые правила и архитектурные ограничения, передай их в Plan Mode как обязательные требования.
-3. Если существует `docs/references.md`, прочитай индекс, выбери только карточки для затронутых компонентов и прочитай их целиком. Их кодовые примеры задают ожидаемую форму реализации; нерелевантные карточки не загружай.
-4. Приоритет: подтверждённое решение пользователя → `docs/rules.md` → `docs/arch.md` → релевантные карточки. Если запрос, research, черновик или шаг плана конфликтует с этой рамкой, не финализируй план. Спроси, адаптировать подход, отдельно изменить рамку или прервать планирование. Отклонение от карточки допустимо только с подтверждённой причиной, записанной в плане.
-5. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
-6. План сохраняется до мета-ревью, иначе ревьюерам нечего читать.
-7. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
-8. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
-9. Если выбран `plan.size: short`, но задача не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
-10. Каждой задаче в фазах присвой уникальный ID и укажи её прямые зависимости. Собери каждую фазу вокруг одной связной цели и объёма, который один исполнитель может реализовать и проверить за один проход; слишком крупную или несвязную фазу раздели.
+3. Сначала определи задачу и затронутое поведение. Если существует `docs/business.md`, по описаниям выбери только применимые карточки и прочитай их целиком; нерелевантные карточки не загружай. Business-карточки ограничивают только затронутое поведение и не расширяют задачу.
+4. Если существует `docs/references.md`, прочитай индекс, выбери только карточки для затронутых компонентов и прочитай их целиком. Их кодовые примеры задают ожидаемую форму реализации; нерелевантные карточки не загружай.
+5. Если запрос, research или черновик плана противоречит применимой business-карточке, не выбирай источник молча и не финализируй план. Покажи конфликт и через `AskUserQuestion` спроси: изменить задачу или сначала пересогласовать business-правило через `eda-business`. Конфликты с rules, architecture или references разрешай отдельным явным решением пользователя.
+6. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
+7. План сохраняется до любой включённой проверки, иначе ревьюерам нечего читать.
+8. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
+9. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
+10. Если выбран `plan.size: short`, но задача не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
+11. Каждой задаче в фазах присвой уникальный ID и укажи её прямые зависимости. Собери каждую фазу вокруг одной связной цели и объёма, который один исполнитель может реализовать и проверить за один проход; слишком крупную или несвязную фазу раздели.
 
 ## Этапы
 
@@ -69,6 +73,7 @@ description: 'Создаёт подробный исполнимый план р
 
 - Разбери текущий вход и настройки.
 - Прочитай `docs/rules.md`, `docs/arch.md`, если они есть; выпиши применимые команды проверки, требования к тестам, границы модулей, зависимости, API, миграции, безопасность, документацию и локальные запреты.
+- Если есть `docs/business.md`, сначала установи границы задачи, затем по описаниям выбери только карточки затронутого поведения и выпиши применимые требования, сценарии и критерии приёмки. Если подходящих карточек нет, продолжай без business-контекста.
 - Если есть `docs/references.md`, выбери по индексу применимые карточки, прочитай их и выпиши обязательные элементы кодовых примеров.
 - Research подтягивай без вопроса, если путь указан; если в сообщении есть описание задачи без research-файла — используй описание как контекст и не спрашивай research автоматически. Если пользователь явно просит research, но файл не указал, предложи последние файлы из `docs/researches/` и вариант «нет».
 - Проверь версии нужных пакетов/ПО, если они не зафиксированы в запросе, правилах, архитектуре, research или lock/config-файлах.
@@ -103,12 +108,14 @@ plan_size: <normal | short>
 decision_mode: <autonomous | recommend_and_ask | ask_each_time>
 status: <draft | meta-reviewed | reviewed>
 reviewer: <pending | none | claude | codex>
-meta_reviewers: []
+plan_review: <docs/plan-reviews/... | none>
+plan_review_fix: <docs/plan-review-fixes/... | none>
 test_strategy: <after_each_phase | tdd_each_phase | end_of_plan>
 logging_strategy: <debug_precise | standard>
 sources:
   rules: <путь или —>
   arch: <путь или —>
+  business: [<пути к применимым карточкам или пусто>]
   references: [<пути к применимым карточкам или пусто>]
   research: <путь или —>
 ---
@@ -168,13 +175,14 @@ sources:
 - Одну фазу целиком выполняет один изолированный субагент `eda-plan-execute`. Задачи фазы должны относиться к общей цели, иметь согласованный scope и помещаться в один исполнительский проход вместе с точечными и фазовыми проверками.
 - В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты; если область не затрагивается, напиши `Не затрагивается`.
 - В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
-- Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай мета-ревью до ответа пользователя.
+- Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай plan-review до ответа пользователя.
 
-Quality gate перед сохранением и после мета-ревью:
+Quality gate перед сохранением и после каждой включённой проверки:
 
 - есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`;
+- применимые business-карточки выбраны только после определения scope задачи, записаны в `sources.business` и отражены в поведении и критериях приёмки;
 - план строго следует `docs/rules.md` и `docs/arch.md`;
-- план следует применимым карточкам или явно фиксирует подтверждённую причину отклонения;
+- план следует применимым reference-карточкам или явно фиксирует подтверждённую причину отклонения;
 - нет конфликтов с правилами, архитектурой, границами модулей, API, миграциями, зависимостями и командами проверки;
 - БД/API изменения описаны конкретно, а не общими словами;
 - каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
@@ -185,49 +193,49 @@ Quality gate перед сохранением и после мета-ревью
 - нет неподтверждённых существенных решений и неразрешённых альтернатив;
 - план можно передать в `eda-plan-execute` без нового исследования.
 
-### 4. Мета-ревью тремя субагентами/моделями
+### 4. Специализированный plan-review и один fix
 
-Запусти три проверки параллельно, в одном batch, до чтения любого результата. Главный планировщик сам решает, что применять; предложения не вставляются механически.
+Если `plan.review: false`, пропусти этап, оставь `plan_review: none`, `plan_review_fix: none` и перейди к strict-этапу или финалу. Не запускай старое общее мета-ревью.
 
-| Среда | Быстрая | Кодовая | Флагман |
-|---|---|---|---|
-| Claude Code (`Agent` tool) | `haiku` | `sonnet` | `opus` |
-| Codex interactive (`spawn_agent`) | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
-| Codex exec / non-interactive fallback | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
+Если `plan.review: true`, каждый вложенный скил запускай в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает их работу. При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
 
-В интерактивном Codex, если доступен инструмент субагентов (`spawn_agent` или аналог), используй его. Не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. В неинтерактивном fallback запускай три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
+1. Запусти один `eda-plan-review`:
 
-Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, карточки из `sources.references`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры/эталонов, необоснованные отклонения, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности, неверные зависимости и слишком крупные или несвязные фазы для одного исполнителя. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
+   ```text
+   Используй eda-plan-review для <PLAN_FILE>.
+   Исходная задача и решения: <текущий запрос и ответы пользователя>.
+   Верни путь к review, status, score, threshold и required/optional ID.
+   ```
 
-После ответов интегрируй принятые замечания в основные разделы плана, снова прогони quality gate и добавь:
+2. Если review имеет `status: ready`, обнови front matter: `status: reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: none`. Содержательных правок не делай.
+3. Если review имеет `status: changes-required`, запусти ровно один новый изолированный субагент:
 
-```markdown
-## Изменения после мета-ревью
+   ```text
+   Используй eda-plan-review-fix apply-optional для <REVIEW_FILE>.
+   Примени все required, самостоятельно разбери optional и сохрани waived с причинами.
+   Верни путь к fix, before_sha256, after_sha256, applied и waived ID.
+   ```
 
-### После моделей
-- **+ Добавлено:** <3–7 главных изменений>
-- **~ Изменено:** <1–5 уточнений>
-- **− Убрано:** <если удалено>
-- **Отклонено:** <существенные отклонённые предложения и причина>
-```
+4. Проверь связь SHA-256. После успешного fix установи `status: meta-reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: <FIX_FILE>` и снова прогони локальный quality gate структуры плана. Не запускай второй review внутри `eda-plan`.
+5. При `blocked` передай один конкретный вопрос пользователю и продолжи тот же вложенный шаг после ответа.
 
-В YAML поменяй `status: draft` на `meta-reviewed`, в `meta_reviewers` запиши модели.
+`meta-reviewed` означает один review и один неперепроверенный fix и остаётся допустимым входом для `eda-plan-execute`. Подтверждённый gate после fix выполняет отдельный `eda-plan-polish`.
 
 ### 5. Strict: кросс-CLI и допил
 
-Обычный режим пропускает этот этап. В `strict` отдай файл соседнему CLI:
+`plan.strict` не зависит от `plan.review`. Обычный режим пропускает этот этап. В `strict` отдай файл соседнему CLI:
 
 ```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references и связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, неучтённые зависимости, нарушения правил, архитектуры и эталонов, необоснованные отклонения, скрытые риски, недостающие тесты и шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, применимые карточки из sources.business и sources.references и связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, нарушения бизнес-требований, неучтённые зависимости, нарушения правил, архитектуры и эталонов, необоснованные отклонения, скрытые риски, недостающие тесты и шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
 ```
 
 Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать.
 
-Бесспорные замечания внеси в план, спорные вынеси через `AskUserQuestion`, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поменяй `status: meta-reviewed` на `reviewed`, покажи дифф.
+Бесспорные замечания внеси в план, спорные вынеси через `AskUserQuestion`, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поменяй `status: draft` или `status: meta-reviewed` на `reviewed`, покажи дифф.
 
 ### 6. Финал
 
-Коротко сообщи режим, путь к плану, путь к review-файлу в `strict`, 3–5 главных шагов простыми словами и что дальше делает `eda-plan-execute`.
+Коротко сообщи режим, выполнялись ли plan-review/fix и strict, путь к плану, пути к plan-review/plan-review-fix и strict-review при наличии, итоговый status, 3–5 главных шагов и что дальше делает `eda-plan-execute`. Для `meta-reviewed` явно укажи, что подтверждающий gate выполняет `eda-plan-polish`.
 
 ## Чего НЕ делать
 
@@ -241,5 +249,5 @@ codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карто
 - Сохранять сырой текст Plan Mode без нормализации.
 - Оставлять финальный план исследованием, списком наблюдений или журналом мета-ревью.
 - Смешивать альтернативы с принятыми решениями.
-- Пропускать мета-ревью тремя моделями или запускать ревьюеров частями.
+- Выполнять plan-review или plan-review-fix основным агентом, запускать старые три общих ревьюера или делать второй review внутри `eda-plan`.
 - Пропускать кросс-CLI молча в `strict`: если CLI нет, спроси.

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

@@ -18,8 +18,8 @@ description: 'Выполняет готовый план из `docs/plans/` по
 1. **Основной агент только управляет.** Разрешены чтение контекста, построение очереди, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию проекта и git-состояние меняют только назначенные субагенты.
 2. **Фазы выполняй строго последовательно.** Не запускай следующую фазу, пока исполнитель текущей не завершил все её задачи и отдельная проверка фазы не прошла.
 3. **Одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Сохраняй идентификатор исполнителя и продолжай его же для вопросов и исправлений этой фазы, пока среда позволяет.
-4. **Рамку читает исполнитель фазы.** Каждый исполнитель целиком читает план, `docs/rules.md`, `docs/arch.md` и индекс `docs/references.md`, если файлы существуют. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением.
-5. **Соблюдай приоритет и блокируй конфликт.** Приоритет: подтверждённое решение пользователя → `docs/rules.md` → `docs/arch.md` → релевантные карточки. При конфликте или необоснованном отклонении от примера применимой карточки исполнитель возвращает `blocked`, а основной агент спрашивает, адаптировать план, вернуться к `eda-plan` или отдельно изменить документацию.
+4. **Рамку читает исполнитель фазы.** Каждый исполнитель целиком читает план, `docs/rules.md` и `docs/arch.md`. Для поведения своей фазы он читает карточки из `sources.business`; у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки. Для затронутых компонентов так же выбирает технические карточки через `sources.references` или `docs/references.md`. Нерелевантные карточки не загружает.
+5. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, исполнитель возвращает `blocked`, а основной агент показывает конфликт и через `AskUserQuestion` спрашивает: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`. Конфликты с rules, architecture или references также не разрешай молча.
 6. **Отмечай только подтверждённое.** Ставь задаче `[x]` только после `completed` от исполнителя и успешной точечной проверки. Фазу закрывай только после отдельного `passed` от проверяющего фазы. При последующем опровержении верни отметку в незавершённое состояние.
 7. **Проверки нельзя подавлять.** Не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, добавлять игноры или ослаблять команды и правила. Причину падения исправляет исполнитель соответствующей фазы, затем отдельный субагент повторяет проверку.
 8. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
@@ -103,10 +103,10 @@ current_phase: <номер>
 
 - рабочую директорию, `$PLAN_FILE`, номер и полный текст текущей фазы;
 - краткие результаты уже завершённых фаз;
-- пути к `docs/rules.md`, `docs/arch.md` и `docs/references.md`;
+- пути к `docs/rules.md`, `docs/arch.md`, `docs/business.md` и `docs/references.md`;
 - ограничения пользователя, команды и критерии проверки фазы, запрет коммитить и запрет менять план и журнал.
 
-Исполнитель целиком читает `$PLAN_FILE`, `docs/rules.md` и `docs/arch.md`, затем выполняет все задачи назначенной фазы по прямым зависимостям. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением. После каждой задачи он выполняет её точечные проверки, а в конце — все проверки фазы. Требуй YAML-результат:
+Исполнитель целиком читает `$PLAN_FILE`, `docs/rules.md` и `docs/arch.md`, затем выполняет все задачи назначенной фазы по прямым зависимостям. Перед изменением поведения он читает применимые карточки из `sources.business`; если поле отсутствует, выбирает их по описаниям из `docs/business.md`. Если подходящих карточек нет, продолжает без business-контекста. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением. После каждой задачи он выполняет её точечные проверки, а в конце — все проверки фазы. Требуй YAML-результат:
 
 ```yaml
 status: completed | needs_input | failed | blocked
@@ -118,6 +118,7 @@ tasks:
     summary: <кратко>
     checks: [<результаты точечных проверок>]
 files_changed: [<пути>]
+business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
 checks:
   - command: <команда или критерий>
@@ -143,7 +144,7 @@ questions: [<вопросы или пусто>]
 
 ### 7. Проверять каждую фазу
 
-После `completed` от исполнителя запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md`, `docs/arch.md` и индекс `docs/references.md`, если они существуют. Если итог фазы затрагивает компонент, для которого в индексе указана карточка, проверяющий читает её целиком. Затем он выполняет все проверки из раздела фазы и подтверждает критерии результата. Требуй YAML:
+После `completed` от исполнителя запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`. Он читает только business-карточки, применимые к поведению этой фазы, и только reference-карточки затронутых компонентов; для старого плана использует соответствующие индексы как fallback. Отсутствие применимой business-карточки не блокирует проверку. Затем он выполняет все проверки из раздела фазы и подтверждает критерии результата. Требуй YAML:
 
 ```yaml
 status: passed | failed | blocked
@@ -153,6 +154,7 @@ checks:
     status: passed | failed
     result: <кратко>
 failures: [<проблемы с доказательствами или пусто>]
+business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
 ```
 
@@ -160,7 +162,7 @@ references_read: [<пути или пусто>]
 
 ### 8. Выполнить финальную проверку
 
-После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет и не меняет файлы, целиком читает план, `docs/rules.md`, `docs/arch.md` и индекс `docs/references.md`, если они существуют. Если итоговые изменения затрагивают компонент, для которого в индексе указана карточка, проверяющий читает её целиком перед оценкой соответствующего результата.
+После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет и не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, затем выбирает только business-карточки итогового изменённого поведения и reference-карточки затронутых компонентов. Отсутствие подходящей business-карточки не требует предупреждения и не блокирует проверку.
 
 Если финальная проверка упала из-за сделанных изменений, сопоставь ошибки с фазами и передай каждую группу исполнителю соответствующей фазы; несколько затронутых фаз исправляй по порядку плана. Если продолжить прежнего исполнителя невозможно, запусти одного нового изолированного исполнителя для каждой затронутой фазы. Затем повтори всю финальную проверку новым субагентом. Чужую или несвязанную поломку зафиксируй и используй `AskUserQuestion`, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 

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 apply-optional` → повторный `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 apply-optional` запускай отдельным изолированным субагентом с чистым контекстом.
+2. Если нативные субагенты или вложенная делегация недоступны, остановись; не выполняй review/fix основным агентом и не используй CLI-fallback.
+3. Успех определяется только review со статусом `ready`, без required findings и `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, состояния findings, 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, required/optional ID и coverage.
+   ```
 
-### 6. Продолжить или остановиться
+2. Прочитай review-артефакт и проверь, что status/score/threshold/findings согласованы.
+3. Если status `ready`, обнови front matter плана: `status: reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: <последний FIX_FILE | none>`. Заверши успешно.
+4. Если это последняя разрешённая review-итерация, остановись `достигнут limit`; fix не запускай.
+5. Если относительно предыдущего review не изменились open/resolved/regressed/waived ID и score, остановись `blocked: review не показывает прогресса`.
+6. Если ниже gate нет применимых findings, остановись `blocked: нет применимых правок для повышения оценки`.
+7. Запусти новый изолированный субагент:
 
-После правок обнови:
+   ```text
+   Используй eda-plan-review-fix apply-optional для <REVIEW_FILE>.
+   Примени все required, самостоятельно разбери optional и сохрани waived с причинами.
+   Верни путь к fix, before_sha256, after_sha256, applied и waived 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, no applicable fixes или blocked), план, последний review/fix, score/threshold, число review-итераций, open ID и coverage warnings. При ready предложи `eda-plan-execute`; при неуспехе перечисли конкретные оставшиеся findings.
 
 ## Чего НЕ делать
 
-- Создавать новый план вместо полировки существующего.
-- Править код, миграции, конфиги, lock-файлы или зависимости.
-- Запускать любые проверки проекта, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы.
-- Ставить предварительную оценку без трёх агентных проверок.
-- Запускать агентов последовательно или давать им разные промпты.
-- Запускать все три прохода на одной модели.
-- Пропускать кросс-CLI молча в `strict`.
-- Вставлять предложения агентов без анализа.
-- Добавлять существенные решения без подтверждения пользователя.
-- Превращать план в длинный отчёт о ревью.
-- Коммитить, пушить или запускать `eda-plan-execute`.
+- Делать review, выставлять score или исправлять содержание плана основным агентом.
+- Запускать старые три общих ревью одним промптом.
+- Запускать кросс-CLI, `strict`, `codex exec` или `claude -p`.
+- Запускать fix после последней review-итерации.
+- Ждать два одинаковых круга: один подтверждённый круг без прогресса уже останавливает цикл.
+- Писать длинный журнал полировки в план, менять код или запускать проверки проекта.