@gian-tiaga/eda 1.0.5 → 2.0.0

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

@@ -0,0 +1,188 @@
+---
+name: eda-plan-review
+description: 'Проводит специализированное read-only ревью готового плана и сохраняет findings с оценкой готовности.'
+---
+
+# Скил: Ревью плана (eda-plan-review)
+
+Работай как оркестратор установленных `eda-plan-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их prompts в task-сообщения. Выбери план и проверки, запусти агентов, проверь структурированные ответы, дедуплицируй подтверждённые findings, выставь экспертный score и сохрани один review-артефакт.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold, предыдущие review/fix, отключённые или принудительно включённые проверки и разовые модели.
+
+Если входа достаточно, продолжай без вопроса. `AskUserQuestion` используй только если план нельзя выбрать однозначно или переданная цепочка review/fix противоречива. Старую историю диалога не считай входом без явной связи с текущим вызовом.
+
+## Настройки
+
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`; при другой версии или невалидном поле используй defaults и добавь warning. Прямое указание пользователя важнее файла.
+
+Используй `plan-review.threshold` и `plan-review.agents.<check>.mode/model`. Threshold по умолчанию `95`, допустимы целые значения `1–100`.
+
+| Проверка | Default mode | Claude | Codex |
+|---|---|---|---|
+| `requirements` | `always` | `sonnet` | `gpt-5.6-terra` |
+| `rules` | `always` | `haiku` | `gpt-5.6-luna` |
+| `architecture` | `always` | `opus` | `gpt-5.6-sol` |
+| `feasibility` | `always` | `opus` | `gpt-5.6-sol` |
+| `execution` | `always` | `sonnet` | `gpt-5.6-terra` |
+| `verification` | `always` | `sonnet` | `gpt-5.6-terra` |
+| `api` | `auto` | `sonnet` | `gpt-5.6-terra` |
+| `database` | `auto` | `opus` | `gpt-5.6-sol` |
+| `security` | `auto` | `opus` | `gpt-5.6-sol` |
+| `frontend` | `auto` | `sonnet` | `gpt-5.6-terra` |
+| `performance` | `auto` | `opus` | `gpt-5.6-sol` |
+| `previous` | `auto` | `haiku` | `gpt-5.6-luna` |
+
+Режимы: `always` — каждый раз, `auto` — только по применимости, `off` — не запускать. Неизвестную модель замени default конкретного агента и добавь warning.
+
+## Вопросы
+
+Когда нужен блокирующий вопрос:
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 2–3 вариантами и остановись.
+- Codex exec/non-interactive: не читай stdin; верни `blocked: нужен план или решение пользователя`.
+
+## Подготовить контекст
+
+1. Выбери `$PLAN_FILE` только в `docs/plans/`: явный путь, однозначное совпадение или самый новый файл при словах «последний план». Без готового плана остановись.
+2. Прочитай план целиком и вычисли SHA-256 его байтов как `$PLAN_SHA256` доступной read-only командой.
+3. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и front matter плана настолько, чтобы выбрать проверки, но не делай собственное ревью.
+4. Определи `$BUSINESS_FILES`: используй относящиеся к задаче пути из `sources.business`; для старого плана выбери только применимые карточки через `docs/business.md`. Если подходящих нет — `none`.
+5. Определи `$REFERENCE_FILES`: используй применимые пути из `sources.references`; для старого плана выбери только карточки затронутых компонентов через `docs/references.md`. Не загружай весь каталог.
+6. Определи `$RESEARCH_FILE` из `sources.research` или `none`.
+7. Сформируй краткий `$PLAN_CONTEXT`: исходная задача, scope, критерии готовности, затронутые компоненты, подтверждённые решения и пути к документам. Если задача неизвестна, напиши `task: unknown`.
+8. Определи `$PREVIOUS_REVIEW` и `$PREVIOUS_FIX`. Явные пути имеют приоритет. Иначе используй последний review для того же канонического пути только когда его `plan_sha256` равен текущему SHA-256 или `after_sha256` связанного fix равен текущему SHA-256. Несвязанную историю не подмешивай.
+
+## Выбрать проверки
+
+- `requirements`, `rules`, `architecture`, `feasibility`, `execution`, `verification` запускай по `always/auto/off`; их default `always`.
+- `api` в auto включай для endpoint, handler, DTO, GraphQL/RPC, events, queues, webhooks и внешних интеграций.
+- `database` в auto включай для схем, моделей хранения, SQL, миграций, индексов и транзакций.
+- `security` в auto включай для auth, permissions, внешнего ввода, файлов, сети, секретов, криптографии и чувствительных данных.
+- `frontend` в auto включай для UI-компонентов, стилей, клиентских маршрутов и пользовательского состояния.
+- `performance` в auto включай для запросов, пакетной обработки, кешей, конкурентности, памяти и горячих путей.
+- `previous` в auto включай только при непустой связанной цепочке.
+- Прямые «без X», «включи X» и разовая модель важнее settings.
+
+Запиши skipped-проверки и причины. Forced-проверка запускается даже если auto-критерий не найден; агент может вернуть `not_applicable`.
+
+## Запустить агентов
+
+Запусти все выбранные проверки одним параллельным пакетом через установленных нативных агентов:
+
+- Claude Code: custom agent `eda-plan-review-<check>` через `Agent` tool с настроенной моделью.
+- Codex: custom agent `eda-plan-review-<check>` через `spawn_agent` или точный аналог с настроенной моделью.
+
+Если нативные packaged-агенты недоступны, остановись. Не используй generic-субагентов, `codex exec`, `claude -p` или основной агент как fallback.
+
+В task-сообщение передавай только рабочую директорию, `PLAN_FILE`, `PLAN_SHA256`, `BUSINESS_FILES`, `REFERENCE_FILES`, `RESEARCH_FILE`, `PREVIOUS_REVIEW`, `PREVIOUS_FIX`, `MODEL` и `$PLAN_CONTEXT`. Полная семантика проверки хранится в prompt агента.
+
+## Проверить ответы
+
+Для каждого ответа проверь:
+
+- один YAML-блок и допустимый `status`;
+- `check` совпадает с ролью, `model` — с фактической моделью;
+- `findings` и `prior_findings` — массивы;
+- у каждого finding есть fingerprint, severity, recommendation, plan_location, problem, evidence, impact, fix, acceptance;
+- `blocked` содержит question; `not_applicable` не содержит findings.
+
+Невалидного или упавшего агента один раз повтори на той же модели с указанием только нарушения контракта. Повторный сбой любой выбранной проверки блокирует всё ревью; итоговый файл не сохраняй.
+
+## Агрегировать findings
+
+1. Подтверди evidence точечным чтением указанных файлов. Не добавляй самостоятельные domain-находки.
+2. Отклони недоказанное, вкусовое, уже закрытое, выходящее за scope или противоречащее подтверждённому решению. Существенные отклонения сохрани с fingerprint и причиной.
+3. Объедини findings с одной первопричиной и одной правкой, сохранив все checks и evidence.
+4. Для совпадающего fingerprint сохрани прежний ID. Новому finding дай следующий свободный `PR-NNN`; номер не переиспользуй.
+5. Статусы `waived` сохраняй без повторного открытия, пока нет нового evidence. Required нельзя сделать waived без явного решения пользователя, меняющего исходное требование.
+6. В итог включай только открытые required/optional findings и состояния прошлых ID.
+
+## Выставить score и gate
+
+Score выставляет главный агент экспертно после обработки всех агентов. Не усредняй оценки, не используй формулу вычетов и не проси агентов ставить score.
+
+- `95–100`: обязательных findings нет, план исполним.
+- `80–94`: остаётся required medium или несколько существенных optional.
+- `60–79`: есть required high.
+- ниже `60`: есть critical или требуется серьёзное перепланирование.
+- при отсутствии открытых findings score равен `100`.
+- если состояния open/resolved/regressed/waived не изменились относительно предыдущего review, score не меняй.
+- каждое изменение score объясни закрытыми, новыми или регрессировавшими ID.
+
+Статус `ready` ставь только когда нет открытых required и `$SCORE >= $THRESHOLD`. Иначе статус `changes-required`. Не выдумывай finding только ради достижения threshold.
+
+## Сохранить review
+
+После успешной обработки всех выбранных агентов создай `docs/plan-reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+
+```markdown
+---
+plan: <docs/plans/...>
+plan_sha256: <sha256>
+previous_review: <path | none>
+previous_fix: <path | none>
+score: <0..100>
+threshold: <1..100>
+status: <ready | changes-required>
+date: <YYYY-MM-DD HH:MM>
+checks:
+  - name: <check>
+    model: <model>
+    status: <completed | skipped>
+    reason: <применимость или причина пропуска>
+---
+
+# Ревью плана: <название>
+
+## Оценка
+**<score>/100.** <экспертное объяснение и изменение относительно предыдущего score>
+
+## Покрытие
+- **Completed:** <checks и модели>
+- **Skipped:** <checks и причины>
+- **Warnings:** <warnings или «нет»>
+
+## Состояние предыдущих findings
+| ID | Статус | Доказательство |
+|---|---|---|
+
+## Findings
+
+### PR-001. <заголовок>
+- **Checks:** <роли>
+- **Severity:** <critical | high | medium | low>
+- **Recommendation:** <required | optional>
+- **Fingerprint:** `<fingerprint>`
+- **Место в плане:** <раздел или задача>
+- **Проблема:** <что не так>
+- **Доказательства:** <evidence>
+- **Риск:** <impact>
+- **Исправление:** <fix>
+- **Приёмка:** <acceptance>
+
+## Отклонённые предложения
+- `<fingerprint>` — <причина или «нет»>
+
+## Gate
+- **Required open:** <ID или «нет»>
+- **Optional open:** <ID или «нет»>
+- **Результат:** <ready | changes-required>
+```
+
+Review содержит только проблемы и техническое покрытие, без похвалы и длинного пересказа плана.
+
+## Финал
+
+Сообщи путь, status, score/threshold, число required/optional, completed/skipped и previous chain. При `changes-required` предложи `eda-plan-review-fix`; при `ready` — `eda-plan-execute` или возврат вызывающему `eda-plan-polish`.
+
+## Чего НЕ делать
+
+- Править план, код, настройки или документацию проекта.
+- Запускать тесты, lint, build, typecheck, серверы, миграции, браузерные проверки или API-запросы.
+- Выполнять специализированную роль главным агентом.
+- Запускать другой CLI или generic-fallback.
+- Усреднять score агентов, менять score без изменения findings или переоткрывать waived без нового evidence.
+- Сохранять итог после повторного сбоя выбранного агента.

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

@@ -0,0 +1,105 @@
+---
+name: eda-plan-review-fix
+description: 'Исправляет готовый план по сохранённому plan-review и фиксирует решения по findings.'
+---
+
+# Скил: Исправитель плана по ревью (eda-plan-review-fix)
+
+Применяй подтверждённые findings из `docs/plan-reviews/` только к связанному плану. Не делай новое ревью: твой контракт — точечно изменить основные разделы плана и сохранить проверяемую цепочку SHA-256.
+
+## Вход из сообщения пользователя
+
+Разбери путь или название review, «последнее ревью», режим `apply-optional`, ограничения и явные решения по ID. Если вход однозначен, продолжай без вопроса. При нескольких равных review или противоречивом target используй `AskUserQuestion`.
+
+## Режимы
+
+Обычный режим:
+
+- все required применяй без дополнительного подтверждения;
+- optional собери в один-два раунда `AskUserQuestion`;
+- waived и отклонённые findings не применяй.
+
+`apply-optional`:
+
+- все required применяй;
+- optional применяй, если правка конкретна, обратима, остаётся в scope и улучшает исполнимость;
+- иначе пометь optional как `waived` с конкретной причиной;
+- продуктовое решение, конфликт с business/rules/architecture или расширение scope всё равно требует пользователя.
+
+## Вопросы
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с вариантами и остановись.
+- Codex exec/non-interactive: не читай stdin; верни `blocked: нужен ответ пользователя` до любых рискованных правок.
+
+## Правила
+
+1. Работай только с review из `docs/plan-reviews/` и его `plan` из `docs/plans/`.
+2. Вычисли SHA-256 текущего плана до правок. Он обязан совпадать с `plan_sha256` review. При несовпадении остановись: review устарел, нужен новый `eda-plan-review`.
+3. Перед правкой прочитай план, `docs/rules.md`, `docs/arch.md`, только применимые `sources.business`, `sources.references` и `sources.research`.
+4. Не переоценивай findings и не создавай новые. Если finding недоказан, противоречит контексту или непонятен, остановись и попроси повторное review либо решение пользователя.
+5. Required нельзя автономно отклонить или сделать waived.
+6. Встраивай правки в `Целевой алгоритм`, `Контракты реализации`, фазы, тесты, логирование и эксплуатацию. Не создавай длинный журнал ревью в теле плана.
+7. Сохраняй ID задач и прямые зависимости; при структурной правке актуализируй все ссылки.
+8. Не правь код, конфиги, зависимости, миграции или другие документы. Не запускай проверки проекта.
+
+## Применить findings
+
+1. Прочитай раздел `Gate`, все открытые findings и `Отклонённые предложения`.
+2. До редактирования собери все вопросы и optional-решения. Не делай частичную правку до ответа на блокирующий вопрос.
+3. Примени required и выбранные optional одним связным изменением плана.
+4. Для каждого ID зафиксируй `applied` или `waived`; не меняй fingerprint.
+5. Заранее определи `$FIX_FILE`, обнови front matter плана полями `status`, `plan_review` и `plan_review_fix`, затем вычисли окончательный SHA-256 как `$AFTER_SHA256`.
+6. Если обязательные правки были, но итоговый SHA-256 не изменился, остановись `blocked: fix не изменил план` и не выдавай успех.
+
+После успешного изменения:
+
+- если review был `changes-required`, установи в front matter плана `status: meta-reviewed`;
+- установи `plan_review: <REVIEW_FILE>` и `plan_review_fix: <FIX_FILE>` до вычисления after SHA-256 и записи отчёта;
+- не ставь `status: reviewed`: это может сделать только подтверждающий review с gate `ready`.
+
+## Сохранить fix-отчёт
+
+Создай `docs/plan-review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+
+```markdown
+---
+review: <docs/plan-reviews/...>
+plan: <docs/plans/...>
+before_sha256: <sha256 из review>
+after_sha256: <sha256 после изменения>
+status: done
+date: <YYYY-MM-DD HH:MM>
+---
+
+# Исправления плана по ревью: <название>
+
+## Применённые findings
+| ID | Что изменено | Раздел плана | Статус |
+|---|---|---|---|
+| PR-001 | <конкретная правка> | <раздел> | applied |
+
+## Waived optional
+| ID | Причина | Новые доказательства для пересмотра |
+|---|---|---|
+
+## Цепочка
+- **Before SHA-256:** `<hash>`
+- **After SHA-256:** `<hash>`
+- **Нужен подтверждающий review:** да
+```
+
+После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком waived ID. Не дублируй раздел при повторном продолжении того же запуска.
+
+## Финал
+
+Сообщи пути к plan/review/fix, before/after SHA-256, applied/waived, оставшиеся блокеры и что изменения не закоммичены. Следующий шаг — `eda-plan-review` для подтверждения или возврат вызывающему `eda-plan-polish`.
+
+## Чего НЕ делать
+
+- Делать новое ревью или выставлять score.
+- Исправлять код или файлы вне выбранного плана, review и fix-отчёта.
+- Применять stale review к другому SHA-256.
+- Молча отклонять required или продуктовый конфликт.
+- Добавлять журнал итераций в тело плана.
+- Коммитить, запускать тесты, lint, build, typecheck, миграции или другой CLI.

package/skills/eda-prepare-ai/SKILL.md

@@ -15,7 +15,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 1. **Не правишь код.** Меняй только `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/*.md`, `AGENTS.md` и `CLAUDE.md`; не ставь пакеты и не меняй конфиги.
 2. **Опирайся на проект.** Читай код, структуру, зависимости, команды, тесты, инфраструктуру, git-историю и существующие документы. Не генерируй универсальный шаблон.
-3. **Разделяй документы по назначению.** `docs/rules.md` задаёт проверяемые обязанности и запреты при работе над проектом; `docs/arch.md` фиксирует устройство, границы и владение ответственностью; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
+3. **Разделяй документы по назначению.** Business-карточки задают подтверждённое целевое поведение и редактируются только через `eda-business`; `docs/rules.md` задаёт проверяемые обязанности и запреты при работе над проектом; `docs/arch.md` фиксирует устройство, границы и владение ответственностью; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
 4. **Обновляй осмысленно.** Сохраняй актуальное, исправляй неверное, удаляй устаревшее и перестраивай документ настолько сильно, насколько требует проект. Не спрашивай отдельно, что делать с каждым существующим файлом.
 5. **Не выдавай предположение за факт.** Значимые неподтверждённые архитектурные решения предложи пользователю; после выбора зафиксируй принятый вариант.
 6. **Предлагай экстремальный профиль проверок.** Не ограничивайся уже установленными командами или базовыми lint/test. Пройди весь каталог ниже, предложи все применимые проверки и объясни каждое `не применимо`; в документацию переноси только подтверждённые правила.
@@ -42,7 +42,9 @@ description: 'Готовит проект к работе с AI: проекти
 
 ### 2. Прочитать существующую документацию
 
-Прочитай `docs/rules.md`, `docs/arch.md`, `docs/references.md`, карточки из `docs/references/`, `AGENTS.md` и `CLAUDE.md`, если они есть. Также прочитай релевантные документы из `docs/`, на которые они ссылаются. Найди дубли, противоречия и устаревшие сведения.
+Прочитай `docs/rules.md`, `docs/arch.md`, `docs/references.md`, карточки из `docs/references/`, `AGENTS.md` и `CLAUDE.md`, если они есть. Если существует `docs/business.md`, сначала определи область текущей подготовки, затем по описаниям выбери относящиеся к ней карточки; при полном bootstrap весь описанный продуктовый контекст может быть применим. Business-карточки используй как требования к целевому поведению, но не редактируй. Также прочитай релевантные документы из `docs/`, на которые они ссылаются. Найди дубли, противоречия и устаревшие сведения.
+
+Если текущая задача подготовки противоречит business-карточке, остановись, покажи конфликт и через `AskUserQuestion` спроси: изменить задачу подготовки или сначала пересогласовать правило через `eda-business`. Не переноси противоречие молча в архитектуру или rules.
 
 ### 3. Определить область обновления
 
@@ -222,6 +224,7 @@ description: 'Готовит проект к работе с AI: проекти
 Сделай `AGENTS.md` короткой входной картой для AI-агента. В нём должны быть:
 - краткое описание проекта;
 - ссылки на `docs/rules.md`, `docs/arch.md`, `docs/references.md` и другие действительно обязательные документы из `docs/`;
+- ссылка на `docs/business.md`, если индекс существует, с требованием выбирать по нему только карточки, применимые к текущей задаче;
 - требование прочитать их и следовать им до работы над проектом.
 
 Не копируй в `AGENTS.md` правила, архитектуру, полное дерево папок, длинное описание стека, справочник команд или содержимое README. Если старый файл раздут или построен иначе, сократи или перестрой его целиком.
@@ -237,6 +240,7 @@ description: 'Готовит проект к работе с AI: проекти
 - каждое правило задаёт проверяемое действие или запрет, а архитектурные границы не продублированы в форме императива;
 - `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без повторения правил;
 - `docs/references.md` ссылается на все актуальные карточки и не содержит самих примеров;
+- существующий `docs/business.md` учтён как вход, не изменён этим скилом и указан в `AGENTS.md`;
 - каждая карточка самодостаточна, содержит законченный пример кода и не содержит ссылок или неподтверждённых элементов;
 - для нового проекта без нескольких устойчивых реализаций не созданы выдуманные reference-карточки;
 - `AGENTS.md` остаётся коротким и ведёт к обязательным документам;
@@ -255,6 +259,7 @@ description: 'Готовит проект к работе с AI: проекти
 ## Чего НЕ делать
 
 - Править файлы вне разрешённого набора проектной документации.
+- Создавать или обновлять `docs/business.md` и `docs/business/*.md` вместо `eda-business`.
 - Спрашивать, какие документы обновлять, если пользователь их не назвал: по умолчанию обновляется весь набор.
 - Просить выбрать режим перезаписи для каждого существующего файла.
 - Ограничивать правила фиксированным количеством или разбавлять их пояснениями и предложениями.

package/skills/eda-review/SKILL.md

@@ -13,11 +13,11 @@ description: 'Проводит полное read-only ревью diff, ветк
 
 Если входа достаточно, продолжай без вопроса. Без аргументов ревьюй незакоммиченный `git diff HEAD`. Ссылка на PR/MR задаёт target однозначно. Если пользователь дал только корень удалённого репозитория, обязательно попроси указать PR/MR, ветку, коммит или файлы; весь репозиторий и последний PR автоматически не выбирай.
 
-Разовые указания вида «без performance», «включи database», «architecture на opus» или «tests на gpt-5.6-sol» важнее `docs/settings.yaml` и действуют только на текущий запуск.
+Разовые указания вида «без performance», «без business», «включи database», «включи business», «architecture на opus» или «tests на gpt-5.6-sol» важнее `docs/settings.yaml` и действуют только на текущий запуск.
 
 ## Настройки
 
-Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 2`. Используй `review.agents.<check>.mode` и `review.agents.<check>.model.<platform>`. Если файла нет или версия отличается, используй defaults и добавь предупреждение; настройки v1 не применяй.
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`. Используй `review.agents.<check>.mode` и `review.agents.<check>.model.<platform>`. Если файла нет или версия отличается, используй defaults и добавь предупреждение; старые настройки не применяй.
 
 Допустимые режимы:
 
@@ -27,7 +27,7 @@ description: 'Проводит полное read-only ревью diff, ветк
 
 Допустимые модели по умолчанию: Claude Code — `haiku`, `sonnet`, `opus`; Codex — `gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`. Неизвестное или отсутствующее значение замени default-значением конкретного агента и добавь предупреждение в покрытие.
 
-Если `version: 2` существует, но раздела `review.agents` нет, используй defaults ниже. Устаревшие поля `review.strict`, `review.include_code_quality` и раздел `review-check` не применяй; добавь предупреждение с просьбой перенести настройки вручную. Существующий файл настроек не переписывай.
+Если `version: 3` существует, но раздела `review.agents` нет, используй defaults ниже и добавь предупреждение. Устаревшие поля `review.strict`, `review.include_code_quality` и раздел `review-check` не применяй. Существующий файл настроек не переписывай.
 
 | Проверка | Default mode | Claude | Codex |
 |---|---|---|---|
@@ -35,6 +35,7 @@ description: 'Проводит полное read-only ревью diff, ветк
 | `architecture` | `auto` | `opus` | `gpt-5.6-sol` |
 | `rules` | `always` | `haiku` | `gpt-5.6-luna` |
 | `references` | `auto` | `haiku` | `gpt-5.6-luna` |
+| `business` | `auto` | `sonnet` | `gpt-5.6-terra` |
 | `plan_alignment` | `auto` | `sonnet` | `gpt-5.6-terra` |
 | `code_quality` | `always` | `sonnet` | `gpt-5.6-terra` |
 | `tests` | `always` | `sonnet` | `gpt-5.6-terra` |
@@ -60,9 +61,10 @@ description: 'Проводит полное read-only ревью diff, ветк
 2. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и сам target настолько, чтобы выбрать проверки и передать агентам точный контекст. На этом шаге не делай собственное code review.
 3. Определи `$PLAN_FILE`. Если его нет, используй `none` и не пытайся восстановить последний план наугад.
 4. Определи `$REFERENCE_FILES`: если план содержит `sources.references`, используй их; иначе через `docs/references.md` выбери только применимые карточки для компонентов target. Если карточек нет, используй `none`.
-5. Сформируй краткий `$REVIEW_CONTEXT`: тип target, base, изменённые области, применимые документы и явные решения пользователя. Не включай в него domain-инструкции агентов.
+5. Определи `$BUSINESS_FILES`: сначала установи исходную задачу и фактически затронутое пользовательское или доменное поведение по текущему сообщению, плану и target. Если план содержит `sources.business`, используй только относящиеся к этому поведению пути; иначе прочитай `docs/business.md` и по описаниям выбери только применимые карточки. Если индекс отсутствует, подходящих карточек нет или изменения не затрагивают бизнес-поведение, используй `none`. Не загружай все карточки только потому, что индекс существует.
+6. Сформируй краткий `$REVIEW_CONTEXT`: тип target, base, исходную задачу из текущего сообщения, плана, PR/MR title/body или явно связанного issue/артефакта, изменённые области, применимые документы и явные решения пользователя. Если надёжного описания задачи нет, явно напиши `task: unknown`, а не восстанавливай намерение по догадке. Не включай в контекст domain-инструкции агентов.
 
-Приоритет решений: подтверждённое решение пользователя → действующие правила → архитектура → применимые карточки.
+Текущая задача задаёт область и намерение изменений. Применимые business-карточки проверяют затронутое поведение, но не расширяют target. Если задача явно меняет правило карточки, это возможная рассинхронизация business-документации, которую должен классифицировать `eda-review-business`, а не основание молча объявить реализацию неверной.
 
 ## Выбрать проверки
 
@@ -71,6 +73,7 @@ description: 'Проводит полное read-only ревью diff, ветк
 - `always` включай всегда, `off` всегда пропускай.
 - `architecture` в `auto` включай при изменении границ модулей, зависимостей, публичных контрактов или разделения ответственности.
 - `references` включай только при непустом `$REFERENCE_FILES`.
+- `business` включай только при непустом `$BUSINESS_FILES` и изменении пользовательского или доменного поведения.
 - `plan_alignment` включай только при непустом `$PLAN_FILE`.
 - `security` включай для auth, permissions, внешнего ввода, файлов, сети, секретов, криптографии и других границ доверия.
 - `performance` включай для запросов, пакетной обработки, кешей, конкурентности, памяти или горячих путей.
@@ -100,6 +103,7 @@ description: 'Проводит полное read-only ревью diff, ветк
 TARGET: <target>
 PLAN_FILE: <path | none>
 REFERENCE_FILES: <paths | none>
+BUSINESS_FILES: <paths | none>
 MODEL: <фактически выбранная модель>
 REVIEW_CONTEXT: <краткий общий контекст>
 
@@ -166,6 +170,10 @@ checks:
 
 <Только подтверждённые plan_alignment-проблемы. Если плана нет: «Проверка плана пропущена: план не указан и не найден.»>
 
+## Проблемы бизнес-логики
+
+<Только подтверждённые business-проблемы: нарушение карточки или рассинхронизация карточки с явно изменившей правило задачей. Если проверка не запускалась или проблем нет — коротко укажи это.>
+
 ## Проблемы в коде
 
 ### 1. <короткий заголовок>

package/skills/eda-roadmap/SKILL.md

@@ -21,8 +21,9 @@ description: 'Создаёт продуктовый или технически
 4. **Каждая задача короткая, но однозначная.** Читатель должен понять границы задачи без дополнительного созвона.
 5. **Можно чуть подробнее, если это снимает двусмысленность.** Допускается одно короткое описание: что должно появиться, для кого и какой результат ожидается.
 6. **Не выдумывай обязательства.** Если пользователь дал только направление, формулируй разумный черновик и явно помечай предположения.
-7. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, чтобы не противоречить зафиксированным правилам и архитектурным ограничениям.
-8. **Существующие roadmap-файлы учитывай только при явной необходимости.** Если пользователь просит продолжить, обновить или не дублировать прошлый roadmap — прочитай релевантные файлы из `docs/roadmaps/`.
+7. **Прочитай рамку проекта.** Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Сначала определи тему и границы текущего roadmap; затем через `docs/business.md` выбери только карточки, чьё описание прямо относится к этой теме. Если подходящих карточек нет, продолжай без business-контекста.
+8. **Не разрешай конфликт молча.** Если задача противоречит применимой business-карточке, остановись, покажи конкретное противоречие и через `AskUserQuestion` спроси: изменить задачу roadmap или сначала пересогласовать правило через `eda-business`.
+9. **Существующие roadmap-файлы учитывай только при явной необходимости.** Если пользователь просит продолжить, обновить или не дублировать прошлый roadmap — прочитай релевантные файлы из `docs/roadmaps/`.
 
 ## Интерактивные вопросы
 
@@ -46,7 +47,7 @@ description: 'Создаёт продуктовый или технически
 
 ### 2. Собрать минимальный контекст
 
-Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Не делай глубокое исследование кода, если пользователь прямо не просит привязать roadmap к текущему состоянию проекта.
+Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Определи продуктовую тему roadmap, затем прочитай `docs/business.md`, если индекс существует, и только применимые по описанию карточки. Business-карточки уточняют требования затронутой темы, но не расширяют roadmap на другие домены. Не делай глубокое исследование кода, если пользователь прямо не просит привязать roadmap к текущему состоянию проекта.
 
 Если пользователь просит продолжить или обновить существующий roadmap:
 - найди релевантный файл по указанному пути или теме;
@@ -73,6 +74,7 @@ status: draft
 sources:
   rules: <путь или —>
   arch: <путь или —>
+  business: [<пути к применимым карточкам или пусто>]
   previous_roadmap: <путь или —>
 ---
 
@@ -106,6 +108,7 @@ Quality gate перед сохранением:
 - есть ровно один основной список задач в разделе `Задачи`;
 - каждая задача имеет короткое название и понятное описание;
 - задачи не содержат деталей реализации: файлов, библиотек, API, команд, миграций, схем таблиц, тестовых стратегий;
+- `sources.business` содержит только карточки, применимые к теме roadmap, либо пустой список;
 - roadmap можно использовать как вход для `eda-explore` или `eda-plan`, но сам он не является исследованием или планом реализации.
 
 ### 5. Финал

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

@@ -11,7 +11,7 @@ description: 'Публикует готовое ревью из `docs/reviews/`
 
 Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настройки.
 
-Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `send-review.close_previous_reviews: false`.
+Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `send-review.close_previous_reviews: false`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|