@gian-tiaga/eda 3.5.0 → 3.7.0

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`, `main` или `main_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`, `main` или `main_propagated` рядом с вызовом `eda-orhestra` задают `$EXECUTION` только для текущего запуска и важнее настроек. Поддерживай также формулировки «основным агентом» для `main` и «основным агентом с передачей» для `main_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. В `main_propagated` добавь `main` к итоговому вводу только совместимых шагов `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. В `main` и `main_propagated` выполняй контракт каждого активного шага, повтора и `on_failure.skill` сам в текущем контексте, строго последовательно. Не создавай для них верхнеуровневых субагентов; собственные правила вложенной делегации вызываемого скилла сохраняются.
+5. Не переключай `$EXECUTION` автоматически. В `subagents` при недоступной изоляции остановись с `blocked: недоступна изоляция этапа`; в main-режимах блокируйся только тогда, когда обязательная вложенная делегация недоступна по контракту самого шага.
 
 ## Технические остановки субагентов
 
-Техническую ошибку инструмента субагентов не смешивай со статусами `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`, явно напиши «полировка кода пропущена настройкой».
 
 ## Чего НЕ делать
 
-- Выполнять содержательную работу вместо настроенного скилла.
+- Обходить или сокращать контракт настроенного скилла из-за выбранного режима исполнения.
+- Передавать `main` скилам вне allowlist `eda-plan-execute`, `eda-polish`, `eda-review`.
 - Запускать отключённый или отсутствующий в цепочке шаг, кроме явно настроенного `on_failure.skill`.
 - Терять `args`, порядок или пути к артефактам при передаче.
 - Считать автоматические тесты заменой включённого `eda-manual-test`.

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

@@ -16,14 +16,14 @@ plan-execute:
   mode: auto
 ```
 
-`plan-execute.mode` принимает `subagents`, `single` или `auto`; при отсутствующем или невалидном значении используй `auto`. Файл настроек не изменяй.
+`plan-execute.mode` принимает `subagents`, `main` или `auto`; при отсутствующем или невалидном значении используй `auto`. Файл настроек не изменяй.
 
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом — главный вход. Разбери тему, путь к файлу, ограничения, прямые указания и режим:
 
 - `subagents`, `субагенты`, `по фазам`, `изолированно` → `$MODE=subagents`;
-- `single`, `один`, `одним контекстом`, `без субагентов`, `сам` → `$MODE=single`;
+- `main`, `один`, `одним контекстом`, `без субагентов`, `сам` → `$MODE=main`;
 - `auto`, `авто`, `автоматически` → `$MODE=auto`;
 - без явного режима → `$MODE=plan-execute.mode` из валидных настроек, иначе `$MODE=auto`.
 
@@ -36,22 +36,22 @@ plan-execute:
 | Режим | Кто выполняет фазу | Кто проверяет фазу и финал |
 |---|---|---|
 | `subagents` | отдельный изолированный субагент на каждую фазу | отдельные субагенты-проверяющие |
-| `single` | основной агент подряд в одном контексте | сам основной агент |
-| `auto` | решает по плану до старта: `single` или `subagents` | по выбранному режиму |
+| `main` | основной агент подряд в одном контексте | сам основной агент |
+| `auto` | решает по плану до старта: `main` или `subagents` | по выбранному режиму |
 
-`auto` выбирай `single`, только когда весь план реально помещается в один контекст: немного фаз, небольшой объём задач и файлов, одна область кода, нет тяжёлых по контексту фаз вроде крупного рефакторинга, миграции данных или множества карточек. Иначе — `subagents`; при сомнении тоже `subagents`. Решение и его причину запиши в журнал.
+`auto` выбирай `main`, только когда весь план реально помещается в один контекст: немного фаз, небольшой объём задач и файлов, одна область кода, нет тяжёлых по контексту фаз вроде крупного рефакторинга, миграции данных или множества карточек. Иначе — `subagents`; при сомнении тоже `subagents`. Решение и его причину запиши в журнал.
 
-В `single` следи за собственным контекстом. Если план оказался тяжелее оценки или контекст заканчивается, переключи оставшиеся фазы на `subagents`, запиши переключение в журнал и продолжи с текущей фазы.
+В `main` следи за собственным контекстом. Если план оказался тяжелее оценки или контекст заканчивается, переключи оставшиеся фазы на `subagents`, запиши переключение в журнал и продолжи с текущей фазы.
 
 ## Главные правила
 
-1. **В `subagents` основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты. В `single` основной агент выполняет фазы и проверки сам и остаётся единственным исполнителем.
+1. **В `subagents` основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты. В `main` основной агент выполняет фазы и проверки сам и остаётся единственным исполнителем.
 2. **Фазы выполняй строго последовательно.** Не начинай следующую, пока текущая не выполнена и её проверка не прошла.
 3. **В `subagents` одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Идентификатор исполнителя сохраняй и продолжай его же для вопросов и исправлений этой фазы.
 4. **Рамку читает тот, кто выполняет фазу.** Он целиком читает план, `docs/rules.md` и `docs/arch.md`. Для поведения своей фазы читает карточки из `sources.business`; у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки. Для затронутых компонентов так же выбирает технические карточки через `sources.references` или `docs/references.md`. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, он читает эту карточку целиком перед соответствующим изменением. Нерелевантные карточки не загружает.
-5. **Исполнитель не додумывает план.** Если в фазе не хватает решения, это вопрос пользователю или возврат в `eda-plan`, но не импровизация в коде. В `subagents` исполнитель возвращает `needs_input`, в `single` основной агент останавливается и спрашивает.
+5. **Исполнитель не додумывает план.** Если в фазе не хватает решения, это вопрос пользователю или возврат в `eda-plan`, но не импровизация в коде. В `subagents` исполнитель возвращает `needs_input`, в `main` основной агент останавливается и спрашивает.
 6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, `rules.md`, `arch.md` или reference-карточке, останови фазу и через `AskUserQuestion` спроси: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
-7. **Отмечай только подтверждённое.** Фазу закрывай только после выполнения и прошедшей проверки: в `subagents` это `completed` от исполнителя и отдельный `passed` от проверяющего, в `single` — пройденные критерии и команды проверки фазы с сохранённым выводом. При последующем опровержении верни отметку в незавершённое состояние.
+7. **Отмечай только подтверждённое.** Фазу закрывай только после выполнения и прошедшей проверки: в `subagents` это `completed` от исполнителя и отдельный `passed` от проверяющего, в `main` — пройденные критерии и команды проверки фазы с сохранённым выводом. При последующем опровержении верни отметку в незавершённое состояние.
 8. **Проверки нельзя подавлять.** Не отключай и не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, не добавляй игноры и не ослабляй команды и правила. Сначала исправляется причина падения, затем проверка повторяется.
 9. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
 
@@ -73,7 +73,7 @@ plan-execute:
 
 Через `AskUserQuestion` предложи текущую ветку, новую ветку от `main`, новую ветку от текущей или worktree от `main`. Если вызывающий оркестратор уже передал подтверждённый выбор, не спрашивай повторно.
 
-В `subagents` git-команды сам не выполняй: для новой ветки или worktree запусти отдельного субагента подготовки окружения; в `single` подготовь окружение сам. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. После успешного создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
+В `subagents` git-команды сам не выполняй: для новой ветки или worktree запусти отдельного субагента подготовки окружения; в `main` подготовь окружение сам. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. После успешного создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
 
 ### 3. Прочитать план и проверить фазы
 
@@ -83,7 +83,7 @@ plan-execute:
 
 ### 4. Определить режим и инициализировать прогресс
 
-Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим `single` или `subagents` до первой фазы. Дальше действуй по зафиксированному режиму.
+Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим `main` или `subagents` до первой фазы. Дальше действуй по зафиксированному режиму.
 
 Создай `$EXECUTION_FILE` по пути `docs/artifacts/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. В `$PLAN_FILE` добавь или актуализируй один раздел `## Прогресс выполнения` со ссылкой на журнал и списком фаз.
 
@@ -92,7 +92,7 @@ plan-execute:
 plan: <путь>
 started: <YYYY-MM-DD HH:MM>
 status: in_progress
-mode: subagents | single
+mode: subagents | main
 current_phase: <номер>
 ---
 
@@ -111,11 +111,11 @@ current_phase: <номер>
 ## Финальная проверка
 ```
 
-Журнал и отметки прогресса в плане ведёт только основной агент. В `single` записывай выбор режима с причиной, а в колонке «Исполнитель» — `основной агент`; в `subagents` явно запрети субагентам менять `$PLAN_FILE` и `$EXECUTION_FILE`.
+Журнал и отметки прогресса в плане ведёт только основной агент. В `main` записывай выбор режима с причиной, а в колонке «Исполнитель» — `основной агент`; в `subagents` явно запрети субагентам менять `$PLAN_FILE` и `$EXECUTION_FILE`.
 
 ### 5. Запускать изолированных субагентов
 
-Весь этап — только для `subagents`. В `single` пропусти его и выполняй фазы сам; переключился на `subagents` — вернись к нему.
+Весь этап — только для `subagents`. В `main` пропусти его и выполняй фазы сам; переключился на `subagents` — вернись к нему.
 
 В Codex используй `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция или субагенты недоступны, остановись: `blocked: недоступно изолированное выполнение`. Работу основным агентом не делай и CLI-fallback не добавляй.
 
@@ -165,7 +165,7 @@ questions: [<вопросы или пусто>]
 5. `blocked` — останови выполнение. Внешний блокер или изменение scope выноси вопросом; сам его не устраняй.
 6. После `completed` запусти независимую проверку фазы.
 
-В `single` перед первой фазой один раз прочитай план целиком, `docs/rules.md` и `docs/arch.md`, а карточки выбирай по правилу 4 под каждую фазу. Затем для каждой фазы по порядку выполни работу фазы, запиши в журнал сделанное, изменённые файлы и результаты проверок и переходи к проверке фазы. Не хватает решения — спроси пользователя; конфликт с правилами или карточками — останови фазу как `blocked`; та же причина падения дважды подряд без содержательного изменения — остановись: `blocked: выполнение не сходится`.
+В `main` перед первой фазой один раз прочитай план целиком, `docs/rules.md` и `docs/arch.md`, а карточки выбирай по правилу 4 под каждую фазу. Затем для каждой фазы по порядку выполни работу фазы, запиши в журнал сделанное, изменённые файлы и результаты проверок и переходи к проверке фазы. Не хватает решения — спроси пользователя; конфликт с правилами или карточками — останови фазу как `blocked`; та же причина падения дважды подряд без содержательного изменения — остановись: `blocked: выполнение не сходится`.
 
 ### 7. Проверять каждую фазу
 
@@ -185,13 +185,13 @@ references_read: [<пути или пусто>]
 
 При `failed` передай полный результат исполнителю этой фазы, поручи исправить подтверждённые проблемы и запусти нового проверяющего. Основной агент код не чинит и контекст прежнего проверяющего не переиспользует.
 
-В `single` сам выполни все проверки фазы и сверь результат с критериями плана, а не с собственным впечатлением. Падение исправляй и повторяй проверку заново целиком.
+В `main` сам выполни все проверки фазы и сверь результат с критериями плана, а не с собственным впечатлением. Падение исправляй и повторяй проверку заново целиком.
 
 При `passed` отметь фазу завершённой и только тогда переходи к следующей.
 
 ### 8. Финальная проверка
 
-После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. В `subagents` это делает отдельный новый субагент: он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения. В `single` тот же полный набор запускает основной агент.
+После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. В `subagents` это делает отдельный новый субагент: он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения. В `main` тот же полный набор запускает основной агент.
 
 Падение из-за сделанных изменений сопоставь с фазами и исправь по порядку плана: в `subagents` передай каждую группу исполнителю соответствующей фазы. Затем повтори всю финальную проверку целиком. Чужую или несвязанную поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 
@@ -205,7 +205,7 @@ references_read: [<пути или пусто>]
 
 - В `subagents` самому менять код, тесты, миграции, конфиги и зависимости или самому запускать проверки проекта.
 - В `subagents` дробить фазу между исполнителями, давать одному исполнителю несколько фаз, давать субагентам историю диалога или разрешать менять план и журнал.
-- Выполнять большой или тяжёлый по контексту план в `single`, если режим не задан явно.
+- Выполнять большой или тяжёлый по контексту план в `main`, если режим не задан явно.
 - Запускать следующую фазу до успешной проверки текущей.
 - Додумывать недостающее решение вместо вопроса.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.

package/skills/eda-polish/SKILL.md

@@ -5,20 +5,18 @@ description: 'Итеративно ревьюит и исправляет изм
 
 # Скил: Полировка изменений (eda-polish)
 
-Оркестрируй цикл `eda-review` → `eda-fix-by-review` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат. В начале каждой итерации запускай полное `eda-review` целевого изменения.
+Оркестрируй цикл `eda-review` → `eda-fix-by-review` → повторное `eda-review`. В `subagents` основной агент только управляет итерациями; в `main` он сам последовательно выполняет контракты review и fix в текущем контексте. В начале каждой итерации выполняй полное `eda-review` целевого изменения.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций и ограничения. Передавай в каждый `eda-review` разовые overrides проверок и моделей из запроса пользователя.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций, ограничения и режим `subagents` или `main`. Явный режим важнее `review.execution` из полного `docs/settings.yaml` версии 3; при отсутствии валидного значения используй `subagents`. Передавай выбранный режим и overrides проверок и моделей в каждый `eda-review`.
 
 Лимит по умолчанию — `5` итераций; пользователь может задать `limit N` положительным целым числом. Порога у цикла нет: устаревшие `threshold N`, `до 90` и `цель 90` не применяй и скажи об этом в финале.
 
 ## Правила
 
-1. Каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
-   - В Claude Code вызывай установленный `eda-review` именно через `Skill`: его отрендеренная копия содержит `context: fork` и сама создаёт изолированный review-runner. Не читай инструкцию `eda-review` в текущий контекст, не воспроизводи её процедуру самостоятельно и не запускай `eda-review-*` агентов напрямую из полировщика.
-   - В Codex каждый вызов `eda-review` и `eda-fix-by-review` запускай через `spawn_agent` с `fork_turns: "none"`. Не оставляй `fork_turns` по умолчанию и не используй `"all"`: субагент получает только самодостаточное task-сообщение и явно указанные пути к артефактам.
-2. Если нативные субагенты недоступны, остановись; не заменяй шаги CLI-процессами.
+1. В `main` основной агент сам выполняет установленные контракты `eda-review` и `eda-fix-by-review` в текущем контексте. Не запускай для них верхнеуровневых или leaf-субагентов и не заменяй их отдельным CLI.
+2. В `subagents` каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. В Claude Code используй `Agent`, в Codex — `spawn_agent` с `fork_turns: "none"`; не оставляй `fork_turns` по умолчанию и не используй `"all"`. Если нативные субагенты недоступны, остановись без CLI-fallback.
 3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean` и ноль находок. Score — только справочное число, условием завершения он не является.
 4. Любая находка обязательно исправляется. Отклонить находку может только `eda-fix-by-review` и только при её фактической неверности.
 5. Не коммить и не отправляй ревью.
@@ -26,7 +24,7 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Технические остановки субагентов
 
-Техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
+В `subagents` техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
 
 - лимит параллельности или отсутствие свободного слота — дождись уже запущенного этим workflow агента, при необходимости закрой завершённые потоки и повтори тот же запуск; если управляемых активных агентов нет, заверши `blocked: заняты слоты субагентов`;
 - лимит глубины вложения — не повторяй запуск и не выполняй этап сам; заверши `blocked: достигнут лимит глубины субагентов`, указав наблюдаемую и требуемую глубину;
@@ -39,19 +37,20 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Вопросы
 
-Если target неоднозначен, передай управление первому `eda-review`: он задаст один конкретный вопрос по правилам своей среды. Если шаг вернул `blocked`, основной агент повторяет только этот вопрос и после ответа продолжает тот же шаг.
+Если target неоднозначен, первый `eda-review` задаёт один конкретный вопрос по правилам своей среды. Если шаг вернул `blocked`, основной агент повторяет только этот вопрос и после ответа продолжает тот же шаг.
 
 ## Цикл
 
-Сформируй `$TARGET_CONTEXT`, `$LIMIT` и журнал: номер итерации, review file, result, число открытых находок, список находок, fix report и причина продолжения.
+Сформируй `$TARGET_CONTEXT`, `$EXECUTION`, `$LIMIT` и журнал: номер итерации, review file, result, число открытых находок, список находок, fix report и причина продолжения.
 
 Для каждой итерации:
 
-1. Запусти отдельного субагента:
+1. В `main` выполни `eda-review` сам; в `subagents` запусти отдельного субагента:
 
    ```text
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
+   Режим исполнения review: <main | subagents | из настроек>.
    Overrides проверок и моделей: <из запроса | none>.
    Ранее отклонённые находки: <предыдущий review file и fix report | none>.
    Верни путь к файлу, status, result, score, находки и coverage.
@@ -59,7 +58,7 @@ description: 'Итеративно ревьюит и исправляет изм
 
 2. Если review остановился из-за обязательного агента, останови цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён.
 3. Если `result: clean` и находок нет, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
-4. Если находки есть, запусти отдельного субагента:
+4. Если находки есть, в `main` выполни `eda-fix-by-review` сам; в `subagents` запусти отдельного субагента:
 
    ```text
    Используй eda-fix-by-review для <REVIEW_FILE>.
@@ -74,11 +73,11 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Финал
 
-Сообщи результат, итоговый result и score, число итераций, счётчик находок по кругам («было 12, осталось 3»), последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
+Сообщи `$EXECUTION`, результат, итоговый result и score, число итераций, счётчик находок по кругам («было 12, осталось 3»), последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
 
 ## Чего НЕ делать
 
-- Делать ревью или исправления основным агентом.
+- В `subagents` делать ревью или исправления основным агентом.
 - Запускать отдельный этап проверки готового ревью.
 - Считать цикл успешным при наличии находок или завершать его по score.
 - Выбирать или отклонять находки основным агентом: отклонение — работа `eda-fix-by-review`.

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. Финал