@gian-tiaga/eda 3.9.1 → 3.10.0

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` сохраняет независимость ролей для ответственных изменений |
@@ -223,8 +225,8 @@ plan:
   # Определяет, как eda-plan принимает существенные решения.
   # autonomous | recommend_and_ask | ask_each_time
   decision_mode: recommend_and_ask
-  # Задаёт стратегию тестов.
-  # after_each_phase | tdd_each_phase | end_of_plan | ask_each_time
+  # Задаёт стратегию тестов и автоматических проверок.
+  # after_each_phase | phase_tests_final_checks | tdd_each_phase | end_of_plan | ask_each_time
   test_strategy: ask_each_time
   # Задаёт стратегию логирования.
   # debug_precise | standard | ask_each_time
@@ -398,7 +400,7 @@ discover-automations:
 - `aim.mode` — `automatic` самостоятельно выбирает безопасные ответы на рабочие вопросы; `manual` передаёт вопросы человеку. Явный режим в текущем вызове имеет приоритет.
 - `explore.strict` и `explore.decision_mode` — кросс-CLI ревью и способ выбора по исследовательским развилкам в `eda-explore`.
 - `plan.review` — изолированный цикл `eda-plan-polish` внутри `eda-plan`, ровно одна итерация полировки (`limit 1`); `plan.strict` независимо управляет кросс-CLI ревью.
-- `plan.size`, `plan.decision_mode`, `plan.test_strategy`, `plan.logging_strategy` — режим и структура работы `eda-plan`.
+- `plan.size`, `plan.decision_mode`, `plan.test_strategy`, `plan.logging_strategy` — режим и структура работы `eda-plan`. Имя `test_strategy` сохранено для совместимости, но настройка управляет и тестами, и автоматическими проверками: `after_each_phase` запускает их после каждой фазы, `tdd_each_phase` сначала пишет тесты и после реализации запускает все проверки фазы, `phase_tests_final_checks` в фазе запускает только добавленные или изменённые ею тесты, а остальные проверки оставляет финалу, `end_of_plan` переносит тесты и автоматические проверки в конец плана.
 - `plan-review.threshold` — доля закрытых пунктов чек-листа для статуса `ready`, default `100`. Отдельных агентов у `plan-review` больше нет: проверку целиком делает один субагент.
 - `plan-polish.limit` — максимальное число итераций «проверка + исправление»; default `1`. Отдельного подтверждающего прохода нет: исправление проверяет ревью следующей итерации. Цикл останавливается раньше, если score перестал расти.
 - `plan-execute.mode` — где `eda-plan-execute` выполняет фазы: `subagents` — каждая фаза в отдельном изолированном субагенте с независимой проверкой, `main` — весь план одним контекстом без субагентов, `auto` — выбор по плану; default `auto`. Явный режим в вызове имеет приоритет.

package/lib/install.js

@@ -447,19 +447,23 @@ const DECISION_MODE_CHOICES = [
 const TEST_STRATEGY_CHOICES = [
   {
     value: 'after_each_phase',
-    name: 'Писать и запускать тесты после каждой фазы'
+    name: 'Писать тесты и запускать все проверки после каждой фазы'
+  },
+  {
+    value: 'phase_tests_final_checks',
+    name: 'Писать тесты в фазах, запускать только их, остальные проверки — в конце'
   },
   {
     value: 'tdd_each_phase',
-    name: 'В каждой фазе сначала тесты, затем код'
+    name: 'В каждой фазе сначала тесты, затем код и все проверки фазы'
   },
   {
     value: 'end_of_plan',
-    name: 'Писать тесты в конце плана отдельной фазой'
+    name: 'Писать тесты и запускать все проверки в конце плана'
   },
   {
     value: 'ask_each_time',
-    name: 'Спрашивать стратегию тестов каждый раз'
+    name: 'Спрашивать стратегию тестов и проверок каждый раз'
   }
 ];
 const LOGGING_STRATEGY_CHOICES = [
@@ -782,7 +786,7 @@ export async function askSettings({
     ['explore', 'explore.decisionMode', settings.explore, 'decisionMode', 'Как принимать важные решения в eda-explore?', DECISION_MODE_CHOICES],
     ['plan', 'plan.size', settings.plan, 'size', 'Какой размер плана eda-plan использовать по умолчанию?', PLAN_SIZE_CHOICES],
     ['plan', 'plan.decisionMode', settings.plan, 'decisionMode', 'Как принимать важные решения в eda-plan?', DECISION_MODE_CHOICES],
-    ['plan', 'plan.testStrategy', settings.plan, 'testStrategy', 'Какую стратегию тестов eda-plan использовать по умолчанию?', TEST_STRATEGY_CHOICES],
+    ['plan', 'plan.testStrategy', settings.plan, 'testStrategy', 'Какую стратегию тестов и проверок eda-plan использовать по умолчанию?', TEST_STRATEGY_CHOICES],
     ['plan', 'plan.loggingStrategy', settings.plan, 'loggingStrategy', 'Какую стратегию логирования eda-plan использовать по умолчанию?', LOGGING_STRATEGY_CHOICES],
     ['plan-review', 'planReview.threshold', settings.planReview, 'threshold', 'Какой порог готовности использовать в eda-plan-review?', PLAN_REVIEW_THRESHOLD_CHOICES],
     ['plan-polish', 'planPolish.limit', settings.planPolish, 'limit', 'Сколько итераций «проверка + исправление» разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES],
@@ -1228,7 +1232,7 @@ function migrateSettingsContent(content) {
   transfer(
     'plan.testStrategy',
     plan.test_strategy ?? legacyDefaults.test_strategy,
-    oneOf(['after_each_phase', 'tdd_each_phase', 'end_of_plan', 'ask_each_time']),
+    oneOf(['after_each_phase', 'phase_tests_final_checks', 'tdd_each_phase', 'end_of_plan', 'ask_each_time']),
     value => { settings.plan.testStrategy = value; }
   );
   transfer(
@@ -1472,8 +1476,8 @@ plan:
   # Определяет, как eda-plan принимает существенные решения.
   # autonomous | recommend_and_ask | ask_each_time
   decision_mode: ${settings.plan.decisionMode}
-  # Задаёт стратегию тестов.
-  # after_each_phase | tdd_each_phase | end_of_plan | ask_each_time
+  # Задаёт стратегию тестов и автоматических проверок.
+  # after_each_phase | phase_tests_final_checks | tdd_each_phase | end_of_plan | ask_each_time
   test_strategy: ${settings.plan.testStrategy}
   # Задаёт стратегию логирования.
   # debug_precise | standard | ask_each_time

package/package.json

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

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

@@ -19,14 +19,21 @@ description: 'Создаёт понятный исполнимый план ре
 | `plan.review` | `true`, `false` | включение: `с ревью плана`, `с plan-review`; выключение: `без ревью плана`, `без plan-review` |
 | `plan.size` | `normal`, `short`, `ask_each_time` | `short`; обычный: `обычный план`, `не short` |
 | `plan.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
-| `plan.test_strategy` | `after_each_phase`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов |
+| `plan.test_strategy` | `after_each_phase`, `phase_tests_final_checks`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов и проверок |
 | `plan.logging_strategy` | `debug_precise`, `standard`, `ask_each_time` | явное указание стратегии логирования |
 
 Если итоговое значение `plan.size`, `plan.test_strategy` или `plan.logging_strategy` равно `ask_each_time`, задай блокирующий вопрос, кроме случая, когда пользователь уже выбрал значение в текущем сообщении.
 
-Варианты вопросов: размер плана — `normal` / `short`; тесты — `after_each_phase` / `tdd_each_phase` / `end_of_plan`; логирование — `debug_precise` / `standard`.
+Варианты вопросов: размер плана — `normal` / `short`; тесты и проверки — `after_each_phase` / `phase_tests_final_checks` / `tdd_each_phase` / `end_of_plan`; логирование — `debug_precise` / `standard`.
 
-`test_strategy` обязан менять план: `tdd_each_phase` начинает каждую фазу с тестов, `after_each_phase` добавляет тесты после реализации каждой фазы, `end_of_plan` выносит тесты в отдельную финальную фазу. `logging_strategy` обязан отражаться в алгоритме, фазах и разделе `Логирование`.
+Имя `test_strategy` сохраняется для совместимости, но настройка управляет и написанием тестов, и моментом запуска автоматических проверок. Она обязана менять план:
+
+- `tdd_each_phase` начинает каждую фазу с тестов, затем выполняет реализацию и запускает написанные тесты вместе со всеми применимыми проверками фазы;
+- `after_each_phase` сначала выполняет реализацию, затем добавляет тесты и запускает их вместе со всеми применимыми проверками фазы;
+- `phase_tests_final_checks` добавляет тесты в ту же фазу, что и реализацию; в `Проверке` фазы оставляет только точечный запуск добавленных или изменённых в ней тестов, а полный набор тестов, линтеры, typecheck, static analysis и остальные обязательные проверки переносит в финальную проверку всего плана;
+- `end_of_plan` выносит написание тестов и первый запуск всех автоматических проверок в отдельную финальную фазу; предыдущие фазы подтверждаются только указанными неавтоматическими критериями готовности.
+
+`logging_strategy` обязан отражаться в алгоритме, фазах и разделе `Логирование`.
 
 `без проверок` одновременно устанавливает `plan.review: false` и `plan.strict: false`. `plan.review` и `plan.strict` независимы.
 
@@ -120,7 +127,7 @@ status: <draft | meta-reviewed | reviewed>
 reviewer: <pending | none | claude | codex>
 plan_review: <docs/artifacts/plan-reviews/... | none>
 plan_review_fix: <docs/artifacts/plan-review-fixes/... | none>
-test_strategy: <after_each_phase | tdd_each_phase | end_of_plan>
+test_strategy: <after_each_phase | phase_tests_final_checks | tdd_each_phase | end_of_plan>
 logging_strategy: <debug_precise | standard>
 sources:
   rules: <путь или —>
@@ -146,6 +153,17 @@ sources:
 ### API и внешние контракты
 Если не меняются: `Не затрагивается`. Иначе метод и путь, auth/permissions, request/query/body, response, ошибки и status codes, события, очереди и внешние сервисы.
 
+### Интерфейс и дизайн
+Если интерфейс не меняется: `Не затрагивается`. Иначе опиши состав и организацию затронутых страниц или экранов: основные области и элементы, их расположение, назначение и взаимосвязи. Используй заданные макеты или референсы; если их нет — текущий дизайн проекта. Формат выбирай по содержанию: свободный текст или таблица `Страница | Описание дизайна`.
+
+Не повторяй здесь целевой алгоритм и содержание фаз. Поведение упоминай только тогда, когда без него нельзя понять состав или организацию интерфейса.
+
+### Консольные команды
+Если команды не меняются: `Не затрагивается`. Иначе перечисли точки входа и команды в таблице:
+
+| Команда | Аргументы и опции | Назначение |
+|---|---|---|
+
 ## Фазы выполнения
 
 ### 1. <Название фазы>
@@ -158,8 +176,8 @@ sources:
 Проверка:
 - команда или критерий готовности.
 
-## Тесты
-Стратегия и сценарии по поведению — в одном месте, а не внутри каждой фазы.
+## Тесты и проверки
+Стратегия, сценарии по поведению, фазовые и финальные команды — в одном месте, а не дублируются внутри каждой фазы. В поле `Проверка` фазы остаётся только применимый к ней запуск или критерий согласно `test_strategy`.
 
 ## Логирование
 Стратегия, уровни, обязательные поля и что писать запрещено.
@@ -183,7 +201,7 @@ sources:
 
 Quality gate перед показом на подтверждение, перед сохранением и после каждой включённой проверки:
 
-- есть `Целевой алгоритм` и `Контракты реализации` с обоими подразделами;
+- есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`, `Интерфейс и дизайн` и `Консольные команды`;
 - применимые business-карточки выбраны после определения scope, записаны в `sources.business` и отражены в критериях приёмки;
 - каждый отсутствующий, неполный или расширяемый пункт целевого поведения покрыт отдельной задачей `Дополнить бизнесовые правила` до зависимой реализации; для чисто технических изменений такая задача не добавлена;
 - план строго следует `docs/rules.md` и `docs/arch.md`, а также применимым reference-карточкам; там, где нужно другое поведение, есть отдельный пункт на изменение самого документа до зависимой реализации;

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` с причиной. Размер плана, желание ускорить работу и предположение о нехватке контекста сами по себе не являются блокером или разрешением сменить режим.
 
 ## Главные правила
 
@@ -77,13 +81,24 @@ plan-execute:
 
 ### 3. Прочитать план и проверить фазы
 
-Прочитай `$PLAN_FILE`. Для каждой фазы извлеки цель, что сделать, результат и проверку. До запуска убедись, что у каждой фазы есть проверяемый результат и команда или критерий проверки.
+Прочитай `$PLAN_FILE`, включая `test_strategy`. Для каждой фазы извлеки цель, что сделать, результат и проверку. До запуска убедись, что у каждой фазы есть проверяемый результат и команда или критерий проверки.
+
+`test_strategy` управляет не только написанием тестов, но и фазовыми проверками:
+
+| Стратегия | Фазовый прогон |
+|---|---|
+| `tdd_each_phase` | сначала написать тесты, после реализации запустить их и все применимые проверки фазы |
+| `after_each_phase` | после реализации написать тесты и запустить их и все применимые проверки фазы |
+| `phase_tests_final_checks` | написать тесты в фазе, но запустить только добавленные или изменённые этой фазой тесты; остальные проверки отложить |
+| `end_of_plan` | до финальной фазы использовать только указанные неавтоматические критерии готовности; тесты и автоматические проверки не запускать |
+
+Полный набор тестов и обязательных проверок всё равно запускается в финале. Если план не соответствует своей стратегии, верни его в `eda-plan` или `eda-plan-polish`, а не меняй стратегию при выполнении.
 
 Если фаза не описывает проверяемый результат или её проверку нечем выполнить, не достраивай смысл молча: через `AskUserQuestion` предложи вернуть план в `eda-plan` или `eda-plan-polish`.
 
 ### 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 +130,7 @@ current_phase: <номер>
 
 ### 5. Запускать изолированных субагентов
 
-Весь этап — только для `subagents`. В `main` пропусти его и выполняй фазы сам; переключился на `subagents` — вернись к нему.
+Весь этап — только для `subagents`. В `main` пропусти его и выполняй фазы сам.
 
 В Codex используй `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция или субагенты недоступны, остановись: `blocked: недоступно изолированное выполнение`. Работу основным агентом не делай и CLI-fallback не добавляй.
 
@@ -132,7 +147,7 @@ current_phase: <номер>
 
 Ожидание слота и один технический retry не считаются попыткой исправления фазы и не расходуют её лимит сходимости.
 
-Каждому исполнителю фазы передай: рабочую директорию, `$PLAN_FILE`, номер и полный текст фазы, краткие результаты завершённых фаз, пути к `docs/rules.md`, `docs/arch.md`, `docs/business.md` и `docs/references.md`, ограничения пользователя, критерии проверки фазы и запрет коммитить и менять план и журнал.
+Каждому исполнителю фазы передай: рабочую директорию, `$PLAN_FILE`, номер и полный текст фазы, `test_strategy`, краткие результаты завершённых фаз, пути к `docs/rules.md`, `docs/arch.md`, `docs/business.md` и `docs/references.md`, ограничения пользователя, критерии проверки фазы и запрет коммитить и менять план и журнал. Явно передай разрешённый фазовый прогон из таблицы стратегии; не разрешай запускать отложенные ею проверки досрочно.
 
 Требуй YAML-результат:
 
@@ -169,7 +184,7 @@ questions: [<вопросы или пусто>]
 
 ### 7. Проверять каждую фазу
 
-В `subagents` после `completed` запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, читает только применимые карточки, выполняет все проверки фазы и подтверждает критерии результата.
+В `subagents` после `completed` запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, читает только применимые карточки, выполняет разрешённый стратегией фазовый прогон и подтверждает критерии результата. При `phase_tests_final_checks` он запускает только тесты, добавленные или изменённые в этой фазе. При `end_of_plan` он не запускает автоматические команды и проверяет только указанные неавтоматические критерии готовности.
 
 ```yaml
 status: passed | failed | blocked
@@ -185,13 +200,13 @@ references_read: [<пути или пусто>]
 
 При `failed` передай полный результат исполнителю этой фазы, поручи исправить подтверждённые проблемы и запусти нового проверяющего. Основной агент код не чинит и контекст прежнего проверяющего не переиспользует.
 
-В `main` сам выполни все проверки фазы и сверь результат с критериями плана, а не с собственным впечатлением. Падение исправляй и повторяй проверку заново целиком.
+В `main` сам выполни разрешённый стратегией фазовый прогон и сверь результат с критериями плана, а не с собственным впечатлением. Для `phase_tests_final_checks` запускай только добавленные или изменённые текущей фазой тесты; для `end_of_plan` не запускай автоматические команды до финальной фазы. Падение исправляй и повторяй проверку заново целиком.
 
 При `passed` отметь фазу завершённой и только тогда переходи к следующей.
 
 ### 8. Финальная проверка
 
-После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. В `subagents` это делает отдельный новый субагент: он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения. В `main` тот же полный набор запускает основной агент.
+После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Для `phase_tests_final_checks` и `end_of_plan` это первый полный прогон; он обязан включить созданные по фазам и существующие тесты проекта вместе со всеми отложенными проверками. Для `after_each_phase` и `tdd_each_phase` это итоговый повтор полного набора после интеграции всех фаз. В `subagents` это делает отдельный новый субагент: он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения. В `main` тот же полный набор запускает основной агент.
 
 Падение из-за сделанных изменений сопоставь с фазами и исправь по порядку плана: в `subagents` передай каждую группу исполнителю соответствующей фазы. Затем повтори всю финальную проверку целиком. Чужую или несвязанную поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 
@@ -205,7 +220,7 @@ references_read: [<пути или пусто>]
 
 - В `subagents` самому менять код, тесты, миграции, конфиги и зависимости или самому запускать проверки проекта.
 - В `subagents` дробить фазу между исполнителями, давать одному исполнителю несколько фаз, давать субагентам историю диалога или разрешать менять план и журнал.
-- Выполнять большой или тяжёлый по контексту план в `main`, если режим не задан явно.
+- Самостоятельно менять зафиксированный режим или применять критерии `auto` к `main` из вызова, настроек либо override оркестратора.
 - Запускать следующую фазу до успешной проверки текущей.
 - Додумывать недостающее решение вместо вопроса.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.

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

@@ -42,7 +42,7 @@ Read-only проверка одного плана по списку ниже.
 | 5 | Все существенные решения имеют источник подтверждения: ответ пользователя, research или `autonomous` с причиной |
 | 6 | В плане не осталось решений, которые придётся принимать исполнителю |
 | 7 | Пакеты, библиотеки и сервисы имеют конкретные версии или ссылку на существующий lock |
-| 8 | Есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД` и `API и внешние контракты` |
+| 8 | Есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`, `Интерфейс и дизайн` и `Консольные команды` |
 | 9 | Ни один факт не описан в двух разделах |
 | 10 | В плане нет сигнатур чужих методов, приведений типов, формы классов, внутренних вычислений без контрактного смысла и пересказа кодовых примеров карточек; формулы, задающие обязательное поведение, допустимы |
 | 11 | У каждой фазы есть цель, что сделать, результат и проверка |

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` — запускать при каждом ревью;