@gian-tiaga/eda 3.3.1 → 3.5.0

package/README.md

@@ -51,11 +51,11 @@ eda update-all ~/Code
 | `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 перестаёт расти, останавливается и восстанавливает лучшую версию, а не последнюю. По умолчанию две review-итерации. Кросс-CLI strict не используется | `docs/artifacts/plan-reviews/`, `docs/artifacts/plan-review-fixes/` |
-| `eda-plan-execute` | Управляет выполнением плана по фазам. Каждую фазу целиком выполняет отдельный изолированный субагент: он читает план, правила, архитектуру и только business/reference-карточки затронутого поведения и компонентов. Фазы проходят строго последовательно и принимаются независимыми проверяющими. Основной агент отмечает подтверждённые задачи и ведёт журнал | `docs/artifacts/executions/` |
+| `eda-plan-execute` | Управляет выполнением плана по фазам в режиме `subagents`, `single` или `auto`. В `subagents` каждую фазу целиком выполняет отдельный изолированный субагент: он читает план, правила, архитектуру и только business/reference-карточки затронутого поведения и компонентов. Фазы проходят строго последовательно и принимаются независимыми проверяющими. В `single` весь план по тем же правилам выполняет и проверяет основной агент в одном контексте, а `auto` выбирает режим по плану. Отметки подтверждённых задач и журнал ведёт основной агент | `docs/artifacts/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или плану. Перед правками читает правила, архитектуру и только применимые карточки, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/artifacts/fixes/` |
 | `eda-review` | Оркестрирует отдельные read-only проверки корректности, архитектуры, правил, references, business-правил, плана, качества, тестов, безопасности, производительности, frontend/UI/UX, API, БД, документации и предыдущих ревью. Сохраняет только доказанные дефекты, которые обязательно исправить; косметические и спекулятивные предложения отбрасывает. Любая находка даёт `changes-required`, а чистое ревью — `clean` и 100/100. Без аргументов ревьюит `git diff HEAD` | `docs/artifacts/reviews/` |
 | `eda-fix-by-review` | Применяет все находки из ревью с учётом правил, архитектуры и применимых карточек. Спрашивает только при неоднозначности, конфликте, расширении scope или рискованном действии. В конце ссылается на отчёт прямо в файле ревью | `docs/artifacts/review-fixes/` |
-| `eda-manual-test` | Делает ручную smoke/acceptance-проверку после изменений: основной чеклист строит по выполненной задаче и связанному плану/issue/review/fix-отчёту, затем сверяет фактический diff. Применимая business-карточка может добавить только относящийся к задаче инвариант или сценарий; несвязанные карточки не загружаются. Не правит код, не пишет автотесты и не коммитит | `docs/artifacts/manual-tests/` |
+| `eda-manual-test` | Делает ручную проверку после изменений. По умолчанию проверка полная: разбирает план или другой артефакт по разделам, дополняет его фактическим `git diff HEAD` и закрывает матрицу областей — API, база данных, консольные команды, интерфейс, алгоритмы, фон и интеграции, права и роли, конфигурация, логи, регрессии рядом. Область нельзя закрыть чтением кода или зелёными автотестами; незакрытая область даёт `blocked`. Быстрый smoke включается настройкой `manual-test.depth` или словом в запросе. Применимая business-карточка может добавить только относящийся к задаче инвариант или сценарий. Не правит код, не пишет автотесты и не коммитит | `docs/artifacts/manual-tests/` |
 | `eda-polish` | Оркестрирует доводку изменений: запускает полное `eda-review`, затем `eda-fix-by-review` и повторяет цикл до `clean` и отсутствия находок либо до лимита 5 итераций. Все находки исправляются, score остаётся справочным. Каждый шаг идёт в изолированном нативном субагенте. Не коммитит | `docs/artifacts/reviews/`, `docs/artifacts/review-fixes/` |
 | `eda-send-review` | На `sonnet` / `gpt-5.6-terra` отправляет ревью на GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Без явно указанного типа использует `comment`; `approve` и `request-changes` берёт только из контекста текущего вызова. По настройке может скрыть предыдущие сводки eda-send-review и зарезолвить их inline-треды. По умолчанию шлёт все пункты. Claude-модель закрепляется при установке; Codex-модель хранится как рекомендуемый будущий override | (комментарий в PR) |
 | `eda-commit` | Работает как лёгкий оркестратор одного `haiku` / `gpt-5.6-luna` агента: тот сам собирает git-контекст, делит выбранный состав на логические коммиты, пишет сообщения, точечно коммитит и выполняет явно заданные push/PR/merge-действия. С явным контекстом охватывает указанный состав; без контекста берёт все tracked-изменения и содержательные untracked-файлы, кроме очевидных кэшей и локальных служебных артефактов. В Claude Code сам оркестратор закреплён за `haiku`; в Codex остаётся на активной модели сессии из-за отсутствия per-skill override. При вероятном секрете агент блокируется до индексации затронутой группы. После любого push всегда возвращает ссылку — на существующий PR или на его создание — и спрашивает, создавать ли PR, если его нет. Если продолжение не задано, предлагает применимые варианты | (git, опционально GitHub PR) |
@@ -124,6 +124,8 @@ eda update-all ~/Code
 
 У некоторых скилов есть флаг `strict` — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: `eda-explore strict <тема>`. Также strict можно включить отдельно в `docs/settings.yaml`, например через `explore.strict: true`. У `eda-review` вместо общего режима каждая проверка имеет собственные `mode` и `model`.
 
+У `eda-plan-execute` есть режимы `subagents` / `single` / `auto`. Режим можно разово указать в вызове, например `eda-plan-execute single docs/artifacts/plans/....md`; без него используется `plan-execute.mode` из настроек, а без настроек — `auto`.
+
 У `eda-aim` есть режимы `automatic` / `manual`. В автоматическом основной агент сам отвечает на безопасные рабочие вопросы по рекомендации субагента и фактам проекта, в ручном передаёт их человеку. Режим можно разово указать в вызове; без него используется `aim.mode` из настроек. Точный список новых целей перед записью в `docs/artifacts/aims/` всё равно один раз подтверждает человек.
 
 Скилы, которых нет в таблице ниже, не поддерживают эти флаги. Набор проверок `eda-review` отдельно управляется через `review.agents`.
@@ -135,7 +137,9 @@ 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` / `single` / `auto` | Разово меняет, где выполняются фазы, поверх `plan-execute.mode` | `single` для небольшого плана в одном контексте, `subagents` для большого или тяжёлого |
 | `eda-plan-polish` | `threshold N`, `limit N` | Меняет gate и максимальное число подтверждающих review-итераций | Для доводки ответственных планов перед `eda-plan-execute` |
+| `eda-manual-test` | `full` / `полная проверка`, `smoke` / `быстро` | Разово меняет глубину ручной проверки поверх `manual-test.depth` | `smoke` для короткой правки, `full` — когда нужно закрыть все области после плана |
 
 ---
 
@@ -229,6 +233,18 @@ plan-polish:
   # Максимальное число подтверждающих review-итераций.
   limit: 2
 
+plan-execute:
+  # Где eda-plan-execute выполняет фазы плана.
+  # subagents — каждая фаза в отдельном субагенте, single — весь план одним контекстом, auto — решает по плану.
+  mode: auto
+
+manual-test:
+  # Глубина ручной проверки в eda-manual-test.
+  # full — закрыть все применимые области: API, база, консольные команды, интерфейс, алгоритмы, фон, права, конфигурацию, логи и регрессии рядом.
+  # smoke — только запуск и основной сценарий изменённой области.
+  # full | smoke | ask_each_time
+  depth: full
+
 review:
   # Каждая проверка имеет собственный режим запуска и модели для обеих сред.
   agents:
@@ -377,6 +393,8 @@ discover-automations:
 - `plan.size`, `plan.decision_mode`, `plan.test_strategy`, `plan.logging_strategy` — режим и структура работы `eda-plan`.
 - `plan-review.threshold` — доля закрытых пунктов чек-листа для статуса `ready`, default `100`. Отдельных агентов у `plan-review` больше нет: проверку целиком делает один субагент.
 - `plan-polish.limit` — максимальное число подтверждающих review-итераций; default `2`. Цикл останавливается раньше, если score перестал расти.
+- `plan-execute.mode` — где `eda-plan-execute` выполняет фазы: `subagents` — каждая фаза в отдельном изолированном субагенте с независимой проверкой, `single` — весь план одним контекстом без субагентов, `auto` — выбор по плану; default `auto`. Явный режим в вызове имеет приоритет.
+- `manual-test.depth` — глубина ручной проверки в `eda-manual-test`: `full` — закрыть все применимые области матрицы покрытия, `smoke` — только запуск и основной сценарий изменённой области, `ask_each_time` — спрашивать каждый раз; default `full`. Явная глубина в вызове имеет приоритет.
 - `review.agents.<check>.mode` — запускать проверку всегда, автоматически по контексту или отключить.
 - `review.agents.<check>.model.claude` и `.codex` — модель конкретной проверки в соответствующей среде.
 - `eda-review` не делит находки по обязательности: каждый принятый пункт требует исправления, а предложения без доказанного практического дефекта отбрасываются. Score остаётся экспертной оценкой серьёзности; любая находка блокирует `clean` независимо от score.
@@ -438,7 +456,7 @@ plan-polish = специализированный plan-review ─> plan-review-
 discover-automations может запускаться от review, fix-by-review или fix.
 ```
 
-`eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API/UI перед ревью или коммитом.
+`eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API, базу, консольные команды, интерфейс и алгоритмы перед ревью или коммитом.
 
 Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный порядок и аргументы задаются в `orhestra.steps`. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 

package/lib/install.js

@@ -274,6 +274,12 @@ const DEFAULT_SETTINGS = {
   planPolish: {
     limit: 2
   },
+  planExecute: {
+    mode: 'auto'
+  },
+  manualTest: {
+    depth: 'full'
+  },
   review: {
     agents: DEFAULT_REVIEW_AGENTS
   },
@@ -291,6 +297,8 @@ const SETTINGS_SECTION_NAMES = [
   'plan',
   'plan-review',
   'plan-polish',
+  'plan-execute',
+  'manual-test',
   'review',
   'send-review',
   'discover-automations'
@@ -364,6 +372,20 @@ const PLAN_POLISH_LIMIT_CHOICES = [1, 2, 3].map(value => ({
   value,
   name: `${value} ${value === 1 ? 'итерация' : value < 5 ? 'итерации' : 'итераций'}`
 }));
+const PLAN_EXECUTE_MODE_CHOICES = [
+  {
+    value: 'auto',
+    name: 'Решать по плану: один контекст для простого плана, субагенты для остальных'
+  },
+  {
+    value: 'subagents',
+    name: 'Каждую фазу выполнять отдельным изолированным субагентом'
+  },
+  {
+    value: 'single',
+    name: 'Выполнять весь план одним контекстом без субагентов'
+  }
+];
 const PLAN_SIZE_CHOICES = [
   {
     value: 'normal',
@@ -378,6 +400,20 @@ const PLAN_SIZE_CHOICES = [
     name: 'Спрашивать размер плана каждый раз'
   }
 ];
+const MANUAL_TEST_DEPTH_CHOICES = [
+  {
+    value: 'full',
+    name: 'Полная проверка всех областей: API, база, консоль, интерфейс, алгоритмы'
+  },
+  {
+    value: 'smoke',
+    name: 'Только smoke: запуск и основной сценарий изменённой области'
+  },
+  {
+    value: 'ask_each_time',
+    name: 'Спрашивать глубину проверки каждый раз'
+  }
+];
 const DECISION_MODE_CHOICES = [
   {
     value: 'recommend_and_ask',
@@ -715,7 +751,9 @@ export async function askSettings({
     ['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', 'Сколько review-итераций разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES]
+    ['plan-polish', 'planPolish.limit', settings.planPolish, 'limit', 'Сколько review-итераций разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES],
+    ['plan-execute', 'planExecute.mode', settings.planExecute, 'mode', 'Как eda-plan-execute должен выполнять фазы по умолчанию?', PLAN_EXECUTE_MODE_CHOICES],
+    ['manual-test', 'manualTest.depth', settings.manualTest, 'depth', 'Какую глубину ручной проверки использовать в eda-manual-test по умолчанию?', MANUAL_TEST_DEPTH_CHOICES]
   ];
   for (const [section, key, target, property, message, choices] of scalarPrompts) {
     if (!requestedSections.has(section) || !shouldAsk(key)) continue;
@@ -1149,6 +1187,22 @@ function migrateSettingsContent(content) {
   const planPolish = objectValue(raw['plan-polish']);
   transfer('planPolish.limit', planPolish.limit, positiveInt, value => { settings.planPolish.limit = value; });
 
+  const planExecute = objectValue(raw['plan-execute']);
+  transfer(
+    'planExecute.mode',
+    planExecute.mode,
+    oneOf(['subagents', 'single', 'auto']),
+    value => { settings.planExecute.mode = value; }
+  );
+
+  const manualTest = objectValue(raw['manual-test']);
+  transfer(
+    'manualTest.depth',
+    manualTest.depth,
+    oneOf(['full', 'smoke', 'ask_each_time']),
+    value => { settings.manualTest.depth = value; }
+  );
+
   const review = objectValue(raw.review);
   transferAgentSettings({
     rawAgents: objectValue(review.agents),
@@ -1368,6 +1422,18 @@ plan-polish:
   # Положительное целое число.
   limit: ${settings.planPolish.limit}
 
+plan-execute:
+  # Где eda-plan-execute выполняет фазы плана.
+  # subagents — каждая фаза в отдельном субагенте, single — весь план одним контекстом, auto — решает по плану.
+  mode: ${settings.planExecute.mode}
+
+manual-test:
+  # Глубина ручной проверки в eda-manual-test.
+  # full — закрыть все применимые области: API, база, консольные команды, интерфейс, алгоритмы, фон, права, конфигурацию, логи и регрессии рядом.
+  # smoke — только запуск и основной сценарий изменённой области.
+  # full | smoke | ask_each_time
+  depth: ${settings.manualTest.depth}
+
 review:
   # Каждая проверка имеет собственный режим запуска и модели для обеих сред.
   agents:

package/package.json

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

package/skills/eda-manual-test/SKILL.md

@@ -1,30 +1,50 @@
 ---
 name: eda-manual-test
-description: 'Проводит ручную smoke/acceptance-проверку изменённого API или интерфейса и сохраняет отчёт.'
+description: 'Проводит ручную проверку изменений — API, база, консольные команды, интерфейс и алгоритмы — и сохраняет отчёт.'
 ---
 
 # Скил: Ручное тестирование (eda-manual-test)
 
-Делаешь ручную smoke/acceptance-проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что пользовательский или API-сценарий реально работает: страница открывается, действие проходит, endpoint отвечает, ошибки выглядят ожидаемо. Сохраняешь QA-отчёт. Код не правишь.
+Делаешь ручную проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что всё реально работает: endpoint отвечает, в базе появились нужные записи, команда отрабатывает, страница открывается, алгоритм проходит по всем веткам. Сохраняешь QA-отчёт. Код не правишь.
 
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: URL, endpoint, сценарий, план, ревью, issue, ветку, ограничение по окружению, логин/роль без секретов и прямые указания.
 
-Если входа достаточно, продолжай без вопроса. Если входа нет, построй минимальный smoke-чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+Если входа достаточно, продолжай без вопроса. Если входа нет, построй чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта; глубину это не меняет. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Режим запуска
+
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+
+Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт `full`; настройки старого формата не применяй.
+
+| Настройка | Значения | Аргументы в сообщении |
+|---|---|---|
+| `manual-test.depth` | `full`, `smoke`, `ask_each_time` | `full`, `полная проверка`; `smoke`, `быстро`, `коротко` |
+
+Если итоговое значение `ask_each_time`, задай блокирующий вопрос о глубине, кроме случая, когда пользователь уже выбрал её в текущем сообщении.
+
+| Глубина | Что проверяется |
+|---|---|
+| `full` | все применимые области матрицы покрытия целиком, по каждому пункту артефакта и diff |
+| `smoke` | запуск, основной happy path изменённой области и 1–2 негативных сценария |
+
+`full` — глубина по умолчанию. Отсутствие плана её не снижает: без артефакта области определяются по `git diff HEAD` и всё равно закрываются целиком. Сузить проверку до главного сценария можно только по явному указанию пользователя или настройке. Полнота считается по областям и пунктам, а не по времени и не по числу шагов.
 
 ## Главные правила
 
 1. **Ручная проверка, не разработка.** Не правь код, не пиши и не обновляй автотесты, не меняй конфиги, не коммить и не пушь.
-2. **Smoke по умолчанию.** Проверь запуск, основной happy path изменённой области и 1–2 негативных или edge-сценария, которые естественно следуют из задачи.
-3. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
-4. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
-5. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
-6. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
-7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
-8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
-9. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
-10. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
+2. **В `full` закрываешь каждую область.** У области либо результат фактической проверки, либо явная причина, почему она не затрагивается или заблокирована. Пустых и молча пропущенных областей быть не может.
+3. **Проверяй фактическое поведение.** Чтение кода, зелёный `npm test` и «должно работать по плану» проверкой не считаются. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
+4. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
+5. **Базу проверяй запросами к базе.** Используй psql/mysql/sqlite-клиент, ORM-консоль или проектные скрипты. Проверяй реальные строки, а не ответ API.
+6. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
+7. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
+8. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
+9. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, откат миграций, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
+10. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
+11. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
 
 ## Интерактивные вопросы
 
@@ -36,56 +56,70 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 
 ## Этапы
 
-### 1. Определить цель проверки
-Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix-отчёт или другой артефакт — прочитай его. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
+### 1. Определить цель и глубину
+Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix- или execution-отчёт — прочитай его целиком. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
 
-Определи `$TEST_TARGET`: `api`, `frontend`, `fullstack` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
+Определи глубину по разделу «Режим запуска» и `$TEST_TARGET`: `api`, `frontend`, `fullstack`, `cli` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
-Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, миграции, консольные команды, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
 
-После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки и не расширяй ими smoke-проверку.
+После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки.
 
 Если ожидаемый результат задачи противоречит применимой business-карточке, не выбирай правильный вариант самостоятельно. До неоднозначного сценария покажи конфликт и через `AskUserQuestion` спроси: проверять изменённую задачу как новое правило или сначала пересогласовать карточку через `eda-business`. В неинтерактивном режиме зафиксируй `blocked` с этим вопросом.
 
 Не устанавливай Playwright, браузеры, пакеты, docker images или системные зависимости молча. Если без этого проверка невозможна — спроси через `AskUserQuestion` или зафиксируй `blocked` в неинтерактивном режиме.
 
-### 3. Составить smoke-чеклист
-Составь короткий чеклист:
-- запуск приложения или API;
-- явные acceptance criteria и сценарии выполненной задачи;
-- основной happy path изменённой области;
-- 1–2 негативных или edge-сценария, которые следуют из задачи;
-- для фронта: console errors, network errors и видимые regressions на основной странице;
-- для API: status code, схема/ключевые поля ответа, обработка неверного ввода или прав доступа, если это относится к задаче.
+### 3. Разложить задачу на сценарии
+Если дан план или другой артефакт, разбери его по разделам и переведи каждый пункт в проверяемый сценарий. Ни один раздел не остаётся без сценариев.
 
-Применимая business-карточка может добавить важный инвариант, ожидаемый результат или один релевантный негативный сценарий, который задача не сформулировала явно. Она не заменяет критерии задачи и не требует тестировать всю предметную область. Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
-
-### 4. Запустить окружение
-Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
+| Раздел артефакта | Что из него обязательно проверить |
+|---|---|
+| Задача, критерии готовности | каждый заявленный результат — отдельным сценарием |
+| Целевой алгоритм | каждый путь от входного события до финального состояния, включая ошибочные ветки |
+| Контракты: Данные и БД | каждую таблицу, поле, связь, индекс, unique и миграцию |
+| Контракты: API и внешние контракты | каждый новый и изменённый endpoint, событие, очередь, внешний вызов |
+| Фазы выполнения | `Результат` и `Проверка` каждой фазы |
+| Тесты | сценарии из плана, выполненные руками, а не запуском автотестов |
+| Логирование | что пишется в лог по сценарию и что писать запрещено |
+| Документация и эксплуатация | новые env, миграции, консольные команды, шаги релиза |
+| Принятые решения | видимые последствия решения в работающей системе |
+
+Дополни сценариями из фактического `git diff HEAD`: изменения, которых нет в артефакте, тоже проверяются. Если артефакта нет, весь набор сценариев строится по diff тем же способом — по затронутым endpoints, миграциям, командам, экранам и ветвлениям кода. Применимая business-карточка может добавить важный инвариант или релевантный негативный сценарий. Она не заменяет критерии задачи и не требует тестировать всю предметную область.
+
+### 4. Собрать матрицу покрытия
+Для `full` пройди все области. Каждая получает статус `✓ проверено`, `✗ провалено`, `— не затрагивается` с причиной или `? blocked` с причиной.
+
+| Область | Что проверяется |
+|---|---|
+| API | все новые и затронутые endpoints: успешный ответ и его поля, валидация неверного ввода, права и auth, несуществующая сущность, коды ошибок, обратная совместимость старых клиентов |
+| База данных | миграции применяются без ошибок; схема совпадает с планом (таблицы, колонки, типы, nullable, default, связи, индексы, unique); после сценария появились, обновились и удалились именно те строки с теми значениями; связанные записи и каскады; нет дублей и осиротевших записей; старые данные читаются |
+| Консольные команды | каждая новая и изменённая команда: запуск с аргументами, поведение без аргументов, exit code, вывод, эффект в базе, повторный запуск |
+| Интерфейс | каждый новый и изменённый экран: основной сценарий до результата, состояния загрузки, пустых данных, ошибки и успеха, валидация форм, видимость по ролям, отсутствие console/network errors, вёрстка на desktop и mobile, если менялась |
+| Алгоритмы | сквозной проход по целевому алгоритму: каждая ветка условий, переход состояний, граничные значения, ошибочные пути и откаты |
+| Фон и интеграции | очереди, воркеры, cron, вебхуки, письма и уведомления, события между модулями: задача ставится, выполняется и даёт ожидаемый эффект |
+| Права и роли | что доступ есть у кого положено и его нет у остальных — на API и в интерфейсе |
+| Конфигурация | новые env-переменные и настройки: значение по умолчанию, поведение при отсутствии и при выключенной фиче |
+| Логи и ошибки | по сценарию пишутся ожидаемые записи с нужными полями; в логах и ответах нет секретов и stack traces наружу |
+| Регрессии рядом | соседние сценарии, которые используют изменённый код или таблицы, продолжают работать |
+
+В `smoke` глубоко проверяется только основной сценарий изменённой области; остальные области помечаются `— не проверялось в smoke`.
+
+### 5. Запустить окружение
+Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы, воркеры и базу. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
 
 Фиксируй команды запуска в черновике отчёта. Не заверши свой ответ, пока запущенные тобой процессы, нужные только для проверки, ещё работают.
 
-### 5. Проверить API
-Для API-сценариев выполни реальные запросы. Предпочитай воспроизводимые команды `curl`, но можно использовать Node `fetch` или проектный HTTP-клиент, если так безопаснее.
-
-Проверяй:
-- успешный status code и ключевые поля ответа;
-- корректную ошибку для неверного ввода, отсутствующих прав или несуществующей сущности, если это относится к задаче;
-- отсутствие явных server errors, stack traces и утечек секретов в ответе.
+### 6. Выполнить проверки
+Иди по областям матрицы. Для каждого сценария сохраняй воспроизводимый способ проверки и фактический результат.
 
-Секретные headers и cookies в отчёт не вставляй: пиши `<redacted>`.
+- **API.** Выполняй реальные запросы, предпочитая воспроизводимые команды `curl`. Секретные headers и cookies пиши как `<redacted>`.
+- **База.** После каждого сценария, который меняет данные, смотри в базу запросом и сверяй значения с контрактом. Схему сверяй отдельно от данных. Откат миграции проверяй только по подтверждению пользователя и только если состояние можно восстановить.
+- **Консоль.** Запускай команды в тестовом окружении и проверяй не только вывод, но и эффект.
+- **Фронт.** Открывай страницу в браузере и проверяй фактический UI, а не только DOM-текст. Скриншоты сохраняй, если инструмент это поддерживает и они подтверждают результат или баг: рядом с отчётом или в `docs/artifacts/manual-tests/assets/`.
+- **Алгоритмы.** Для каждой ветки укажи, каким входом ты её вызвал и в каком состоянии система оказалась.
 
-### 6. Проверить фронт
-Для фронтовых сценариев открой страницу в браузере. Если доступен Playwright, используй его для навигации, кликов, ввода и проверок. Если доступен browser plugin или другой инструмент браузерной автоматизации — используй его. Проверяй фактический UI, а не только DOM-текст.
-
-Проверяй:
-- страница загружается без критических console/network errors;
-- основной сценарий пользователя проходит до ожидаемого результата;
-- видимые состояния ошибок, пустых данных или невалидного ввода, если они относятся к задаче;
-- текст и элементы управления не ломаются на очевидном desktop/mobile viewport, если менялась вёрстка.
-
-Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/artifacts/manual-tests/assets/`.
+Если область нельзя проверить, не заменяй её чтением кода: ставь `? blocked` и пиши, чего конкретно не хватает.
 
 ### 7. Сохранить отчёт
 Сохрани отчёт в `docs/artifacts/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
@@ -93,8 +127,9 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
+depth: <full | smoke>
 source: <text | git diff HEAD | docs/artifacts/plans/... | docs/artifacts/reviews/...>
-target: <api | frontend | fullstack | other>
+target: <api | frontend | fullstack | cli | other>
 status: <passed | failed | blocked>
 ---
 
@@ -111,16 +146,34 @@ status: <passed | failed | blocked>
 |---|---|
 | Команды запуска | `<command>` |
 | URL / endpoint | `<url или endpoint>` |
+| База | `<как проверялась>` |
 | Авторизация | `<не нужна | тестовый пользователь | уже настроена | blocked>` |
 
+## Покрытие
+| Область | Статус | Комментарий |
+|---|---|---|
+| API | ✓ / ✗ / — / ? | <что проверено или почему нет> |
+| База данных | | |
+| Консольные команды | | |
+| Интерфейс | | |
+| Алгоритмы | | |
+| Фон и интеграции | | |
+| Права и роли | | |
+| Конфигурация | | |
+| Логи и ошибки | | |
+| Регрессии рядом | | |
+
 ## Чеклист
-| # | Сценарий | Способ проверки | Результат | Заметки |
-|---|----------|-----------------|-----------|---------|
-| 1 | ... | `curl ...` / Playwright / browser | ✓ / ✗ / ? | ... |
+| # | Область | Сценарий | Способ проверки | Результат | Заметки |
+|---|---------|----------|-----------------|-----------|---------|
+| 1 | API | ... | `curl ...` / SQL / Playwright / команда | ✓ / ✗ / ? | ... |
 
 ## Найденные проблемы
 <если нет — «Явных проблем не найдено»; если есть — список с воспроизведением и фактическим/ожидаемым результатом>
 
+## Не проверено
+<области и пункты артефакта, оставшиеся без фактической проверки, с причиной; если таких нет — «нет»>
+
 ## Артефакты
 <ссылки на скриншоты, логи или «Нет»>
 
@@ -128,16 +181,19 @@ status: <passed | failed | blocked>
 <passed / failed / blocked и короткое объяснение относительно выполненной задачи>
 ```
 
-Если найден баг, статус отчёта `failed`. Если проверка невозможна из-за окружения, авторизации, отсутствующих зависимостей или непонятного риска, статус `blocked`.
+`passed` ставится только когда все применимые области закрыты фактической проверкой и проблем нет. Найден баг — `failed`. Есть незакрытая область или проверка невозможна из-за окружения, авторизации, зависимостей или риска — `blocked`, даже если остальное прошло.
 
 ### 8. Финал
-Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, какие сценарии реально проверены, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
+Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, глубина, какие области закрыты и какие нет, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
 - Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/artifacts/manual-tests/`.
 - Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-plan-execute` или отдельной задачи.
+- Сводить проверку по плану к smoke-проходу основного сценария.
+- Закрывать область чтением кода, ссылкой на автотесты или словами «по плану должно работать».
+- Ставить `passed`, пока хотя бы одна применимая область не закрыта фактической проверкой.
 - Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
-- Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.
+- Подменять ручную проверку запуском `npm test` без фактического прохождения сценария.
 - Проверять production или staging с изменением данных без подтверждения пользователя.
 - Сохранять секреты, cookies, токены или passwords в отчёт.
 - Коммитить, пушить, создавать PR или отправлять ревью.

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

@@ -5,24 +5,54 @@ description: 'Выполняет готовый план последовате
 
 # Скил: Управляющий выполнением плана (eda-plan-execute)
 
-Оркестрируй выполнение плана. Сам не пиши код и не запускай проверки проекта: передавай каждую фазу целиком отдельному изолированному субагенту, а её приёмку — отдельному проверяющему. Связывай результаты фаз, обновляй прогресс и журнал.
+Веди выполнение плана: фазы строго по порядку, каждая с проверяемым результатом, прогресс и журнал в актуальном состоянии. Где именно выполняются фазы, задаёт режим.
+
+## Настройки
+
+Прочитай только раздел `plan-execute` из `docs/settings.yaml`, если файл есть. Применяй только `version: 3`.
+
+```yaml
+plan-execute:
+  mode: auto
+```
+
+`plan-execute.mode` принимает `subagents`, `single` или `auto`; при отсутствующем или невалидном значении используй `auto`. Файл настроек не изменяй.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом — главный вход. Разбери тему, путь к файлу, ограничения и прямые указания.
+Текст рядом с вызовом — главный вход. Разбери тему, путь к файлу, ограничения, прямые указания и режим:
+
+- `subagents`, `субагенты`, `по фазам`, `изолированно` → `$MODE=subagents`;
+- `single`, `один`, `одним контекстом`, `без субагентов`, `сам` → `$MODE=single`;
+- `auto`, `авто`, `автоматически` → `$MODE=auto`;
+- без явного режима → `$MODE=plan-execute.mode` из валидных настроек, иначе `$MODE=auto`.
+
+Режим из вызова важнее настройки, настройка важнее умолчания.
 
 Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных планов или есть риск выполнить не тот план.
 
+## Режимы выполнения
+
+| Режим | Кто выполняет фазу | Кто проверяет фазу и финал |
+|---|---|---|
+| `subagents` | отдельный изолированный субагент на каждую фазу | отдельные субагенты-проверяющие |
+| `single` | основной агент подряд в одном контексте | сам основной агент |
+| `auto` | решает по плану до старта: `single` или `subagents` | по выбранному режиму |
+
+`auto` выбирай `single`, только когда весь план реально помещается в один контекст: немного фаз, небольшой объём задач и файлов, одна область кода, нет тяжёлых по контексту фаз вроде крупного рефакторинга, миграции данных или множества карточек. Иначе — `subagents`; при сомнении тоже `subagents`. Решение и его причину запиши в журнал.
+
+В `single` следи за собственным контекстом. Если план оказался тяжелее оценки или контекст заканчивается, переключи оставшиеся фазы на `subagents`, запиши переключение в журнал и продолжи с текущей фазы.
+
 ## Главные правила
 
-1. **Основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты.
-2. **Фазы выполняй строго последовательно.** Не запускай следующую, пока текущая не выполнена и её отдельная проверка не прошла.
-3. **Одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Идентификатор исполнителя сохраняй и продолжай его же для вопросов и исправлений этой фазы.
-4. **Рамку читает исполнитель фазы.** Каждый исполнитель целиком читает план, `docs/rules.md` и `docs/arch.md`. Для поведения своей фазы он читает карточки из `sources.business`; у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки. Для затронутых компонентов так же выбирает технические карточки через `sources.references` или `docs/references.md`. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением. Нерелевантные карточки не загружает.
-5. **Исполнитель не додумывает план.** Если в фазе не хватает решения, он возвращает `needs_input`, а не выбирает сам. Недостающее решение — это вопрос пользователю или возврат в `eda-plan`, но не импровизация в коде.
-6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, `rules.md`, `arch.md` или reference-карточке, исполнитель возвращает `blocked`. Основной агент показывает конфликт и через `AskUserQuestion` спрашивает: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
-7. **Отмечай только подтверждённое.** Фазу закрывай только после `completed` от исполнителя и отдельного `passed` от проверяющего. При последующем опровержении верни отметку в незавершённое состояние.
-8. **Проверки нельзя подавлять.** Не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, добавлять игноры или ослаблять команды и правила. Причину падения исправляет исполнитель фазы, затем отдельный субагент повторяет проверку.
+1. **В `subagents` основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты. В `single` основной агент выполняет фазы и проверки сам и остаётся единственным исполнителем.
+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` основной агент останавливается и спрашивает.
+6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, `rules.md`, `arch.md` или reference-карточке, останови фазу и через `AskUserQuestion` спроси: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
+7. **Отмечай только подтверждённое.** Фазу закрывай только после выполнения и прошедшей проверки: в `subagents` это `completed` от исполнителя и отдельный `passed` от проверяющего, в `single` — пройденные критерии и команды проверки фазы с сохранённым выводом. При последующем опровержении верни отметку в незавершённое состояние.
+8. **Проверки нельзя подавлять.** Не отключай и не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, не добавляй игноры и не ослабляй команды и правила. Сначала исправляется причина падения, затем проверка повторяется.
 9. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
 
 ## Вопросы
@@ -43,7 +73,7 @@ description: 'Выполняет готовый план последовате
 
 Через `AskUserQuestion` предложи текущую ветку, новую ветку от `main`, новую ветку от текущей или worktree от `main`. Если вызывающий оркестратор уже передал подтверждённый выбор, не спрашивай повторно.
 
-Сам git-команды не выполняй: для новой ветки или worktree запусти отдельного субагента подготовки окружения. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. После успешного создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
+В `subagents` git-команды сам не выполняй: для новой ветки или worktree запусти отдельного субагента подготовки окружения; в `single` подготовь окружение сам. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. После успешного создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
 
 ### 3. Прочитать план и проверить фазы
 
@@ -51,7 +81,9 @@ description: 'Выполняет готовый план последовате
 
 Если фаза не описывает проверяемый результат или её проверку нечем выполнить, не достраивай смысл молча: через `AskUserQuestion` предложи вернуть план в `eda-plan` или `eda-plan-polish`.
 
-### 4. Инициализировать прогресс
+### 4. Определить режим и инициализировать прогресс
+
+Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим `single` или `subagents` до первой фазы. Дальше действуй по зафиксированному режиму.
 
 Создай `$EXECUTION_FILE` по пути `docs/artifacts/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. В `$PLAN_FILE` добавь или актуализируй один раздел `## Прогресс выполнения` со ссылкой на журнал и списком фаз.
 
@@ -60,6 +92,7 @@ description: 'Выполняет готовый план последовате
 plan: <путь>
 started: <YYYY-MM-DD HH:MM>
 status: in_progress
+mode: subagents | single
 current_phase: <номер>
 ---
 
@@ -69,8 +102,8 @@ current_phase: <номер>
 | Фаза | Результат | Проверка | Статус |
 |---|---|---|---|
 
-## Запуски субагентов
-| Время | Роль | Фаза | Результат | Файлы | Проверки |
+## Запуски
+| Время | Исполнитель | Фаза | Результат | Файлы | Проверки |
 |---|---|---|---|---|---|
 
 ## Решения и блокеры
@@ -78,10 +111,12 @@ current_phase: <номер>
 ## Финальная проверка
 ```
 
-Основной агент пишет только этот журнал и отметки прогресса в плане. Субагентам явно запрети менять `$PLAN_FILE` и `$EXECUTION_FILE`.
+Журнал и отметки прогресса в плане ведёт только основной агент. В `single` записывай выбор режима с причиной, а в колонке «Исполнитель» — `основной агент`; в `subagents` явно запрети субагентам менять `$PLAN_FILE` и `$EXECUTION_FILE`.
 
 ### 5. Запускать изолированных субагентов
 
+Весь этап — только для `subagents`. В `single` пропусти его и выполняй фазы сам; переключился на `subagents` — вернись к нему.
+
 В Codex используй `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция или субагенты недоступны, остановись: `blocked: недоступно изолированное выполнение`. Работу основным агентом не делай и CLI-fallback не добавляй.
 
 #### Технические остановки субагентов
@@ -121,7 +156,7 @@ questions: [<вопросы или пусто>]
 
 ### 6. Выполнять фазы
 
-Для каждой фазы по порядку:
+В `subagents` для каждой фазы по порядку:
 
 1. Запусти одного нового изолированного исполнителя и сохрани его идентификатор как исполнителя этой фазы.
 2. Проверь YAML-контракт, фактический scope файлов и результаты проверок. Запиши запуск в журнал.
@@ -130,9 +165,11 @@ questions: [<вопросы или пусто>]
 5. `blocked` — останови выполнение. Внешний блокер или изменение scope выноси вопросом; сам его не устраняй.
 6. После `completed` запусти независимую проверку фазы.
 
+В `single` перед первой фазой один раз прочитай план целиком, `docs/rules.md` и `docs/arch.md`, а карточки выбирай по правилу 4 под каждую фазу. Затем для каждой фазы по порядку выполни работу фазы, запиши в журнал сделанное, изменённые файлы и результаты проверок и переходи к проверке фазы. Не хватает решения — спроси пользователя; конфликт с правилами или карточками — останови фазу как `blocked`; та же причина падения дважды подряд без содержательного изменения — остановись: `blocked: выполнение не сходится`.
+
 ### 7. Проверять каждую фазу
 
-После `completed` запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, читает только применимые карточки, выполняет все проверки фазы и подтверждает критерии результата.
+В `subagents` после `completed` запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, читает только применимые карточки, выполняет все проверки фазы и подтверждает критерии результата.
 
 ```yaml
 status: passed | failed | blocked
@@ -146,27 +183,30 @@ business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
 ```
 
-При `failed` передай полный результат исполнителю этой фазы, поручи исправить подтверждённые проблемы и запусти нового проверяющего. Основной агент код не чинит и контекст прежнего проверяющего не переиспользует. При `passed` отметь фазу завершённой и только тогда переходи к следующей.
+При `failed` передай полный результат исполнителю этой фазы, поручи исправить подтверждённые проблемы и запусти нового проверяющего. Основной агент код не чинит и контекст прежнего проверяющего не переиспользует.
+
+В `single` сам выполни все проверки фазы и сверь результат с критериями плана, а не с собственным впечатлением. Падение исправляй и повторяй проверку заново целиком.
+
+При `passed` отметь фазу завершённой и только тогда переходи к следующей.
 
 ### 8. Финальная проверка
 
-После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения.
+После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. В `subagents` это делает отдельный новый субагент: он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения. В `single` тот же полный набор запускает основной агент.
 
-Падение из-за сделанных изменений сопоставь с фазами и передай каждую группу исполнителю соответствующей фазы по порядку плана, затем повтори всю финальную проверку новым субагентом. Чужую или несвязанную поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
+Падение из-за сделанных изменений сопоставь с фазами и исправь по порядку плана: в `subagents` передай каждую группу исполнителю соответствующей фазы. Затем повтори всю финальную проверку целиком. Чужую или несвязанную поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 
 Запиши команды и результаты в `## Финальная проверка`. Только после `passed` поставь `status: done` и время завершения. Если обязательная проверка объективно недоступна, сохрани `status: blocked`, причину и непройденные критерии; выполненным план не объявляй.
 
 ### 9. Финал
 
-Коротко сообщи пути к плану и журналу, завершённые фазы, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
+Коротко сообщи режим выполнения, пути к плану и журналу, завершённые фазы, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
 
-- Самому менять код, тесты, миграции, конфиги, зависимости или проектную документацию.
-- Самому запускать тесты, линтеры, typecheck, сборку, миграции, серверы и другие команды разработки и проверки.
-- Дробить фазу между исполнителями или давать одному исполнителю несколько фаз.
-- Запускать следующую фазу до успешной отдельной проверки текущей.
-- Позволять исполнителю додумывать недостающее решение вместо вопроса.
-- Давать субагентам историю диалога или разрешать менять план и журнал.
+- В `subagents` самому менять код, тесты, миграции, конфиги и зависимости или самому запускать проверки проекта.
+- В `subagents` дробить фазу между исполнителями, давать одному исполнителю несколько фаз, давать субагентам историю диалога или разрешать менять план и журнал.
+- Выполнять большой или тяжёлый по контексту план в `single`, если режим не задан явно.
+- Запускать следующую фазу до успешной проверки текущей.
+- Додумывать недостающее решение вместо вопроса.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.
 - Коммитить, пушить, создавать PR или делать ревью.