@gian-tiaga/eda 1.0.5 → 2.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "1.0.5",
+  "version": "2.0.0",
   "description": "Пакет скилов и специализированных агентов eda-* для Claude Code и Codex CLI",
   "type": "module",
   "bin": {
@@ -40,6 +40,7 @@
   },
   "dependencies": {
     "@inquirer/checkbox": "^4.3.2",
-    "@inquirer/select": "^5.1.5"
+    "@inquirer/select": "^5.1.5",
+    "yaml": "^2.9.0"
   }
 }

package/skills/eda-aim/SKILL.md

@@ -9,7 +9,7 @@ description: 'Согласует одну или несколько провер
 
 ## Настройки
 
-Прочитай только раздел `aim` из `docs/settings.yaml`, если файл есть. Применяй только `version: 2`.
+Прочитай только раздел `aim` из `docs/settings.yaml`, если файл есть. Применяй только `version: 3`.
 
 ```yaml
 aim:

package/skills/eda-business/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: eda-business
+description: 'Создаёт и обновляет согласованное описание проекта, требований и бизнес-логики по тематическим карточкам.'
+---
+
+# Скил: Бизнес-логика (eda-business)
+
+Создаёшь и поддерживаешь согласованную бизнес-документацию проекта: короткое оглавление `docs/business.md` и самостоятельные тематические карточки в `docs/business/`. Документы отвечают на вопросы «что должен делать продукт», «для кого», «по каким правилам» и «какой результат считается правильным», но не проектируют техническую реализацию.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Извлеки названную тему, требования, ограничения, ответы на бизнес-вопросы и прямые указания по существующим карточкам.
+
+- Если пользователь назвал тему, работай только с ней. Не расширяй вызов до полного аудита проекта.
+- Если тема не названа, проанализируй проект и предложи упорядоченный список тем, которые действительно стоит описать. Для полного каталога первой предлагай `about`, затем только доказанные проектом домены и сценарии.
+- Явные требования из текущего сообщения считай подтверждёнными. Выводы из кода, тестов и других документов сначала показывай как предложения.
+
+Старое обсуждение не считай входом, если пользователь явно не связал его с текущим вызовом.
+
+## Главные правила
+
+1. **Только business-документация.** Меняй лишь `docs/business.md` и Markdown-файлы непосредственно в `docs/business/`. Не правь код, настройки, правила, архитектуру, планы, тесты или другие документы.
+2. **Целевое поведение.** Карточки фиксируют согласованные требования и бизнес-логику, даже если код пока им не соответствует. Фактические отличия вынеси в последний раздел `Расхождения с реализацией`.
+3. **Никаких догадок как фактов.** Код помогает найти существующие сценарии и вопросы, но не подтверждает продуктовые решения сам по себе.
+4. **Одна тема за раз.** После согласования общего списка полностью проработай текущую тему и получи подтверждение её содержания до записи, затем переходи к следующей.
+5. **В индекс — только готовое.** Не записывай предложенные, незавершённые или спорные темы в `docs/business.md` и не создавай для них черновые карточки.
+6. **Самодостаточные карточки.** Основной текст не должен требовать чтения исходного кода, плана или внешнего материала, чтобы понять бизнес-правило.
+7. **Не проектируй реализацию.** Не назначай классы, таблицы, endpoints, очереди, библиотеки, модули или порядок технических изменений.
+8. **Сохраняй подтверждённое.** При обновлении не удаляй и не ослабляй существующее правило, не переименовывай и не удаляй карточку без явного решения пользователя.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос с 2–3 вариантами, рекомендацией и остановись до ответа.
+- Codex exec / неинтерактивный запуск: не читай stdin. Если требуется решение или подтверждение, заверши `blocked: нужен ответ пользователя`, перечисли варианты и не записывай неподтверждённые файлы.
+- Не запускай команды, ожидающие интерактивный ввод в терминале.
+
+Задавай пакетами не больше трёх связанных вопросов. Не спрашивай факты, которые можно надёжно выяснить из проекта.
+
+## Процесс
+
+### 1. Прочитать существующий контекст
+
+Прочитай `docs/business.md` и только карточки, которые относятся к текущей теме. Затем изучи релевантные README, стартовые документы, правила, архитектуру, пользовательские сценарии, routes, модели, тесты и историю, достаточные для понимания фактического поведения.
+
+Не загружай все карточки и весь код без необходимости. Разделяй:
+
+- подтверждённые требования пользователя;
+- уже записанные бизнес-правила;
+- наблюдаемое поведение реализации;
+- гипотезы и вопросы.
+
+### 2. Выбрать темы при пустом вызове
+
+Если тема не задана, составь короткий список только из реально применимых тем. Для каждой укажи, что именно будет описано и почему тема нужна проекту. Не используй обязательный универсальный набор: `auth`, `posts`, `payments` и другие названия допустимы только при наличии соответствующего поведения.
+
+Покажи список через `AskUserQuestion` и попроси подтвердить его или изменить. До подтверждения ничего не записывай. После ответа прорабатывай темы последовательно. Если работа прервана, следующий пустой вызов заново анализирует индекс и предлагает только отсутствующие или требующие актуализации темы.
+
+### 3. Согласовать текущую тему
+
+Собери достаточную бизнес-спецификацию:
+
+- назначение и границы темы;
+- участники, роли и значимые термины;
+- требования, правила и инварианты;
+- основные сценарии и порядок бизнес-действий;
+- состояния, переходы, ограничения и исключения;
+- ошибки и пограничные случаи, видимые пользователю или внешнему потребителю;
+- проверяемые критерии приёмки.
+
+Для `about` вместо детального алгоритма зафиксируй назначение проекта, аудиторию, решаемую проблему, границы, ключевые возможности, основные пользовательские сценарии и общие бизнес-ограничения.
+
+Сравни целевое поведение с реализацией. Подготовь отдельный список подтверждённых расхождений с точными путями и строками, когда они доступны. Отсутствие реализации также является расхождением, если требование уже подтверждено.
+
+Покажи человеку собранное содержание и запроси итоговое подтверждение через `AskUserQuestion`. Если остаётся спорное решение, сначала закрой его отдельным вопросом. Не записывай карточку до подтверждения.
+
+### 4. Записать карточку и индекс
+
+Используй стабильное имя файла в lowercase ASCII kebab-case: `docs/business/<topic>.md`.
+
+Обычная тематическая карточка:
+
+```markdown
+# <Название темы>
+
+## Назначение и границы
+<что покрывает тема и что не покрывает>
+
+## Участники и термины
+<роли и доменные понятия>
+
+## Требования и правила
+<согласованные требования и инварианты>
+
+## Сценарии и алгоритмы
+<пошаговое бизнес-поведение без технической реализации>
+
+## Состояния и исключения
+<переходы, ограничения, ошибки и пограничные случаи>
+
+## Критерии приёмки
+<наблюдаемые условия корректного поведения>
+
+## Расхождения с реализацией
+<подтверждённые отличия с доказательствами либо «Известных расхождений не обнаружено.»>
+```
+
+Для `about.md` используй подходящие смысловые разделы из шага 3, но всегда оставляй последним `## Расхождения с реализацией`.
+
+Создай или обнови `docs/business.md` как короткое оглавление только существующих согласованных карточек:
+
+```markdown
+# Бизнес-логика проекта
+
+| Описание | Карточка |
+|---|---|
+| Назначение проекта, аудитория и основные возможности | [О проекте](business/about.md) |
+| Регистрация, вход, восстановление доступа и права пользователей | [Авторизация](business/auth.md) |
+```
+
+Описание должно позволять другому скилу решить, нужна ли карточка для текущей задачи, не открывая её. В индексе не должно быть статусов, планов будущих тем или содержания самих карточек.
+
+### 5. Проверить результат
+
+Убедись, что:
+
+- индекс содержит только существующие согласованные карточки и ровно две колонки `Описание` и `Карточка`;
+- новая или обновлённая карточка соответствует подтверждённому содержанию;
+- каждое правило однозначно и проверяемо на уровне поведения;
+- техническая реализация не выдана за бизнес-требование;
+- раздел `Расхождения с реализацией` последний и отделяет целевое состояние от текущего;
+- существующие несвязанные карточки сохранены без изменений.
+
+### 6. Финал
+
+Коротко сообщи путь к карточке и индексу, какие решения зафиксированы и какие расхождения с реализацией обнаружены. Если после пустого вызова остались подтверждённые темы, переходи к следующей; дополнительное разрешение продолжить не спрашивай.
+
+## Чего НЕ делать
+
+- Записывать неподтверждённые темы или черновики в индекс.
+- Выводить бизнес-правило только из текущего кода и сразу считать его целевым.
+- Подменять карточку исследованием, roadmap, архитектурой или планом реализации.
+- Создавать ссылки из индекса на отсутствующие файлы.
+- Молча удалять, переименовывать или ослаблять подтверждённые требования.
+- Сохранять business-документацию вне `docs/business.md` и `docs/business/`.

package/skills/eda-discover-automations/SKILL.md

@@ -11,7 +11,7 @@ description: 'Аудирует автоматические проверки п
 
 Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
 
-Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `discover-automations.include_plans: false`.
+Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `discover-automations.include_plans: false`.
 
 Если актуального раздела `discover-automations` нет, но есть прежний раздел `automate`, используй `automate.include_plans` как совместимый fallback и сообщи, что настройку следует переименовать. Если присутствуют оба раздела, применяй только `discover-automations`.
 
@@ -55,6 +55,7 @@ description: 'Аудирует автоматические проверки п
 - Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
 - В режиме `plans`: все выбранные планы из `docs/plans/`.
 - `docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
+- Сначала определи затронутые историей и текущим аудитом доменные области. Затем через `docs/business.md` выбери только карточки этих областей; если подходящих нет, продолжай без business-контекста. Используй карточки лишь для поиска автоматизируемых инвариантов и acceptance-сценариев, не расширяй аудит на несвязанные темы.
 - Какие языки и фреймворки в проекте — определи сам.
 - Какие инструменты качества уже установлены и работают: линтеры, форматтеры, статанализаторы, typecheck, все виды тестов, coverage, архитектурные проверки, валидаторы конфигов, security/supply-chain сканеры, performance budgets, pre-commit, CI, release/post-deploy проверки и npm/composer/make-скрипты.
 - Какие агентные усиления уже есть: `.claude/skills/`, `.codex/skills/`, MCP-конфиги, локальные скилы, команды для ревью/планирования. Не предлагай дубль уже установленному.
@@ -107,7 +108,7 @@ description: 'Аудирует автоматические проверки п
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
-sources: [docs/reviews/..., docs/review-fixes/..., docs/fixes/...]
+sources: [docs/reviews/..., docs/review-fixes/..., docs/fixes/..., docs/business/...]
 mode: <normal | plans>
 status: draft
 ---
@@ -119,6 +120,7 @@ status: draft
 - Стек проекта: <по конфигам>
 - Уже работающие инструменты: <список>
 - Уже найденные скилы/MCP/агентные проверки: <список или «не найдены»>
+- Применимые business-карточки: <пути или «нет»>
 
 ## Покрытие экстремального каталога
 | Группа | Уже есть | Пробелы | Статус | Причина N/A |

package/skills/eda-explore/SKILL.md

@@ -11,7 +11,7 @@ description: 'Исследует техническую тему или зада
 
 Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
 
-Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `explore.strict: false`, `explore.decision_mode: recommend_and_ask`.
+Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `explore.strict: false`, `explore.decision_mode: recommend_and_ask`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
@@ -43,8 +43,8 @@ description: 'Исследует техническую тему или зада
 3. **Развилки закрывай по `decision_mode`.** Значимые развилки подтверждай до финализации, мелкие локальные решения выбирай сам и не создавай шум.
 4. **Риски вплетай в исследование.** Не создавай отдельный обязательный раздел или этап рисков. Если риск влияет на выбор, источник, ограничение или будущую проверку, фиксируй его рядом с соответствующим решением: что может пойти не так и как это учитывается — снимаем, принимаем или выносим за рамки.
 5. **Версии проверяй.** Если речь о пакетах, библиотеках, CLI, сервисах или другом ПО, а версия не задана контекстом, проверь последнюю стабильную версию через context7, если он доступен, или через web search по официальным источникам.
-6. **Прочитай рамку проекта.** Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Если существует `docs/references.md`, прочитай индекс, выбери только карточки, применимые к исследуемым компонентам, и прочитай их целиком; нерелевантные карточки не загружай.
-7. **Соблюдай приоритеты.** Подтверждённое решение пользователя важнее `docs/rules.md`, затем идёт `docs/arch.md`, затем релевантные карточки. Не рекомендуй отклонение от эталона без явной причины и подтверждения пользователя.
+6. **Прочитай рамку проекта.** Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Сначала определи исследуемую задачу, затем через `docs/business.md` выбери только карточки затронутого поведения, а через `docs/references.md` — только карточки затронутых компонентов. Нерелевантные карточки не загружай.
+7. **Разделяй источники.** Текущий запрос задаёт область исследования; применимые business-карточки — требования к затронутому поведению; rules, architecture и references — техническая рамка. Если запрос противоречит business-карточке, остановись и через `AskUserQuestion` спроси, изменить задачу или пересогласовать правило через `eda-business`. Не рекомендуй отклонение от технического эталона без явной причины и подтверждения пользователя.
 7. **Каждое фактическое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза» и не делай её основанием выбранного решения.
 8. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
 9. **Таблицы > сплошной текст** для фактов, развилок, сравнений, версий и источников.
@@ -70,7 +70,7 @@ description: 'Исследует техническую тему или зада
 
 ### 2. Собрать контекст
 
-Работай read-only: читай код, документы, конфиги, тесты, историю и внешние источники. Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Если есть `docs/references.md`, выбери по индексу только применимые карточки и используй их кодовые примеры как эталон ожидаемой формы решения.
+Работай read-only: читай код, документы, конфиги, тесты, историю и внешние источники. Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Если есть `docs/business.md`, выбери по описаниям только карточки, непосредственно относящиеся к исследуемому поведению; если подходящих нет, продолжай без них. Если есть `docs/references.md`, выбери по индексу только применимые технические карточки и используй их кодовые примеры как эталон ожидаемой формы решения.
 
 Если исследование касается пакетов или ПО:
 - сначала проверь, не зафиксирована ли версия в запросе, lock-файле, package/config-файле, `docs/rules.md`, `docs/arch.md` или связанном документе;
@@ -102,6 +102,7 @@ reviewer: <pending | none | claude | codex>
 sources:
   rules: <путь или —>
   arch: <путь или —>
+  business: [<пути к применимым карточкам или пусто>]
   references: [<пути к применимым карточкам или пусто>]
 ---
 
@@ -148,13 +149,13 @@ Quality gate перед сохранением:
 Если ты в Claude Code — запускай Codex CLI:
 
 ```bash
-codex exec "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md, карточки из sources.references при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, применимые эталоны учтены, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
+codex exec "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md, применимые карточки из sources.business и sources.references при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, применимые бизнес-требования учтены, архитектура не выдумана, применимые эталоны учтены, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, нарушения бизнес-требований, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
 ```
 
 Если ты в Codex — запускай Claude CLI с теми же требованиями:
 
 ```bash
-claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md, карточки из sources.references при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, применимые эталоны учтены, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
+claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md, применимые карточки из sources.business и sources.references при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, применимые бизнес-требования учтены, архитектура не выдумана, применимые эталоны учтены, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, нарушения бизнес-требований, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
 ```
 
 CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.

package/skills/eda-fix/SKILL.md

@@ -37,10 +37,10 @@ description: 'Вносит изменения в код по плану или
 Определи `$FIX_CONTEXT`: путь к файлу прочитай, план из `docs/plans/` используй как план фикса, текст используй как контекст. Если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
-Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Если существует `docs/references.md`, выбери по индексу только применимые карточки и используй их примеры как ожидаемую форму реализации. Если `$FIX_CONTEXT` ссылается на план с `sources.references`, прочитай перечисленные карточки; если ссылается на research, review, issue или другой файл — прочитай и его.
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Сначала определи задачу фикса и затронутое поведение. Если связанный план содержит `sources.business`, прочитай только перечисленные применимые карточки; иначе через `docs/business.md` выбери по описаниям только карточки этой темы. Если подходящих карточек нет, продолжай без business-контекста. Если существует `docs/references.md`, выбери по индексу только применимые технические карточки и используй их примеры как ожидаемую форму реализации. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.
 
 ### 3. Сделать фикс
-Найди релевантный код и внеси минимальные правки. Следуй применимому примеру; отклоняйся только по причине, подтверждённой пользователем или уже записанной во входном плане. Если задача состоит из нескольких пунктов, иди по ним последовательно. Останавливайся и спрашивай, если пункт противоречит коду или документации, требует необоснованного отклонения от карточки, продуктового решения, рискованной операции, миграции, удаления данных или затрагивает секреты.
+Найди релевантный код и внеси минимальные правки. Текущая задача задаёт scope, применимая business-карточка — требования к затронутому поведению, reference-карточка — форму реализации. Если задача противоречит business-карточке, остановись, покажи конфликт и через `AskUserQuestion` спроси: изменить задачу или сначала пересогласовать правило через `eda-business`. Следуй применимому техническому примеру; отклоняйся только по причине, подтверждённой пользователем или уже записанной во входном плане. Если задача состоит из нескольких пунктов, иди по ним последовательно. Останавливайся и спрашивай также при рискованной операции, миграции, удалении данных или работе с секретами.
 
 ### 4. Добавить или обновить тесты
 Если фикс меняет поведение — добавь тест рядом с изменением или обнови существующий. Если тесты не нужны, в отчёте коротко объясни почему.
@@ -61,7 +61,7 @@ status: done
 # Фикс: <краткий заголовок>
 
 ## Контекст
-<что было передано на вход и какие правила, архитектура и карточки учтены>
+<что было передано на вход и какие правила, архитектура, business- и reference-карточки учтены>
 
 ## Что изменено
 | # | Файл | Что изменено | Зачем |
@@ -86,4 +86,5 @@ status: done
 - Выполнять большой план с чекбоксами и журналом `docs/executions/` — это `eda-plan-execute`.
 - Применять замечания из готового ревью — это `eda-fix-by-review`.
 - Сохранять отчёт куда-либо кроме `docs/fixes/`.
-- Игнорировать применимую карточку или молча отклоняться от её примера.
+- Загружать несвязанные business-карточки или расширять ими scope фикса.
+- Игнорировать применимую карточку или молча отклоняться от её требований либо примера.

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

@@ -21,7 +21,7 @@ description: 'Исправляет код по готовому ревью из
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Если есть `docs/references.md`, выбери по индексу только карточки для затронутых замечаниями компонентов и прочитай их целиком. Приоритет: подтверждённое решение пользователя → правила → архитектура → карточки. Сделай это один раз в начале.
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Сначала определи замечания и затронутое ими поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов. Если подходящих business-карточек нет, продолжай без них. Сделай это один раз в начале.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
 4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
@@ -47,7 +47,7 @@ description: 'Исправляет код по готовому ревью из
 Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
 
 ### 2. Прочитать контекст
-Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Через `docs/references.md` выбери только применимые карточки. Если связанный план содержит `sources.references`, прочитай перечисленные карточки и не загружай остальные.
+Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Если связанный план содержит `sources.business`, прочитай только перечисленные карточки, относящиеся к исправляемым замечаниям; иначе выбери их по описаниям через `docs/business.md`. Отсутствие подходящей карточки не является блокером. Через `docs/references.md` выбери только применимые технические карточки. Если связанный план содержит `sources.references`, прочитай перечисленные карточки и не загружай остальные.
 
 Если `$REVIEW_SOURCE=review_file`, прочитай сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
 
@@ -59,7 +59,7 @@ description: 'Исправляет код по готовому ревью из
 - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
 - **Не править** → пропусти.
 
-Останавливайся и спрашивай, если замечание непонятно, противоречит коду или проектной документации, требует необоснованного отклонения от карточки либо задевает рискованное вне ревью (удаление, миграции, секреты). Подтверждённое отклонение зафиксируй в отчёте.
+Останавливайся и спрашивай, если замечание непонятно, противоречит коду или проектной документации либо задевает рискованное вне ревью (удаление, миграции, секреты). Если исправление противоречит применимой business-карточке, покажи конфликт и спроси: изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Не разрешай такой конфликт автоматически даже в `apply-optional`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
 
 ### 4. Финальная проверка
 Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
@@ -116,4 +116,5 @@ status: done
 - Гонять полный сьют и линтеры на каждой правке — только в конце.
 - Пропускать финальную проверку.
 - Сохранять отчёт куда-либо кроме `docs/review-fixes/`.
-- Игнорировать применимую карточку или молча отклоняться от её примера.
+- Загружать несвязанные business-карточки или расширять ими состав исправлений.
+- Игнорировать применимую карточку или молча отклоняться от её требований либо примера.

package/skills/eda-manual-test/SKILL.md

@@ -24,6 +24,7 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
 8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
 9. **Отчёт обязателен.** Сохрани результат в `docs/manual-tests/`, даже если проверка заблокирована или нашла баги.
+10. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
 
 ## Интерактивные вопросы
 
@@ -36,25 +37,29 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 ## Этапы
 
 ### 1. Определить цель проверки
-Разбери вход пользователя. Если указан файл плана, ревью, research, issue или другой артефакт — прочитай его. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
+Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix-отчёт или другой артефакт — прочитай его. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
 
 Определи `$TEST_TARGET`: `api`, `frontend`, `fullstack` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
 Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
 
+После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки и не расширяй ими smoke-проверку.
+
+Если ожидаемый результат задачи противоречит применимой business-карточке, не выбирай правильный вариант самостоятельно. До неоднозначного сценария покажи конфликт и через `AskUserQuestion` спроси: проверять изменённую задачу как новое правило или сначала пересогласовать карточку через `eda-business`. В неинтерактивном режиме зафиксируй `blocked` с этим вопросом.
+
 Не устанавливай Playwright, браузеры, пакеты, docker images или системные зависимости молча. Если без этого проверка невозможна — спроси через `AskUserQuestion` или зафиксируй `blocked` в неинтерактивном режиме.
 
 ### 3. Составить smoke-чеклист
 Составь короткий чеклист:
 - запуск приложения или API;
+- явные acceptance criteria и сценарии выполненной задачи;
 - основной happy path изменённой области;
-- 1–2 негативных или edge-сценария;
-- явные acceptance criteria из плана или входа пользователя;
+- 1–2 негативных или edge-сценария, которые следуют из задачи;
 - для фронта: console errors, network errors и видимые regressions на основной странице;
 - для API: status code, схема/ключевые поля ответа, обработка неверного ввода или прав доступа, если это относится к задаче.
 
-Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
+Применимая business-карточка может добавить важный инвариант, ожидаемый результат или один релевантный негативный сценарий, который задача не сформулировала явно. Она не заменяет критерии задачи и не требует тестировать всю предметную область. Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
 
 ### 4. Запустить окружение
 Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
@@ -98,6 +103,9 @@ status: <passed | failed | blocked>
 ## Контекст
 <что проверялось и откуда взяты сценарии>
 
+## Business-контекст
+<только если использовался: применимые карточки и какие сценарии или ожидания они добавили>
+
 ## Окружение
 | Что | Значение |
 |---|---|
@@ -117,7 +125,7 @@ status: <passed | failed | blocked>
 <ссылки на скриншоты, логи или «Нет»>
 
 ## Итог
-<passed / failed / blocked и короткое объяснение>
+<passed / failed / blocked и короткое объяснение относительно выполненной задачи>
 ```
 
 Если найден баг, статус отчёта `failed`. Если проверка невозможна из-за окружения, авторизации, отсутствующих зависимостей или непонятного риска, статус `blocked`.

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
 
@@ -123,18 +126,18 @@ orhestra:
 
 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`, явно напиши «полировка кода пропущена настройкой».
 
 ## Чего НЕ делать