@gian-tiaga/eda 1.0.5 → 2.1.0

package/skills/eda-polish/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: eda-polish
-description: 'Итеративно ревьюит и исправляет изменения до заданной оценки качества.'
+description: 'Итеративно ревьюит и исправляет изменения до чистого результата и заданной оценки качества.'
 ---
 
 # Скил: Полировка изменений (eda-polish)
 
-Оркестрируй цикл `eda-review` → `eda-fix-by-review apply-optional` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат.
-В начале каждой итерации запускай полное `eda-review` целевого изменения.
+Оркестрируй цикл `eda-review` → `eda-fix-by-review` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат. В начале каждой итерации запускай полное `eda-review` целевого изменения.
 
 ## Вход из сообщения пользователя
 
@@ -16,12 +15,12 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Правила
 
-1. Каждый вызов `eda-review` и `eda-fix-by-review apply-optional` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
+1. Каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
 2. Если нативные субагенты недоступны, остановись; не заменяй шаги CLI-процессами.
-3. Сравнивай порог только со `score` полного ревью со статусом `reviewed` или `reviewed-with-warnings`.
-4. Все пункты «править обязательно» исправь. Для каждого optional-пункта fix-агент сам решает, применять ли его, и сохраняет причины отклонения, чтобы следующие ревьюеры не повторяли решение без новых аргументов.
+3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean`, ноль находок и `score >= threshold`.
+4. Любая находка обязательно исправляется независимо от score. Порог не превращает найденную проблему в допустимую.
 5. Не коммить и не отправляй ревью.
-6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, отсутствии применимых замечаний ниже порога или если score не растёт два круга подряд.
+6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, неизменном наборе находок один полный круг или достижении лимита.
 
 ## Вопросы
 
@@ -29,53 +28,42 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Цикл
 
-Сформируй `$TARGET_CONTEXT`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: номер итерации, review file, score, fix report и причина продолжения.
+Сформируй `$TARGET_CONTEXT`, `$THRESHOLD`, `$LIMIT` и журнал: номер итерации, review file, result, score, список находок, fix report и причина продолжения.
 
 Для каждой итерации:
 
-1. Запусти отдельного субагента с задачей:
+1. Запусти отдельного субагента:
 
    ```text
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
    Overrides проверок и моделей: <из запроса | none>.
-   Верни путь к файлу, status, score и coverage.
+   Верни путь к файлу, status, result, score, находки и coverage.
    ```
 
-2. Если review остановился из-за обязательного агента, останови весь цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён и не блокирует цикл.
-3. Если `score >= threshold`, заверши успешно.
-4. Если score ниже порога, прочитай рекомендации. Если обязательных и optional-пунктов нет, остановись `blocked: нет применимых замечаний для повышения оценки`.
-5. Запусти отдельного субагента:
+2. Если review остановился из-за обязательного агента, останови цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён.
+3. Если `result: clean`, находок нет и `score >= threshold`, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
+4. Если находки есть, запусти отдельного субагента:
 
    ```text
-   Используй eda-fix-by-review apply-optional для <REVIEW_FILE>.
-   Примени все обязательные замечания. По каждому optional сам реши, применять ли его; отклонённые решения сохрани с причиной.
+   Используй eda-fix-by-review для <REVIEW_FILE>.
+   Примени все находки минимальными достаточными правками и выполни проверки.
    Верни путь к fix-отчёту и результат проверок.
    ```
 
-6. При успешных исправлениях начни следующую итерацию с новым полным `eda-review`.
+5. После успешных исправлений начни новую итерацию с полным `eda-review`.
 
-Если score не растёт два проверенных круга подряд, остановись раньше лимита. Если достигнут лимит, не скрывай незавершённую сходимость.
+Если после полного круга набор находок не изменился, остановись раньше лимита с конкретными оставшимися проблемами. При достижении лимита не скрывай незавершённую сходимость. Состояние `clean` со score ниже threshold является несогласованным с контрактом `eda-review`: при отсутствии находок score должен быть `100`; остановись как на ошибке контракта.
 
 ## Финал
 
-Сообщи:
-
-- результат: достигнут порог, достигнут лимит, blocked, нет применимых замечаний или score не растёт;
-- итоговую оценку и порог;
-- количество итераций;
-- последний review file и fix report;
-- предупреждения coverage, если они были;
-- что изменения не закоммичены.
-
-При успехе предложи `eda-commit`. При неуспехе назови конкретный блокер или оставшиеся замечания.
+Сообщи результат, итоговый result и score, порог, число итераций, последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
 
 ## Чего НЕ делать
 
 - Делать ревью или исправления основным агентом.
 - Запускать отдельный этап проверки готового ревью.
-- Сравнивать порог с неполным или заблокированным ревью.
-- Механически применять все optional-пункты.
-- Терять причины отклонённых optional-решений.
+- Считать цикл успешным только по score при наличии находок.
+- Выбирать или отклонять принятые находки.
 - Переписывать `docs/settings.yaml`, правила или архитектуру ради score.
 - Коммитить, пушить или отправлять ревью.

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: <краткий общий контекст>
 
@@ -110,7 +114,7 @@ REVIEW_CONTEXT: <краткий общий контекст>
 
 ## Проверить ответы и обработать сбои
 
-Проверь для каждого ответа `status`, `check`, фактически запрошенный `model` и структуру `findings`. Несовпадение модели считай ошибкой контракта. Находка без конкретного риска и доказательства не подтверждена.
+Проверь для каждого ответа `status`, `check`, фактически запрошенный `model` и структуру `находки`. Несовпадение модели считай ошибкой контракта. Каждая находка означает дефект, который обязательно исправить. Находка без точного места, конкретного достижимого риска, доказательства и проверяемого способа исправления не подтверждена.
 
 - При `blocked`, неверном YAML или отсутствующих обязательных полях один раз повтори того же агента на той же модели с исходным контекстом и описанием ошибки формата.
 - `completed` означает успешно выполненную проверку. `not_applicable` перенеси в skipped с причиной и не повторяй.
@@ -124,9 +128,11 @@ REVIEW_CONTEXT: <краткий общий контекст>
 
 1. Проверь находки по указанным evidence и отклони неподтверждённые.
 2. Объедини дубли разных агентов в один пункт, сохранив все полезные доказательства.
-3. Распредели проблемы по тяжести и рекомендации `required` или `optional`.
-4. Сам выставь итоговый `score` от 0 до 100 по серьёзности, вероятности, влиянию и общему качеству реализации. Не используй фиксированные вычеты, среднее или минимум оценок агентов. Добавь короткое обоснование числа.
-5. Не выполняй дополнительное самостоятельное ревью и не добавляй новые domain-находки от себя.
+3. Оставь только конкретные ошибки, нарушения контрактов и существенные неточности, которые нельзя безопасно игнорировать. Косметические улучшения, вкусовой рефакторинг, спекулятивное усиление, необязательные тесты, документацию и оптимизации отклони, а не превращай в находку.
+4. Для каждой принятой находки проверь точное место, доказательство, практическое влияние, минимальное исправление и способ проверки. Если хотя бы одного элемента нет, отклони находку.
+5. Сам выставь итоговый `score` от 0 до 100 по серьёзности, вероятности, влиянию и общему качеству реализации. Не используй фиксированные вычеты, среднее или минимум оценок агентов. Ориентир: `100` — находок нет; `95–99` — только low; `80–94` — medium или несколько low; `60–79` — high; ниже `60` — critical или нужна существенная переработка. Любое снижение score связывай с принятыми находками; если находок нет, score равен `100`. Добавь короткое обоснование числа.
+6. Установи `result: clean`, только если находок нет; при любой находке используй `result: changes-required` независимо от score.
+7. Не выполняй дополнительное самостоятельное ревью и не добавляй новые domain-находки от себя.
 
 Ревью содержит только проблемы. Не перечисляй выполненную работу, похвалу и успешные проверки. Исключение — короткий технический раздел покрытия.
 
@@ -140,6 +146,7 @@ target: <что проверено>
 plan: <docs/plans/... | none>
 score: <0..100>
 status: <reviewed | reviewed-with-warnings>
+result: <clean | changes-required>
 date: <YYYY-MM-DD HH:MM>
 checks:
   - name: <check>
@@ -166,6 +173,10 @@ checks:
 
 <Только подтверждённые plan_alignment-проблемы. Если плана нет: «Проверка плана пропущена: план не указан и не найден.»>
 
+## Проблемы бизнес-логики
+
+<Только подтверждённые business-проблемы: нарушение карточки или рассинхронизация карточки с явно изменившей правило задачей. Если проверка не запускалась или проблем нет — коротко укажи это.>
+
 ## Проблемы в коде
 
 ### 1. <короткий заголовок>
@@ -176,29 +187,18 @@ checks:
 
 - **Тип:** <check>
 - **Тяжесть:** <critical | high | medium | low>
-- **Рекомендация:** <править обязательно | на усмотрение автора>
 - **Файлы:** `<path:line>`
 - **Что подтверждает проблему:** <evidence>
 - **Как исправить:** <общий подход и конкретные шаги>
 - **Тесты:** <что добавить или обновить>
 
-## Рекомендации
-
-### Править обязательно
-- <номера или «Нет»>
-
-### На усмотрение автора
-- <номера или «Нет»>
-
-### Не править
-- <только явно отклонённые пункты или «Нет»>
 ```
 
 Основная часть каждого замечания — главный ответ: простой язык, 1–3 коротких абзаца и контекст, понятный без чтения diff или плана. Файлы, строки, SQL, DTO и внутренние имена давай ниже в `Технические детали`.
 
 ## Финал
 
-Коротко сообщи путь к ревью, статус, score, количество обязательных и optional-проблем, completed/skipped/warnings. Предложи `eda-fix-by-review` для исправления или `eda-commit`, если результат приемлем.
+Коротко сообщи путь к ревью, status, result, score, количество находок, completed/skipped/warnings. При `changes-required` предложи `eda-fix-by-review`; при `clean` — `eda-commit`.
 
 ## Чего НЕ делать
 

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`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
@@ -53,9 +53,9 @@ description: 'Публикует готовое ревью из `docs/reviews/`
 ### 2. Выбрать ревью и что отправлять
 Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`), статус отправки (`comment`, `review-comment`, `approve`, `request-changes`) и указание закрыть или сохранить предыдущие ревью.
 
-Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации. Отсутствие статуса отправки само по себе не считается недостатком входа и не требует вопроса.
+Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: result, оценку и замечания. Отсутствие статуса отправки само по себе не считается недостатком входа и не требует вопроса.
 
-**Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5»), по обязательности («только обязательные» → раздел «Править обязательно»), по типу («только security» → замечания с этим `Тип`). Выбор влияет и на сводку, и на комментарии к строкам.
+**Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5») или по типу («только security» → замечания с этим `Тип`). У находок нет разных степеней обязательности: каждый отправляемый пункт требует исправления. Выбор влияет и на сводку, и на комментарии к строкам. Для старого формата отправляй только раздел `Править обязательно`; предложения из остальных групп отбрасывай.
 
 ### 3. Найти целевой PR
 Если номер PR указан в тексте пользователя — используй его. Иначе попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
@@ -73,7 +73,7 @@ Review отправляется всегда; здесь выбирается т
 | явно указано `comment` / `review-comment` | `COMMENT` | не задавать |
 | статус не указан | `COMMENT` | не задавать |
 
-`comment` и `review-comment` означают review без решения о принятии изменений (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. Явно приложенный или названный пользователем контекст текущего вызова учитывай наравне с текстом рядом со скиллом. Не выводи статус из score, раздела рекомендаций, не связанного с вызовом старого обсуждения или предыдущих запусков. Если в текущем контексте одновременно указаны несовместимые статусы и приоритет неясен — `AskUserQuestion` с тремя вариантами.
+`comment` и `review-comment` означают review без решения о принятии изменений (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. Явно приложенный или названный пользователем контекст текущего вызова учитывай наравне с текстом рядом со скиллом. Не выводи статус из result, score, старого обсуждения или предыдущих запусков. Если в текущем контексте одновременно указаны несовместимые статусы и приоритет неясен — `AskUserQuestion` с тремя вариантами.
 
 ### 5. Собрать сводку и комментарии к строкам
 Из выбранных пунктов собери две части.
@@ -84,12 +84,12 @@ Review отправляется всегда; здесь выбирается т
 ## Ревью: <заголовок>
 
 **Оценка:** N/100. <одно-два предложения почему>
+**Результат:** <clean | changes-required>
 
 <короткое резюме: что отправлено и общий вывод>
 
-### Рекомендации
-- **Править обязательно:** 1, 3, 5
-- **На усмотрение автора:** 2, 4
+### Замечания
+1. **[тип]** <краткая суть и требуемое исправление>
 
 ### Замечания вне diff
 1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
@@ -170,7 +170,7 @@ gh api graphql -f query='mutation($id: ID!) { resolveReviewThread(input: {thread
 - Делать само ревью или править замечания — это `eda-review` / `eda-fix-by-review`.
 - Отправлять всё одним обычным комментарием PR, когда строки можно привязать к diff — обычный комментарий только fallback при отсутствии diff.
 - Терять замечания вне diff — они идут в сводку отдельным разделом.
-- Выводить `approve` или `request-changes` из score, рекомендаций или не связанного с вызовом старого контекста — без явного статуса в контексте текущего вызова всегда `COMMENT`.
+- Выводить `approve` или `request-changes` из result, score или не связанного с вызовом старого контекста — без явного статуса в контексте текущего вызова всегда `COMMENT`.
 - Скрывать или резолвить чужие, ручные или не связанные с предыдущими отправками `eda-send-review` комментарии.
 - Закрывать предыдущие отправки до успешной публикации нового ревью.
 - Передавать тело через `-b "..."` со спецсимволами — только `--input` (Reviews API) или `--body-file` (fallback).