@gian-tiaga/eda 3.9.0 → 3.9.2

package/README.md

@@ -47,7 +47,7 @@ eda update-all ~/Code
 | `eda-business` | Совместно с человеком описывает целевое поведение проекта по тематическим карточкам: сложные темы фиксирует подробно, но без шума, соседних модулей и привязки к текущему коду. Может закрепить значимый механизм вроде JWT или серверного хранения токенов, но не язык, библиотеку или конкретную СУБД. `about` содержит лишь короткое описание проекта и основные возможности | `docs/business.md`, `docs/business/` |
 | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/artifacts/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. После определения темы читает только применимые business- и reference-карточки. В дефолтном режиме ведёт исследование как диалог; для пакетов и ПО проверяет актуальные стабильные версии | `docs/artifacts/researches/` |
-| `eda-plan` | Пишет план реализации через Plan Mode: фиксирует решения, БД/API-контракты и фазы, каждую из которых один агент выполняет и проверяет за один проход. Задач с идентификаторами внутри фаз нет. Реализацию не описывает — её задают `docs/rules.md`, `docs/arch.md` и карточки. Если целевое поведение ещё не описано в business-карточках, до реализации добавляет `Дополнить бизнесовые правила`; если решение противоречит правилам или архитектуре, сначала меняет сам документ. По `plan.review` запускает изолированный `eda-plan-polish` ровно на одну итерацию полировки (`limit 1`); `plan.strict` независимо включает кросс-CLI ревью | `docs/artifacts/plans/`, опционально plan-review артефакты |
+| `eda-plan` | Пишет план реализации через Plan Mode: фиксирует решения, БД/API-контракты и фазы, каждую из которых один агент выполняет и проверяет за один проход. На подтверждение показывает полный план в формате скила, включая метаданные, разделы и структуру фаз; сохраняет тот же текст. Задач с идентификаторами внутри фаз нет. Реализацию не описывает — её задают `docs/rules.md`, `docs/arch.md` и карточки. Если целевое поведение ещё не описано в business-карточках, до реализации добавляет `Дополнить бизнесовые правила`; если решение противоречит правилам или архитектуре, сначала меняет сам документ. По `plan.review` запускает изолированный `eda-plan-polish` ровно на одну итерацию полировки (`limit 1`); `plan.strict` независимо включает кросс-CLI ревью | `docs/artifacts/plans/`, опционально plan-review артефакты |
 | `eda-plan-review` | Одним read-only проходом проверяет план по фиксированному чек-листу из 16 пунктов: покрытие запроса, отсутствие развилок, соответствие правилам и архитектуре, дубли, регистр текста, фазы и объём. Замечания вне списка не принимает. Оценка — доля закрытых пунктов, поэтому растёт монотонно. План не меняет | `docs/artifacts/plan-reviews/` |
 | `eda-plan-review-fix` | Закрывает проваленные пункты чек-листа минимальным изменением плана с совпадающим SHA-256. План не растёт: сначала удаление и замена, прирост объёма за один заход не больше 3%. Новое ревью не делает и код не меняет | `docs/artifacts/plan-review-fixes/` |
 | `eda-plan-polish` | Оркестрирует изолированный цикл plan-review → plan-review-fix. Хранит снапшот лучшей версии плана: как только score перестаёт расти, останавливается и восстанавливает лучшую версию, а не последнюю. По умолчанию одна итерация: проверка и исправление. Исправление проверяет ревью следующей итерации, поэтому при `limit 1` последняя правка остаётся неперепроверенной. Кросс-CLI strict не используется | `docs/artifacts/plan-reviews/`, `docs/artifacts/plan-review-fixes/` |
@@ -127,6 +127,8 @@ eda update-all ~/Code
 
 У `eda-plan-execute` есть режимы `subagents` / `main` / `auto`. Режим можно разово указать в вызове, например `eda-plan-execute main docs/artifacts/plans/....md`; без него используется `plan-execute.mode` из настроек, а без настроек — `auto`.
 
+Выбранный режим исполнения обязателен для `eda-plan-execute`, `eda-review`, `eda-polish` и `eda-orhestra`. При `main` из вызова или настроек агент не может перейти к субагентам из-за большого плана, diff или нехватки контекста. Прогресс и режим сохраняются для продолжения после сжатия контекста; при технической невозможности продолжить агент сообщает блокер. Выбор по размеру плана разрешён только в `eda-plan-execute auto` до начала выполнения. Зафиксированный режим меняется только по новому прямому указанию пользователя; `automatic` оркестратора такого права не даёт. У оркестратора `main` по-прежнему управляет только верхней цепочкой, а `main_propagated` также передаёт `main` совместимым execute/review-этапам; остальные вложенные контракты сохраняются.
+
 У `eda-aim` есть режимы `automatic` / `manual`. В автоматическом основной агент сам отвечает на безопасные рабочие вопросы по рекомендации субагента и фактам проекта, в ручном передаёт их человеку. Режим можно разово указать в вызове; без него используется `aim.mode` из настроек. Точный список новых целей перед записью в `docs/artifacts/aims/` всё равно один раз подтверждает человек.
 
 Скилы, которых нет в таблице ниже, не поддерживают эти флаги. Набор проверок `eda-review` отдельно управляется через `review.agents`.
@@ -138,7 +140,7 @@ eda update-all ~/Code
 | `eda-explore` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью конкретности, фактов, развилок, рисков и версий; затем доправляет отчёт по замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
 | `eda-plan` | `strict`, `без ревью плана`, `без проверок` | `strict` независимо включает кросс-CLI проверку; `без ревью плана` отключает встроенный review/fix; `без проверок` отключает оба вида ревью | Когда нужно разделить создание плана и его последующую полировку |
 | `eda-plan-review` | `threshold N` | Разово меняет долю закрытых пунктов, при которой план считается готовым | Для самостоятельного аудита готового плана |
-| `eda-plan-execute` | `subagents` / `main` / `auto` | Разово меняет, где выполняются фазы, поверх `plan-execute.mode` | `main` для небольшого плана в одном контексте, `subagents` для большого или тяжёлого |
+| `eda-plan-execute` | `subagents` / `main` / `auto` | Разово меняет, где выполняются фазы, поверх `plan-execute.mode` | `main` для обязательного выполнения основным агентом, `subagents` для изолированных фаз, `auto` для выбора по размеру плана |
 | `eda-plan-polish` | `threshold N`, `limit N` | Меняет gate и максимальное число итераций «проверка + исправление» | Для доводки ответственных планов перед `eda-plan-execute` |
 | `eda-manual-test` | `full` / `полная проверка`, `smoke` / `быстро` | Разово меняет глубину ручной проверки поверх `manual-test.depth` | `smoke` для короткой правки, `full` — когда нужно закрыть все области после плана |
 | `eda-review` | `subagents` / `main` | Разово меняет способ выполнения выбранных проверок поверх `review.execution` | `main` экономит контекст на частых локальных ревью; `subagents` сохраняет независимость ролей для ответственных изменений |

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

@@ -34,9 +34,9 @@
 До любых изменений индекса:
 
 1. Проверь `git status`, staged и unstaged diff, включая содержимое релевантных untracked-файлов.
-2. Прочитай последние 5–10 коммитов и определи наблюдаемый стиль сообщений.
-3. Получи текущую ветку, upstream, remotes и основную ветку из `origin/HEAD`.
-4. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и связанные артефакты из `docs/**`, если они есть и применимы к изменениям.
+2. Получи текущую ветку, upstream, remotes и основную ветку из `origin/HEAD`.
+3. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и связанные артефакты из `docs/**`, если они есть и применимы к изменениям.
+4. Определи форму сообщений по разделу «Форма сообщений».
 5. Проверяй существующий PR текущей ветки, когда `USER_REQUEST` или `REQUESTED_ACTIONS` упоминает PR или push. Если предстоит создание или обновление PR, найди применимый шаблон PR в репозитории и прочитай его целиком.
 6. Определи состав коммита:
    - если `COMMIT_SCOPE` непустой, выбери соответствующий ему логический набор и отдели несвязанные пользовательские изменения;
@@ -53,6 +53,17 @@
 2. Определи порядок по зависимостям: базовые изменения раньше потребителей. Каждый выбранный файл должен попасть ровно в одну группу. Если один файл содержит изменения нескольких групп и безопасно разделить его без правки рабочего дерева нельзя, помести файл в наиболее подходящую группу и не блокируй весь дефолтный запуск только из-за этого.
 3. Зафиксируй исходное состояние индекса. Уже staged-файлы могут относиться к разным будущим группам или лежать вне `COMMIT_SCOPE`; их staging нельзя потерять или случайно включить не в тот коммит.
 
+## Форма сообщений
+
+Форму сообщения задаёт проект, а не ты.
+
+- Бери форму только из `AGENTS.md`, `CLAUDE.md` и `docs/rules.md`: язык текста, вид заголовка, префиксы вроде `feat:`, структуру и обязательные части тела.
+- Если ни один из этих трёх файлов о сообщениях не говорит, повтори форму 2–3 последних коммитов.
+- Остальные документы проекта форму не задают. Язык твоих инструкций и общения с пользователем — тоже.
+- Та же форма действует для заголовка и описания PR.
+
+Форма отвечает только на вопрос «как написано». Что написать, бери из фактического кандидата коммита: что в этой группе стало другим и зачем.
+
 ## Создать коммиты
 
 Для каждой группы последовательно:
@@ -60,7 +71,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 символов должен конкретно называть результат группы, а не повторять имя ветки, список файлов или общие слова вроде `changes`, `updates` и «правки». Если причина или важное изменение поведения не очевидны из заголовка, добавь короткое тело. Описывай только фактический кандидат коммита и не приписывай ему изменения или проверки из других групп.
+4. Составь отдельное сообщение: форма — по разделу «Форма сообщений», содержание — по фактическому кандидату. Заголовок до примерно 70 символов должен конкретно называть результат группы, а не повторять имя ветки, список файлов или общие слова вроде `changes`, `updates` и «правки». Если причина или важное изменение поведения не очевидны из заголовка, добавь короткое тело. Описывай только фактический кандидат коммита и не приписывай ему изменения или проверки из других групп.
 5. Выполни `git commit` выбранным изолированным способом без `--amend`, `--no-verify` и `--no-gpg-sign`. Проверь фактический состав нового commit, сохрани hash, subject и files, затем переходи к следующей группе.
 
 После последнего коммита проверь, что из выбранного состава ничего не осталось. Только затем выполняй действия после коммитов.
@@ -71,7 +82,7 @@
 
 Выполни `REQUESTED_ACTIONS` по порядку без повторного вопроса. Явное «создай PR» разрешает обычный push текущей ветки как необходимую предпосылку.
 
-Для создания или явно запрошенного обновления PR составь заголовок и описание по полному `USER_REQUEST`, фактическим коммитам текущей ветки относительно base и итоговому diff. Не своди PR к копии последнего commit message, если коммитов несколько.
+Для создания или явно запрошенного обновления PR составь заголовок и описание по полному `USER_REQUEST`, фактическим коммитам текущей ветки относительно base и итоговому diff. Форму текста бери из раздела «Форма сообщений», состав разделов — из шаблона PR. Не своди PR к копии последнего commit message, если коммитов несколько.
 
 - Явно заданные пользователем заголовок, текст или обязательные разделы имеют приоритет. Иначе следуй найденному шаблону PR; если шаблона нет, дай короткое описание цели, список фактических изменений и раздел проверки.
 - Заголовок должен описывать общий результат PR конкретно и без имени ветки, номера коммита, служебных префиксов или общих формулировок вроде `updates` и «изменения».

package/package.json

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

package/skills/eda-commit/SKILL.md

@@ -75,7 +75,7 @@ COMMIT_SCOPE:
 Верни результат строго по YAML-контракту агента.
 ```
 
-Агент сам собирает git-контекст, читает правила и историю, формирует сообщения коммитов и тексты PR по исходному запросу и фактическому diff, точечно коммитит и выполняет разрешённое продолжение. При непустом `$COMMIT_SCOPE` он выбирает соответствующий состав. При пустом `$COMMIT_SCOPE` включает все tracked-изменения и содержательные untracked-файлы, исключая только очевидные кэши, временные, системные и локальные служебные артефакты. Выбранный состав он сам делит на необходимое число логически цельных коммитов и создаёт их по порядку; несколько задач в полном дефолтном наборе не являются причиной для вопроса. При вероятном секрете или другой реальной небезопасности он обязан вернуть `blocked` до индексации затронутой группы.
+Агент сам собирает git-контекст, читает правила и историю, формирует сообщения коммитов и тексты PR по исходному запросу и фактическому diff, точечно коммитит и выполняет разрешённое продолжение. Форму этих текстов — язык, вид заголовка, префиксы, части тела — он берёт из `AGENTS.md`, `CLAUDE.md` и `docs/rules.md`, а если там о сообщениях ничего нет — из последних коммитов. Содержание берётся из фактического diff. При непустом `$COMMIT_SCOPE` он выбирает соответствующий состав. При пустом `$COMMIT_SCOPE` включает все tracked-изменения и содержательные untracked-файлы, исключая только очевидные кэши, временные, системные и локальные служебные артефакты. Выбранный состав он сам делит на необходимое число логически цельных коммитов и создаёт их по порядку; несколько задач в полном дефолтном наборе не являются причиной для вопроса. При вероятном секрете или другой реальной небезопасности он обязан вернуть `blocked` до индексации затронутой группы.
 
 Явная команда пользователя разрешает обычные ожидаемые действия и безопасные предпосылки в её рамках. Например, «создай PR» разрешает обычный push текущей ветки, если без него PR создать нельзя. Она не разрешает force-push, публикацию секретов или другое не названное рискованное действие.
 

package/skills/eda-orhestra/SKILL.md

@@ -89,6 +89,7 @@ orhestra:
 - Для `eda-plan` добавь `decision_mode: autonomous`; значения `ask_each_time` для размера, тестов и логирования замени соответственно на `normal`, `after_each_phase`, `standard`, если текущий вызов не задаёт другое.
 - Для вопроса `eda-plan-execute` о месте выполнения выбирай текущую ветку, если пользователь явно не запросил ветку или worktree.
 - Не спрашивай о переходе между успешными шагами.
+- `automatic` управляет ответами на рабочие вопросы и не разрешает менять выбранный режим исполнения оркестратора или вложенного скила. Не передавай от себя `auto` или `subagents` вместо заданного `main` из-за размера плана, diff или нехватки контекста.
 
 Автоматический режим не разрешает необратимые внешние действия, расширение scope, публикацию, расходы, удаление данных, ослабление проверок вне настроенной цепочки или изменение production/staging. Дефолтное `без проверок` у `eda-plan` не считай ослаблением: следующий обязательный `eda-plan-polish` выполняет проверку и доводку плана. Подтверждение из-за риска передай человеку; в неинтерактивной среде остановись с `blocked: нужен ответ пользователя`. Обратимые решения плана, включая БД/API-контракты и подтверждение готового плана, выбирай сам.
 
@@ -111,7 +112,7 @@ orhestra:
 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-режимах блокируйся только тогда, когда обязательная вложенная делегация недоступна по контракту самого шага.
+5. Не переключай `$EXECUTION` автоматически. Зафиксируй режим и его источник до первого шага и сохраняй их после сжатия контекста. Размер задачи и нехватка контекста не разрешают делегацию вопреки выбранному режиму; сменить его может только новое прямое указание пользователя. В `subagents` при недоступной изоляции остановись с `blocked: недоступна изоляция этапа`; в main-режимах при технической невозможности продолжить сохрани прогресс и конкретный блокер без смены режима. Обязательная вложенная делегация по контракту самого шага сохраняется.
 
 ## Технические остановки субагентов
 

package/skills/eda-plan/SKILL.md

@@ -5,7 +5,7 @@ description: 'Создаёт понятный исполнимый план ре
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/artifacts/plans/` и делишь работу на фазы, каждую из которых один агент выполняет и проверяет за один проход. По настройкам запускаешь `eda-plan-polish`, а в strict — независимую кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, приводишь план к формату скила до подтверждения пользователем и сохраняешь подтверждённый текст в `docs/artifacts/plans/`. Делишь работу на фазы, каждую из которых один агент выполняет и проверяет за один проход. По настройкам запускаешь `eda-plan-polish`, а в strict — независимую кросс-CLI проверку.
 
 ## Режим запуска
 
@@ -98,14 +98,16 @@ description: 'Создаёт понятный исполнимый план ре
 4. Найденные версии пакетов и источники.
 5. Пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам и research с выпиской обязательных требований рамки.
 6. Требование: план следует правилам, архитектуре и применимым эталонам. Если нужное решение им противоречит, план сначала меняет сам документ отдельным пунктом, а не отклоняется от него.
-7. Требование: план нормализуется в структуру ниже и делится на фазы, каждую из которых один агент выполняет и проверяет за один проход.
+7. Требование: уже на подтверждение пользователь получает полный план по шаблону этапа 3, включая YAML front matter, все разделы в заданном порядке и фазы с полями «Цель», «Что сделать», «Результат», «Проверка». Это формат и показа в Plan Mode, и сохраняемого файла.
 8. Требование: конкретика не равна максимальной подробности. План описывает, что и зачем меняется, а не как это написать: не пересказывать запрос и существующий код, не повторять один контракт в нескольких разделах, не выдумывать пути, символы или API ради видимости конкретики. Реализацию задают `docs/rules.md`, `docs/arch.md` и карточки.
 
-Не выходи из Plan Mode, пока пользователь не подтвердил план.
+До запроса подтверждения нормализуй план и прогони quality gate из этапа 3. Покажи полный текст плана в формате скила; краткое резюме, список главных шагов или ссылка на файл не заменяют план на подтверждение. При правках пользователя обнови план и снова предъяви его целиком в том же формате. Не выходи из Plan Mode, пока пользователь не подтвердил план.
 
-### 3. Нормализовать и сохранить
+### 3. Сохранить подтверждённый план
 
-Сохрани подтверждённый план в `docs/artifacts/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Смысл решений не меняй без вопроса, форму и ясность правь обязательно.
+Сохрани подтверждённый план в `docs/artifacts/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md` с теми же содержанием и структурой, которые показал пользователю. Нормализация формы и ясности должна быть завершена до подтверждения.
+
+Единый шаблон для показа на подтверждение и сохранения:
 
 ```markdown
 ---
@@ -179,7 +181,7 @@ sources:
 - Риски и порядок выполнения отдельными разделами не выносятся: закрытые риски встраиваются в решения, фазы, тесты и проверки.
 - Раздела `Открытые вопросы` в плане нет. Незакрытая развилка — это блокирующий вопрос пользователю до сохранения, а не пункт в файле.
 
-Quality gate перед сохранением и после каждой включённой проверки:
+Quality gate перед показом на подтверждение, перед сохранением и после каждой включённой проверки:
 
 - есть `Целевой алгоритм` и `Контракты реализации` с обоими подразделами;
 - применимые business-карточки выбраны после определения scope, записаны в `sources.business` и отражены в критериях приёмки;
@@ -230,7 +232,7 @@ codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md и прим
 
 ### 6. Финал
 
-Коротко сообщи режим, выполнялись ли polish и strict, путь к плану, пути к последним артефактам проверок, итоговый статус, открытые вопросы, 3–5 главных шагов и что дальше делает `eda-plan-execute`.
+Коротко сообщи режим, выполнялись ли polish и strict, путь к плану, пути к последним артефактам проверок, итоговый статус, открытые вопросы, 3–5 главных шагов и что дальше делает `eda-plan-execute`. Если требуется повторное подтверждение плана, предъяви полный актуальный текст по шаблону этапа 3.
 
 ## Чего НЕ делать
 

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

@@ -22,13 +22,15 @@ plan-execute:
 
 Текст рядом с вызовом — главный вход. Разбери тему, путь к файлу, ограничения, прямые указания и режим:
 
-- `subagents`, `субагенты`, `по фазам`, `изолированно` → `$MODE=subagents`;
+- `subagents`, `субагенты`, `изолированно` → `$MODE=subagents`;
 - `main`, `один`, `одним контекстом`, `без субагентов`, `сам` → `$MODE=main`;
 - `auto`, `авто`, `автоматически` → `$MODE=auto`;
 - без явного режима → `$MODE=plan-execute.mode` из валидных настроек, иначе `$MODE=auto`.
 
 Режим из вызова важнее настройки, настройка важнее умолчания.
 
+Считай override только прямым указанием способа выполнения этого скила. «По фазам» описывает порядок работы, а `automatic` оркестратора и слово «автоматически» без явного выбора режима исполнения не задают `$MODE=auto`.
+
 Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных планов или есть риск выполнить не тот план.
 
 ## Режимы выполнения
@@ -41,7 +43,9 @@ plan-execute:
 
 `auto` выбирай `main`, только когда весь план реально помещается в один контекст: немного фаз, небольшой объём задач и файлов, одна область кода, нет тяжёлых по контексту фаз вроде крупного рефакторинга, миграции данных или множества карточек. Иначе — `subagents`; при сомнении тоже `subagents`. Решение и его причину запиши в журнал.
 
-В `main` следи за собственным контекстом. Если план оказался тяжелее оценки или контекст заканчивается, переключи оставшиеся фазы на `subagents`, запиши переключение в журнал и продолжи с текущей фазы.
+Выбранный режим обязателен: `main` из вызова, `plan-execute.mode` или переданного оркестратором override запрещает делегацию независимо от размера плана. Критерии объёма выше применяй только при `$MODE=auto`; не переоценивай по ним явно заданный режим. После выбора в `auto` итоговый режим также зафиксирован. Менять его можно только по новому прямому указанию пользователя; решение оркестратора в `automatic` не заменяет такого указания.
+
+В `main` не запускай `spawn_agent`, `Agent`, аналогичные инструменты или отдельный CLI для делегирования подготовки, фаз и проверок. При нехватке контекста сохрани текущую фазу, незавершённую работу, результаты проверок и режим в журнале; после сжатия контекста продолжай основным агентом с этого места. Если продолжить в выбранном режиме технически невозможно, сохрани `status: blocked` с причиной. Размер плана, желание ускорить работу и предположение о нехватке контекста сами по себе не являются блокером или разрешением сменить режим.
 
 ## Главные правила
 
@@ -83,7 +87,7 @@ plan-execute:
 
 ### 4. Определить режим и инициализировать прогресс
 
-Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим `main` или `subagents` до первой фазы. Дальше действуй по зафиксированному режиму.
+Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим `main` или `subagents` до первой фазы. Дальше действуй по зафиксированному режиму. Перед выполнением коротко сообщи режим и его источник: вызов, override оркестратора, `plan-execute.mode` или default; сохрани их в журнале. Для `auto` также запиши причину выбора. При продолжении после сжатия контекста восстанови зафиксированный режим из журнала, если пользователь не изменил его прямо.
 
 Создай `$EXECUTION_FILE` по пути `docs/artifacts/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. В `$PLAN_FILE` добавь или актуализируй один раздел `## Прогресс выполнения` со ссылкой на журнал и списком фаз.
 
@@ -115,7 +119,7 @@ current_phase: <номер>
 
 ### 5. Запускать изолированных субагентов
 
-Весь этап — только для `subagents`. В `main` пропусти его и выполняй фазы сам; переключился на `subagents` — вернись к нему.
+Весь этап — только для `subagents`. В `main` пропусти его и выполняй фазы сам.
 
 В Codex используй `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция или субагенты недоступны, остановись: `blocked: недоступно изолированное выполнение`. Работу основным агентом не делай и CLI-fallback не добавляй.
 
@@ -205,7 +209,7 @@ references_read: [<пути или пусто>]
 
 - В `subagents` самому менять код, тесты, миграции, конфиги и зависимости или самому запускать проверки проекта.
 - В `subagents` дробить фазу между исполнителями, давать одному исполнителю несколько фаз, давать субагентам историю диалога или разрешать менять план и журнал.
-- Выполнять большой или тяжёлый по контексту план в `main`, если режим не задан явно.
+- Самостоятельно менять зафиксированный режим или применять критерии `auto` к `main` из вызова, настроек либо override оркестратора.
 - Запускать следующую фазу до успешной проверки текущей.
 - Додумывать недостающее решение вместо вопроса.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.

package/skills/eda-polish/SKILL.md

@@ -15,6 +15,8 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Правила
 
+Зафиксируй режим и его источник до первой итерации. Выбор из вызова, override оркестратора или `review.execution` обязателен на весь цикл: большой diff, число проверок и нехватка контекста не разрешают переход к субагентам. Сохраняй режим и прогресс после сжатия контекста; если продолжить технически невозможно, верни конкретный блокер без смены режима. Менять режим можно только по новому прямому указанию пользователя.
+
 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 — только справочное число, условием завершения он не является.
@@ -50,7 +52,7 @@ description: 'Итеративно ревьюит и исправляет изм
    ```text
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
-   Режим исполнения review: <main | subagents | из настроек>.
+   Режим исполнения review: <$EXECUTION: main | subagents>.
    Overrides проверок и моделей: <из запроса | none>.
    Ранее отклонённые находки: <предыдущий review file и fix report | none>.
    Верни путь к файлу, status, result, score, находки и coverage.

package/skills/eda-review/SKILL.md

@@ -28,6 +28,8 @@ description: 'Проводит полное read-only ревью diff, ветк
 
 Default — `subagents`. При неизвестном или отсутствующем значении используй default и добавь предупреждение. Сначала выбери `$EXECUTION` по явному режиму из текущего сообщения, затем по настройке, иначе по default.
 
+Зафиксируй режим и его источник до первой проверки. Выбор из вызова, override оркестратора или `review.execution` обязателен: большой diff, число проверок и нехватка контекста не разрешают переход к субагентам. Сохраняй режим и прогресс после сжатия контекста; если продолжить технически невозможно, верни конкретный блокер без смены режима. Менять режим можно только по новому прямому указанию пользователя. `auto` у отдельной проверки ниже определяет её применимость и не меняет `$EXECUTION`.
+
 Допустимые режимы:
 
 - `always` — запускать при каждом ревью;