@gian-tiaga/eda 3.5.0 → 3.6.0

package/MIGRATION.md

@@ -87,6 +87,8 @@ docs/
 
 - **Удалены двенадцать агентов `eda-plan-review-*`.** Проверку плана целиком выполняет один субагент по фиксированному чек-листу. `eda update` стирает файлы этих агентов из `.claude/agents/` и `.codex/agents/`.
 - **Секция `plan-review.agents` больше не читается.** Начиная с 3.1.1 `eda update` находит её в готовом файле настроек и убирает вместе с другими устаревшими ключами — `review-check`, `review.strict`, `review.include_code_quality`. Дефолт `plan-review.threshold` — `100`, `plan-polish.limit` — `2`.
+- **У `eda-review` появился режим исполнения.** `review.execution` принимает `subagents` или `single`; default `subagents` сохраняет прежнее поведение. В `single` все выбранные проверки выполняет один review-runner, поэтому модели отдельных `review.agents` не применяются.
+- **У `eda-orhestra` появился режим исполнения.** `orhestra.execution` принимает `subagents`, `single` или `single_propagated`; default `subagents` сохраняет прежнее поведение. `single` выполняет верхние этапы текущим агентом, а `single_propagated` дополнительно передаёт `single` совместимым execute/review-этапам.
 - **У `eda-polish` больше нет порога.** Цикл завершается только при нуле находок и останавливается досрочно, если за круг число открытых находок не сократилось. Аргумент вида `args: "threshold 90 limit 2"` в шаге оркестратора `eda update` приводит к виду `args: "limit 2"`.
 - **Формат ревью дополнен.** У каждой находки появилось поле `repro` — чем проблема воспроизводится, — а в отчёт добавлен раздел «Отклонено» с причинами отклонения. `eda-fix-by-review` может отклонить находку, но только фактически неверную и с обоснованием в отчёте. Старые файлы ревью читаются как есть.
 

package/README.md

@@ -41,7 +41,7 @@ eda update-all ~/Code
 
 | Скил | Что делает | Куда складывает |
 |---|---|---|
-| `eda-orhestra` | Выполняет настраиваемую цепочку `eda-*`-скилов. Каждый этап запускает в отдельном субагенте с чистым контекстом, включая составные скилы и повторы QA-цикла. По умолчанию: план без проверок → полировка плана → выполнение → автономное ревью и исправления → ручные тесты. Если QA нашёл баг, оркестра запускает fix и повторяет только ручной тест. В `orhestra.steps` шаги можно переставлять, отключать и снабжать `args`. Не коммитит | Артефакты включённых скилов |
+| `eda-orhestra` | Выполняет настраиваемую цепочку `eda-*`-скилов. В `subagents` каждый этап получает чистый контекст, в `single` этапы выполняет текущий агент, а `single_propagated` дополнительно передаёт `single` в совместимые execute/review-этапы. По умолчанию: план без проверок → полировка плана → выполнение → автономное ревью и исправления → ручные тесты. Если QA нашёл баг, оркестра запускает fix и повторяет только ручной тест. В `orhestra.steps` шаги можно переставлять, отключать и снабжать `args`. Не коммитит | Артефакты включённых скилов |
 | `eda-aim` | Сначала через отдельного агента-планировщика согласует с человеком одну или несколько простых проверяемых целей, затем передаёт их агентам-исполнителям и повторяет работу до независимого подтверждения агентом-проверяющим. При необходимости использует установленные скилы в отдельных изолированных субагентах. В `automatic` отвечает на безопасные рабочие вопросы самостоятельно, в `manual` передаёт их человеку; режим задаётся через `aim.mode` или текущий вызов. Точный список новых целей человек подтверждает всегда | `docs/artifacts/aims/` и артефакты задействованных скилов |
 | `eda-new-project` | Помогает стартовать новый проект: собирает и согласует требования, функциональность и границы, ограничения и архитектурные драйверы, сравнивает варианты основного стека и фиксирует выбранные компоненты с актуальными стабильными версиями. Не проектирует архитектуру, правила, проверки, AI-скилы или MCP; сохраняет подтверждённый стартовый бриф и всегда без дополнительного вопроса запускает полный технический bootstrap через `eda-prepare-ai` | `docs/artifacts/project-starts/`, затем артефакты `eda-prepare-ai` |
 | `eda-business` | Совместно с человеком описывает целевое поведение проекта по тематическим карточкам: сложные темы фиксирует подробно, но без шума, соседних модулей и привязки к текущему коду. Может закрепить значимый механизм вроде JWT или серверного хранения токенов, но не язык, библиотеку или конкретную СУБД. `about` содержит лишь короткое описание проекта и основные возможности | `docs/business.md`, `docs/business/` |
@@ -58,10 +58,10 @@ eda update-all ~/Code
 | `eda-manual-test` | Делает ручную проверку после изменений. По умолчанию проверка полная: разбирает план или другой артефакт по разделам, дополняет его фактическим `git diff HEAD` и закрывает матрицу областей — API, база данных, консольные команды, интерфейс, алгоритмы, фон и интеграции, права и роли, конфигурация, логи, регрессии рядом. Область нельзя закрыть чтением кода или зелёными автотестами; незакрытая область даёт `blocked`. Быстрый smoke включается настройкой `manual-test.depth` или словом в запросе. Применимая business-карточка может добавить только относящийся к задаче инвариант или сценарий. Не правит код, не пишет автотесты и не коммитит | `docs/artifacts/manual-tests/` |
 | `eda-polish` | Оркестрирует доводку изменений: запускает полное `eda-review`, затем `eda-fix-by-review` и повторяет цикл до `clean` и отсутствия находок либо до лимита 5 итераций. Все находки исправляются, score остаётся справочным. Каждый шаг идёт в изолированном нативном субагенте. Не коммитит | `docs/artifacts/reviews/`, `docs/artifacts/review-fixes/` |
 | `eda-send-review` | На `sonnet` / `gpt-5.6-terra` отправляет ревью на GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Без явно указанного типа использует `comment`; `approve` и `request-changes` берёт только из контекста текущего вызова. По настройке может скрыть предыдущие сводки eda-send-review и зарезолвить их inline-треды. По умолчанию шлёт все пункты. Claude-модель закрепляется при установке; Codex-модель хранится как рекомендуемый будущий override | (комментарий в PR) |
-| `eda-commit` | Работает как лёгкий оркестратор одного `haiku` / `gpt-5.6-luna` агента: тот сам собирает git-контекст, делит выбранный состав на логические коммиты, пишет сообщения, точечно коммитит и выполняет явно заданные push/PR/merge-действия. С явным контекстом охватывает указанный состав; без контекста берёт все tracked-изменения и содержательные untracked-файлы, кроме очевидных кэшей и локальных служебных артефактов. В Claude Code сам оркестратор закреплён за `haiku`; в Codex остаётся на активной модели сессии из-за отсутствия per-skill override. При вероятном секрете агент блокируется до индексации затронутой группы. После любого push всегда возвращает ссылку — на существующий PR или на его создание — и спрашивает, создавать ли PR, если его нет. Если продолжение не задано, предлагает применимые варианты | (git, опционально GitHub PR) |
+| `eda-commit` | Работает как лёгкий оркестратор одного `sonnet` / `gpt-5.6-terra` агента: тот сам собирает git-контекст, делит выбранный состав на логические коммиты, пишет сообщения и тексты PR по исходному запросу и фактическому diff, точечно коммитит и выполняет явно заданные push/PR/merge-действия. Для PR использует шаблон репозитория, отражает все группы изменений и указывает только реально выполненные проверки. С явным контекстом охватывает указанный состав; без контекста берёт все tracked-изменения и содержательные untracked-файлы, кроме очевидных кэшей и локальных служебных артефактов. В Claude Code сам оркестратор закреплён за `sonnet`; в Codex остаётся на активной модели сессии из-за отсутствия per-skill override. При вероятном секрете агент блокируется до индексации затронутой группы. После любого push всегда возвращает ссылку — на существующий PR или на его создание — и спрашивает, создавать ли PR, если его нет. Если продолжение не задано, предлагает применимые варианты | (git, опционально GitHub PR) |
 | `eda-worktree` | На `haiku` / `gpt-5.6-luna` создаёт через пакетного агента git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
 | `eda-merge-worktree` | На `haiku` / `gpt-5.6-luna` мержит через пакетного агента ветку из соседнего worktree в текущую ветку. Принимает номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Worktree и ветку после merge не удаляет | (git) |
-| `eda-prepare-ai` | Выполняет технический bootstrap нового или существующего проекта: проектирует архитектуру, строгие правила и профиль инструментов, проходит полный каталог автоматических проверок, подбирает применимые AI-скилы, роли и MCP, затем создаёт AI-документацию. Подтверждённые требования, стек и архитектурные драйверы из `eda-new-project` принимает как обязательный вход и не переоткрывает без обнаруженного конфликта. Для пустого проекта не выдумывает reference-карточки и не выдаёт неустановленные инструменты за доступные | `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/`, `AGENTS.md`, `CLAUDE.md` |
+| `eda-prepare-ai` | Выполняет технический bootstrap нового или существующего проекта: проектирует архитектуру, строгие правила и профиль инструментов, проходит полный каталог автоматических проверок, подбирает применимые AI-скилы, роли и MCP, затем создаёт AI-документацию. Один факт хранит у одного владельца: `docs/rules.md` содержит рабочие действия, запреты и команды проверок, а `docs/arch.md` — топологию исходного кода, ownership, зависимости и потоки без рабочих инструкций. Подтверждённые требования, стек и архитектурные драйверы из `eda-new-project` принимает как обязательный вход и не переоткрывает без обнаруженного конфликта. Для пустого проекта не выдумывает reference-карточки и не выдаёт неустановленные инструменты за доступные | `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/`, `AGENTS.md`, `CLAUDE.md` |
 | `eda-discover-automations` | Проводит baseline gap-аудит проекта даже без истории, а при наличии анализирует ревью, планы и фиксы. Не ограничивает число предложений: проверяет тесты/e2e, стиль, статанализ, границы модулей, конфиги/IaC, API/БД, security/supply chain, performance, release, эксплуатацию, browser MCP и MCP стека. Для каждой идеи даёт команду, контур запуска и приоритет; ничего не внедряет | `docs/artifacts/automations/` |
 
 ### Структура `docs/`
@@ -95,7 +95,7 @@ eda update-all ~/Code
 | `eda-aim-planner` | `sonnet`, workspace-write | `gpt-5.6-terra`, workspace-write | Задаёт вопросы, формулирует простой проверяемый список и создаёт файл только после подтверждения человека |
 | `eda-aim-executor` | `opus`, workspace-write | `gpt-5.6-sol`, workspace-write | Выполняет назначенные пункты, при необходимости запрашивает установленные скилы для запуска в изолированных субагентах и дополняет общий журнал |
 | `eda-aim-verifier` | `opus`, workspace-write | `gpt-5.6-sol`, workspace-write | Независимо проверяет каждый критерий, отмечает подтверждённые цели и возвращает пробелы на новый круг выполнения |
-| `eda-commit-executor` | `haiku` | `gpt-5.6-luna` | Собирает git-контекст, выбирает заданный scope или все содержательные незакоммиченные изменения, делит их на логические коммиты и выполняет явно разрешённые push/PR/merge-действия |
+| `eda-commit-executor` | `sonnet` | `gpt-5.6-terra` | Собирает git-контекст, пишет сообщения коммитов и PR по запросу и фактическим изменениям, делит выбранный scope на логические коммиты и выполняет явно разрешённые push/PR/merge-действия |
 | `eda-worktree-executor` | `haiku` | `gpt-5.6-luna` | Создаёт соседний worktree и одноимённую ветку, не изменяя файлы проекта |
 | `eda-merge-worktree-executor` | `haiku` | `gpt-5.6-luna` | Мержит ветку из соседнего worktree в текущую без cleanup и ручного разрешения конфликтов |
 | `eda-review-correctness` | `sonnet`, read-only | `gpt-5.6-terra`, read-only | Проверяет функциональную корректность и крайние случаи |
@@ -114,15 +114,15 @@ eda update-all ~/Code
 | `eda-review-documentation` | `haiku`, read-only | `gpt-5.6-luna`, read-only | Проверяет обязательные обновления документации |
 | `eda-review-previous-reviews` | `haiku`, read-only | `gpt-5.6-luna`, read-only | Перепроверяет незакрытые удалённые замечания |
 
-Агенты устанавливаются отдельно от скилов. Модели review-агентов в таблице — сбалансированные defaults; `docs/settings.yaml` или прямое указание пользователя может заменить модель конкретной проверки на текущий запуск. `eda-aim` последовательно разделяет согласование, выполнение и независимую проверку, а при необходимости использует установленные скилы только в отдельных изолированных субагентах; основной агент передаёт вопросы и структурированные результаты. `eda-commit` сохраняет исходный запрос и целиком передаёт сбор контекста, выбор файлов, коммит и разрешённое продолжение одному простому агенту. `eda-worktree` и `eda-merge-worktree` передают одному специализированному агенту git-операцию, обрабатывают его вопрос или результат и сами команды не выполняют. `eda-review` параллельно запускает только применимые review-агенты; полный prompt каждой роли хранится в агенте, а скил отвечает за выбор, retry и агрегацию. В Claude Code установленный `eda-review` всегда выполняется через `context: fork`, в том числе из `eda-polish`. В Codex шаги polish и специализированные review-агенты запускаются с `fork_turns: "none"`, без наследования истории. Все выбранные проверки отправляются одним нативным параллельным пакетом без ручных партий и shell-опроса.
+Агенты устанавливаются отдельно от скилов. Модели review-агентов в таблице — сбалансированные defaults; `docs/settings.yaml` или прямое указание пользователя может заменить модель конкретной проверки на текущий запуск в режиме `subagents`. `eda-aim` последовательно разделяет согласование, выполнение и независимую проверку, а при необходимости использует установленные скилы только в отдельных изолированных субагентах; основной агент передаёт вопросы и структурированные результаты. `eda-commit` сохраняет исходный запрос и целиком передаёт сбор контекста, выбор файлов, коммит и разрешённое продолжение одному простому агенту. `eda-worktree` и `eda-merge-worktree` передают одному специализированному агенту git-операцию, обрабатывают его вопрос или результат и сами команды не выполняют. `eda-review` поддерживает два режима: `subagents` параллельно запускает применимых review-агентов, а `single` один раз читает общий контекст и выполняет те же проверки одним агентом по встроенной матрице. В Claude Code установленный `eda-review` всегда выполняется через `context: fork`, в том числе из `eda-polish`. В Codex шаги polish и специализированные review-агенты запускаются с `fork_turns: "none"`, без наследования истории. В `subagents` все выбранные проверки отправляются одним нативным параллельным пакетом без ручных партий и shell-опроса.
 
-Для Claude Code установленные `eda-commit`, `eda-worktree` и `eda-merge-worktree` получают `model: haiku`. В Codex у скилов пока нет отдельного per-skill model override: основной поток остаётся на выбранной пользователем модели, но он выполняет только лёгкую оркестрацию, а содержательная работа `eda-commit` и worktree-операций закреплена за `gpt-5.6-luna`.
+Для Claude Code установленный `eda-commit` получает `model: sonnet`, а `eda-worktree` и `eda-merge-worktree` — `model: haiku`. В Codex у скилов пока нет отдельного per-skill model override: основной поток остаётся на выбранной пользователем модели, но он выполняет только лёгкую оркестрацию; содержательная работа `eda-commit` закреплена за `gpt-5.6-terra`, а worktree-операции — за `gpt-5.6-luna`.
 
 ---
 
 ## 🚩 Флаги скилов
 
-У некоторых скилов есть флаг `strict` — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: `eda-explore strict <тема>`. Также strict можно включить отдельно в `docs/settings.yaml`, например через `explore.strict: true`. У `eda-review` вместо общего режима каждая проверка имеет собственные `mode` и `model`.
+У некоторых скилов есть флаг `strict` — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: `eda-explore strict <тема>`. Также strict можно включить отдельно в `docs/settings.yaml`, например через `explore.strict: true`. У `eda-review` режим исполнения задаётся через `subagents` / `single`, а состав проверок — через собственные `mode` и `model`.
 
 У `eda-plan-execute` есть режимы `subagents` / `single` / `auto`. Режим можно разово указать в вызове, например `eda-plan-execute single docs/artifacts/plans/....md`; без него используется `plan-execute.mode` из настроек, а без настроек — `auto`.
 
@@ -132,7 +132,7 @@ eda update-all ~/Code
 
 | Скил | Флаг | Что включает | Когда стоит использовать |
 |---|---|---|---|
-| `eda-orhestra` | `automatic` / `manual`, `без полировки плана`, `без полировки кода`, `полировка кода N итераций`, `без ручных тестов` | Разово меняет режим, состав цепочки и параметры шагов поверх `docs/settings.yaml` | Когда нужно довести задачу по сохранённому workflow или временно сократить дорогие этапы |
+| `eda-orhestra` | `automatic` / `manual`, `subagents` / `single` / `single_propagated`, `без полировки плана`, `без полировки кода`, `полировка кода N итераций`, `без ручных тестов` | Разово меняет вопросы, исполнение, состав цепочки и параметры шагов поверх `docs/settings.yaml` | `single` экономит верхний слой, `single_propagated` также включает single у совместимых execute/review-этапов |
 | `eda-aim` | `automatic` / `manual` | Разово меняет способ ответа на рабочие вопросы поверх `aim.mode`; подтверждение точного списка новых целей остаётся обязательным | Автономная работа или совместное прохождение развилок с человеком |
 | `eda-explore` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью конкретности, фактов, развилок, рисков и версий; затем доправляет отчёт по замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
 | `eda-plan` | `strict`, `без ревью плана`, `без проверок` | `strict` независимо включает кросс-CLI проверку; `без ревью плана` отключает встроенный review/fix; `без проверок` отключает оба вида ревью | Когда нужно разделить создание плана и его последующую полировку |
@@ -140,6 +140,7 @@ eda update-all ~/Code
 | `eda-plan-execute` | `subagents` / `single` / `auto` | Разово меняет, где выполняются фазы, поверх `plan-execute.mode` | `single` для небольшого плана в одном контексте, `subagents` для большого или тяжёлого |
 | `eda-plan-polish` | `threshold N`, `limit N` | Меняет gate и максимальное число подтверждающих review-итераций | Для доводки ответственных планов перед `eda-plan-execute` |
 | `eda-manual-test` | `full` / `полная проверка`, `smoke` / `быстро` | Разово меняет глубину ручной проверки поверх `manual-test.depth` | `smoke` для короткой правки, `full` — когда нужно закрыть все области после плана |
+| `eda-review` | `subagents` / `single` | Разово меняет способ выполнения выбранных проверок поверх `review.execution` | `single` экономит контекст на частых локальных ревью; `subagents` сохраняет независимость ролей для ответственных изменений |
 
 ---
 
@@ -156,6 +157,9 @@ orhestra:
   # Режим полного цикла eda-orhestra.
   # automatic | manual
   mode: automatic
+  # Где выполняются этапы и передаётся ли single совместимым вложенным скилам.
+  # subagents | single | single_propagated
+  execution: subagents
   # Упорядоченная цепочка. Шаги можно отключать, удалять и переставлять.
   steps:
     - id: plan
@@ -246,7 +250,9 @@ manual-test:
   depth: full
 
 review:
-  # Каждая проверка имеет собственный режим запуска и модели для обеих сред.
+  # subagents — отдельный специализированный агент на проверку, single — все проверки одним агентом.
+  execution: subagents
+  # Каждая проверка имеет собственный режим запуска; модели применяются только в subagents.
   agents:
     # Проверяет ошибки в логике, крайние случаи и обработку ошибок.
     # Эта базовая проверка по умолчанию запускается всегда.
@@ -384,6 +390,7 @@ discover-automations:
 
 Что означают настройки:
 - `orhestra.mode` — `automatic` безопасно закрывает рабочие вопросы без промежуточных подтверждений; `manual` пишет план вместе с человеком и передаёт ему вопросы.
+- `orhestra.execution` — `subagents` запускает каждый этап отдельно, `single` выполняет верхнюю цепочку текущим агентом, `single_propagated` дополнительно передаёт `single` шагам `eda-plan-execute`, `eda-polish` и прямому `eda-review`; default `subagents`. Другие вложенные скилы сохраняют собственный контракт.
 - `orhestra.steps` — выполняемый сверху вниз workflow. `enabled: false` отключает шаг, а `args` передаёт ему дополнительные параметры. Например, для `eda-polish`: `args: "limit 2"`. Шаги можно переставлять или добавлять, но git/publish-скиллы оркестратор не запускает.
 - Старое значение `steps[].skill: eda-execute` во время запуска автоматически понимается как `eda-plan-execute`; существующий `docs/settings.yaml` установщик не переписывает.
 - `steps[].on_failure` — настраивает исправление failed manual-test прямо рядом с этим шагом: `skill` и `args` задают фикс, `then` — повторяемые id шагов, `max_cycles` — лимит. Если обработчика нет, оркестратор сохраняет failed-отчёт и останавливается.
@@ -395,8 +402,9 @@ discover-automations:
 - `plan-polish.limit` — максимальное число подтверждающих review-итераций; default `2`. Цикл останавливается раньше, если score перестал расти.
 - `plan-execute.mode` — где `eda-plan-execute` выполняет фазы: `subagents` — каждая фаза в отдельном изолированном субагенте с независимой проверкой, `single` — весь план одним контекстом без субагентов, `auto` — выбор по плану; default `auto`. Явный режим в вызове имеет приоритет.
 - `manual-test.depth` — глубина ручной проверки в `eda-manual-test`: `full` — закрыть все применимые области матрицы покрытия, `smoke` — только запуск и основной сценарий изменённой области, `ask_each_time` — спрашивать каждый раз; default `full`. Явная глубина в вызове имеет приоритет.
+- `review.execution` — где выполняются проверки `eda-review`: `subagents` запускает отдельные специализированные роли, `single` выполняет те же выбранные проверки одним агентом с однократной загрузкой общего контекста; default `subagents`. Явный режим в вызове имеет приоритет.
 - `review.agents.<check>.mode` — запускать проверку всегда, автоматически по контексту или отключить.
-- `review.agents.<check>.model.claude` и `.codex` — модель конкретной проверки в соответствующей среде.
+- `review.agents.<check>.model.claude` и `.codex` — модель конкретной проверки в соответствующей среде для `subagents`; в `single` используется текущая модель агента.
 - `eda-review` не делит находки по обязательности: каждый принятый пункт требует исправления, а предложения без доказанного практического дефекта отбрасываются. Score остаётся экспертной оценкой серьёзности; любая находка блокирует `clean` независимо от score.
 - `send-review.close_previous_reviews` — после успешной новой отправки скрывает предыдущие сводки, созданные `eda-send-review` текущим GitHub-пользователем, и резолвит связанные inline-треды; прямое указание в текущем запросе переопределяет настройку.
 - `discover-automations.include_plans` — добавляет `docs/artifacts/plans/` в обычный запуск `eda-discover-automations`.
@@ -413,7 +421,7 @@ discover-automations:
 
 `eda-orhestra` по умолчанию запускает основной цикл одной командой:
 
-Каждая стрелка между этапами передаёт только явный вход и пути к артефактам: каждый этап работает в новом изолированном субагенте без истории диалога.
+В default `subagents` каждая стрелка передаёт явный вход и пути к артефактам в новый изолированный субагент. В `single` и `single_propagated` верхние этапы идут последовательно в текущем контексте.
 
 ```text
 plan без проверок → plan-polish → plan-execute → polish → manual-test ──passed──> готово
@@ -458,7 +466,7 @@ discover-automations может запускаться от review, fix-by-revie
 
 `eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API, базу, консольные команды, интерфейс и алгоритмы перед ревью или коммитом.
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный порядок и аргументы задаются в `orhestra.steps`. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra single <задача>`, `eda-orhestra single_propagated <задача>`, `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный режим исполнения задаётся в `orhestra.execution`, порядок и аргументы — в `orhestra.steps`. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 
 Вызов `eda-commit` без контекста охватывает все незакоммиченные tracked-изменения и содержательные untracked-файлы; очевидные кэши, временные и локальные служебные артефакты остаются вне коммитов. Executor сам делит полный состав на необходимое число логически цельных коммитов — один, три или больше. Например, запрос `eda-commit сразу отправь ветку, создай PR и дай ссылку` использует тот же полный состав и выполняет всю указанную цепочку без отдельного вопроса после серии коммитов.
 
@@ -468,7 +476,7 @@ discover-automations может запускаться от review, fix-by-revie
 
 - **Простой язык.** Скилы общаются с тобой так, чтобы понял человек без глубоких знаний предмета. Термины — только когда без них нельзя.
 - **Все вопросы — интерактивно.** В Claude Code — через `AskUserQuestion`; в интерактивном Codex — через `request_user_input` или блокирующий вопрос в чат. В `codex exec` и других неинтерактивных запусках скил не имитирует диалог: если без ответа нельзя безопасно продолжать, он завершает работу со статусом `blocked: нужен ответ пользователя`.
-- **Проверки — через субагентов.** `eda-review` запускает установленных read-only агентов нативным механизмом Claude/Codex. Если субагенты недоступны, review останавливается: CLI-fallback, кросс-проверки соседним провайдером и подмена ролей главным агентом не используются.
+- **Способ review настраивается.** В `subagents` `eda-review` запускает установленных read-only агентов нативным механизмом Claude/Codex и блокируется при их недоступности без CLI-fallback. В `single` один review-runner выполняет те же выбранные проверки по общей матрице без leaf-субагентов и повторной загрузки общего контекста.
 - **Технические остановки обрабатываются по причине.** Оркестраторы ждут свободный слот при лимите параллельности, запрашивают недостающее разрешение, один раз продолжают агента после временной API-ошибки и без бессмысленных retry останавливаются при лимите глубины, исчерпанной квоте или неизвестном сбое.
 - **Повторяемые роли — в пакетных агентах.** Скилы управляют процессом, а стабильные изолированные роли получают собственный prompt, модель и доступ. Полные review-prompts не дублируются в оркестраторе.
 - **Артефакты по папкам.** Исследования отдельно, планы отдельно, ревью отдельно. Между файлами — ссылки. Через месяц легко найти, кто что когда решал.

package/agents/eda-commit-executor/agent.json

@@ -3,12 +3,12 @@
   "name": "eda-commit-executor",
   "description": "Самостоятельно собирает git-контекст, делит выбранные или все незакоммиченные изменения на логические коммиты и выполняет явно разрешённые push, PR или merge-действия для eda-commit.",
   "models": {
-    "claude": "haiku",
-    "codex": "gpt-5.6-luna"
+    "claude": "sonnet",
+    "codex": "gpt-5.6-terra"
   },
   "reasoning": {
-    "claude": "low",
-    "codex": "low"
+    "claude": "medium",
+    "codex": "medium"
   },
   "access": "git-write"
 }

package/agents/eda-commit-executor/prompt.md

@@ -37,7 +37,7 @@
 2. Прочитай последние 5–10 коммитов и определи наблюдаемый стиль сообщений.
 3. Получи текущую ветку, upstream, remotes и основную ветку из `origin/HEAD`.
 4. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и связанные артефакты из `docs/**`, если они есть и применимы к изменениям.
-5. Проверяй существующий PR текущей ветки, когда `USER_REQUEST` или `REQUESTED_ACTIONS` упоминает PR или push.
+5. Проверяй существующий PR текущей ветки, когда `USER_REQUEST` или `REQUESTED_ACTIONS` упоминает PR или push. Если предстоит создание или обновление PR, найди применимый шаблон PR в репозитории и прочитай его целиком.
 6. Определи состав коммита:
    - если `COMMIT_SCOPE` непустой, выбери соответствующий ему логический набор и отдели несвязанные пользовательские изменения;
    - если `COMMIT_SCOPE` пустой, выбери все незакоммиченные tracked-изменения — staged, unstaged и удаления — и все содержательные untracked-файлы во всём репозитории. Несколько задач или несвязанных изменений в этом режиме охватываются одной серией коммитов и не требуют вопроса;
@@ -60,7 +60,7 @@
 1. Непосредственно перед индексацией повторно проверь `git status` и diff оставшихся изменений. Если состояние неожиданно изменилось или при непустом `COMMIT_SCOPE` состав стал неоднозначным, верни `blocked` до `git add` этой группы.
 2. Добавляй новые файлы и подготавливай обычный изолированный индекс только точечно через `git add -- <paths>`; не используй `git add -A` или `git add .`. Если в индексе остаются файлы других групп или изменения вне scope, используй `git commit --only -- <paths>` либо эквивалентную безопасную path-limited стратегию: чужие staged-изменения не должны попасть в текущий коммит, исчезнуть из индекса или расшириться за счёт их unstaged-части.
 3. Проверь точный кандидат текущего коммита: `git diff --cached` для изолированного индекса или соответствующий path-limited diff для `--only`. Убедись, что кандидат содержит только текущую логическую группу без служебных артефактов или секретных файлов. При обнаружении проблемы не коммить и верни `blocked` с точным состоянием индекса и списком уже созданных коммитов.
-4. Составь отдельное сообщение в стиле истории проекта: заголовок до примерно 70 символов, при необходимости тело с объяснением причины.
+4. Составь отдельное сообщение в стиле истории проекта. Заголовок до примерно 70 символов должен конкретно называть результат группы, а не повторять имя ветки, список файлов или общие слова вроде `changes`, `updates` и «правки». Если причина или важное изменение поведения не очевидны из заголовка, добавь короткое тело. Описывай только фактический кандидат коммита и не приписывай ему изменения или проверки из других групп.
 5. Выполни `git commit` выбранным изолированным способом без `--amend`, `--no-verify` и `--no-gpg-sign`. Проверь фактический состав нового commit, сохрани hash, subject и files, затем переходи к следующей группе.
 
 После последнего коммита проверь, что из выбранного состава ничего не осталось. Только затем выполняй действия после коммитов.
@@ -71,9 +71,18 @@
 
 Выполни `REQUESTED_ACTIONS` по порядку без повторного вопроса. Явное «создай PR» разрешает обычный push текущей ветки как необходимую предпосылку.
 
+Для создания или явно запрошенного обновления PR составь заголовок и описание по полному `USER_REQUEST`, фактическим коммитам текущей ветки относительно base и итоговому diff. Не своди PR к копии последнего commit message, если коммитов несколько.
+
+- Явно заданные пользователем заголовок, текст или обязательные разделы имеют приоритет. Иначе следуй найденному шаблону PR; если шаблона нет, дай короткое описание цели, список фактических изменений и раздел проверки.
+- Заголовок должен описывать общий результат PR конкретно и без имени ветки, номера коммита, служебных префиксов или общих формулировок вроде `updates` и «изменения».
+- В описании объясни, зачем нужен PR и что изменилось с точки зрения проверяемого поведения или контракта. Не пересказывай diff по файлам и не добавляй ритуальные разделы без содержательной информации.
+- В разделе проверки перечисли только реально выполненные команды и их результат. Если проверки не запускались, так и напиши; не выдумывай тесты, issue, метрики, совместимость или breaking changes.
+- Перед отправкой сверь текст с base...HEAD diff: каждое утверждение должно подтверждаться текущим PR, а все основные логические группы коммитов должны быть отражены.
+- Передавай многострочное описание через временный файл и `--body-file`, чтобы shell quoting не повредил Markdown. Не оставляй незаполненные placeholder'ы шаблона.
+
 - Для push используй существующий upstream, иначе `git push -u origin <branch>`.
 - Для PR определи base по `origin/HEAD`, сначала проверь текущую ветку через `gh pr view`; существующий PR не дублируй.
-- Если PR отсутствует, создай его через `gh pr create`, затем получи фактические номер и URL через `gh`; не угадывай ссылку.
+- Если PR отсутствует, создай его через `gh pr create --title <title> --body-file <file>`, затем получи фактические номер и URL через `gh`; не угадывай ссылку. Если PR уже существует, меняй его заголовок или описание только по явному запросу пользователя через `gh pr edit`; обычный push не перезаписывает текст PR.
 - После любого выполненного push всегда возвращай ссылку. Если PR текущей ветки есть — `pr.status: existing` и его фактический URL. Если PR нет — `pr.status: absent` и `pr.create_url`: ссылка на создание PR, собранная из фактического URL репозитория (`gh repo view`), base из `origin/HEAD` и имени ветки.
 - Если PR нет, а его создание не запрошено, сам PR не создавай: верни `completed`, `pr.create_url`, вопрос «Создать PR?» и варианты «создать PR» / «оставить ссылку на создание».
 - Если репозиторий не на GitHub или `gh` недоступен, верни `pr.create_url: null` и назови причину в `error`.

package/lib/install.js

@@ -251,6 +251,7 @@ const DEFAULT_ORHESTRA_STEPS = ORHESTRA_STEP_DEFINITIONS.map(({ name, ...step })
 const DEFAULT_SETTINGS = {
   orhestra: {
     mode: 'automatic',
+    execution: 'subagents',
     steps: DEFAULT_ORHESTRA_STEPS
   },
   aim: {
@@ -281,6 +282,7 @@ const DEFAULT_SETTINGS = {
     depth: 'full'
   },
   review: {
+    execution: 'subagents',
     agents: DEFAULT_REVIEW_AGENTS
   },
   sendReview: {
@@ -350,6 +352,20 @@ const ORHESTRA_MODE_CHOICES = [
     name: 'Писать план вместе с человеком и передавать ему вопросы'
   }
 ];
+const ORHESTRA_EXECUTION_CHOICES = [
+  {
+    value: 'subagents',
+    name: 'Каждый этап выполнять отдельным изолированным субагентом'
+  },
+  {
+    value: 'single',
+    name: 'Все этапы выполнять текущим агентом без передачи режима внутрь'
+  },
+  {
+    value: 'single_propagated',
+    name: 'Все этапы выполнять текущим агентом и передавать single совместимым скилам'
+  }
+];
 const AIM_MODE_CHOICES = [
   {
     value: 'automatic',
@@ -465,6 +481,16 @@ const REVIEW_MODE_CHOICES = [
   { value: 'auto', name: 'auto — запускать только когда проверка применима' },
   { value: 'off', name: 'off — отключить проверку' }
 ];
+const REVIEW_EXECUTION_CHOICES = [
+  {
+    value: 'subagents',
+    name: 'Каждую review-проверку выполнять отдельным специализированным субагентом'
+  },
+  {
+    value: 'single',
+    name: 'Все review-проверки выполнять одним агентом в общем контексте'
+  }
+];
 const CLAUDE_REVIEW_MODEL_CHOICES = [
   { value: 'haiku', name: 'haiku — быстрая проверка' },
   { value: 'sonnet', name: 'sonnet — сильная проверка кода' },
@@ -744,6 +770,7 @@ export async function askSettings({
   }
 
   const scalarPrompts = [
+    ['orhestra', 'orhestra.execution', settings.orhestra, 'execution', 'Как eda-orhestra должен выполнять этапы по умолчанию?', ORHESTRA_EXECUTION_CHOICES],
     ['aim', 'aim.mode', settings.aim, 'mode', 'Как eda-aim должен отвечать на рабочие вопросы по умолчанию?', AIM_MODE_CHOICES],
     ['explore', 'explore.decisionMode', settings.explore, 'decisionMode', 'Как принимать важные решения в eda-explore?', DECISION_MODE_CHOICES],
     ['plan', 'plan.size', settings.plan, 'size', 'Какой размер плана eda-plan использовать по умолчанию?', PLAN_SIZE_CHOICES],
@@ -753,7 +780,8 @@ export async function askSettings({
     ['plan-review', 'planReview.threshold', settings.planReview, 'threshold', 'Какой порог готовности использовать в eda-plan-review?', PLAN_REVIEW_THRESHOLD_CHOICES],
     ['plan-polish', 'planPolish.limit', settings.planPolish, 'limit', 'Сколько review-итераций разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES],
     ['plan-execute', 'planExecute.mode', settings.planExecute, 'mode', 'Как eda-plan-execute должен выполнять фазы по умолчанию?', PLAN_EXECUTE_MODE_CHOICES],
-    ['manual-test', 'manualTest.depth', settings.manualTest, 'depth', 'Какую глубину ручной проверки использовать в eda-manual-test по умолчанию?', MANUAL_TEST_DEPTH_CHOICES]
+    ['manual-test', 'manualTest.depth', settings.manualTest, 'depth', 'Какую глубину ручной проверки использовать в eda-manual-test по умолчанию?', MANUAL_TEST_DEPTH_CHOICES],
+    ['review', 'review.execution', settings.review, 'execution', 'Как eda-review должен выполнять проверки по умолчанию?', REVIEW_EXECUTION_CHOICES]
   ];
   for (const [section, key, target, property, message, choices] of scalarPrompts) {
     if (!requestedSections.has(section) || !shouldAsk(key)) continue;
@@ -766,7 +794,8 @@ export async function askSettings({
       output,
       selectPrompt,
       seedAgents: settings.review.agents,
-      missingKeys
+      missingKeys,
+      skipModels: settings.review.execution === 'single'
     });
   }
   return settings;
@@ -777,7 +806,8 @@ export async function askReviewAgentSettings({
   output = process.stdout,
   selectPrompt = select,
   seedAgents = DEFAULT_REVIEW_AGENTS,
-  missingKeys = null
+  missingKeys = null,
+  skipModels = false
 } = {}) {
   return askAgentSettings({
     input,
@@ -787,11 +817,12 @@ export async function askReviewAgentSettings({
     seedAgents,
     missingKeys,
     keyPrefix: 'review.agents',
-    label: 'review'
+    label: 'review',
+    skipModels
   });
 }
 
-async function askAgentSettings({ input, output, selectPrompt, definitions, seedAgents, missingKeys, keyPrefix, label }) {
+async function askAgentSettings({ input, output, selectPrompt, definitions, seedAgents, missingKeys, keyPrefix, label, skipModels = false }) {
   const configuredAgents = structuredClone(seedAgents);
   const shouldAsk = key => missingKeys === null || missingKeys.has(key);
   for (const agent of definitions) {
@@ -809,14 +840,14 @@ async function askAgentSettings({ input, output, selectPrompt, definitions, seed
 
     let claude = configuredAgents[agent.key].model.claude;
     let codex = configuredAgents[agent.key].model.codex;
-    if (mode !== 'off' && shouldAsk(claudeKey)) {
+    if (!skipModels && mode !== 'off' && shouldAsk(claudeKey)) {
       claude = await selectPrompt({
         message: `Какой моделью Claude проверять ${agent.key}?`,
         choices: CLAUDE_REVIEW_MODEL_CHOICES,
         default: claude
       }, { input, output });
     }
-    if (mode !== 'off' && shouldAsk(codexKey)) {
+    if (!skipModels && mode !== 'off' && shouldAsk(codexKey)) {
       codex = await selectPrompt({
         message: `Какой моделью Codex проверять ${agent.key}?`,
         choices: CODEX_REVIEW_MODEL_CHOICES,
@@ -1137,6 +1168,12 @@ function migrateSettingsContent(content) {
   const legacyDefaults = objectValue(raw.defaults);
   const orhestra = objectValue(raw.orhestra);
   transfer('orhestra.mode', orhestra.mode, oneOf(['automatic', 'manual']), value => { settings.orhestra.mode = value; });
+  transfer(
+    'orhestra.execution',
+    orhestra.execution,
+    oneOf(['subagents', 'single', 'single_propagated']),
+    value => { settings.orhestra.execution = value; }
+  );
   const steps = normalizeStoredOrhestraSteps(orhestra.steps);
   transfer('orhestra.steps', steps, value => Array.isArray(value), value => { settings.orhestra.steps = value; });
 
@@ -1204,6 +1241,12 @@ function migrateSettingsContent(content) {
   );
 
   const review = objectValue(raw.review);
+  transfer(
+    'review.execution',
+    review.execution,
+    oneOf(['subagents', 'single']),
+    value => { settings.review.execution = value; }
+  );
   transferAgentSettings({
     rawAgents: objectValue(review.agents),
     settingsAgents: settings.review.agents,
@@ -1375,6 +1418,9 @@ orhestra:
   # Режим полного цикла eda-orhestra.
   # automatic | manual
   mode: ${orhestra.mode ?? 'automatic'}
+  # Где выполняются этапы и передаётся ли single совместимым вложенным скилам.
+  # subagents | single | single_propagated
+  execution: ${orhestra.execution ?? 'subagents'}
   # Упорядоченная цепочка. Шаги можно отключать, удалять и переставлять.
   steps:
 ${orhestraSteps}
@@ -1435,7 +1481,10 @@ manual-test:
   depth: ${settings.manualTest.depth}
 
 review:
-  # Каждая проверка имеет собственный режим запуска и модели для обеих сред.
+  # Где eda-review выполняет выбранные проверки.
+  # subagents — отдельный специализированный агент на проверку, single — все проверки одним агентом.
+  execution: ${settings.review.execution ?? 'subagents'}
+  # Каждая проверка имеет собственный режим запуска; модели применяются только в subagents.
   agents:
 ${reviewAgents}
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "3.5.0",
+  "version": "3.6.0",
   "description": "Пакет скилов и специализированных агентов eda-* для Claude Code и Codex CLI",
   "type": "module",
   "bin": {

package/skills/eda-commit/SKILL.md

@@ -23,7 +23,7 @@ description: 'Коммитит выбранные или все незакомм
 
 | Агент | Claude Code | Codex | Доступ |
 |---|---|---|---|
-| `eda-commit-executor` | `haiku` | `gpt-5.6-luna` | git-write |
+| `eda-commit-executor` | `sonnet` | `gpt-5.6-terra` | git-write |
 
 - В Claude Code запускай установленный custom agent через `Agent` tool по имени.
 - В Codex запускай установленный custom agent через `spawn_agent` или аналог по имени.
@@ -75,7 +75,7 @@ COMMIT_SCOPE:
 Верни результат строго по YAML-контракту агента.
 ```
 
-Агент сам собирает git-контекст, читает правила и историю, формирует сообщения, точечно коммитит и выполняет разрешённое продолжение. При непустом `$COMMIT_SCOPE` он выбирает соответствующий состав. При пустом `$COMMIT_SCOPE` включает все tracked-изменения и содержательные untracked-файлы, исключая только очевидные кэши, временные, системные и локальные служебные артефакты. Выбранный состав он сам делит на необходимое число логически цельных коммитов и создаёт их по порядку; несколько задач в полном дефолтном наборе не являются причиной для вопроса. При вероятном секрете или другой реальной небезопасности он обязан вернуть `blocked` до индексации затронутой группы.
+Агент сам собирает git-контекст, читает правила и историю, формирует сообщения коммитов и тексты PR по исходному запросу и фактическому diff, точечно коммитит и выполняет разрешённое продолжение. При непустом `$COMMIT_SCOPE` он выбирает соответствующий состав. При пустом `$COMMIT_SCOPE` включает все tracked-изменения и содержательные untracked-файлы, исключая только очевидные кэши, временные, системные и локальные служебные артефакты. Выбранный состав он сам делит на необходимое число логически цельных коммитов и создаёт их по порядку; несколько задач в полном дефолтном наборе не являются причиной для вопроса. При вероятном секрете или другой реальной небезопасности он обязан вернуть `blocked` до индексации затронутой группы.
 
 Явная команда пользователя разрешает обычные ожидаемые действия и безопасные предпосылки в её рамках. Например, «создай PR» разрешает обычный push текущей ветки, если без него PR создать нельзя. Она не разрешает force-push, публикацию секретов или другое не названное рискованное действие.
 

package/skills/eda-commit/skill.json

@@ -1,6 +1,7 @@
 {
   "schemaVersion": 1,
   "models": {
-    "claude": "haiku"
+    "claude": "sonnet",
+    "codex": "gpt-5.6-terra"
   }
 }

package/skills/eda-orhestra/SKILL.md

@@ -11,11 +11,12 @@ description: 'Выполняет настраиваемую цепочку `eda-
 
 Прочитай только раздел `orhestra` из `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее любого поля настроек.
 
-Поддерживается только `version: 3`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолт режима: `orhestra.mode: automatic`.
+Поддерживается только `version: 3`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолты: `orhestra.mode: automatic`, `orhestra.execution: subagents`.
 
 ```yaml
 orhestra:
   mode: automatic
+  execution: subagents
   steps:
     - id: plan
       skill: eda-plan
@@ -48,6 +49,7 @@ orhestra:
 Правила схемы:
 
 - `mode`: только `automatic` или `manual`; дефолт `automatic`.
+- `execution`: `subagents`, `single` или `single_propagated`; дефолт `subagents`.
 - `steps`: упорядоченный непустой список. Выполняй сверху вниз только элементы с `enabled: true`; отсутствующий `enabled` считай `true`.
 - `id`: уникальное непустое имя шага для ссылок из `on_failure.then`.
 - `skill`: имя установленного `eda-*`-скила. Не разрешай `eda-orhestra`, `eda-aim`, `eda-commit`, `eda-send-review`, `eda-worktree` и `eda-merge-worktree`.
@@ -63,7 +65,9 @@ orhestra:
 
 ## Вход из сообщения пользователя
 
-Сохрани весь текст рядом с вызовом в `$USER_REQUEST`. Извлеки задачу, пути к готовым артефактам, режим и разовые изменения цепочки.
+Сохрани весь текст рядом с вызовом в `$USER_REQUEST`. Извлеки задачу, пути к готовым артефактам, режим вопросов, режим исполнения и разовые изменения цепочки.
+
+Явные `subagents`, `single` или `single_propagated` рядом с вызовом `eda-orhestra` задают `$EXECUTION` только для текущего запуска и важнее настроек. Поддерживай также формулировки «одним агентом» для `single` и «одним агентом с передачей» для `single_propagated`. Не принимай режим, явно адресованный отдельному шагу, за режим самого оркестратора.
 
 Поддерживай естественные overrides: `без полировки плана`, `без полировки кода`, `полировка кода 2 итерации`, `без ручных тестов`, `только plan и execute`, `plan-polish threshold 95 limit 3`, `для manual-test <args>`. Явное перечисление порядка заменяет порядок из настроек; локальное включение, отключение или параметры меняют только названный шаг. Фразу `полировка кода N итераций` нормализуй в `limit N` внутри `args` шага `eda-polish`; аналогичную фразу о плане — в `args` шага `eda-plan-polish`. Не принимай слово из описания самой задачи за override без явной связи с цепочкой.
 
@@ -71,10 +75,10 @@ orhestra:
 
 ## Подготовка цепочки
 
-1. Нормализуй настройки и overrides в `$STEPS` с `id`, `skill`, `enabled` и `args`.
+1. Определи `$EXECUTION` по явному режиму оркестратора, затем по `orhestra.execution`, иначе `subagents`; нормализуй настройки и overrides в `$STEPS` с `id`, `skill`, `enabled` и `args`.
 2. Проверь уникальность id, наличие скилов, `on_failure`-инварианты и положительные числовые лимиты. Неизвестный id в `on_failure.then`, запрещённый скилл, handler без повторного manual-test, пустая активная цепочка или отсутствующий установленный скилл — `blocked: некорректная конфигурация orhestra` с точным полем.
 3. Не исправляй подозрительный порядок молча. Если шаг очевидно требует ещё не созданный артефакт, в automatic остановись только когда вход нельзя безопасно получить из `$USER_REQUEST` или предыдущих результатов; в manual задай один вопрос о порядке или входе.
-4. Сформируй для каждого шага итоговый ввод: `$USER_REQUEST` + пути ко всем артефактам предыдущих шагов + `args`.
+4. Сформируй для каждого шага итоговый ввод: задача из `$USER_REQUEST` без orchestration-only указания `$EXECUTION` + пути ко всем артефактам предыдущих шагов + `args`. Явно адресованный режим отдельного шага сохрани.
 5. Прямые параметры текущего вызова всегда ставь выше противоречащих `args` и настроек.
 
 ## Режимы и вопросы
@@ -104,15 +108,14 @@ orhestra:
 ## Вызов вложенных скилов
 
 1. Загружай установленный `SKILL.md` каждого шага как источник правды. Не копируй его процедуру в этот скилл.
-2. Каждый активный шаг запускай в отдельном изолированном субагенте. Это обязательно и для составных скилов с собственными субагентами, включая `eda-plan`, `eda-plan-polish`, `eda-polish` и `eda-review`.
-3. Изоляция означает свежий контекст без наследования истории текущего диалога. Передавай субагенту только рабочую директорию, имя скилла, подготовленный итоговый ввод и пути к нужным артефактам. В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог; в Claude Code — новый `Agent` с самодостаточным task-сообщением.
-4. Субагент шага сам загружает его `SKILL.md`, выполняет весь контракт скилла и при необходимости запускает его штатных нативных субагентов. Основной оркестратор только готовит ввод, передаёт ответы человека, проверяет статус и связывает артефакты; содержательную работу этапа он не выполняет.
-5. Каждый повтор шага и каждый `on_failure.skill` считай новым вызовом: запускай его в новом изолированном субагенте с полным актуальным входом.
-6. Если чистый контекст, субагент этапа или нужная составному скилу вложенная делегация недоступны, остановись с `blocked: недоступна изоляция этапа`. Не выполняй этап основным агентом и не вводи новый CLI-fallback, которого нет в инструкции вызываемого скилла.
+2. В `single_propagated` добавь `single` к итоговому вводу только совместимых шагов `eda-plan-execute`, `eda-polish` и `eda-review`, если пользователь не задал этому шагу собственный режим. Не передавай его другим скилам: `eda-polish` уже передаст режим своему `eda-review`, а остальные продолжат по собственному контракту.
+3. В `subagents` каждый активный шаг, повтор и `on_failure.skill` запускай в отдельном изолированном субагенте. Передавай только рабочую директорию, имя скилла, итоговый ввод и пути к нужным артефактам. В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог; в Claude Code — новый `Agent` с самодостаточным task-сообщением.
+4. В `single` и `single_propagated` выполняй контракт каждого активного шага, повтора и `on_failure.skill` сам в текущем контексте, строго последовательно. Не создавай для них верхнеуровневых субагентов; собственные правила вложенной делегации вызываемого скилла сохраняются.
+5. Не переключай `$EXECUTION` автоматически. В `subagents` при недоступной изоляции остановись с `blocked: недоступна изоляция этапа`; в single-режимах блокируйся только тогда, когда обязательная вложенная делегация недоступна по контракту самого шага.
 
 ## Технические остановки субагентов
 
-Техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
+В `subagents` техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
 
 - лимит параллельности или отсутствие свободного слота — дождись уже запущенного этим workflow агента, при необходимости закрой завершённые потоки и повтори тот же запуск; если управляемых активных агентов нет, заверши `blocked: заняты слоты субагентов`;
 - лимит глубины вложения — не повторяй запуск и не выполняй этап сам; заверши `blocked: достигнут лимит глубины субагентов`, указав наблюдаемую и требуемую глубину;
@@ -148,13 +151,14 @@ orhestra:
 
 ## Финал
 
-Сообщи режим, фактически выполненную цепочку с args и лимитами, пропущенные шаги и причины, пути ко всем артефактам, последний review score при наличии, результат manual-test при наличии, число QA-циклов и состояние git «не закоммичено».
+Сообщи режим вопросов, `$EXECUTION`, переданные вложенным шагам overrides, фактически выполненную цепочку с args и лимитами, пропущенные шаги и причины, пути ко всем артефактам, последний review score при наличии, результат manual-test при наличии, число QA-циклов и состояние git «не закоммичено».
 
 Успех означает, что все включённые шаги завершились по собственным контрактам. Если manual-test был включён, после последних изменений обязателен `passed`; если он отключён, явно напиши «ручные тесты пропущены настройкой». Если отключён `eda-plan-polish`, явно напиши «полировка плана пропущена настройкой». Если отключён `eda-polish`, явно напиши «полировка кода пропущена настройкой».
 
 ## Чего НЕ делать
 
-- Выполнять содержательную работу вместо настроенного скилла.
+- Обходить или сокращать контракт настроенного скилла из-за выбранного режима исполнения.
+- Передавать `single` скилам вне allowlist `eda-plan-execute`, `eda-polish`, `eda-review`.
 - Запускать отключённый или отсутствующий в цепочке шаг, кроме явно настроенного `on_failure.skill`.
 - Терять `args`, порядок или пути к артефактам при передаче.
 - Считать автоматические тесты заменой включённого `eda-manual-test`.

package/skills/eda-polish/SKILL.md

@@ -9,7 +9,7 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций и ограничения. Передавай в каждый `eda-review` разовые overrides проверок и моделей из запроса пользователя.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций и ограничения. Передавай в каждый `eda-review` разовый режим `subagents` или `single`, overrides проверок и моделей из запроса пользователя.
 
 Лимит по умолчанию — `5` итераций; пользователь может задать `limit N` положительным целым числом. Порога у цикла нет: устаревшие `threshold N`, `до 90` и `цель 90` не применяй и скажи об этом в финале.
 
@@ -52,6 +52,7 @@ description: 'Итеративно ревьюит и исправляет изм
    ```text
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
+   Режим исполнения review: <single | subagents | из настроек>.
    Overrides проверок и моделей: <из запроса | none>.
    Ранее отклонённые находки: <предыдущий review file и fix report | none>.
    Верни путь к файлу, status, result, score, находки и coverage.

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. **Разделяй документы по назначению.** Business-карточки задают подтверждённое целевое поведение и редактируются только через `eda-business`; `docs/rules.md` задаёт проверяемые обязанности и запреты при работе над проектом; `docs/arch.md` фиксирует устройство, границы и владение ответственностью; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
+3. **Разделяй документы по назначению.** Business-карточки задают подтверждённое целевое поведение и редактируются только через `eda-business`; `docs/rules.md` задаёт действия, запреты, команды проверки и требования к процессу, совместимости и безопасности; `docs/arch.md` фиксирует структуру исходного кода, назначение каталогов, модули и слои, ownership, зависимости, runtime/data-flow, данные и интеграции; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. У каждого факта должен быть ровно один документ-владелец: допустима ссылка на другой документ, но не вторая копия содержания даже в иной формулировке. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
 4. **Обновляй осмысленно.** Сохраняй актуальное, исправляй неверное, удаляй устаревшее и перестраивай документ настолько сильно, насколько требует проект. Не спрашивай отдельно, что делать с каждым существующим файлом.
 5. **Не выдавай предположение за факт.** Значимые неподтверждённые архитектурные решения предложи пользователю; после выбора зафиксируй принятый вариант.
 6. **Предлагай экстремальный профиль проверок.** Не ограничивайся уже установленными командами или базовыми lint/test. Пройди весь каталог ниже, предложи все применимые проверки и объясни каждое `не применимо`; в документацию переноси только подтверждённые правила.
@@ -125,20 +125,29 @@ description: 'Готовит проект к работе с AI: проекти
 В `docs/rules.md` уместны:
 
 - обязательные команды и момент их запуска;
-- действующие соглашения об именовании, формате, размещении и совместимости;
+- действующие соглашения об именовании, формате и совместимости;
 - требования к изменениям, например обязательная миграция при изменении схемы или обновление контракта при изменении публичного API;
 - точечные запреты небезопасных конструкций, бесконтрольных подавлений, утечки секретов и персональных данных;
 - строгие режимы уже внедрённых инструментов.
 
+Пути допустимы в `docs/rules.md` только как операнды точных команд или указатели на конфиги и создаваемые артефакты. Не описывай в `docs/rules.md` топологию исходного кода, назначение каталогов, размещение компонентов или границы модулей.
+
 Не помещай в `docs/rules.md`:
 
 - выбор архитектурного подхода, слоёв, модулей и CQRS;
+- дерево и топологию исходного кода, назначение каталогов и размещение компонентов;
 - владение данными и ответственностью, направления зависимостей, transaction boundaries, persistence boundaries, trust boundaries и runtime/data-flow;
 - решение, в каком слое выполняются валидация, преобразование типов, авторизация или управление транзакцией;
 - форму controller, handler, repository, DTO, entity, теста, атрибута или другого компонента;
 - желаемое будущее состояние, рекомендации и правила для ещё не внедрённых инструментов.
 
-Если утверждение определяет, **где** находится ответственность или **какая часть системы** может зависеть от другой, запиши его в `docs/arch.md`, даже если его можно переписать как «не вызывай X из Y». Если утверждение показывает, **как именно выглядит код**, оно относится к применимой reference-карточке. Не дублируй одно решение в нескольких документах.
+Если утверждение определяет, **где** находится ответственность или **какая часть системы** может зависеть от другой, запиши его в `docs/arch.md`, даже если его можно переписать как «не вызывай X из Y». Если утверждение показывает, **как именно выглядит код**, оно относится к применимой reference-карточке. Если утверждение задаёт **целевое поведение продукта**, оно относится к применимой business-карточке. При дубле перенеси утверждение к единственному владельцу и удали пересказ из остальных документов; не сохраняй вторую копию даже другими словами.
+
+Пограничные случаи разделяй так:
+
+- запрет зависимости `X → Y` хранится в `docs/arch.md`; обязательный запуск проверки границ хранится в `docs/rules.md` без пересказа самой границы;
+- требование добавить миграцию при изменении схемы хранится в `docs/rules.md`; владение данными и расположение persistence-компонентов — в `docs/arch.md`;
+- путь к конфигу или каталогу артефактов может быть операндом рабочего правила, но путь исходного компонента и его место в системе описываются только в `docs/arch.md`.
 
 Используй эту границу для типичных спорных тем:
 
@@ -164,6 +173,8 @@ description: 'Готовит проект к работе с AI: проекти
 
 Опиши устройство проекта, не повторяя рабочие правила из `docs/rules.md`. Документ должен позволять понять, где находится нужная часть системы, за что она отвечает и как связана с остальными.
 
+`docs/arch.md` не должен содержать команды, чек-листы разработки, настройки линтеров и других инструментов или иные рабочие правила. Если архитектурную границу проверяет конкретная команда, в `docs/arch.md` оставь только саму границу, а требование и момент запуска команды запиши в `docs/rules.md` без пересказа границы.
+
 Включи релевантные проекту сведения:
 - выбранный архитектурный подход, например модульный монолит, слоистая архитектура или набор сервисов, и коротко почему он подходит проекту;
 - дерево основных папок с назначением каждой значимой части;
@@ -193,7 +204,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 Индекс содержит ссылки только на карточки. В каждой карточке должны быть:
 
-- назначение и границы ответственности компонента;
+- назначение эталона и показываемая форма реализации без пересказа архитектурных границ компонента;
 - условия, при которых пример применим;
 - один минимальный, законченный и синтаксически цельный пример в fenced code block с указанием языка;
 - короткий разбор элементов примера, которые нужно повторять;
@@ -237,9 +248,10 @@ description: 'Готовит проект к работе с AI: проекти
 
 Убедись, что:
 - `docs/rules.md` содержит только лаконичные действующие правила;
-- каждое правило задаёт проверяемое действие или запрет, а архитектурные границы не продублированы в форме императива;
-- `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без повторения правил;
+- каждое правило задаёт проверяемое действие или запрет, пути используются только как операнды команд или указатели на конфиги и артефакты, а топология исходного кода и архитектурные границы не продублированы в форме императива;
+- `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без команд, чек-листов разработки, tooling-политик и повторения правил;
 - `docs/references.md` ссылается на все актуальные карточки и не содержит самих примеров;
+- reference-карточки описывают форму реализации, business-карточки — целевое поведение, а архитектурные факты из `docs/arch.md` в них не пересказаны;
 - существующий `docs/business.md` учтён как вход, не изменён этим скилом и указан в `AGENTS.md`;
 - каждая карточка самодостаточна, содержит законченный пример кода и не содержит ссылок или неподтверждённых элементов;
 - для нового проекта без нескольких устойчивых реализаций не созданы выдуманные reference-карточки;
@@ -250,7 +262,8 @@ description: 'Готовит проект к работе с AI: проекти
 - выбранные инструменты имеют максимальный применимый строгий профиль, а каждое ослабление явно обосновано;
 - для нового проекта требования, стек и архитектурные драйверы взяты из стартового документа, а архитектура и правила спроектированы внутри `eda-prepare-ai`;
 - AI-скилы, роли и MCP разделены на уже доступные и требующие отдельного внедрения;
-- документы не противоречат проекту и друг другу.
+- у каждого факта есть ровно один документ-владелец, а остальные документы при необходимости только ссылаются на него без пересказа;
+- между документами нет дублей, архитектурных путей в `docs/rules.md`, императивных рабочих инструкций в `docs/arch.md` и противоречий с проектом или друг с другом.
 
 ### 13. Финал
 

package/skills/eda-review/SKILL.md

@@ -5,21 +5,28 @@ description: 'Проводит полное read-only ревью diff, ветк
 
 # Скил: Ревьюер (eda-review)
 
-Работай как оркестратор установленных `eda-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их системные prompts в task-сообщения. Определи target и контекст, выбери проверки, запусти агентов, проверь их структурированные ответы, объедини подтверждённые находки и сохрани одно итоговое ревью.
+Проводи одно полное read-only ревью в выбранном режиме исполнения. В `subagents` оркестрируй установленных `eda-review-*` агентов и сам не выполняй их специализированные роли. В `single` выполни те же выбранные проверки самостоятельно по общей матрице, не запуская leaf-субагентов. В обоих режимах сохрани один итоговый отчёт с одинаковыми требованиями к доказательствам и результату.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении — главный вход. Сначала разбери target, план, ссылку, ограничения, отключённые или принудительно включённые проверки и разовые модели.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Сначала разбери target, план, ссылку, ограничения, режим `subagents` или `single`, отключённые или принудительно включённые проверки и разовые модели.
 
 Если входа достаточно, продолжай без вопроса. Без аргументов ревьюй незакоммиченный `git diff HEAD`. Ссылка на PR/MR задаёт target однозначно. Если пользователь дал только корень удалённого репозитория, обязательно попроси указать PR/MR, ветку, коммит или файлы; весь репозиторий и последний PR автоматически не выбирай.
 
-Разовые указания вида «без performance», «без business», «включи database», «включи business», «architecture на opus» или «tests на gpt-5.6-sol» важнее `docs/settings.yaml` и действуют только на текущий запуск.
+Явное слово `subagents` или `single` задаёт режим только для текущего запуска и важнее `docs/settings.yaml`. Разовые указания вида «без performance», «без business», «включи database», «включи business», «architecture на opus» или «tests на gpt-5.6-sol» также важнее настроек.
 
 Если во входе даны ранее отклонённые находки или путь к предыдущему ревью, прочитай их раздел «Отклонено» и не принимай эти находки повторно без нового доказательства.
 
 ## Настройки
 
-Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`. Используй `review.agents.<check>.mode` и `review.agents.<check>.model.<platform>`. Если файла нет или версия отличается, используй defaults и добавь предупреждение; старые настройки не применяй.
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`. Используй `review.execution`, `review.agents.<check>.mode` и `review.agents.<check>.model.<platform>`. Если файла нет или версия отличается, используй defaults и добавь предупреждение; старые настройки не применяй.
+
+`review.execution` принимает:
+
+- `subagents` — каждая выбранная проверка выполняется отдельным установленным агентом;
+- `single` — все выбранные проверки выполняет текущий агент в одном контексте.
+
+Default — `subagents`. При неизвестном или отсутствующем значении используй default и добавь предупреждение. Сначала выбери `$EXECUTION` по явному режиму из текущего сообщения, затем по настройке, иначе по default.
 
 Допустимые режимы:
 
@@ -27,7 +34,9 @@ description: 'Проводит полное read-only ревью diff, ветк
 - `auto` — запускать только когда проверка применима;
 - `off` — не запускать.
 
-Допустимые модели по умолчанию: Claude Code — `haiku`, `sonnet`, `opus`; Codex — `gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`. Неизвестное или отсутствующее значение замени default-значением конкретного агента и добавь предупреждение в покрытие.
+Допустимые модели по умолчанию для `subagents`: Claude Code — `haiku`, `sonnet`, `opus`; Codex — `gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`. Неизвестное или отсутствующее значение замени default-значением конкретного агента и добавь предупреждение в покрытие.
+
+В `single` все проверки выполняются текущей моделью агента. Настройки и разовые overrides моделей отдельных проверок не применяются; добавь об этом один warning в покрытие, только если пользователь явно передал такой override. Для completed-проверок укажи фактическую текущую модель, если хост её сообщает, иначе `current`.
 
 Если `version: 3` существует, но раздела `review.agents` нет, используй defaults ниже и добавь предупреждение. Устаревшие поля `review.strict`, `review.include_code_quality` и раздел `review-check` не применяй. Существующий файл настроек не переписывай.
 
@@ -60,7 +69,7 @@ description: 'Проводит полное read-only ревью diff, ветк
 ## Подготовить контекст
 
 1. Определи `$TARGET`: явный файл, папка, URL PR/MR, ветка, коммит, указанный diff или `git diff HEAD` без аргументов. Для GitHub/GitLab URL получи metadata и diff read-only командами `gh`/`glab`; для другого сервиса используй доступное read-only средство. Если основной diff недоступен, остановись: warning разрешён только для недоступных прошлых обсуждений, а не для самого target.
-2. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и сам target настолько, чтобы выбрать проверки и передать агентам точный контекст. На этом шаге не делай собственное code review.
+2. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и сам target настолько, чтобы выбрать проверки и сформировать точный контекст. В `subagents` на этом шаге не делай собственное code review; в `single` эти документы и target станут общей основой всех проходов и не должны загружаться заново для каждой проверки.
 3. Определи `$PLAN_FILE`. Если его нет, используй `none` и не пытайся восстановить последний план наугад.
 4. Определи `$REFERENCE_FILES`: если план содержит `sources.references`, используй их; иначе через `docs/references.md` выбери только применимые карточки для компонентов target. Если карточек нет, используй `none`.
 5. Определи `$BUSINESS_FILES`: сначала установи исходную задачу и фактически затронутое пользовательское или доменное поведение по текущему сообщению, плану и target. Если план содержит `sources.business`, используй только относящиеся к этому поведению пути; иначе прочитай `docs/business.md` и по описаниям выбери только применимые карточки. Если индекс отсутствует, подходящих карточек нет или изменения не затрагивают бизнес-поведение, используй `none`. Не загружай все карточки только потому, что индекс существует.
@@ -87,7 +96,21 @@ description: 'Проводит полное read-only ревью diff, ветк
 
 Для каждой проверки сохрани причину `selected` или `skipped`; она попадёт в покрытие.
 
-## Запустить packaged-агентов
+## Выполнить проверки
+
+### Режим single
+
+Всю работу выполни сам в текущем контексте. Не запускай `eda-review-*` агентов, другие субагенты или отдельный CLI. Если `eda-review` вызван из `eda-polish`, `eda-orhestra` или другого внешнего workflow в одном изолированном субагенте, это не нарушает `single`: запрет относится к leaf-субагентам отдельных проверок внутри текущего review-runner.
+
+Прочитай [references/review-matrix.md](references/review-matrix.md) целиком. Это обязательный контракт всех специализированных проходов в `single`; не читай packaged prompts из `agents/eda-review-*` и не пытайся вызвать их как скилы.
+
+1. Прочитай target и общий код вокруг изменений один раз. Применимые инструкции, `$PLAN_FILE`, `$REFERENCE_FILES` и `$BUSINESS_FILES` также загрузи один раз и только когда соответствующая проверка выбрана.
+2. Последовательно выполни отдельный проход по каждой выбранной проверке из матрицы. Не смешивай области и не пропускай проход из-за того, что соседняя проверка уже изучала тот же код.
+3. Для каждого прохода сохрани внутренний результат: `check`, `status`, `summary` и кандидаты в находки с `severity`, `explanation`, `evidence`, `repro`, `fix` и `tests`. YAML между проходами не нужен.
+4. Если проверка оказалась неприменима, перенеси её в skipped с конкретной причиной. Если обязательную проверку невозможно выполнить из-за недоступного target или контекста, остановись без итогового файла. Недоступные предыдущие удалённые обсуждения преврати в warning и продолжай.
+5. После всех проходов проверь доказательства, дедуплицируй кандидатов, выставь score и сохрани итог по общим правилам ниже. Не запускай отдельный редакторский или подтверждающий проход.
+
+### Режим subagents
 
 Имя агента получается из имени проверки:
 
@@ -131,7 +154,7 @@ REVIEW_CONTEXT: <краткий общий контекст>
 
 Не вставляй системный prompt агента в task-сообщение.
 
-## Проверить ответы и обработать сбои
+### Проверить ответы и обработать сбои subagents
 
 Проверь для каждого ответа `status`, `check`, фактически запрошенный `model` и структуру `находки`. Несовпадение модели считай ошибкой контракта. Каждая находка означает дефект, который обязательно исправить. Находка без точного места, конкретного достижимого риска, доказательства, способа воспроизведения (`repro`) и проверяемого способа исправления не подтверждена.
 
@@ -143,7 +166,7 @@ REVIEW_CONTEXT: <краткий общий контекст>
 
 ## Собрать итог
 
-Главный агент выполняет только редакторскую работу над результатами:
+В `subagents` главный агент выполняет только редакторскую работу над результатами. В `single` эти же правила применяются к кандидатам, собранным в специализированных проходах:
 
 1. Проверь находки по указанным evidence и отклони неподтверждённые.
 2. Объедини дубли разных агентов в один пункт, сохранив все полезные доказательства.
@@ -153,18 +176,19 @@ REVIEW_CONTEXT: <краткий общий контекст>
 6. Каждую отклонённую находку запиши в раздел «Отклонено» с проверкой-источником и причиной. В число находок и в score отклонённые не входят.
 7. Сам выставь итоговый `score` от 0 до 100 по серьёзности, влиянию и общему качеству реализации. Не используй фиксированные вычеты, среднее или минимум оценок агентов. Ориентир: `100` — находок нет; `95–99` — только low; `80–94` — medium или несколько low; `60–79` — high; ниже `60` — critical или нужна существенная переработка. Любое снижение score связывай с принятыми находками; если находок нет, score равен `100`. Добавь короткое обоснование числа.
 8. Установи `result: clean`, только если находок нет; при любой находке используй `result: changes-required` независимо от score.
-9. Не выполняй дополнительное самостоятельное ревью и не добавляй новые domain-находки от себя.
+9. Не выполняй дополнительное ревью после специализированных проходов и не добавляй находки вне выбранных проверок.
 
 Ревью содержит только проблемы. Не перечисляй выполненную работу, похвалу и успешные проверки. Исключение — короткие технические разделы покрытия и «Отклонено».
 
 ## Сохранить ревью
 
-Создай файл `docs/artifacts/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md` только после успешной обработки всех обязательных агентов. Для недоступного `previous_reviews` используй `status: reviewed-with-warnings`, иначе `status: reviewed`.
+Создай файл `docs/artifacts/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md` только после успешной обработки всех обязательных проверок. Для недоступного `previous_reviews` или другого разрешённого warning используй `status: reviewed-with-warnings`, иначе `status: reviewed`.
 
 ```markdown
 ---
 target: <что проверено>
 plan: <docs/artifacts/plans/... | none>
+execution: <subagents | single>
 score: <0..100>
 status: <reviewed | reviewed-with-warnings>
 result: <clean | changes-required>
@@ -184,6 +208,7 @@ checks:
 
 ## Покрытие
 
+- **Execution:** <subagents | single>
 - **Completed:** <проверки и модели>
 - **Skipped:** <проверки и причины>
 - **Warnings:** <предупреждения или «нет»>
@@ -216,7 +241,7 @@ checks:
 
 ## Отклонено
 
-<Находки агентов, отклонённые при сверке: короткая формулировка, проверка-источник и причина. Если отклонённых нет — «нет».>
+<Кандидаты, отклонённые при сверке: короткая формулировка, проверка-источник и причина. Если отклонённых нет — «нет».>
 
 ```
 
@@ -224,14 +249,14 @@ checks:
 
 ## Финал
 
-Коротко сообщи путь к ревью, status, result, score, количество принятых и отклонённых находок, completed/skipped/warnings. При `changes-required` предложи `eda-fix-by-review`; при `clean` — `eda-commit`.
+Коротко сообщи путь к ревью, execution, status, result, score, количество принятых и отклонённых находок, completed/skipped/warnings. При `changes-required` предложи `eda-fix-by-review`; при `clean` — `eda-commit`.
 
 ## Чего НЕ делать
 
 - Править код, настройки проекта или удалённые обсуждения.
-- Выполнять специализированную роль главным агентом.
-- Запускать другой CLI или подменять отсутствующих субагентов одним общим ревью.
-- Записывать итоговый файл после повторного сбоя обязательного агента.
+- В `subagents` выполнять специализированную роль главным агентом или подменять отсутствующих субагентов одним общим ревью.
+- В `single` запускать leaf-субагентов, другой CLI или читать packaged prompts вместо `references/review-matrix.md`.
+- Записывать итоговый файл после повторного сбоя обязательного агента в `subagents` или незавершённой обязательной проверки в `single`.
 - Выбирать последний PR или весь репозиторий по ссылке на корень.
 - Загружать все карточки references без отбора.
 - Усреднять оценки агентов или считать score по фиксированной формуле.

package/skills/eda-review/references/review-matrix.md

@@ -0,0 +1,70 @@
+# Матрица проверок single-режима
+
+Этот файл используется только при `review.execution: single`. Выполни отдельный проход по каждой выбранной проверке, но читай общий target и проектные инструкции один раз. Не смешивай области: одна проблема должна остаться в наиболее точной проверке.
+
+Для любой находки обязательны точное место, достижимый на текущем коде сценарий, практический ущерб, доказательство, `repro`, способ исправления и нужный тест. Не принимай вкусовой рефакторинг, косметику, спекулятивное усиление, необязательный тест или проблему, которая появится только после гипотетического будущего изменения. Не перечисляй удачные решения и выполненные пункты.
+
+## correctness
+
+Ищи реальные ошибки поведения: неверную логику, потерю данных, неправильные состояния, пропущенные крайние случаи и некорректную обработку ошибок. Архитектуру, стиль, документацию, безопасность и план упоминай только когда они прямо доказывают функциональную ошибку.
+
+## architecture
+
+Проверяй границы модулей и слоёв, направление зависимостей, ответственность компонентов, публичные контракты и соответствие `docs/arch.md`. Находка допустима только когда решение уже создаёт неправильную связанность, нарушение границы или несовместимый контракт с конкретным практическим риском.
+
+## rules
+
+Проверяй только применимые инструкции из `AGENTS.md`, `CLAUDE.md` и `docs/rules.md` с учётом области действия и приоритета. Не выдумывай правила и не превращай предпочтение в нарушение. В evidence укажи правило и код, который ему противоречит.
+
+## references
+
+Проверяй только карточки из `$REFERENCE_FILES`; не загружай остальные `docs/references/` и внешние источники. Подтверждённое решение пользователя, правила и архитектура имеют приоритет. Отличие от примера без практического риска не является проблемой.
+
+## business
+
+Проверяй изменённое пользовательское и доменное поведение только по `$BUSINESS_FILES`. Не расширяй target требованиями соседних карточек. Различай:
+
+- реализация нарушает действующее правило, которое задача или план не меняют — дефект бизнес-логики;
+- задача или план явно меняют правило, но карточка не обновлена — рассинхронизация business-документации, которую нужно пересогласовать через `eda-business`.
+
+Если задача неизвестна, не объявляй правило намеренно изменённым, но продолжай сверку с действующей карточкой.
+
+## plan_alignment
+
+Проверяй только конкретный `$PLAN_FILE`: невыполненные или частично выполненные пункты, рискованные отклонения, забытые тесты, миграции и документацию, изменённые вопреки плану контракты. Не требуй буквального совпадения, если цель плана сохранена без дополнительного риска.
+
+## code_quality
+
+Проверяй читаемость, сложность, дублирование, имена, размер и ответственность функций или классов и сцепление модулей. Находка допустима только когда структура уже создаёт конкретный риск ошибок или тестовых пробелов и код обязательно нужно исправить; мелкие стилистические предпочтения не принимай.
+
+## tests
+
+Ищи пропущенные регрессии, неверные ожидания, неподходящий уровень теста, хрупкие проверки и изменённое поведение без защиты. Не требуй тест на каждую строку. Находка должна назвать конкретную регрессию, которую текущие тесты не поймают, либо ошибку в самих тестах. Для подтверждения разрешены только безопасные проверки, не меняющие tracked-файлы.
+
+## security
+
+Проверяй аутентификацию, авторизацию, границы доверия, валидацию внешнего ввода, инъекции, секреты, файлы, сеть, криптографию и утечки чувствительных данных. Учитывай реальную модель угроз и достижимость. Не проводи активные атаки и не принимай общий hardening без конкретного пути эксплуатации или нарушенного защитного инварианта.
+
+## performance
+
+Ищи N+1, лишние запросы и проходы, неограниченную обработку, чрезмерные аллокации, блокировки, ошибки кеширования и конкурентности. Свяжи риск с фактическим размером данных или частотой вызова. Не принимай микроптимизацию без измеримого или очевидного эффекта; безопасные измерения разрешены, если они не меняют tracked-файлы.
+
+## frontend
+
+Проверяй по исходникам компоненты, состояние, формы, действия, клиентские данные, loading/error/empty/success, адаптивность, стили и очевидные проблемы доступности. Рассмотри основные и ошибочные пользовательские сценарии. Не утверждай, что интерфейс проверен визуально: браузерная проверка относится к `eda-manual-test`.
+
+## api
+
+Проверяй обе стороны публичных и внутренних API-контрактов: методы и пути, request/query/body, response, коды ошибок, валидацию, auth, совместимость, идемпотентность и версионирование. Находка должна назвать нарушенный контракт и достижимо затронутого потребителя.
+
+## database
+
+Проверяй схемы, миграции, nullable/default, обратимость и совместимость выкладки, запросы, индексы, транзакции, блокировки и целостность данных. Учитывай существующие данные, конкурентные операции и порядок деплоя. Не выполняй миграции, не изменяй базу и не требуй индекс без обоснованного запроса и нагрузки.
+
+## documentation
+
+Ищи только обязательные обновления документации из-за изменившегося публичного API, CLI, конфигурации, установки, пользовательского сценария или проектного контракта. Сравни фактическое поведение с документами, которые его описывают. Не требуй комментарии для очевидных внутренних изменений и не проводи редакторское ревью текста.
+
+## previous_reviews
+
+Для удалённого PR/MR read-only средствами найди незакрытые комментарии и треды и сверь их с текущим кодом. Классифицируй их как актуальные, исправленные, но открытые, или недоступные для проверки. В находки включай только всё ещё существующие проблемы; исправленные открытые треды перенеси в покрытие. Не отправляй комментарии, не скрывай сводки, не resolve/close треды. Если сервис, авторизация или формат обсуждений недоступны, верни warning и не утверждай, что история проверена.