@gian-tiaga/eda 1.0.5 → 2.1.0

package/skills/eda-orhestra/SKILL.md

@@ -5,13 +5,13 @@ description: 'Выполняет настраиваемую цепочку `eda-
 
 # Скил: Оркестра полного цикла (eda-orhestra)
 
-Выполняй настроенные `eda-*`-скилы по порядку. По умолчанию цепочка остаётся полной: `eda-plan` → `eda-plan-execute` → `eda-polish` → `eda-manual-test`; failed-отчёт ручной проверки передаётся в `eda-fix`, после чего повторяются включённые polish и manual-test.
+Выполняй настроенные `eda-*`-скилы по порядку. По умолчанию цепочка: `eda-plan` без проверок → `eda-plan-polish` → `eda-plan-execute` → `eda-polish` → `eda-manual-test`. Failed-отчёт ручной проверки передавай в `eda-fix`, затем возвращайся к `eda-manual-test` до `passed` или лимита QA-циклов.
 
 ## Настройки
 
 Прочитай только раздел `orhestra` из `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее любого поля настроек.
 
-Поддерживается только `version: 2`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолт режима: `orhestra.mode: automatic`.
+Поддерживается только `version: 3`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолт режима: `orhestra.mode: automatic`.
 
 ```yaml
 orhestra:
@@ -20,6 +20,10 @@ orhestra:
     - id: plan
       skill: eda-plan
       enabled: true
+      args: "без проверок"
+    - id: plan-polish
+      skill: eda-plan-polish
+      enabled: true
       args: ""
     - id: execute
       skill: eda-plan-execute
@@ -37,7 +41,6 @@ orhestra:
         skill: eda-fix
         args: ""
         then:
-          - polish
           - manual-test
         max_cycles: 5
 ```
@@ -48,13 +51,13 @@ orhestra:
 - `steps`: упорядоченный непустой список. Выполняй сверху вниз только элементы с `enabled: true`; отсутствующий `enabled` считай `true`.
 - `id`: уникальное непустое имя шага для ссылок из `on_failure.then`.
 - `skill`: имя установленного `eda-*`-скила. Не разрешай `eda-orhestra`, `eda-aim`, `eda-commit`, `eda-send-review`, `eda-worktree` и `eda-merge-worktree`.
-- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для `eda-polish` здесь же задавай штатные `threshold N` и `limit N`; дефолт — `limit 5`.
+- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для дефолтного `eda-plan` передавай `без проверок`, чтобы оба вида ревью выполнил следующий `eda-plan-polish`. Для `eda-polish` здесь же задавай штатные `threshold N` и `limit N`; дефолт — `limit 5`.
 - `on_failure`: опциональный обработчик `failed` у шага `eda-manual-test`. Если поля нет, сохрани failed-отчёт и остановись без исправлений.
 - `on_failure.skill` и `on_failure.args`: разрешённый установленный скил исправления и его аргументы; дефолты `eda-fix` и пустая строка. Для `skill` действуют те же запреты, что для `steps[].skill`.
 - `on_failure.then`: id шагов, которые после исправления нужно повторить в указанном порядке. Пропускай отключённые шаги. Список должен содержать id активного `eda-manual-test`, иначе исправление нельзя подтвердить.
 - `on_failure.max_cycles`: положительное целое число, дефолт `5`.
 
-Старый v2 только с `orhestra.mode` означает полную дефолтную цепочку. Настройки проекта не переписывай во время запуска.
+Если в v3 есть только `orhestra.mode`, используй полную дефолтную цепочку. Настройки проекта не переписывай во время запуска.
 
 Для совместимости старое значение `steps[].skill: eda-execute` нормализуй в памяти в `eda-plan-execute`. Файл настроек не переписывай; остальные неизвестные или удалённые скилы не заменяй автоматически.
 
@@ -62,7 +65,7 @@ orhestra:
 
 Сохрани весь текст рядом с вызовом в `$USER_REQUEST`. Извлеки задачу, пути к готовым артефактам, режим и разовые изменения цепочки.
 
-Поддерживай естественные overrides: `без полировки`, `полировка 2 итерации`, `без ручных тестов`, `только plan и execute`, `после plan запусти plan-polish strict`, `для manual-test <args>`. Явное перечисление порядка заменяет порядок из настроек; локальное включение, отключение или параметры меняют только названный шаг. Фразу `полировка N итераций` нормализуй в `limit N` внутри `args` шага. Не принимай слово из описания самой задачи за override без явной связи с цепочкой.
+Поддерживай естественные overrides: `без полировки плана`, `без полировки кода`, `полировка кода 2 итерации`, `без ручных тестов`, `только plan и execute`, `plan-polish threshold 95 limit 3`, `для manual-test <args>`. Явное перечисление порядка заменяет порядок из настроек; локальное включение, отключение или параметры меняют только названный шаг. Фразу `полировка кода N итераций` нормализуй в `limit N` внутри `args` шага `eda-polish`; аналогичную фразу о плане — в `args` шага `eda-plan-polish`. Не принимай слово из описания самой задачи за override без явной связи с цепочкой.
 
 Если передан готовый план, а включённый `eda-plan` должен создать тот же план, пропусти этот шаг как уже выполненный и запиши причину. Остальные шаги не додумывай и не подменяй: если им не хватает входного артефакта, обработай их вопрос по выбранному режиму.
 
@@ -83,7 +86,7 @@ orhestra:
 - Для вопроса `eda-plan-execute` о месте выполнения выбирай текущую ветку, если пользователь явно не запросил ветку или worktree.
 - Не спрашивай о переходе между успешными шагами.
 
-Автоматический режим не разрешает необратимые внешние действия, расширение scope, публикацию, расходы, удаление данных, ослабление проверок или изменение production/staging. Подтверждение из-за такого риска передай человеку; в неинтерактивной среде остановись с `blocked: нужен ответ пользователя`. Обратимые решения плана, включая БД/API-контракты и подтверждение готового плана, выбирай сам.
+Автоматический режим не разрешает необратимые внешние действия, расширение scope, публикацию, расходы, удаление данных, ослабление проверок вне настроенной цепочки или изменение production/staging. Дефолтное `без проверок` у `eda-plan` не считай ослаблением: следующий обязательный `eda-plan-polish` выполняет проверку и доводку плана. Подтверждение из-за риска передай человеку; в неинтерактивной среде остановись с `blocked: нужен ответ пользователя`. Обратимые решения плана, включая БД/API-контракты и подтверждение готового плана, выбирай сам.
 
 ### Manual
 
@@ -116,25 +119,25 @@ orhestra:
 1. Запусти скилл с подготовленным вводом.
 2. Обработай его вопрос по режиму.
 3. Прочитай сохранённый артефакт и явный статус. `blocked`, неполный обязательный результат или непройденная обязательная проверка останавливают цепочку.
-4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings` и `score >= threshold`; отдельного polish-файла нет.
+4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean`, без находок и с `score >= threshold`; отдельного polish-файла нет.
 5. Для успешного шага сохрани все пути и передай их следующему.
 
 Если `eda-manual-test` вернул `failed`:
 
 1. Если у этого шага нет `on_failure`, остановись с результатом `manual-test: failed`.
 2. Запусти `on_failure.skill` с manual-test-отчётом, `$USER_REQUEST`, предыдущими артефактами и `on_failure.args`.
-3. После успешного fix увеличь счётчик и выполни активные шаги из `on_failure.then` в заданном там порядке. Их собственные `args` сохраняются.
+3. После успешного fix увеличь счётчик и выполни активные шаги из `on_failure.then` в заданном там порядке. Их собственные `args` сохраняются. В дефолтной цепочке здесь только `manual-test`: после QA-фикса вернись к ручной проверке, не запускай полировку кода повторно.
 4. Если повторный manual-test снова `failed`, начни следующий QA-цикл.
 5. Остановись с `blocked: QA не сходится`, если достигнут `on_failure.max_cycles`, два fix-цикла подряд не меняют результат того же сценария, нужен выход за scope или окружение не позволяет проверить.
 6. После `passed` продолжи линейную цепочку со шага, следующего за исходным manual-test.
 
-Если manual-test отключён или отсутствует, failure-цикл не запускай и не изображай ручную проверку. Если polish отключён, не требуй review score и не запускай его после fix через `on_failure.then`.
+Если manual-test отключён или отсутствует, failure-цикл не запускай и не изображай ручную проверку. Если шаг `eda-polish` отключён, не требуй review score. Если `eda-plan-polish` отключён, не требуй оценку плана. Не запускай ни одну из полировок после fix, если её id нет в `on_failure.then`.
 
 ## Финал
 
 Сообщи режим, фактически выполненную цепочку с args и лимитами, пропущенные шаги и причины, пути ко всем артефактам, последний review score при наличии, результат manual-test при наличии, число QA-циклов и состояние git «не закоммичено».
 
-Успех означает, что все включённые шаги завершились по собственным контрактам. Если manual-test был включён, после последних изменений обязателен `passed`; если он отключён, явно напиши «ручные тесты пропущены настройкой». Если polish отключён, явно напиши «полировка пропущена настройкой».
+Успех означает, что все включённые шаги завершились по собственным контрактам. Если manual-test был включён, после последних изменений обязателен `passed`; если он отключён, явно напиши «ручные тесты пропущены настройкой». Если отключён `eda-plan-polish`, явно напиши «полировка плана пропущена настройкой». Если отключён `eda-polish`, явно напиши «полировка кода пропущена настройкой».
 
 ## Чего НЕ делать
 

package/skills/eda-plan/SKILL.md

@@ -1,21 +1,22 @@
 ---
 name: eda-plan
-description: 'Создаёт подробный исполнимый план реализации задачи и сохраняет его в `docs/plans/`.'
+description: 'Создаёт конкретный исполнимый план реализации задачи и сохраняет его в `docs/plans/`.'
 ---
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом. По настройкам запускаешь специализированный цикл `eda-plan-polish`, а в 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,16 @@ 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 и укажи её прямые зависимости. Собери каждую фазу вокруг одной связной цели и объёма, который один исполнитель может реализовать и проверить за один проход; слишком крупную или несвязную фазу раздели.
+12. Пиши конкретно и без воды. Каждая формулировка должна определять действие, место изменения, поведение или контракт, зависимость, проверку либо существенное принятое решение. Если её удаление ничего из этого не меняет, удали её из плана.
 
 ## Этапы
 
@@ -69,6 +74,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-файлах.
@@ -87,6 +93,7 @@ description: 'Создаёт подробный исполнимый план р
 6. Требование: план следует правилам, архитектуре и применимым эталонам с указанным приоритетом; при конфликте или необоснованном отклонении остановиться и спросить пользователя.
 7. Требование: финальный план нормализуется в структуру ниже, не смешивает исследование с исполнением и не добавляет неподтверждённые существенные решения.
 8. Требование: каждая задача получает уникальный ID и прямые зависимости, а каждая фаза образует связный объём работы для одного исполнителя.
+9. Требование: конкретика не равна максимальной подробности. Не пересказывать запрос и существующий код, не повторять один контракт в нескольких разделах, не добавлять очевидные пояснения и не выдумывать пути, символы или API ради видимости конкретики.
 
 Не выходи из Plan Mode, пока пользователь не подтвердил план.
 
@@ -103,12 +110,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 +177,16 @@ 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 изменения описаны конкретно, а не общими словами;
 - каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
@@ -183,51 +195,42 @@ Quality gate перед сохранением и после мета-ревью
 - для `short` не больше 2 фаз и явно указан ожидаемый объём;
 - пакеты/ПО имеют конкретные версии или ссылку на существующий lock/config;
 - нет неподтверждённых существенных решений и неразрешённых альтернатив;
+- нет общих призывов, повторов и пояснений, удаление которых не меняет действия, контракты, зависимости, проверки или принятые решения;
 - план можно передать в `eda-plan-execute` без нового исследования.
 
-### 4. Мета-ревью тремя субагентами/моделями
-
-Запусти три проверки параллельно, в одном batch, до чтения любого результата. Главный планировщик сам решает, что применять; предложения не вставляются механически.
-
-| Среда | Быстрая | Кодовая | Флагман |
-|---|---|---|---|
-| 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` |
+### 4. Специализированная полировка плана
 
-В интерактивном Codex, если доступен инструмент субагентов (`spawn_agent` или аналог), используй его. Не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. В неинтерактивном fallback запускай три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
+Если `plan.review: false`, пропусти этап, оставь `plan_review: none`, `plan_review_fix: none` и перейди к strict-этапу или финалу. Не запускай старое общее мета-ревью.
 
-Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, карточки из `sources.references`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры/эталонов, необоснованные отклонения, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности, неверные зависимости и слишком крупные или несвязные фазы для одного исполнителя. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
+Если `plan.review: true`, запусти `eda-plan-polish` в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает review или fix. При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
 
-После ответов интегрируй принятые замечания в основные разделы плана, снова прогони quality gate и добавь:
+1. Запусти один `eda-plan-polish`:
 
-```markdown
-## Изменения после мета-ревью
-
-### После моделей
-- **+ Добавлено:** <3–7 главных изменений>
-- **~ Изменено:** <1–5 уточнений>
-- **− Убрано:** <если удалено>
-- **Отклонено:** <существенные отклонённые предложения и причина>
-```
+   ```text
+   Используй eda-plan-polish для <PLAN_FILE>.
+   Исходная задача и решения: <текущий запрос и ответы пользователя>.
+   Верни результат, последний review/fix, score, threshold и открытые ID.
+   ```
 
-В YAML поменяй `status: draft` на `meta-reviewed`, в `meta_reviewers` запиши модели.
+2. Проверь артефакты и SHA-256 цепочку, затем снова прогони локальный quality gate структуры плана.
+3. При `ready` убедись, что front matter содержит `status: reviewed`, последний `plan_review` и последний `plan_review_fix` либо `none`. Содержательных правок не делай.
+4. При limit, отсутствии прогресса или `blocked` не выдавай план за подтверждённый; сообщи открытые ID и передай пользователю только конкретный вопрос, если он действительно нужен.
 
 ### 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-polish и strict, путь к плану, пути к последним plan-review/plan-review-fix и strict-review при наличии, итоговый status, score/threshold, открытые ID, 3–5 главных шагов и что дальше делает `eda-plan-execute`.
 
 ## Чего НЕ делать
 
@@ -241,5 +244,5 @@ codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карто
 - Сохранять сырой текст Plan Mode без нормализации.
 - Оставлять финальный план исследованием, списком наблюдений или журналом мета-ревью.
 - Смешивать альтернативы с принятыми решениями.
-- Пропускать мета-ревью тремя моделями или запускать ревьюеров частями.
+- Выполнять plan-review, plan-review-fix или plan-polish основным агентом либо запускать старые три общих ревьюера.
 - Пропускать кросс-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`, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.