@gian-tiaga/eda 1.0.5 → 2.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "1.0.5",
+  "version": "2.1.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,162 @@
+---
+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. **Не проектируй конкретную реализацию.** Не назначай язык, фреймворк, библиотеку, конкретную СУБД, схему данных, классы, функции, внутренние модули или порядок технических изменений.
+8. **Сохраняй подтверждённое.** При обновлении не удаляй и не ослабляй существующее правило, не переименовывай и не удаляй карточку без явного решения пользователя.
+9. **Полнота без шума.** Зафиксируй все подтверждённые детали, которые меняют целевое поведение темы: правила, выбранные алгоритмы, состояния, переходы, ограничения, исключения и наблюдаемые результаты. Не сокращай сложную тему ради краткости; убирай повторы, общие рассуждения и факты, не влияющие на правило.
+10. **Строгая граница темы.** Карточка описывает только названную тему. Сведения о соседнем домене, внутреннем модуле или другой карточке опускай; если у них есть самостоятельное бизнес-значение, предложи отдельную тему, но не включай её в текущую.
+11. **`about` — только обзор.** Это не сводная бизнес-спецификация и не каталог остальных карточек. Кратко опиши сам проект и перечисли его основные пользовательские возможности; не раскладывай их по модулям и не детализируй правила, сценарии и исключения других тем.
+12. **Карточка не привязана к коду.** Код, тесты и конфиги используй для поиска вопросов и проверки текущего поведения, но пиши карточку устойчивым предметным языком. Не включай пути и строки исходников, имена классов, функций, файлов и внутренних модулей — в том числе в `about` и `Расхождения с реализацией`.
+13. **Алгоритм допустим, стек — нет.** Фиксируй выбранный функциональный или security-механизм, если он определяет поведение продукта: например, JWT либо непрозрачные токены с хранением в базе данных, правила выпуска, срока действия, обновления и отзыва. Не регламентируй язык, framework, библиотеку, конкретную СУБД, таблицы и способ программной сборки механизма, если это не отдельное подтверждённое ограничение продукта.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос с 2–3 вариантами, рекомендацией и остановись до ответа.
+- Codex exec / неинтерактивный запуск: не читай stdin. Если требуется решение или подтверждение, заверши `blocked: нужен ответ пользователя`, перечисли варианты и не записывай неподтверждённые файлы.
+- Не запускай команды, ожидающие интерактивный ввод в терминале.
+
+Задавай пакетами не больше трёх связанных вопросов. Не спрашивай факты, которые можно надёжно выяснить из проекта.
+
+## Процесс
+
+### 1. Прочитать существующий контекст
+
+Прочитай `docs/business.md` и только карточки, которые относятся к текущей теме. Затем изучи минимальный набор релевантных источников, достаточный для понимания именно этой темы. Для `about` обычно достаточно основного README, метаданных проекта и пользовательских точек входа; не обходи каждый внутренний модуль, route, модель или тест.
+
+Не загружай все карточки и весь код без необходимости. Разделяй:
+
+- подтверждённые требования пользователя;
+- уже записанные бизнес-правила;
+- наблюдаемое поведение реализации;
+- гипотезы и вопросы.
+
+### 2. Выбрать темы при пустом вызове
+
+Если тема не задана, составь короткий список только из реально применимых и непересекающихся тем. Для каждой одной фразой укажи, что именно будет описано. Не используй обязательный универсальный набор и не создавай тему для каждого технического модуля: `auth`, `posts`, `payments` и другие названия допустимы только при наличии самостоятельных правил продукта.
+
+Покажи список через `AskUserQuestion` и попроси подтвердить его или изменить. До подтверждения ничего не записывай. После ответа прорабатывай темы последовательно. Если работа прервана, следующий пустой вызов заново анализирует индекс и предлагает только отсутствующие или требующие актуализации темы.
+
+### 3. Согласовать текущую тему
+
+Сначала сформулируй суть темы в одном-двух предложениях. Затем собери все конкретные решения, необходимые для полного описания целевого поведения этой темы. Требования, термины, сценарии, состояния, ограничения, исключения и критерии приёмки добавляй по смыслу, а не ради заполнения универсального чеклиста. Не пропускай значимую конкретику только потому, что карточка получится длинной.
+
+Например, карточка аутентификации может подробно фиксировать выбранный вид токенов, их выпуск, срок действия, обновление, отзыв, завершение сессий и значимые ошибки. В ней допустимо выбрать JWT или токены, хранящиеся в базе данных, но не следует назначать язык, framework, библиотеку, конкретную СУБД, таблицы, классы и файлы.
+
+Для `about` подготовь короткое описание проекта и компактный список его основных возможностей. Не включай аудиторию, решаемую проблему, границы, общие ограничения или пользовательские сценарии отдельными разделами, если пользователь их явно не запросил и они не нужны для самого краткого описания. Не упоминай устройство внутренних модулей и не пересказывай содержимое тематических карточек.
+
+Сравни с реализацией только подтверждённые правила непосредственно текущей темы. Расхождение описывай как отличие наблюдаемого поведения от целевого, без ссылок на исходники и без пересказа устройства кода. В `Расхождения с реализацией` не добавляй наблюдения о соседних модулях, случайно замеченные дефекты, технический долг и неполноту других карточек. Для `about` не перечисляй пофункциональные расхождения: они относятся к отдельным тематическим карточкам. Если прямого существенного расхождения по теме нет, напиши `Известных расхождений не обнаружено.`
+
+Покажи человеку короткий текст будущей карточки целиком и запроси итоговое подтверждение через `AskUserQuestion`. Если остаётся спорное решение, сначала закрой его отдельным вопросом. Не записывай карточку до подтверждения.
+
+### 4. Записать карточку и индекс
+
+Используй стабильное имя файла в lowercase ASCII kebab-case: `docs/business/<topic>.md`.
+
+У обычной тематической карточки нет обязательного набора содержательных разделов. Выбирай структуру по сложности темы и фиксируй в ней всю значимую подтверждённую конкретику без лишних разделов, например:
+
+```markdown
+# <Название темы>
+
+<краткое описание темы>
+
+## Правила
+
+- <только необходимые согласованные правила>
+
+## Расхождения с реализацией
+
+<подтверждённые отличия с доказательствами либо «Известных расхождений не обнаружено.»>
+```
+
+Если отдельный раздел `Правила` не нужен, не создавай его. Для сложной темы добавь столько смысловых разделов, сколько требуется, чтобы не смешивать правила, алгоритмы, состояния, исключения и критерии. Для простой темы не создавай пустые или формальные разделы.
+
+Для `about.md` используй простой обзорный формат:
+
+```markdown
+# О проекте
+
+<краткое описание проекта>
+
+## Основные возможности
+
+- <возможность на уровне пользователя>
+
+## Расхождения с реализацией
+
+Известных расхождений не обнаружено.
+```
+
+Сохраняй `Расхождения с реализацией` последним разделом любой карточки.
+
+Создай или обнови `docs/business.md` как короткое оглавление только существующих согласованных карточек:
+
+```markdown
+# Бизнес-логика проекта
+
+| Описание | Карточка |
+|---|---|
+| Краткое описание проекта и основные возможности | [О проекте](business/about.md) |
+| Регистрация, вход, восстановление доступа и права пользователей | [Авторизация](business/auth.md) |
+```
+
+Описание должно позволять другому скилу решить, нужна ли карточка для текущей задачи, не открывая её. В индексе не должно быть статусов, планов будущих тем или содержания самих карточек.
+
+### 5. Проверить результат
+
+Убедись, что:
+
+- индекс содержит только существующие согласованные карточки и ровно две колонки `Описание` и `Карточка`;
+- новая или обновлённая карточка соответствует подтверждённому содержанию;
+- карточка не содержит сведений о соседних темах и не раздута необязательными разделами;
+- `about` остаётся коротким обзором проекта и его основных возможностей без описания внутренних модулей;
+- сложная тема подробно фиксирует все значимые подтверждённые правила, алгоритмы, состояния и исключения;
+- текст карточки не ссылается на файлы, строки, классы, функции и внутренние модули текущей реализации;
+- выбранный механизм поведения отделён от языка, framework, библиотеки, конкретной СУБД и схемы реализации;
+- каждое правило однозначно и проверяемо на уровне поведения;
+- техническая реализация не выдана за бизнес-требование;
+- раздел `Расхождения с реализацией` последний и отделяет целевое состояние от текущего;
+- существующие несвязанные карточки сохранены без изменений.
+
+### 6. Финал
+
+Коротко сообщи путь к карточке и индексу, какие решения зафиксированы и какие расхождения с реализацией обнаружены. Если после пустого вызова остались подтверждённые темы, переходи к следующей; дополнительное разрешение продолжить не спрашивай.
+
+## Чего НЕ делать
+
+- Записывать неподтверждённые темы или черновики в индекс.
+- Выводить бизнес-правило только из текущего кода и сразу считать его целевым.
+- Подменять карточку исследованием, roadmap, архитектурой или планом реализации.
+- Сокращать сложную тему до общего описания и терять подтверждённые правила или алгоритмы.
+- Переписывать в карточку структуру кода, пути, строки, классы, функции и внутренние модули.
+- Использовать `about` как сводку всех доменов, модулей, правил и расхождений проекта.
+- Переносить в текущую карточку подробности и расхождения соседней темы «для контекста».
+- Создавать ссылки из индекса на отсутствующие файлы.
+- Молча удалять, переименовывать или ослаблять подтверждённые требования.
+- Сохранять 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

@@ -5,80 +5,72 @@ description: 'Исправляет код по готовому ревью из
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
 
-Берёшь готовое ревью из `docs/reviews/`, применяешь замечания к коду, сохраняешь отчёт о фиксах в `docs/review-fixes/`. После всех правок — полный прогон тестов и линтеров.
+Берёшь готовое ревью из `docs/reviews/` или сообщения, применяешь все находки к коду и сохраняешь отчёт в `docs/review-fixes/`. После правок выполняешь полный прогон тестов и линтеров.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Сначала разбери тему, задачу, путь к файлу, номера замечаний, ограничения и прямые указания. Если входа достаточно, продолжай без вопроса. Старое обсуждение не считай входом, если пользователь явно не связал его с текущим вызовом.
 
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Режим запуска
-
-Обычный режим: все пункты «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
-
-Режим `apply-optional`: все пункты «Править обязательно» применяешь без исключений. По каждому пункту «На усмотрение автора» сам принимаешь решение без вопроса: применяешь, если правка явно улучшает качество, снижает риск или стоит дёшево; отклоняешь, если польза спорная, правка расширяет scope, создаёт риск регрессии, конфликтует с правилами/архитектурой или требует продуктового решения. Название режима означает «разобрать optional без вопроса», а не «механически применить все optional». Пункты «Не править» всё равно пропускаешь.
+У нового формата ревью одна группа находок: каждый пункт обязательно исправить. Режимов выбора рекомендаций нет. Если дан старый файл с разделами `Править обязательно`, `На усмотрение автора` и `Не править`, применяй только пункты из `Править обязательно`; остальные старые предложения не переноси в работу и отчёт.
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Если есть `docs/references.md`, выбери по индексу только карточки для затронутых замечаниями компонентов и прочитай их целиком. Приоритет: подтверждённое решение пользователя → правила → архитектура → карточки. Сделай это один раз в начале.
-2. **Интерактивные вопросы** — по разделу ниже.
-3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
-4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
-5. **Логика по группам ревью:** «Править обязательно» — правишь все сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`, где сам решаешь применить или отклонить; «Не править» — пропускаешь и отмечаешь в отчёте.
-6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
-7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
-8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
+1. Перед правкой прочитай `docs/rules.md` и `docs/arch.md`. Определи замечания и затронутое поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов.
+2. Применяй все выбранные находки. Не переоценивай их полезность и не превращай исправление в более широкий рефакторинг.
+3. Задавай вопрос только если находка неоднозначна, противоречит коду или обязательной документации, требует продуктового решения, расширяет scope либо ведёт к рискованному действию. В остальных случаях работай автономно.
+4. Не делай новое ревью и не коммить. Только исправляй замечания и пиши отчёт.
+5. Если находка касается поведения, добавь или обнови точечный тест в той же правке и прогони его.
+6. В конце обязательно прогони полный набор тестов и линтеров один раз.
+7. Пиши просто и конкретно; в отчёте используй таблицу.
 
 ## Интерактивные вопросы
 
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+Когда без ответа нельзя безопасно продолжать:
+
 - Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`, где решение принимает сам агент; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 2–3 вариантами и остановись до ответа.
+- Codex exec и другой неинтерактивный запуск: не читай stdin; верни `blocked: нужен ответ пользователя`, перечисли вопрос и варианты, не выполняй рискованное действие.
+
+Не запускай команды, которые ждут интерактивного ввода в терминале. Вопрос не разрешает молча заменить находку другой правкой или исправлять несвязанные поломки.
 
 ## Этапы
 
 ### 1. Выбрать ревью
-Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», номера замечаний или вставленный текст замечаний. Если замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
 
-Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
+Разбери путь к ревью, название, «последнее ревью», номера находок или вставленный текст. Для текста используй `$REVIEW_SOURCE=review_text`, не выбирай файл и сохраняй отчёт с `review: text`.
+
+Если найден ровно один файл, используй `$REVIEW_SOURCE=review_file`. Если найдено несколько равно подходящих файлов или входа нет, задай один вопрос со списком. Если `docs/reviews/` пуста и текст замечаний не дан, остановись с `blocked: нужно ревью`.
 
 ### 2. Прочитать контекст
-Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Через `docs/references.md` выбери только применимые карточки. Если связанный план содержит `sources.references`, прочитай перечисленные карточки и не загружай остальные.
 
-Если `$REVIEW_SOURCE=review_file`, прочитай сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
+Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Для исправляемого поведения выбери только применимые business-карточки и технические reference-карточки. Если связанный план уже задаёт `sources.business` или `sources.references`, используй относящиеся к находкам пути из этих списков.
+
+При `$REVIEW_SOURCE=review_file` прочитай ревью целиком, а также явно связанные план и research. При `$REVIEW_SOURCE=review_text` работай по текущему сообщению. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи план или research без явной ссылки.
 
-Если `$REVIEW_SOURCE=review_text`, работай по замечаниям из текущего сообщения пользователя. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи связанные plan/research, если они не указаны в тексте.
+### 3. Применить находки
 
-### 3. Применить замечания
-Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
-- **Править обязательно** → правишь все пункты сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
-- **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
-- **Не править** → пропусти.
+Исправь все находки нового формата либо выбранные пользователем номера. Для старого формата возьми только пункты из `Править обязательно`. Делай минимальную достаточную правку и точечную проверку после каждого логического изменения.
 
-Останавливайся и спрашивай, если замечание непонятно, противоречит коду или проектной документации, требует необоснованного отклонения от карточки либо задевает рискованное вне ревью (удаление, миграции, секреты). Подтверждённое отклонение зафиксируй в отчёте.
+Остановись с вопросом при неоднозначности, конфликте с правилами, архитектурой или business-карточкой, необходимости расширить scope либо выполнить рискованное действие. При конфликте с business-карточкой предложи изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
 
 ### 4. Финальная проверка
-Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
 
-### 5. Сохранить отчёт о фиксах и связать с ревью
-Сохрани отчёт в `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же что у ревью или близкий). Если `$REVIEW_SOURCE=review_file`, затем **допиши в конец файла ревью** (`$REVIEW_FILE`) раздел со ссылкой:
+Прогони полный сьют тестов и линтеры стандартными командами проекта. Свои поломки исправь и повтори проверку. При чужой или несвязанной ошибке остановись с конкретным блокером.
+
+### 5. Сохранить отчёт и связать с ревью
+
+Сохрани `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Если `$REVIEW_SOURCE=review_file`, допиши в конец `$REVIEW_FILE`:
 
 ```markdown
 ## Применённые фиксы
 Отчёт: `docs/review-fixes/{file}.md`
 ```
 
-Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: такого файла нет. В отчёте укажи `review: text`.
-
-Шаблон отчёта:
+Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: исходного файла нет.
 
 ```markdown
 ---
-review: <путь к docs/reviews/...>
+review: <docs/reviews/... | text>
 date: <YYYY-MM-DD HH:MM>
 status: done
 ---
@@ -89,13 +81,6 @@ status: done
 | # | Замечание | Файлы | Тесты | Статус |
 |---|-----------|-------|-------|--------|
 | 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
-| 2 | ... | ... | — | ✓ применено |
-| 3 | ... | — | — | ✗ отклонено (на усмотрение, причина: <короткое обоснование>) |
-| 4 | ... | — | — | — не править (по решению ревью) |
-
-## Решения по optional
-- **Принято:** <номера и коротко почему>
-- **Отклонено:** <номера и коротко почему, чтобы следующие ревьюеры не повторяли это как открытое замечание>
 
 ## Финальная проверка
 - **Тесты:** `<команда>` — ✓ / ✗
@@ -103,17 +88,16 @@ status: done
 - **Заметки:** <если что-то осталось не зелёным — почему>
 ```
 
-Если `$REVIEW_SOURCE=review_file` и в режиме `apply-optional` отклонены пункты «На усмотрение автора», в добавляемом в ревью разделе `## Применённые фиксы` после ссылки на отчёт добавь короткий список `Отклонённые optional-решения` с причинами. Это нужно, чтобы следующие ревьюеры видели уже принятое решение и не повторяли тот же optional-пункт без новых аргументов.
-
 ### 6. Финал
-Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
+
+Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к fix-отчёту, сколько находок применено, результат финальной проверки и состояние git «не закоммичено». Предложи `eda-commit`.
 
 ## Чего НЕ делать
+
 - Делать само ревью — это `eda-review`.
-- Коммитить, пушить — это `eda-commit`.
-- Применять или отклонять «на усмотрение» молча без явного режима `apply-optional` или ответа пользователя.
-- Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
-- Гонять полный сьют и линтеры на каждой правке — только в конце.
-- Пропускать финальную проверку.
-- Сохранять отчёт куда-либо кроме `docs/review-fixes/`.
-- Игнорировать применимую карточку или молча отклоняться от её примера.
+- Коммитить или пушить — это `eda-commit`.
+- Выбирать, какие находки достойны исправления: принятая находка уже обязательна.
+- Расширять scope ради улучшений, которых нет в находках.
+- Гонять полный сьют после каждого пункта или пропускать финальную проверку.
+- Сохранять отчёт вне `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`.